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.

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.

Tied in Silk Ropes - A subtler way to infosec

After reading the Infosec Jerk's Problem blog, I wanted to suggest another way of dealing with the constant struggle between infosec and the rest of the organization.   It's a method I've used to great effectiveness in multiple situations and it normally leaves all parties happy, (or at least not unhappy with you).

Lets take an example, department X comes by with a new requirement to open ports between Y and Z.  The standard infosec answer is 'no'.  The normal resolution is "how big an issue is X willing to make this to get what they want"?  Can they push it high enough that they can overwride infosec?

Compassionately, you could listen to their arguements, try to see it from their point of view, maybe consider different design options.  Many times though, they won't want to change the design and even if you understand their view, your view is still what your view was.

I have a different approach. In true Mafia style, I do you a favor; maybe you do me a favor one day.  Rather than make their life harder, request something in return that they don't care about.  In the above example, ask them to install a suite of monitoring equipment.  You didn't tell them 'no'.  You didn't even change their design.  You might even have provided the equipment yourself.  Instead, you simply asked that they return the favor of you allowing them to do what they wanted by them helping you do what you wanted.  It's mutually beneficial.

However, you're going to pick your side of the favor wisely.  Your goal is not to solve this one-off problem but create a change in how business is done.  If you ask EVERY person who wants to open ports to install that monitoring suite, well, that suite has now become standard for boundaries.  If every time someone asks to plug A into B, even temporarily, you request they simply put in a firewall (even if it has almost no rules), eventually, a firewall becomes standard for connecting things.

What about when people ask you to agree to not raising a fuss when they want to do something that causes security risk, (and we're speaking relatively minor)? You say, "yes, that's fine, but I need you to fill out this risk form.  I'll analyze it and accept it."  You've now created a risk acceptance and tracking program.  The next step is to say "Well yes, I'll sign the risk form, but I need to include when you DO plan on patching."  Now you have them generating mitigation plans.  You'll follow with, "Ok, but I want an update when you do mitigate it.  If I don't get one, I'll check up and potentially rescind the acceptance".  Now you have continuious oversight.  Finally, you'll get to the point where you can say, "gee, I don't think this risk is acceptable.  We should elevate."  In effect you've established a risk program without ever having to force fight anyone to get it.

This works for many things.  It can be installing new systems, allowing vulnerabilities to persist, making new connections, opening ports, etc.  You can get all sorts of things out of it:  firewalls, IDSs, policies, procedures, authority, and more.  And the people will love you for doing it.  You'll be tieing the binds of security tight, but you'll be doing it softly and slowly with silk ropes.  In the end the ties that bind will be just as tight and secure as if you'd tried to force them on people, but you'll have done it without having to have a single fight.

When Educating Doesn't Work

I used to sell computers at Circuit City. Their hiring test said I'd be great at it. I wasn't, for one reason: I tried to educate people. I would try to teach them why one computer was different from another, and how certain characteristics were better for one use then another. I'd even leave them with a simple choice: "buy X for gaming, buy Y for business stuff.”

That was too much. It wasn't until much later that I realized they wanted to tell me what they wanted to do, then have me point to a single computer and tell them to buy it. Why did I make this mistake? I'm a highly cerebral intellectual. I want to know about the man behind the curtain. And, erroneously, I assume others do as well.

This is a problem we face in information security today. While less technical people – the sales person at your local mattress firm, say – may not really try and educate, but simply settle for influencing you, we try to educate on the honest belief that educated people will make the right decision. However, that’s not how it works. People buy what they want first, then (maybe) what they think they need second.

What we should do is try to influence them. Our job is to make them want what they need and think it's their idea. This doesn't mean giving them what they ask for. That would be the exact opposite of influencing. Instead, we want to change what they want, in order to align with what is best for them from an infosec standpoint.

The next time you’re trying to get a client or customer to take a certain action, don’t forget to influence. At the end of the day, you may even be able to influence them to want to be educated.  But the first task is to do what is right by them and that will probably require influencing them first.

Weaving the Tools of Infosec Defense Together

I’m very excited to finally be able to talk about a technology that I've been working on for some time. I have figured out how to connect all aspects of defense: architecting and securing systems (I'll call it 'engineering'), gathering intelligence on what attackers are doing, and detecting and responding to incidents (I'll call this 'operations'). But let’s start at the beginning.

I’ve assessed risk for years and it has never felt 'right'. At a fundamental level, I'm not sure we even knew what risk we were assessing. A vulnerability wasn't a risk. A control definitely wasn't a risk. Additionally, nothing quite seemed right when it came to determining risk likelihood. I've seen every approach under the sun. Many were repeatable, but simply obscured analysts’ decisions behind various weights and 'classifications' (like calling a vulnerability exploitable by outsiders or insiders).

I came to realize risk was a path, as I've previously blogged.  Others have come to this conclusion as well, sometimes referring to these paths as kill chains.  I make the path distinction since, as a coworker and Lockheed pointed out, kill chains tend to be a specific number of steps. Attack paths are fairly flexible and arbitrary.  A kill chain is an attack path, but not necessarily vice versa.

The next question becomes how to aggregate these paths.  The Lockheed paper begins to address it, but a much better approach is the use of graph theory!  I won't claim to be the first to use graph theory for this.  Many have, and I intend to publish a research paper giving full credit to all those whose works I built upon.  However, what I am doing is fundamentally different.

By combining attack paths from analysts with graph theory, we now have something that closely resembles how we think about risks happening.  An attacker can do A, then B, then C to cause us consequences.  And if we block B, they still have the option of doing D in it's place.  By using Bayesian math, the combination of risk can be aggregated.  Additionally, risk can be tied to threats and their specific attributes.  (The explanation of this is something that'll have to wait for the research paper.)

