How to Use the Mitre ATT&CK Library in IriusRisk

Overview of Mitre ATT&CK Framework

MITRE ATT&CK® is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations. The ATT&CK knowledge base is used as a foundation for the development of specific threat models and methodologies in the private sector, in government, and in the cybersecurity product and service community.

The knowledge base is divided into three categories: Enterprise, Mobile and ICS, the first one being the one that has been included in the 4.9 release of IriusRisk among other new libraries.

The knowledge base is composed of:

• Tactics/Domain (TA): It is the adversary's tactical goal: the reason for performing an action.

• E.g.: TA0043 - Reconnaissance: consists of techniques that involve adversaries actively or passively gathering information that can be used to support targeting.

• Techniques (w/o Subtechniques) (T): Techniques represent 'how' an adversary achieves a tactical goal by performing an action.

• E.g.: T1595 - Active Scanning: Active scans are those where the adversary probes victim infrastructure via network traffic, as opposed to other forms of reconnaissance that do not involve direct interaction.

• Data Sources/Detections (DS): Data sources represent the various subjects/topics of information that can be collected by sensors/logs.

• E.g.: DS0029 - Network Traffic: Data transmitted across a network that is either summarized and/or captured as raw data in an analyzable format

• Mitigations (M): Mitigations represent security concepts and classes of technologies that can be used to prevent a technique or sub-technique from being successfully executed.

• E.g.: M1027 - Password Policies: Set and enforce secure password policies for accounts.

• Groups (G): Groups are sets of related intrusion activity that are tracked by a common name in the security community.

• E.g.: IndigoZebra is a suspected Chinese cyber espionage group that has been targeting Central Asian governments since at least 2014.

• Software (S): Software entries include publicly reported technique use or capability to use a technique.

• E.g.: Agent.btz is a worm that primarily spreads itself via removable devices such as USB drives.

• All these elements are linked through relationships which establish what happens between each other. A technique that is related to a tactic may be performed by a group using a particular software. Detections and mitigations can be put in place depending on the technique to prevent the attack from being successful.

How did we structure the IriusRisk ATT&CK Library?

The framework has been mapped as follows:

• Tactics (or Domains) are mapped to Risk Patterns since they group a set of threats. Having the Tactics mapped as Risk Patterns gives us a chance of deciding how we are going to import the content.  We did not create any rules that would automatically import Risk Patterns under certain scenarios, but having the content in patterns provides the building block for you to create those rules.
• Techniques and Subtechniques are mapped to Use Cases and Threats respectively since the technique describes how an adversary achieves a tactical goal. Since a technique may consist of several subtechniques it is possible that a technique can be seen as a use case while the subtechniques are the threats. In those cases where the technique doesn’t have subtechniques it will be present both as a use case and as a threat to be consistent.
• Nothing has been mapped to Weaknesses, but since this is an optional element in IriusRisk’s data model, we just skipped it.
• Mitigations and Data Sources are related to Countermeasures since they tell us what to do in order to prevent the technique from being successful and how to detect it.

We specifically chose to consider Software and Groups as out of scope for our library, because we prefer to focus on defense, rather than attack details.  Although attack details such as who the attacking group is are useful information in some contexts, we believe that for IriusRisk users, this is not as relevant and is therefore omitted.

How to use it in IriusRisk

This library provides techniques, mitigations and detections so that users can build their own risk patterns. Similarly, we also provide a CAPEC/CWE library to provide CAPEC attack patterns that we used to create most of our default content for basic components.

Techniques imported directly as new threats

The simplest use is to add a known technique/subtechnique to a given component by searching for it using the “Add threat from existing” feature:

When a threat is added the countermeasures related to it will also be included. As an example if we add the threat T1548.001 (Abuse Elevation Control Mechanism: Setuid and Setgid) it will include the mitigation M1028 (Operating System Configuration) and detection methods DS0017 (Command) and DS0022 (File), as established in the framework. Since the information provided by the framework is generic, additional information can be added after the import to provide insights.

In case we want to add an entire technique (including all its subtechniques) we would have to create a rule to import a specific use case if a certain condition is met. Importing a use-case manually into a threat model is not supported. As detailed before, if a technique doesn’t have subtechniques it will appear both as a use case and as a threat, so users can choose how to import the content in the threat model.

Threats can also be included via rules for a given set of conditions.

Techniques imported through risk patterns

An alternative would be adding the threat in a risk pattern so that it can be reused in other components. Risk patterns are reusable collections of use cases, threats, weaknesses and countermeasures that can be imported into a threat model as a unit. They are the basic building blocks of threat models in IriusRisk.  

A risk pattern can be created to represent a specific set of techniques that can be conceptually related to a specific type of component. For example, a server-like component that might be affected by techniques T1134, T1071 and T1010 could be statically associated with those risk patterns, so that when that component is selected those patterns and their associated threats and countermeasures are always automatically included.

As stated above, when the threat is added it will include the countermeasures that should help mitigate this threat based on what the ATT&CK Framework dictates. This risk pattern can then be added via the component definition or a rule as many times as needed.

‍