Association Rules

Check out my blog on Association Rules over at the Verizon Security Blog.  It's definitely an under-utilized area of machine learning.

Standardized Data Trees (UN M.49, ISO 3166-1, ISO 3366-2, country population/area, NAICS)

To help in aggregating, comparing, and validating data, I've created a pair of data of graphs which represent tree hierarchies of standard formatted data.

The World Graph contains:

• UN M.49 country codes
• ISO 3166-1 alpha-2 and alpha-3 codes from pycountry
• ISO 3166-2 country subdivision codes from pycountry
• World Bank country population data
• World Bank country geographical area data
• Aggregation of population and geographical area data at higher levels of the graph
• (Some population and geographical data filled in from wikipedia where missing from the World Bank)

World Graph Visualized

The NAICS Graph contains:

• 2012 NAICS codes in hierarchical form
• Percentage of the graph under each node

The percentage under the graph in the NAICS graph and the aggregate population/geographic area allow two things:

1. Provide an amount as a dimension for data coded in these systems, (whether that amount be percentage of NAICS codes, population, or geographic area).
2. Provide a means of comparing the similarity of two records by finding the Lowest Common Ancestor (LCA) and retrieving the score from that node.  The greater the score, the greater the distance between the nodes.

The hierarchies can be used for validating data as well as comparing things (as above) that are not on the same level of the graph.  For example, a US state could be compared to the country to South-Eastern Asia.

None of this is groundbreaking, but hopefully some find the graphs of use.

The Opportunity to Create

We work in a great profession in information security.  Unlike other professions which are bound by the physical world, we work with near limitless scope as infosec's context is not just spread out over the physical world, but also the digital.  In addition, we work in a profession whose challenges are not just static, caused by physical/technical constraints, but also dynamic, caused by the competing interest of different people.  However, that also hinders us in succeeding in our profession.

Information security has always had a combative context.  It's understandable as there is a clear offensive side, a clear defensive side, and rational actors existing on both sides.  We think about solutions in the context of winning the conflict.  This leads us to look for solutions based in force.  Either the force to overcome the other side's defenses or the force to absorb the other side's attacks.

There is another way though.  Instead of thinking of conflict, we can think of building something that simply transcends the conflict.  The same way a dancer compliments their partner's movements rather than forcing their partner to do what they want, we can think of information security as the opportunity to create something that transcends the combat; to create something that makes the combat a suboptimal solution to the goals of those participating in it.

I can't say I know what those solutions are.  I'm sure they are much harder to find than simple us versus them solutions.  however I think the transcendentals are a good starting place:

1. Goodness: Is the solution good, (and not just in the moral relativistic sense that it is good in my own context, but in all stakeholder contexts.)
2. Truth: Is the solution true, (again not just in the relativistic sense.  It must be true for all stakeholders.)
3. Beauty: Is the solution beautiful to all stakeholders.

However, the transcendentals are very abstract concepts to apply.  In our day to day work, the following tenants may be much easier to test:

1. If we are thinking of how a solution helps us gain an advantage over someone or beat someone, it is not the right train of thought.
2. Finding solutions should include thinking about all stakeholders on all sides of the conflict and their needs.
3. Finding solutions should include thinking about how the capabilities of all stakeholders can be integrated to create something greater than the sum of the parts.
4. The solutions may not be technical in nature and may require the inclusion of stakeholders with non-technical skills to implement.
5. We should be prepared to compromise and sacrifice to find the solution.

Hopefully by considering these tenants as we think of how to solve information security problems, we can find solutions which transcend the daily conflict of information security.  Hopefully we can find solutions which prevent conflict not because of the risk of losing is too great, but because there is no incentive to engage in it.

So the next time you are trying to solve an information security problem, test your approach to finding a solution against the tenants above.  If you find that your approach is inconsistent with the tenants, consider what you could do to meet these tenants.  The better a solution meets these tenants, the more likely it is to be a long lasting solution.

I Made a Million Models

Check out my blog over at Verizon Security:  I Made a Million Models.

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.