Here's where it gets interesting

Once you have aggregated your attack paths, you don't just have a way of assessing risk, you have a representation of your entire Infosec Posture! It not only shows you what your current risk posture is, but also allows you to combine your gathered intelligence in such a way as to see how it influences your risk.  It furthermore allows you to add hypothetical vulnerabilities (which are just likely conditions) as well as adding mitigations and controls (which are unlikely conditions) to see how they affect your posture.  You can also add your operational sensor events (IDS, FW, log files, etc) to see if they match any attack paths, threats, or consequences in your graph. And incident handlers can use it to collect and share information about an incident.

From this single graph, you can manage your entire defensive infosec posture.  While I'm in no way a coder, I've started to write a tool to realize this capability: Moirai.  Named after the Greek Fates – mythological goddesses that wove people's lives – Moirai weaves together the defense of an information system.  I am licensing this tool as open source in the hopes that it will help us bring our defensive tools together.  At its most fundamental level, Moirai operates as a pubsub and RPC server for graphs using autobahn and neo4j.  It does four specific things: 1. It receives state changes to the Infosec Posture stored in a graph.  2. It validates them, fixing them as needed.  3. It stores the changes, and 4. It shares the Infosec Posture, including sharing state changes.  The rules for validating an update to the graph are can be found here.

It does this using the Defensive Construct Exchange Standard.  Because the standard uses graph theory rather than records to send information, it can represent and connect records of any existing type together.  It is my hope that this will allow all defensive tools to share information without the need to support any specific record format.

Currently, Moirai has reached Milestone 1.  This represents basic functionality, but there is still much to do, in functionality, security, and robustness.  DCES has achieved a basic, functional baseline as well.

It is time that we, as defensive security experts, have at our disposal a method for coordinating our network defense activities.  Moirai is the way to do that.

Defensive Construct Exchange Standard 0.3

This is the last update of the Defense Construct Exchange Standard (DCES) before implementation of milestone 1 of Moirai.  You can read more about the previous version 0.1 and version 0.2.

The major changes in this version are:

1. Attribute edges need to be "described by" rather than describes. This will change the direction of the edges in the construct to the standard in version 0.1.  This way edges are not a parent of the node they describe.  This is important for risk calculations. CPTs are based on parents and so edges pointing from attributes to nodes need to have a relationship of "influences" rather than "describes" to make sure CPTs are calculating on the correct edges.
2. Attributes no longer require a "metadata" property.  Instead, the dictionary containing the single {type:value} dictionary will be stored in the "label" of the attributes
3. Event, Condition, and Actor nodes are considered the same node if the have exactly matching labels.
4. Edges are considered the same if they have the same source & target.

The last two are not so much require but should be kept in mind as they influence the inclusion of constructs into the graph.

Defensive Construct Exchange Standard 0.3:

Mandatory Statements:

1. All discrete pieces of information within a construct shall be given an individual node.
2. All nodes within the construct shall have the property "class" of value "attribute".
3. The actual attribute property shall be stored as a JSON object within the node's "label" property.  The object shall have a single {"type":"value"} pair.  All other type:value pares shall be rejected.
4. All nodes shall be linked to a node containing a construct ID generated by the construct originator.  (It is recommended that those receiving constructs into their own graphs generate a local construct ID so as to avoid conflicts within their graph.)
5. The construct ID shall be a child node of all Attributes within the construct.
6. The nodes and edges shall be represented in JSON.  They shall be transmitted in accordance with the JSON format outlined by the gephi graph streaming project (Gephi graph streaming).  In practice, all constructs shall be 'an' (add node) or 'ae' (add edge), with the recipient deciding how to actually handle the information.  All required properties are documented at https://github.com/gdbassett/moirai/blob/dev-ms1/protocol_definitions.txt
7. The DCES event shall have a "dces_version" property.
8. The WAMP standard should be used when the DCES event is transmitted to/from an RPC or pubsub.

