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.