Cyber Attack Graph Schema (CAGS) 2.0

This post represents the update to the Cyber Attack Graph Schema (CAGS) 1.0 I published last year.  It incorporates many practical lessons learned from version 1.0.

Schema

1. All property names discussed must be stored as lower case.
2. The graph must be a directed multigraph.
3. Nodes properties:
1. 'class': Must be 'actor', 'event', 'condition', or 'attribute'. (required)
2. 'value': An atomic value that the node represents.  For nodes of 'class':'event' and 'class':'condition', it will contain a string holding a narrative describing the event or condition.  For 'class':'actor' and 'class':'attribute', it will be a succinct description of the atomic, (e.g. <'class':'actor', 'value':'happy panda'> or <'class':'attribute', 'value':'8.8.8.8'>.)
3. 'start_time': The time the atomic the node represents began to exist.  Time should be in ISO 8601 combined date and time format (e.g. 2014-11-01T10:34Z) (optional but encouraged)
4. 'finish_time': The time the atomic the node represents ceased to exist.  Time should be in ISO 8601 combined date and time format (e.g. 2014-11-01T10:34Z) (optional but encouraged)
5. uri: Uniform Reference Indicator in the form "class=<node class>&key=<node key>&value=<node value>" with <node class>, <node key>, and <node value> filled in.  If the node is of a class without a 'key' property ('actor', 'event', and 'condition'), "&key=<node key>" should be omitted.   Note that the prefix is not included and should be handled by the client and server. (optional but encouraged)
6. 'comments': Provides a narrative of the node. (optional)
7. 'cpt'. A JSON string in the format defined here. (optional.  Likely unnecessary unless using a Bayesian network to predict actor attack paths.)
4. Additional properties for nodes of 'class':'attribute':
1. 'key': A succinct type of the atomic.  (e.g. <'class':'attribute', 'key':'ip', 'value':'8.8.8.8'>) (required)
5. Edge Properties:
1. 'source': the id of the source node. (required) (see Note 4)
2. 'destination': the id of the destination node. (required) (see Note 4)
3. 'relationship': The following table describes the relationship types based on the 'class' of the source and destination nodes:

		destination node 'class'
		Actor	Attribute	Event	Condition
source node 'class'	Actor	desribed_by	described_by	leads_to	leads_to
	Attribute	desribed_by	described_by	influences	influences
	Event	leads_to	described_by	leads_to	leads_to
	Condition	influences	described_by	influences	influences

