I’m very excited to finally be able to talk about a technology that I've been working on for some time. I have figured out how to connect all aspects of defense: architecting and securing systems (I'll call it 'engineering'), gathering intelligence on what attackers are doing, and detecting and responding to incidents (I'll call this 'operations'). But let’s start at the beginning.
I’ve assessed risk for years and it has never felt 'right'. At a fundamental level, I'm not sure we even knew what risk we were assessing. A vulnerability wasn't a risk. A control definitely wasn't a risk. Additionally, nothing quite seemed right when it came to determining risk likelihood. I've seen every approach under the sun. Many were repeatable, but simply obscured analysts’ decisions behind various weights and 'classifications' (like calling a vulnerability exploitable by outsiders or insiders).
I came to realize risk was a path, as I've previously blogged. Others have come to this conclusion as well, sometimes referring to these paths as kill chains. I make the path distinction since, as a coworker and Lockheed pointed out, kill chains tend to be a specific number of steps. Attack paths are fairly flexible and arbitrary. A kill chain is an attack path, but not necessarily vice versa.
The next question becomes how to aggregate these paths. The Lockheed paper begins to address it, but a much better approach is the use of graph theory! I won't claim to be the first to use graph theory for this. Many have, and I intend to publish a research paper giving full credit to all those whose works I built upon. However, what I am doing is fundamentally different.
By combining attack paths from analysts with graph theory, we now have something that closely resembles how we think about risks happening. An attacker can do A, then B, then C to cause us consequences. And if we block B, they still have the option of doing D in it's place. By using Bayesian math, the combination of risk can be aggregated. Additionally, risk can be tied to threats and their specific attributes. (The explanation of this is something that'll have to wait for the research paper.)
Here's where it gets interesting
Once you have aggregated your attack paths, you don't just have a way of assessing risk, you have a representation of your entire Infosec Posture! It not only shows you what your current risk posture is, but also allows you to combine your gathered intelligence in such a way as to see how it influences your risk. It furthermore allows you to add hypothetical vulnerabilities (which are just likely conditions) as well as adding mitigations and controls (which are unlikely conditions) to see how they affect your posture. You can also add your operational sensor events (IDS, FW, log files, etc) to see if they match any attack paths, threats, or consequences in your graph. And incident handlers can use it to collect and share information about an incident.
From this single graph, you can manage your entire defensive infosec posture. While I'm in no way a coder, I've started to write a tool to realize this capability: Moirai. Named after the Greek Fates – mythological goddesses that wove people's lives – Moirai weaves together the defense of an information system. I am licensing this tool as open source in the hopes that it will help us bring our defensive tools together. At its most fundamental level, Moirai operates as a pubsub and RPC server for graphs using autobahn and neo4j. It does four specific things: 1. It receives state changes to the Infosec Posture stored in a graph. 2. It validates them, fixing them as needed. 3. It stores the changes, and 4. It shares the Infosec Posture, including sharing state changes. The rules for validating an update to the graph are can be found here.
It does this using the Defensive Construct Exchange Standard. Because the standard uses graph theory rather than records to send information, it can represent and connect records of any existing type together. It is my hope that this will allow all defensive tools to share information without the need to support any specific record format.
Currently, Moirai has reached Milestone 1. This represents basic functionality, but there is still much to do, in functionality, security, and robustness. DCES has achieved a basic, functional baseline as well.
It is time that we, as defensive security experts, have at our disposal a method for coordinating our network defense activities. Moirai is the way to do that.
