VERUM

It's taken years to design, months to build, and weeks to write about, but the blogs are finally up. Meet Verum, a Context Graph System:

• Introducing Verum: A Context Graph System - Part 1 of 2 - http://goo.gl/D7Kvuf
• Context Graph Based Analysis of Apple Pay Domains - Part 1 of 3 - http://goo.gl/Gff9Ox
• Introducing Verum: A Context Graph System - Part 2 of 2 - http://goo.gl/ksjzOn
• Context Graph Based Analysis of Apple Pay Domains - Part 2 of 3 - http://goo.gl/IIjozs
• Context Graph Based Analysis of Apple Pay Domains - Part 3 of 3 - http://goo.gl/GYi0z0

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.