Optional Statements to facilitate usage:

1. Attribute nodes within the construct may have their own attributes.  (I.E. A threat construct's location attribute may have a 'classification' attribute.)
2. Individual constructs should be contained in a single JSON message represent a single DCES event.  (I.E. {"an":{1:{...}, 2:{...}, 3:{...}}, "ae":{4:{...}, 5:{...}}, "dces_version":"0.3"} could represent a single construct".  While it is possible to create a construct in the receiving graph with multiple messages, it is unnecessarily complex.
3. The recipient of a DCES event may define it's own response to receipt depending on it's needs. If the sender needs to understand the linkage of the construct in the recipient's attack graph, it is recommended the recipient return the the node ID of the node storing the construct ID in the recipient's graph.
4. "an"s are implicitly anchored to originIDs. (Because the node doesn't exist in the DB graph yet, there is no dbID to anchor to.) If any "an"s are present in the event, any "ae"s in that event are explicitly anchored to originIDs to avoid confusion
5. Event, Condition, and Actor nodes are considered the same node if the have exactly matching labels.
6. Edges are considered the same if they have the same source & target.

Example:

This example, used previosuly has been updated to be a DCES version 0.3 compliant construct transmitted in a single event.  Graphically, it can be represented as:

This produces the following Object which can be dumped to json.  (Please note, as the CPT for the construct ID is quite large, I have left it out.)

{"dces_version":"0.3",

"ae":{"1":{"source":"B","target":"A","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},

"2":{"source":"C","target":"A","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},

"3":{"source":"D","target":"A","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},

"4":{"source":"C","target":"D","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},

"5":{"source":"B","target":"C","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},

"6":{"source":"E","target":"A","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},

"7":{"source":"F","target":"A","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},

"8":{"source":"G","target":"A","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},

"9":{"source":"F","target":"G","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},

"10":{"source":"E","target":"F","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},

"11":{"source":"H","target":"A","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},

"12":{"source":"I","target":"A","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},

"13":{"source":"J","target":"A","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},

"14":{"source":"I","target":"J","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},

"15":{"source":"H","target":"I","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"}},

"an":{"A":{"label":{"id":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"A"}},

"B":{"label":{"url":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"B","index":["C",true,false],"0":[0,1,0],"1":[1,1,0]}},

"C":{"label":{"domain":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"C","index":["D",true,false],"0":[0,1,0],"1":[1,1,0]}},

"D":{"label":{"whois":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"D","index":[true,false],"0":[1,0]}},

"E":{"label":{"dns query":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"E","index":["F",true,false],"0":[0,1,0],"1":[1,1,0]}},

"F":{"label":{"dns record":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"F","index":["G",true,false],"0":[0,1,0],"1":[1,1,0]}},

"G":{"label":{"record type":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"G","index":[true,false],"0":[1,0]}},

"H":{"label":{"dns query":"<value2>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"H","index":["I",true,false],"0":[0,1,0],"1":[1,1,0]}},

"I":{"label":{"dns record":"<value2>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"I","index":["J",true,false],"0":[0,1,0],"1":[1,1,0]}},

"J":{"label":{"record type":"<value2>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"J","index":[true,false],"0":[1,0]}}}}

This version of the DCES standard will be used for Moirai Milestone 1.  For those interested, the following python code can reproduce the CPT for node A.  .

d = {}
d["nodeid"] = "A"
d["index"] = ["B", "C", "D", "E", "F", "G", "H", "I", "J", true, false]
parents = len(d["index"]) - 2
for i in range(0,2**parents):
   k = [int(x) for x in list('{0:0b}'.format(i))]
   for l in range(0, parents - len(k)):
      k.insert(0,0)
   k.append(1)
   k.append(0)
   d[i] = k

A Path to Understanding Risk

Part of the life of an information security professional is assessing risk, however we rarely feel that the likelihood and consequence we give a risk at the end of the day represents our true feelings about the risk.  That is because most of the processes we have for assessing risk are vague approximations of the true context we understand as professionals.  Whether it's an organic approach or an approach such as CVSS, it is usually a system for creating buckets that we try to capture the context of the risk in.  However, it ends up being like trying to set buckets outside to capture all of the rain.  Instead we need a way to capture the entire context of the risk as it exists in our minds.

1. Instead, we should start with what is in our head when we consider the risk.  A Narrative.  The narrative starts with a threat actor and ends when they accomplish their goal, realizing our risk along the way.  The narrative includes events that happen and conditions that exist or occur because of events in the narrative.  An example might be...

A thief wants to steal my dog.  He walks by my house and sees my dog in the window.  He walks up to the front door and rings the door bell.  I'm not home so nobody answers.  He then tries the door nob.  The door was unlocked so he walks in.  He picks up my dog and leaves.  The thief now has my dog and I do not.

In this example we have a threat actor, (the thief), his goal, (steal my dog), the consequence, (I no longer have my dog), multiple actions, (the thief walks by, he rings the doorbell, he walks in, etc), and multiple conditions, (my dog is in my house, I am not, my door is unlocked, etc).

Conditions represent many things.  The thief's goal and the consequence in the example above, (and in general), are conditions.  Mitigations and vulnerabilities are also conditions.  In the example, my door being unlocked is a vulnerable condition.  If I had a security system, that would be a mitigating condition.  This helps tie this approach back to our normal risk assessment process.

2. The next step is to understand the consequences.  I lost my dog, yes, but what was the impact? In the example, the impact is mostly personal.  However, in the real world, the impact should be assessed against the Business Mission.  The impact is likely a loss of:

• Confidentiality
• Integrity
• Availability
• Resources
• Control

Some good questions to ask are:

• Can the Information System's mission still be accomplished?
• How is the mission degraded?
• What are the secondary impacts to mission degradation (political, brand image, confidence, etc)
• Is the mission recoverable?
• What are the resources (cost, schedule, technical, risk) to recovery?
• What happens if the mission is executed with incorrect information?
• Does the loss of information decrease our (or our friends') ability to act?
• Does the threat gaining information decrease our (or our friends) ability to act?
• Does the threat gaining information increase their ability to act?
• What additional control does the threat gain by realizing the risk (even if we do not lose control)?

3. From the narrative, create an attack path.  The attack path is going to include the same actors, conditions and events as above.  We're also going to add another element, an "attribute".  Attributes are characteristics that describe other steps in the attack path.  In our example, the thief has the attribute: "motive" = "wants my dog".  Additionally, the thief having the attribute "skill" = "lock picks" may make it more likely for him to open the door, even if it were locked.  Also, we can capture other, alternate approaches.  If the door was locked, the thief might try a window, the garage door, or a back door.  In our example, the attack path may look something like:

• STEP NUM - STEP NAME - STEP CLASS - LIKELIHOOD - DESCRIPTION

1. - A Thief - Actor - 5 - A normal, everyday thief.
2. - "Motive" = "Wants to steal my dog" - Attribute - 1 - I don't know why anyone would want to steal my dog.
3. - Walks by my house - Event - 3 - Not many thieves walk by my house.
4. - Sees my dog - Event - 1 - My dog is normally asleep on the couch where you can't see him.
5. - Walks up to my door - Event - 5 - Walking up to my door is easy.
6. - Rings the doorbell - Event - 5 - Anyone can ring my doorbell.
7. - Nobody is home - Condition - 2 - My wife is usually at home when I'm not, but there are times when nobody's home.
8. - Nobody answers door - Event - 5 - If no-one's home, of course no-one's going to answer the door.
9. - Tries door nob - Event - 5 - Anyone can turn my doornob
10. - Door's unlocked - Condition - 2 - The house is usually locked when no-ones at home.
11. - Actor walks in - Event - 5 - The actor comes inside my house.  If the door is unlocked, there's nothing stopping him from doing this.
12. - Actor picks up my dog - Event - 4 - My dog is kinda hard to pick up.
13. - Actor leaves - Event - 4 - The actor leaves my house with my dog and without being caught.  Notionally he then walks to wherever he is parked with my dog in his hands.  While not completely likely, it's possible and I doubt anyone would stop him.
14. - Actor has my dog - Condition - 5 - If they took it, they have it.
15. - I don't have my dog - Condition - 5 - If they have my dog, I definitely don't.
16. - "Impact" = "2" - Attribute - 5 - I like my dog, but I can find a new one.  Life could be worse.

Ultimately, you can make the attack path as detailed or as general as you want.  You can have more steps or fewer, more attributes or less, let it branch more or make it very linear.  I assessed likelihood and risk on a 1-5 scale.  You could do 1-3 (low, medium, high), or a percentage.  It really doesn't matter much.  There are ways to calculate a final number from this that are mathematically sound, but, more importantly, you can capture the risk and it's context as it exists in your mind.  You can also see what mitigating conditions and vulnerable conditions effect your risk.  And as you become more adept at it's use, you can combine the attack paths you collect into an attack graph to ultimately help you manage your information security posture.