Attack Flow — Beyond Atomic Behaviors

Written by Andy Applebaum, Desiree Beck, Mark E. Haase, and Jon Baker.

There is a new Attack Flow update! Check out the announcement here.

Defenders commonly track adversary behaviors individually, often focusing on only one specific action at a time. This is a good first step towards adopting a threat-informed defense, but adversaries use sequences of techniques to achieve their goals. Understanding the context within those sequences, as well as the relationships among them, enables additional defensive capabilities that make defenders much more effective.

To help defenders address this problem, the Center for Threat-Informed Defense (Center) launched the Attack Flow project. The project is developing a data format for describing sequences of adversary behavior in order to improve defensive capability. Attack Flow will enable the community to visualize, analyze, and (possibly most importantly) share sequences of actions and the assets they affect; thus, ultimately advancing our understanding of adversary threats and how to handle them.

Working in collaboration with Center participants including Anomali, Inc., AttackIQ, Inc., Citigroup Technology, Inc., Cybereason, Inc., Cyber Threat Alliance, Inc., The Global Cyber Alliance, Fortinet, Inc., Fujitsu, HCA — Information Technology & Services, Inc., Microsoft Corporation, and Verizon Business Services, we continue to develop the attack flow data model and tools. In this blog post, we’ll examine the current format, provide an example flow, and discuss our vision for its use. We are seeking feedback from the community — so if you have thoughts about the model, please let us know!

Figure 1. Core Attack Flow components

What is Attack Flow?

At a high level, Attack Flow is a machine-readable representation of a sequence of actions and assets along with knowledge properties about those actions and assets. This representation is composed of five main objects: the flow itself, a list of actions, a list of assets, a list of knowledge properties, and a list of causal relationships between the actions and assets. Each of these five objects includes a set of required and optional fields. For example, an action must have a description and a name, whereas an asset may — but not must! — have an associated state. We’ve included the full specification at the end of this post.

Attack Flow uses MITRE ATT&CK® to describe specific adversary behaviors. Flexibility and extensibility are core design goals. We have tried to take a simple pragmatic approach to modeling sequences of adversary behaviors that aligns well with operational needs.

What does it look like?

Below is one example of an Attack Flow, built from our analysis of a public intrusion described at this link.

Figure 2. Example Attack Flow based on a threat intelligence report.

In this example, each action is red (and references an ATT&CK technique), each asset is blue, and some select properties are shown in green. While we’re using ATT&CK techniques for the actions, any action schema (such as VERIS) could be used instead. Likewise, the assets can be from any existing ontology such as VERIS, CAR, or any other framework containing systems information. Properties — connected to their associated assets via dashed purple lines — add knowledge and context to the actions and assets in the graph, and in some cases even help define the execution scope of a particular action; e.g., in the above one of the required properties for T1133: External Remote Services to succeed is that the associated Kubernetes Dashboard be Insecure. Lastly, relationships — black arrows — link the flow together, showing how some assets (with specific properties) help the adversary execute an action (“required-by”) and an action changes the state of an asset and in some cases instantiates a new property (“provides”).

How do I use Attack Flow?

There are a number of ways you can use attack flow, and it is our hope that the format becomes a standard used throughout the industry to communicate non-atomic information, helping use cases within threat intelligence, adversary emulation, detection, assessments, and so on.

Let’s focus on three key use cases for Attack Flow:

• Explaining defensive posture to executives,
• Understanding lessons learned from an incident, and
• Building realistic adversary emulation scenarios.

We can see each of these three use cases in the example above.

First, let’s consider an executive’s point of view. As defenders, we might see all the different techniques and assets the adversary interacts with. But an executive might simply see two paths: one on the left that leads to “Cryptocurrency” and one on the right that leads to “Data.” If the executive knows that the Cryptocurrency outcome only costs the company ten thousand dollars, versus ten million dollars for the Data outcome, then they can prioritize their defensive investments accordingly and work to mitigate the actions and break the path that leads to the Data outcome.

One useful way for defenders looking to learn from an incident is through analyzing the assets. A defender looking to prevent this attack can quickly see that if they harden their Kubernetes Dashboard, they can make it more difficult for an adversary to execute the full sequence of actions. Alternatively, they can look at how the assets interact with the actions: a defender looking at this graph might want to make sure that they have analytics that don’t just detect T1610: Deploy Container generally, but rather analytics that detect the technique as it relates to Kubernetes Cluster Access.

Lastly, Attack Flow can help red teamers use adversary emulation, or even replay an incident. With the above example, a red team trying to replicate the attack can follow the graph to identify what techniques to execute and what to execute them on. Although this example doesn’t show all of the details, the full specification allows users to encode much more information, helping to enable red teamers to replay the incident with high fidelity. Alternatively, if the detail isn’t available, just having the action order can be enough for a red team to emulate how the behaviors chain together.

What’s next for Attack Flow?

We have big plans for Attack Flow! Check out some of the areas we are working on below.

Tooling

To help the community, we are building several tools to make working with Attack Flows easier. This includes a visualization tool, allowing users to easily communicate flows to each other and also to leadership. We’re also building a tool to make it easy to construct and export flows — Figure 4 below is a screenshot from our current prototype Attack Flow construction tool.

Figure 3. Screenshot of our work-in-progress tool to make it easy to automatically build and export Attack Flows.

Flow Library

While documentation and other resources — such as this blog post — can help in describing the schema, nothing can help as much as real examples. To assist with this, we plan to build out a small set of flows based on interesting open cyber threat intelligence reports.

Namespaces

One last feature of Attack Flow that we haven’t discussed is namespaces. One of the downsides of having such a flexible format is it can be difficult for different organizations to call the same objects by the same name; looking at the example above, what exactly is “Data”?

We’re still kicking the tires on ways to solve this, but right now we’re looking into creating namespaces that organizations can reference and share so that they can refer to the same objects across different flows. Our current idea is to leverage ideas from the Web Ontology Language (OWL) standard, a family of languages designed to work with knowledge representation. Indeed, knowledge representations in Attack Flow will likely be compatible with OWL, which would enable it to be used with existing OWL tooling like API standards, entity resolution services, and enable easy usage and customization of namespaces.

How do I get involved?

If you want to get involved, start by reviewing our examples, data model, and tooling on GitHub. Please send us feedback! If you have thoughts about what should — or shouldn’t — be included in the schema, let us know! Common representations are only as valuable as the community contributing to it, so your input is important.

You can contact us at ctid@mitre-engenuity.org

Can I see the details?

Figure 4. Fields and information for flows.

Figure 5. Fields and information for actions.

Figure 6. Fields and information for assets.

Figure 7. Fields and information for relationships.

Figure 8. Fields and information for properties. Note that properties are separated into data properties and object properties; the former links objects to information about the object, whereas the latter links objects together in a non-causal way.

Table 1. Table of valid edges in Attack Flow showing connections for each object pair. Edges between objects with a pink square are disallowed. Edges between objects shown with a gray square are represented with a relationship object and denote a state change or requirement. Edges between objects shown with a green square are represented with a property object and denote additional context.

About the Center for Threat-Informed Defense

The Center is a non-profit, privately funded research and development organization operated by MITRE Engenuity. The Center’s mission is to advance the state of the art and the state of the practice in threat-informed defense globally. Comprised of participant organizations from around the globe with highly sophisticated security teams, the Center builds on MITRE ATT&CK®, an important foundation for threat-informed defense used by security teams and vendors in their enterprise security operations. Because the Center operates for the public good, outputs of its research and development are available publicly and for the benefit of all.

© 2022 MITRE Engenuity. Approved for Public Release. Document number CT0040.