When is an Intelligence Feed Record New?

Head on over to the Verizon Security blog to check out my new post on when an intelligence feed record is new.

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.