Offense and Defense in your Infosec Department

It is now generally accepted that our job as infosec professionals is not to prevent compromise but to defend against it and operate in a compromised environment.  With that understanding the DFIR/infosec operations staff are the front lines of information security.

The operations team could be thought of as a sports team.  They need the right equipment, but nothing takes the place of practice.  And to practice you need a good practice squad.

Most large infosec departments have the staff to do this.  We have staff skilled in evaluating the security of products and tools.  Unfortunately, this body of staff is primarily focused on the acquisition side of infosec.

To fix this, lets switch things up a bit.  We probably already have 3 teams in infosec:

1. Operations - DFIR responsibilities (they'll be the blue team)
2. Engineering - Risk and Compliance responsibilities (they'll be the red team)
3. Architecture - Stategic vision (they'll be the white team)

In this model, operation's primary role is to prevent, identify and remediate incidents.  Their secondary role is to generate high-level security needs and provide them to Architecture for implementation.

Engineering's primary role is to validate that security requirements are appropriate implemented in a product's design and to assess the risk of those not implemented.  Their secondary role, however, is to attack Operations.  Because their skill set should be the ability to identify security vulnerabilities, a measurable amount of their time should be used attacking the internal network.  

In this way, we pit operations against engineering in friendly blue vs red battle.  Both teams benefit from the continuous training and the enterprise information system benefits from the identification of security weaknesses that can be remediated.  If you play both offense and defense on your home network, when attackers come to your turf, they shouldn't stand a chance.

Architecture plays the final role.  Their primary role is to help translate Operations' needs into requirements and then into designs.  They also play the white cell role, providing an unbiased referee for the competition between Engineering and Operations.

In this way, we keep the task of operationally defending the network forefront in everyone's mind.  We also make sure that the security we build is truly derived from operational needs rather than 'gut feelings' about what should be bought.  We merge operations and acquisition into a single process without adding any additional organizations.  And because of it, everyone benefits.

Unflattening a Flat Network – Adventures in Network Segmentation

In October I had the honor of speaking at the Lancope Vision conference about my experience in network segmentation.  I have spent the last few months establishing a program to segment a very large network.  It is based heavily on netflow and algorithmic identification of where enclaves should be.  I have finally cleaned up the slides for publishing.  Please read the notes along with each slide as they will be hard to understand otherwise.

Unflattening a Flat Network – Adventures in Network Segmentation:Slides

(EDIT: Video of the talk can be found at http://vimeo.com/78941693)

Since giving the talk, I have done additional work.  I am currently working on other methods for cluster creation as well as identifying the interactions between clusters to help identify groupings of hosts.  This all also eventually leads to algorithmic profiling of a network, predominantly the legitimate usage.  The profiling algorithms could then easily be run against packet captures of malicious network traffic and new traffic compare to both the legitimate and malicious profiles to identify malice on a network.  This work is still ongoing.

Model the Good With the Bad

When security monitoring appliances were originally envisioned, it was believed that the purpose was to "visualize risk" as Davi Ottenheimer (@daviottenheimer) put it.  However, for all of the fancy visualizations, the most useful part of a Security Information and Event Monitor (SIEM) is the list of correlated events.

That has lead us to realize the real benefit is in being able to prioritize potential malice on the network for investiagtion and identify data correlated with the potential malice.  We can see this in the rise of Splunk as a SIEM.  Now many SIEM producers are working toward this approach.

The next logical step is to develop models for malicious activity to help identify attackers in the massive amounts number of observations available.  But as we go forward with this approach, we need to not lose sight of the importance of modeling legitimate access as well.  

If we only model malice, the question we have to ask about any given observation of the network is "Does this observation match the model of malice?"  As a binary question, this is very hard to answer.  It will be very rare that something exactly matches the model.  If we don't have an exact match, it becomes a fairly arbitrary question as to whether the partial match is malicious or not.

However, if you model legitimate use along with malicious use, the question changes.  Now you can ask, "Does this observation match the model of malice more than the model of legitimate use?"  This is a much easier question to answer and provides real comparisons.  It also lets you monitor the hosts in an observation to watch for movement in the observation.  Over multiple observations you should be able to identify a host who's observations trend away from legitimate use towards malicious use.

Ultimately, the availability of innumerable observations of our network is opening up new options for   detection of malice on the network. Whether machine learning, subjective, or other approaches are used for modeling activity, they will all be more effective if we model not just the malicious activity, but the legitimate use as well.

Derbycon

I had a great time talking about graph theory and infosec at Derbycon 3.0.  Derbycon is an incredible gathering and I am honored to have been a part of it.  Other than a few technical glitches, the presentation went great (even the demo worked) and the room was packed.  If you weren't able to make it, you can either watch the video when it's posted or, if there's enough interest, I'll see if I can give it at another conference.  I'd love to have a 50 minute time slot to give the talk so I can give a bit more love to each of the slides.  If you want the charts or any of the links from my presentation, you can see them here.  Again, I'm so thankful to have both attended and spoke at Derbycon.  Thank you to everyone who's taken the time to speak with me here.  I'll see you at ISSA, Skydogcon, or BsidesNash!

UPDATE: If you want watch my derbycon talk, you see it on: irongeek.com.

UPDATE: You can also listen to my first podcast with Rafal Los at: his podcast.

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.

Defensive Construct Exchange Standard .2

Previously I laid out the need for a graph-based standard to exchange information (here).  After working with Defensive Construct Exchange Standard (DCES) events in my personal projects I want to provide some additional refinement of the standard.  If you want to read they why, read the last post.

As a primer, graphs are made up of nodes and edges.  Nodes are the circles.  Edges are lines that connect them.  All have other names, but we'll use nodes, edges, and graphs for now.  Nodes and edges can have properties, just like properties attached to an object in programming.  DCES events are constructs from other tools.  Where in another tool, the construct may have been a record in a table in a database, the DCES event represents it as a small graph in a JSON compatible format.

Defensive Construct Exchange Standard .2:

1. All discrete pieces of information within a construct will be given an individual node.  All nodes within the construct have the property "class" of value "attribute".
2. The actual attribute property will be stored as a JSON object within the node's "metadata" attribute.  The object will have a single {"type":"value"} pair.  All others shall be rejected.
3. All nodes will be linked to a node containing a construct ID generated by the construct originator.  (It will be recommended that those receiving constructs into their own graphs generate a local construct ID so as to avoid conflicts within their graph.)
4. The construct ID will be a parent node of all Attributes within the construct.
5. The nodes and edges will 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
6. Attribute nodes within the construct may have their own attributes.  (I.E. A threat construct's location attribute may have a 'classification' attribute.)
7. 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.2"} could represent a single construct"
8. 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 receipient's attack graph, it is recommended the recipient return the the node ID of the node storing the construct ID in the receipient's graph.
9. The WAMP standard should be used when the DCES event is transmitted to/from an RPC or pubsub.
10. The DCES event shall have a "dces_version" property.
11. "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. If an "ae" needs to be referenced to a dbID, add it as a separate event.

Example:

This example from the previous post has been updated to present version .2 of the standard.  Graphically, it looks like this:

Parsed into JSON with all properties included, it looks like this:

{"dces_version":"0.2",
"ae":{"1":{"source":"A","target":"B","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
"2":{"source":"A","target":"C","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
"3":{"source":"A","target":"D","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
"4":{"source":"D","target":"C","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
"5":{"source":"C","target":"B","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
"6":{"source":"A","target":"E","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
"7":{"source":"A","target":"F","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
"8":{"source":"A","target":"G","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
"9":{"source":"G","target":"F","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
"10":{"source":"F","target":"E","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
"11":{"source":"A","target":"H","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
"12":{"source":"A","target":"I","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
"13":{"source":"A","target":"J","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
"14":{"source":"J","target":"I","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
"15":{"source":"I","target":"H","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"}},
"an":{"A":{"label":"Construct From X","class":"attribute","metadata":{"id":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"A","index":[true,false],"0":[1,0]}},
"B":{"label":"url","class":"attribute","metadata":{"url":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"B","index":["A","C",true,false],"0":[0,0,0,1],"1":[0,0,0,1],"2":[0,0,0,1],"3":[1,0,0,0]}},
"C":{"label":"domain","class":"attribute","metadata":{"domain":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"C","index":["A","D",true,false],"0":[0,0,0,1],"1":[0,0,0,1],"2":[0,0,0,1],"3":[1,0,0,0]}},
"D":{"label":"whois","class":"attribute","metadata":{"whois":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"D","index":["A",true,false],"0":[0,1],"1":[1,0]}},
"E":{"label":"dns query","class":"attribute","metadata":{"dns query":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"E","index":["A","F",true,false],"0":[0,0,0,1],"1":[0,0,0,1],"2":[0,0,0,1],"3":[1,0,0,0]}},
"F":{"label":"dns record","class":"attribute","metadata":{"dns record":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"F","index":["A","G",true,false],"0":[0,0,0,1],"1":[0,0,0,1],"2":[0,0,0,1],"3":[1,0,0,0]}},
"G":{"label":"dns record type","class":"attribute","metadata":{"record type":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"G","index":["A",true,false],"0":[0,1],"1":[1,0]}},
"H":{"label":"dns query","class":"attribute","metadata":{"dns query":"<value2>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"H","index":["A","I",true,false],"0":[0,0,0,1],"1":[0,0,0,1],"2":[0,0,0,1],"3":[1,0,0,0]}},
"I":{"label":"dns record","class":"attribute","metadata":{"dns record":"<value2>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"I","index":["A","J",true,false],"0":[0,0,0,1],"1":[0,0,0,1],"2":[0,0,0,1],"3":[1,0,0,0]}},
"J":{"label":"dns record type","class":"attribute","metadata":{"record type":"<value2>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"J","index":["A",true,false],"0":[0,1],"1":[1,0]}}}}

However, in practicality, the receiving graph will probably add much of the information.  For edges, "relationship", "directed", and "start" can all be added by the receiver.  For nodes, "class", "start", and "cpt" can be added by the receiver greatly simplifying the sender's job.

Ultimately, this standard will continue to evolve slowly as it is put into use.  While it is another new standard in a sea of standards, it is truly unique and offers clear benefits.

Conditional Probability Tables in JSON

I have found myself in need of a JSON format to transmit and process Bayesian Conditional Probability Tables (CPTs).  While there are a few XML formats, none seem to be both simple and effective.  As such, I propose the following standard, (with the intent of using it in my future projects):

• The CPT will be inclosed in a javascript object or python dictionary when not in string format.
• One item labeled "nodeid" with the node ID of the node the CPT represents. (as booleans are acceptable values in JSON, if the CPT has only states true and false, which it should, they may be recorded as such rather than as strings)
• One item labeled "index" with an array of the node IDs of parents of the represented node followed by the CPT states.
• 2^p (where p = # of parents) arrays representing the states of the CPT with a label of the base 10 representation of the state (as a string)
• The CPT may have a "reviewed" item of type "bool" representing whether the CPT has been manually reviewed.  (Set it to "false" if the CPT was auto-generated and "true" if someone manually updated/reviewed the CPT.)

For example:

{
"nodeid":4,
"index":[1,2,3,true,false],
"0":[0,0,0,0,1],
"1":[0,0,1,0.1,0.9],
"2":[0,1,0,0.1,0.9],
"3":[0,1,1,0.1,0.9],
"4":[1,0,0,0.1,0.9],
"5":[1,0,1,0.1,0.9],
"6":[1,1,0,0.1,0.9],
"7":[1,1,1,0.9,0.1]
}

Capture Your Thoughts

This is not really a security blog though many security people will appreciate it.  This is for all the people who have good ideas; all the people who think "you know, this would work better if ..."; all the people who can't help but think about solving every problem they hear:

CAPTURE YOUR THOUGHTS

There are very few things which can not be created w/ time & money.  Thoughts and ideas are one of them.  No matter how much money you spend, it will not make the award winning idea appear.  No matter how long you wait, you will not simply outlast the idea.  It will not get tired of being hidden and jump into your mind (or the mind of another).  But once it's there, it is the most precious commodity in the world.  It has real value. And you will lose it if you don't do something about it.

The first step is to have the facilities to capture it.  Do you tell yourself you'll just remember it later?  You won't.  Whether you always carry pen and paper, have a phone with something like evernote or springpad, or even twitter, make sure you have something with you.  If there's some place you are particularly creative (hiking, in the shower, or right before bed), make SURE you have something there.  I especially like aquanotes!

The second is to commit to writing it down.  It's very easy to tell yourself you'll do it later.  Or to try and file it in your head for when you really need it.  Don't.  You might as well be pouring a Duval down the drain.  You're wasting something of value.  Even if you aren't going to use it right then, write it down.  Tag it with some metadata.  Capture it!

You may never use your ideas.  You may never tell anyone about them. You may forget you even had them.  But when it comes time to solve problems, you'll always have them and the world will be better because of it!

Fault Tolerance

Fault tolerance is "the property that enables a system (often computer-based) to continue operating properly in the event of the failure of (or one or more faults within) some of its components. If its operating quality decreases at all, the decrease is proportional to the severity of the failure..." (1)

Fault tolerance is integral to systems engineering of critical systems.The assumption is that systems will fail and that the impacts of those failures must be controlled.  An example approach would be to mandate that a system be two fault tolerant.  This would then drive the design of three inhibits, any one of which could prevent the failure of the system.  For a physical system, the failure may be physical failure.  For an information system, the failure will likely be loss of confidentiality, integrity, or availability of critical data or a critical business process.

Fault tolerance can and should be applied to infosec as well.  When we plan our defenses, we should assume that some defenses will fail to mitigate the risks they were designed to prevent.  We should assume that some vulnerable conditions will be taken advantage of.  To plan infosec inhibits, we must understand the attack path between the causes of our risk (likely a threat) and where the consequences are realized.  It is along these paths that we can then document inhibits.  Whether it be a firewall, code whitelisting, requiring a written form before receiving privileges, or detecting and responding to threats before consequences are realized, we can capture those along the attack path.  Currently we refer to this as 'defense in depth'.  We all have a general understanding of what it means, but the above approach provides a concrete and quantifiable method for implementing it.

A few months ago there was a significant discussion on whether pen test teams should have a 'zero day' card they could use during a pen test.  What this is really asking is, "Should we test whether the system's backup defenses can be relied upon in case of a failure of primary defenses?"  Or, in other words, "Is the system fault tolerant?" The answer is we should absolutely include a 'zero day' card.  Part of any pen test should be to articulate which defenses, inhibits, or mitigating conditions (whatever you call them) failed.  However, it a system is supposed to implement 'defense in depth', then a 'zero day' card allows us to test that assertion by simulating the failure to see how well the system's defenses handle a failure.  The documentation simply needs to be able to articulate that a failure was simulated to test the fault tolerance of the system.

Ultimately, we should plan for our information systems to be fault tolerant, even under purposeful information security attack.  One fault tolerant, two fault tolerant, three fault tolerant... Regardless the standard set, not planning for fault tolerance is assuming the system's defenses will function perfectly.  An inherently flawed assumption.

The Inside Liar

 A significant topic for risk management these days is the insider threat.  While it is accepted that the insider is the most likely threat actor, we have very little ability to deal with the insider threat.  We generally treat them as an exterior threat:  we look for their malicious actions and consequences.  Whether it be sabotage or the loss of an organization's protected data, we see the results of the threat's actions and then attempt to find the root cause of what happened, hopefully associated with a threat actor (be it insider or exterior threat).  However this is extremely hard.  The complexity of our information systems provides ample space to hide malice.

There is another way:  FIND THE LIE
If you ever watch an episode of COPS, after they have the situation under control, they break up the parties and ask a simple question, "So what happened here?"  The reason is that, once they have the statements of the various parties, their job changes.  They are no longer trying to find 'root cause', they are trying to figure out who is lying.  When they find the liar, they've found the threat.

This offers a unique way for us to find insider threats.  Rather than look for the consequences of their actions, look for the lies.  From the second they get to the door to the minute they leave we expect our staff to assert information.  They assert that they have a legitimate badge and that the badge represents them.  They assert that they have a legitimate account on our information systems.  They assert that they have a legitimate reason to access information through access forms and user agreements.

To realize a consequence, our threat must lie.  Whether it's about why they are accessing information, why they are using a system, or why they are entering an area, they must lie.  Those lies provide us an opportunity to detect our insiders.  By processing the wealth of information we have on our users, we can look not for malicious actions and consequences, but instead for the lies that precede them.  While threats will actively attempt to cover up their their malicious actions and consequences, they will continuously generate more and more lies as they do so providing us additional opportunities to detect them.

It is time we focused our defensive efforts where we have the advantage and where our attackers do not.  While threats may have the advantage when it comes to hiding their malicious actions within the vast complexity of our information systems, a lie begets a lie.  And a lie has short legs.

Infosec Management Is The Problem

I regularly hear keynotes, presentations, and press releases from industry and, in particular, the government, about how there are simply not enough information security professionals to do the jobs available.  They seem to imply that what we need is a larger pool of information security professionals.  I think this is patently untrue.

The unavailability of infosec professionals is a manufactured shortage.  It's controlled by many factors: specialization within information security, required certifications, fragmented compliance standards, required software qualifications, clearances, and job locations to name a few.  Infosec, cybersec, or whatever you want to call it is one of the coolest yet most accessible STEM jobs available.  There is a huge body of programmers, systems administrators, and technology professionals who would gladly work in infosec.  No, what we have is a management problem.

Management Problem 1:  Who we will hire.
If you are CYBERCOM, you want 4,000 qualified cyber security professionals.  Except you want them in the Washington D.C. area with a TS/SCI clearance.  If you are DHS, you still want them with a clearance as well as an arbitrary certification.  If you are a business, you want them with broad infosec knowledge, experience on the tools you've bought, certification in your area of specialty, and experience in your specific compliance regimen.  The frank fact is that deep experience is somewhat mutually exclusive with specialization in your business area.  As anyone gains experience, they're going to have it mostly in one technical area (whether it be IDS-firewall-SEIM management, pen-testing, systems administration, etc) as well as one field of application (military, ICS, health care, payment, etc).  They will know about the other areas, but not be experienced in them.  They will also be older, which means they're more likely to have a family, which means they likely need to live near the business.

All of this adds up to restricting the pool of 'qualified' applications unnecessarily.  The person who understands NIST compliance will pick up PCI DSS compliance fairly quickly.  The person who can use Splunk will understand IBM Tivoli.  If the person can do the job, they will be able to gain whatever certification is necessary.

Alternately, an organization could simply hire out of the body of skilled programmers and systems administrators and plan to train them in security.  With some minor planning, this will provide much better employees anyway as you can ensure their skill set and most will enjoy the opportunity to improve their skills.  Frankly, the industry moves so fast that you're going to be continuously training your infosec professionals anyway.  Someone who has simply been the specialist in their area for years without continuous education is likely just as ready to take the job as a newcomer to infosec, regardless of what their resume says.  What you really get with an experienced employee is maturity and acclimation to the business environment.

Management Problem 2: Getting them.
First, if you happened to have found the perfect person, they know it too.  They will expect to be very well paid (regardless of how mundane the actual job is).  Additionally, if the job description says you wanted an infosec deity yet your plan is to have them write firewall rules all day, they might not be amused.  If you hire highly technical, highly skilled people, give them a broad, highly technical job.  Give the firewall rule writing to an intern with a reference manual. Also, be mindful of your location.  Do you really need the person on sight or would one week a month work?  Most people either love or hate the urban environments of the coast.  Finally, if you're the government, don't require clearances for everyone.  There's a large portion of the infosec community who doesn't want to have a clearance.  They are good, honest, professionals.  They just don't want the obligations and hassle associated with a clearance.  Additionally, be leaving defensive work as unclassified as possible, you make it available to industry who desperately needs it.


Management Problem 3: Keeping them.
So you gave a bunch of money to a rock star infosec professional.  Or maybe you hired a young gun to become one of your infosec gurus.  Like many things in life, they won't stay or be productive unless they are treated right.  The very first step is to figure out what type of person they are.  (Employers should have figured this out before they hired, but it can take some time.)  Some people enjoy 'turning the crank'. They enjoy doing a somewhat repeatable job that has clear bounds.  If that's the type of infosec professional you hired, best not to ask them to architect your infosec defense.  Put them on change request review.  Alternately, if they are a creative self-starter, asking them to predominantly push windows patches may not provide them a fulfilling work life.  Regardless, most infosec professionals have some ideas about how things could be done better.  listen and act on them!  Clearly the status quo is not good enough.  Implicitly that means new ideas will be required to get an acceptable infosec posture.

Second, provide a career, not just a job.  Currently, infosec is about desperately needing to fill some niche in an organizations security team.  This simply makes for pigeon-holed, unfulfilled, employees.  The wealth of infosec training is absolutely necessary to help employees grow in their career (as well as simply maintain their proficiency).   Additionally, there is a need to provide a career progression.  The guy watching the SEIM at night should know where he will be promoted next if he does well. There should be tractability from his position to CISO with a list of necessary skills to move to the next level.  Finally, as stated above, give your employees a chance to have their ideas assessed and supported.  You hired them to solve problems.  Listen to the solutions they provide.  When you don't listen, people leave or simply give their ideas to someone else, (most likely github).

In Conclusion.
Any organization should be able to meet their security needs.  They won't do it by hiring the perfect infosec professionals, but hiring an appropriate mix of creative thinkers and skilled crank turners, preparing them for the work the organization needs done, and then providing them rewards and career growth for accomplishing it.  Until we realize infosec staffing is a management problem and not a labor force one, our information security will continue to lag.

Epilogue.
I do want to point out that most of these are not specific to infosec.  Any seasoned manager will notice that these are general management concepts.  They apply to almost any skilled labor force.  That said, I think the mysticism behind computer security has caused us to go blind on infosec management.  Organizations believe infosec is a type of voodoo that only an appropriate witch doctor can wield.  Consequently, organizations forget everything they know about management and instead hand the entire operation (management and all) over to whoever their current chosen witch doctor is.  Instead they should treat it as any other skilled profession.  Good management will lead to good recruiting.  No voodoo necessary.

Defensive Construct Exchange Standard

It has come time to provide a standard for the transmission of information between defensive tools.  I understand that this is not a unique endeavor, however all attempts to this point have been limited by a single approach, a set of attributes a construct must or should have.

Why do we need something else?  First, this is not a new SIEM.  This is not Arcsight, it's not Splunk, it's not CIF or ELSA.  This is not an information structure.  It's not STIX, VERIS, or Mandiant IOCs.  If anything, it's similar to TAXII or IDMEF.  However all of these approaches (and the many other existing approaches) have a primary flaw: they have structure.  The fundamental issues it that no matter what tool we use, it will collect different data.  We will have similar fields (URLs, IPs, etc) tool to tool, but each provides a slightly different construct with slightly different fields associated with each construct.  This limits all but the most general indexing tools (such as Splunk or ELSA) from importing data without an importer designed specifically for that data (such as an Arcsight connector).

Also, basically all tools (other than Paterva's Maltego) take a database approach to storing data.  While this still allows searching data to match specific patterns (such as IP address), it is less efficient as linkages are implied only by the existence of the pattern in a row with other data.  Passing data as records may hide linkages that could otherwise be uncovered.

How is this different?  In the Defensive Construct Exchange Standard (DCES), we see constructs as a small graph (in the graph theory sense).  All the fields in the construct are represented as nodes and the nodes are linked with edges (rather than with a predefined construct or record format as in most other tools).  See the example below for a visual representation.  Because of this, sending parties and tools may provide any set or subset of fields, whether it be ones defined in STIX, CybOX, IDMEF, Unified2, or one specific to their needs.  Receiving parties may easily discard or replace portions of the format that are unimportant to them while adding their own information to the construct.  I'll detail some of the uses of this approach below.

Whats the standard?  Initially, the standard is as follows.  I recognize that this is a very early approach and that working with tool builders, vendors, and stakeholders will be necessary to fully realize this standard:

1. All discrete pieces of information within a construct will be given an individual node (in the graph theory sense).  All nodes within the construct are a type of Attribute.  The actual attribute Attribute will be stored as a tuple within the node's "Metadata" attribute.  
2. All nodes will be linked to a node containing a construct ID generated by the construct originator.  (It will be recommended that those linking constructs into their own graphs generate a local construct ID so as to avoid conflicts within their graph.)
3. The construct ID will be a child node of all Attributes within the construct.
4. The nodes and edges will be represented in JSON.  They will be transmitted in accordance with the JSON format outlined by the @gephi graph streaming project (Gephi graph streaming).  In practice, all constructs should be transmittable as a grouping of 'add node' and 'add edge' messages, with the recipient deciding how to actually handle the information.
5. Attributes within the construct may have their own Attributes.  (I.E. A threat construct's location Attribute may have a 'confidence' Attribute.  Also, Attributes within the construct may have a child attribute representing a Classification such as "company proprietary", "PII", etc.)  (Note this is less of a rule of the standard as an explicit flexibility.)

What a great idea gabe!  Can we see an example?  The following construct is used as an example in the STIX format.  In the STIX example, it represents a link within a phishing email.  Using our new format, it could be visually represented as:

This would then be represented in JSON as:

{"an":{"A":{"label":"Construct From X","Class":"Attribute","Metadata":{"ID":<value>}}}}\r

{"ae":{"1":{"source":"A","target":"B","directed":true}}}

{"ae":{"2":{"source":"A","target":"C","directed":true}}}

{"ae":{"3":{"source":"A","target":"D","directed":true}}}

{"ae":{"4":{"source":"D","target":"C","directed":true}}}

{"ae":{"5":{"source":"C","target":"B","directed":true}}}

{"ae":{"6":{"source":"A","target":"E","directed":true}}}

{"ae":{"7":{"source":"A","target":"F","directed":true}}}

{"ae":{"8":{"source":"A","target":"G","directed":true}}}

{"ae":{"9":{"source":"G","target":"F","directed":true}}}

{"ae":{"10":{"source":"F","target":"E","directed":true}}}

{"ae":{"11":{"source":"A","target":"H","directed":true}}}

{"ae":{"12":{"source":"A","target":"I","directed":true}}}

{"ae":{"13":{"source":"A","target":"J","directed":true}}}

{"ae":{"14":{"source":"J","target":"I","directed":true}}}

{"ae":{"15":{"source":"I","target":"H","directed":true}}}

{"an":{"B":{"label":"URL","Class":"Attribute","Metadata":{"URL":<value>}}}}

{"an":{"C":{"label":"DOMAIN","Class":"Attribute","Metadata":{"DOMAIN":<value>}}}}

{"an":{"D":{"label":"WHOIS","Class":"Attribute","Metadata":{"WHOIS":<value>}}}}

{"an":{"E":{"label":"DNS Query","Class":"Attribute","Metadata":{"DNS Query":<value>}}}}

{"an":{"F":{"label":"DNS Record","Class":"Attribute","Metadata":{"DNS Record":<value>}}}}

{"an":{"G":{"label":"DNS Record Type","Class":"Attribute","Metadata":{"Record Type":<value>}}}}

{"an":{"H":{"label":"DNS Query","Class":"Attribute","Metadata":{"DNS Query":<value2>}}}}

{"an":{"I":{"label":"DNS Record","Class":"Attribute","Metadata":{"DNS Record":<value2>}}}}

{"an":{"J":{"label":"DNS Record Type","Class":"Attribute","Metadata":{"Record Type":<value2>}}}}

How will this approach be used?  In the most basic sense, two tools or groups exchanging information can simply use this to exchange standard formats (such as an IDMEF message).  Alternately, it could be easily databased by tools such as Splunk or ELSA, however neither of these approaches makes use of the strength of the format and instead simply provide backwards compatibility with previous approaches and workflows.

A better use would be to maintain threat and event data in a graph.  Graphs can be stored in memory, in a standard RDB, in a graph database or in any of a number of formats.  When a DCES construct arrives at the receiving tool, it will likely parse the information, drop information it is uninterested in, and add information (such as a local ID) that it finds useful.  From there the construct can be stored, linked to the rest of the graph (based on common information such as a common IP, alert ID, or any information that is present in both the construct and the graph.  This linkage may be permanent or temporary to allow searching of the graph for other related information.  This is similar to adding information in a graph in Maltego.  

Tool wise, the clear benefit is that once a single DCES handler has been defined, there is no need to adjust it based on different construct formats which it might receive.  Therefore a tool or organization can share and receive a much larger and more diverse set of information.  From an operational standpoint this allows more robust collection and definition of threat actor (and non-threat actor) information.  It also allows new approaches to determining the reputation of an event, (i.e. is it a false positive or is it linked to other suspicious behavior).

We're on the cusp of mounting an effective information security defense and putting all the information our threats reveal about themselves to use.  To do that though, we must not just be able to tune big SIEMS to accept a specific set of information, but must be able to aggregate all information and understand it's associations.  This format is a step in that direction.