4. 'confidence': Float value between 0 and 1 representing the percent confidence that a relationship exists. (optional but implied to be 1 if not present)
5. 'origin': The source of the relationship. (required)
6. relationship chain: An edge may have a property of the same name as the relationship and following properties such that "property value"->"property names" form a chain.  For example: <'relationship':'described_by', 'described_by':'x', 'x':'y'>.  A practical example is when two domains are linked by a relationship where one is the nameserver of the other.  The edge relationship would appear as <'relationship':'described_by', 'described_by':'nameserver'>. (optional)
7. 'start_time': The time the relationship the edge represents began to exist.  Time should be in ISO 8601 combined date and time format (e.g. 2014-11-01T10:34Z) (required)
8. 'finish_time': The time the relationship the edge represents ceased to exist.  Time should be in ISO 8601 combined date and time format (e.g. 2014-11-01T10:34Z) (optional but encouraged)
9. uri: Uniform Reference Indicator in the form "source=<source hash>&destination=<destination hash>&relationship=<edge relationship><& relationship chain>&origin=<edge origin>.  (optional but encouraged)
1. <source hash>, <destination hash>, <edge relationship>, <& relationship chain>, and <edge origin> should be filled in.
2. The has should be a md5 hash of the source and destination URI in URL namespace.
3. All additional links in the relationship chain (as described in #6) should be included in order.
4. Note that the prefix is not included and should be handled by the client and server. 
6. Additional properties for edges of 'relationship' :'leads_to':
1. 'cost': The economic cost to transverse the edge.  (optional.  May be actor-specific and algorithmically generated.)

Notes:

1. Nodes and edges may have additional properties, however they will not be validated and may be ignored by the attack graph.
2. Nodes and edges missing values may be accepted by the server if the missing value can be implicitly filled in.  If the server cannot imply a required property, the node or edge should be denied.
3. In some cases, various property naming requirements may be incompatible with a piece of software.  In that case, a name should be used in which removing non-alphanumeric characters and casting to lower case results in the same name as doing so to the the standard property would.
4. Most databases will automatically assign a unique identifier such as 'id', 'label', etc.  As the key for this value is normally hard coded in the database and varies from database to database, it is simply a node property that is tolerated.
5. For reasoning behind schema decisions, see the comments to the CAGS 1.0 post.

Schema Summary Explanation
This schema provides two fundamental abilities: 1. It allows the description of the context of an organization's information security posture. and 2. It allows the description of an organization's risks in the form of attack paths combined to form an attack graph.

Attack paths start with an actor and progress through conditions and events until they reach a condition which represents the consequence of the risk.  Because these attack paths can be interlinked between shared conditions and events, they form a graph.  Attributes provide context to the attack paths in the form of a robust graph around the core attack graph.

The application of the attack graph is far too complex for description in this post.  Current Moirai code is based on CAGS version 1.0 and requires update to be consistent with version 2.0.

Examination of the Cassandra Distributed Storage System

Attached is my review of the Cassandra top-level Apache Foundation project: Examination of the Cassandra Distributed Storage System.  This may be helpful to those looking at potential solutions for building a scalable security solutions.

The Importance of Data

Based on a twitter conversation with Wade Baker, I wrote a post on why data is so significant in information security.  Check it out here at the Verizon Security blog.  Twitter just a bit short to answer Wade's question, but I think the blog does the question justice.

Application of a Buyer Readiness Model to Adoption of Cross-Vertical Initiatives

I just finished a talk at the Nashville Technology Council's Nashville Analytics Summit.  It covered my colleague and I's paper: Application of a Buyer Readiness Model to Adoption of Cross-Vertical Initiatives. It covers how to sell an analytics initiative, (or any other cross-vertical initiative such as security), to internal stakeholders.  If you'd like, also check out the slides for our presentation: Your Boss Buys Analytics.

Signal to Noise

Just posted a blog at Verizon Security about the signal to noise ratio advantage that attackers have over defense.  Check it out here.

Security to Serve, not to Subjugate

A reoccurring theme in information security (and many other disciplines which cut across verticals) is "I could solve the problem if I could just get everyone to follow a few, simple rules".  We know, and they may even agree, that the simple rules are good practices that should be done.  However, the rules are rarely followed.  When they are followed, any adversity causes them to fall by the wayside, and no-one is particularly happy to follow the rules.

The fact is, even though we are benevolent rulers with a light burden, we are still acting as authorities over other groups in our organization.  Authority is rare appreciated, regardless of the burden.  If we want to truly get the support of our organization, we need to serve them, not rule over them.  But how do we provide security through service?

A Model for Service
With a little adaptation, the Center of Excellence (CoE) model can be adapted to provide cross-vertical competencies through service to the organization.  Our CoE will have three goals (services it provides):

1. Evaluate Quality - The CoE will provide a repeatable approach to evaluating how well other groups in the organization are doing at infosec.
2. Lessons Learned Sharing - The CoE will collect lessons learned about infosec from groups across the organization and distribute them to the rest of the groups.
3. Support Execution: The CoE will support the execution of infosec in three ways based on how the supported group wants to be supported.
1. If the group knows how to do infosec, leave them alone.  Let them do their thing.
2. If the group wants to know how to do infosec, teach them how to do it well.
3. If group doesn't want to deal with infosec, offer to do it for them.  Obviously they will still need to provide the resources, authority, etc, necessary for you the CoE to provide this service.

It is important that the CoE not see themselves as specialists proselytizing to the unwashed heathens.  The CoE serves others; it doesn't rule them and it isn't better than them.  To that end, the CoE should strive to provide the services when requested, only providing them unsolicited when absolutely necessary.  Also, the CoE need only charge for bullet 3.3. The CoE should be internally funded to provide the other services.

One way to start developing this CoE is for the group to begin solving problems that are likely to arise before the CoE is engaged.  If you look forward and help develop solutions before the problems arise, when groups come to you with questions, you will be able to serve them by solving their problems.  This will bring them back to you and help you establish your CoE of infosec service.  And by all means, don't be shy about your successes.  Make sure others know you are serving the organization and solving other's problems.  Soon they will be coming to you for infosec help and you can use the opportunity to establish the CoE.

P.S.
The approach doesn't just work for information security. It can work for any service: Data Analytics, Quality Assurance, etc. By applying this approach, the requirements will not be burdens, but services.

You the Outlier - Why Privacy/Anonymity is Important in a Big-Data World

In my previous piece, I argued that privacy was dead and multi-persona anonymity needs to take its place.  This is based on a critical premise though, that we need privacy (or anonymity).  I hear many poor arguments in support of privacy.  Let's look at those first and then consider a better reason.

Being Held Accountable for Your Actions

Lets address all the poor reasons we hear.  Obviously the argument against privacy is, "Why do you need privacy if you have nothing to hide?"  There are multiple luke-warm responses:

1. "BECAUSE" - The concept that it is something you should 'just have'.
2. What if the acceptability of my actions changes with the progression of time or 'those in charge' think my actions are a problem when I do not?
3. No-one is perfect.  Should that be held against us?  In perpetuity?
4. What about the insurance company who'll raise our rates when they find out what we've done?

These are all poor arguments against lack of privacy for one reason: They all assume someone shouldn't be held accountable for their actions.  While I think forgiveness is at the foundation of humanity, I don't think not being held accountable for actions can be held up as the reason for needing privacy.

Being Held Accountable for Others' Actions

In a big-data world, we are not necessarily judged by our actions, but by the profiles we match.  This is nothing new.  But while in the past an employer might require employees to sign a letter letting them inspect his driving habits and then fire those that receive any tickets or a DUI, with massive data available it can be taken to an unprecedented level.

Instead of inspecting a driving record, an employer may install monitoring devices in personal vehicles.   The monitor had a database of speed limits.  If you went more than 5 miles over, you received a warning to slow down.  If you didn't within 6 seconds, your violation was reported which could lead to your firing.

The first case is a crude model with very bold, red lines not to cross.  The second is a much more subtle model, with ambiguous grey lines. It is one fed with every speed you have ever driven.  It says that those who spend more than 5 miles over the speed limit regularly are a liability.  However, where did that model come from? How was it validated?  Was it validated?

The reason privacy (anonymity) is important is that every model has a large number of outliers, and there is a good chance you are that outlier in some model.

In a big-data world, we are judged against models.  "If a person exhibits, A, B, and C, then they must be D".  Being D may mean being unemployable.  It may mean being paid less or paying more.  It may mean being excluded, untrusted, or any other number of things.  However, in the model, there will be a number of outliers.  No-one cares for them as, by definition, they are not the norm.  Still, on the flip side, everyone is probably an outlier in some model.  And being judged by a model to which you are an outlier is inherently being held accountable for others' actions. 

In this case, you have done nothing wrong.  You will not do what the model accuses you of doing.  But you fit some model which you will not get to challenge and which may never have been critically assessed in the first place.

This critique isn't meant to detract from the usefulness of models.  Models can co-exist with privacy and anonymity.  Models trained on real data still offer significant value in many areas including trends and decision analysis.

But we want to make sure models don't become the pre-cogs in Minority Report.  Otherwise, the movie Gattaca could easily become our future.  Where privacy is not about being held accountable for the things you did.  It's about not being held accountable for the things you didn't do.