Monday, July 29, 2013

Cyber Attack Graph Schema (CAGS) 1.0

While the concept of attack graphs has been discussed, once thing that is lacking is a standard definition for an attack graph.  This blog hopes to resolve that by presenting a new standard: the Cyber Attack Graph Schema (CAGS) 1.0
1.    All property names must be lower case
2.    Nodes must have the following properties:
1.    "class": May be "actor", "event", "condition", "attribute"
2.    "cpt": must be a JSON string in the format defined at http://infosecanalytics.blogspot.com/2013/03/conditional-probability-tables-in-json.html
3.    "start": The time the node is created. Time should be in ISO 8601 combined date and time format (e.g. 2013-03-14T16:57Z)
4.    "id": Assigned by database.
3.    Nodes must have property "label".
4.    The "label" property of nodes of "class" "event", "condition", or "actor" will contain a string holding a narrative describing the actor, event, or condition
5.    The "label" property of nodes of "class" "attribute" must contain a JSON formatted string with a single "{'type':'value'}" pair. Type is the type/name of the attribute and value the value.
6.    Nodes of any class MAY have property "comments" providing additional narrative on the node
7.    Nodes of any class MAY have property "finish" providing a finish time for the node. Time should be in ISO 8601 combined date and time format (e.g. 2013-03-14T16:57Z)
8.    Edges must have the following properties:
1.    "source": the id of the source node
2.    "target": the id of the target node
3.    "id": id assigned by the database
4.    "relationship":
1.    Value of "influence" if "source" property "class" is "attribute" and "target" property "class" is "event" or "condition".  Value of "leads to" if "source" property "class" is "event", "threat"
2.    Value of "influence" if "condition" and "target" property "class" is "actor", "event", or "condition"
3.    Value of "described by" if "source" property "class" is "event", "condition", or "actor" and "target" property "class" is "attribute"
4.    Value of "described by" if both "source" and "target" property "class" are "attribute"
5.    "directed": value of "True"
9.    Edges may have a property "confidence" with an integer value from 0 to 100 representing the percent confidence
10.                    Edges must be directed
11.                    Nodes and Edges may have additional properties, however they will not be validated and may be ignored by the attack graph.
12.                    Nodes and Edges missing values may still be accepted if the value can be filled in.


Friday, July 12, 2013

Disincentivizing Delaying Risk Mitigation

There is an ongoing issue in infosec:  the never-ending risk.  This is a risk that infosec has identified but the project would rather not mitigate.  The project cannot refuse to address the risk, but they can do the next best thing: agree to mitigate the risk, but never actually implement the mitigation.

This cycle normally starts with the infosec review and the project agreeing to mitigate the risk, hopefully in a set amount of time.  That time rolls around and infosec conducts a review of the progress in implementing the mitigation.  This is where things start to fall apart.  Rather than answering that they have followed the plan and mitigated the risk, the project indicates that they've made little to no progress.  Infosec has no choice but to accept a new mitgation schedule and meet months later.  Infosec can't spend its valuable resources following the schedule week to week so another period of time passes and nothing has been accomplished.  The cycle continues.

The primary driver of this cycle is that infosec cannot say 'no'.  It can't say no initially (or maybe put its foot down on a few issues which did get fixed) and it gets harder to say 'no' as time passes.  If the risk was acceptable for the last 6 months, it becomes harder and harder to justify to senior leadership why it won't be acceptable for the next 6 months.

There is an option though.  You don't have to say know, you have to say "yes but".  Think of it as saying, "yes, you can do whatever it was that you wanted to do, but only while you hop on one foot while patting your belly, rubbing your head, and singing Yankee Doodle."  In reality, this may be, "yes, you may use FTP, however each file must be encrypted individually and the password snail mailed to the receiver".  The goal is to both reduce risk and disincentivize delaying implementing a real mitigation (such as using SFTP).

An alternate is to decrease the time frame for review.  If the project doesn't know when they will have it mitigated, approve use for only 1 month.  At the renewal, they should be required to provide the mitigation plan.  If they don't know how long it will take to come up with a mitigation plan, give approval for 1 week.  At 1 week they should have a schedule for creating the mitigation plan (effectively a schedule to create a schedule).

This only works if they have to prepare significantly more for a renewal than you do.  There should be assessments, forms, plans, briefing charts, etc that they have to prepare for the renewal and that you only have to read.  The goal is to make renewals more time consuming for them than for you.  That way increasing the number of renewals is burdensome on them and not on you, again disincentivizing delaying a mitigation.

Regardless of which way you go, it must be tied to risk.  If you cannot show that the reason you are requiring the extra work or quicker turns is to help minimize risk, you really are simply generating make-work which will not be tolerated at your level or at upper levels.  Also, you must be absolutely responsive.  You once they decide to mitigate the risk you must help and support their solution so that you do not impede the work.

Ultimately, while it sounds harsh to disincentivize delaying mitigation through additional work, in many cases it, is unfortunately necessary.  Unless the project is benevolent, they will do what they are incentivized to do and most of the time; only infosec is incentivized to mitigate risk before it is realized.  By disincentivising delaying mitigation, you are simply balancing the scales to help ensure a quality product.