Solution Draft

IBM Resilient SOAR, MITRE ATT&CK, Recorded Future Cyber Threat Intelligence, STIX}

By Rukhsar Khan on Thursday, December 13, 2018

Based on the experience we’ve made in the last decade with dozens of large customers and new emerged market technologies like Security Information and Event Management (SIEM), Endpoint Detection and Response (EDR), sophisticated CTI and advanced tools and products for computer and network forensics, our claim is, that Security Operations and DFIR need to converge. Both disciplines have strengths and weaknesses, so the goal should be to merge the strengths and shun the weaknesses of both in a single platform. And what would be the most suitable for this other than a SOAR platform? See our solution draft in figure 1.3.

  • Secops and DFIR need to converge. The preferred tool should be SOAR.
  • Security Operations need a holistic approach to analyze known Threat Scenarios with better CTI - strategic & tactical - and sophisticated data collection sources - e.g. endpoint sensing, flows.
  • DFIR needs standardized procedures for known Threat Scenarios and integration of all their forensic tools with the SOAR platform.

Figure 1.3: Solution draft – Claim

In order to better qualify Cyber Security threats and drastically reduce the median breach confirmation time, Security Operations need a holistic approach to analyze known threat scenarios. Also, they need to start an investigation on the right foot. This is why they need a better CTI that is providing comprehensive strategic and tactical intelligence and giving them context around their IOCs. In addition to this, sophisticated data collection sources need to be implemented. E.g. endpoint sensing and flows are absolutely essential as they provide the means to understand the IOCs in context of their local relevance.

DFIR needs standardized procedures for known threat scenarios in the form of playbooks and workflows. Also, they need to integrate their forensic tools with the SOAR platform.

All of this is part of our solution draft but before we go into the details, we need to introduce the MITRE ATT&CK framework, some useful MITRE resources, sophisticated CTI of the provider Recorded Future, STIX and another expression language called Malware Attribute Enumeration and Characterization (MAEC).

Figure 1.4: Holistic approach – MITRE ATT&CK framework

Figure 1.4 is showing the MITRE ATT&CK framework1. As we mentioned before, the MITRE institute spent many years in analyzing the global high profile breaches and categorizing them into individual TTPs. The currently 11 tactics of the ATT&CK Matrix for Enterprise, starting off with Initial Access up to Command and Control, are holding individual techniques. Every technique is describing adversarial procedures and methods. You can also see on the right top corner how the ATT&CK Matrix for Enterprise maps to the Cyber Kill Chain. It fits into the last three phases and is therefore a post-compromise matrix. There is also a Pre-ATT&CK Matrix available that maps to the pre-compromise phases of the Cyber Kill Chain.

The MITRE ATT&CK framework is a TTP-based, behavioral threat model. The goal is to detect and mitigate adversarial behaviors based on the individual TTPs as opposed to IOC-based detection and mitigation. As we learned before, IOCs are changing too rapidly but behaviors of an attack scenario can’t change entirely. That’s why MITRE ATT&CK is entirely concentrating on detection behaviors.

However, for starting the analysis on the right foot it is crucial to have an excellent and robust CTI in place that provides real facts and informs an organization on the ATT&CK tactics and techniques on which to focus. In our solution draft we are leveraging CTI from Recorded Future. See figure 1.5.

  • A robust threat intelligence capability can provide real facts and inform an organization on the ATT&CK tactics and techniques on which to focus.
  • Beginning the analysis on the right foot is crucial. Else you quickly loose focus and waste all your time.

Figure 1.5: Cyber Threat Intelligence – Recorded Future

This CTI is related to an IP address entity of the value The term entity is equivalent to the term indicator which means that this is the IOC we are starting our investigation with. As you can see further down in the CTI there are multiple related entities to this indicator like related hashes, related email addresses, related IP addresses and most importantly for now a related Threat Actor – APT 28, a well known Russian Threat Group – which we have learned should be part of a robust and actionable CTI.

Based on the provided Threat Actor our next step is to map the CTI out to the MITRE ATT&CK Matrix. In our example we have two related Threat Actors, namely AIVD and APT28. Since MITRE is providing known Threat Actors and their used TTPs as part of the ATT&CK framework, you can simply map out TTPs based on the Threat Actor name.

Figure 1.6 introduces a free tool from MITRE, the ATT&CK Navigator, that visualizes all the TTPs of one of the ATT&CK matrices, depending on which matrix you have loaded. In our example we have loaded the ATT&CK Matrix for Enterprise. This tool allows us to select a Threat Actor. Since our CTI includes APT28 as a related Threat Actor and this specific Threat Actor is available in the ATT&CK framework, we can simply select it and the ATT&CK Navigator highlights all the related TTPs. This allows us to learn how the Threat Group is operating. If we right-klick on a TTP we can select to view the corresponding technique details. This opens a new browser tab which is linked back to the MITRE website.

Figure 1.6: ATT&CK Navigator for Enterprise

As shown in figure 1.7 a TTP has a unique id (T1091), some high-level information on the corresponding procedures and methods, examples out of the wild, detection and mitigation advise and a whole universe of further detailed references to known global high-profile breach reports. We call this the human readable version of the ATT&CK framework.

Figure 1.7: MITRE TTP – T1091 (Human readable)

In our solution draft we are dividing the TTP provided information into two stages, namely Stage 1 Analysis and Stage 2 Analysis. We will describe later what we exactly mean by this.

In contrast to the human readable version of the ATT&CK Matrix the entire framework is also available in machine code, more precisely in STIX2 format. As mentioned earlier, STIX2 is a specific JSON formatting. Based on figures 1.8 and 1.9 let’s see what STIX2 is about.

Figure 1.8: Structured Threat Information Expression (STIX)

STIX is a great language that can express and describe a Cyber Security threat or incident by breaking down its complex and obfuscated elements into individual structured objects and put those objects into a relationship. You can then visualize the relationships in a graph.

Figure 1.9: Structured Threat Information Expression (STIX) continued

STIX2 defines twelve STIX Domain Objects (SDOs), namely Attack Pattern, Campaign, Course of Action, Identity, Indicator, Intrusion Set, Malware, Observed Data, Report, Threat Actor, Tool and Vulnerability. In addition to these, two additional STIX Relationship Objects (SROs) are defined which can put the SDOs in a specific kind of relationship. SRO names are Relationship and Sighting.

Following is an enumeration of all the domain objects provided by MITRE ATT&CK as part of their framework:

1. MITRE TTPs = Attack Pattern SDO

2. MITRE Mitigation = Course of Action SDO

3. MITRE Intrusion Set = Intrusion Set SDO

4. MITRE Malware = Malware SDO

5. MITRE Tool = Tool SDO

6. MITRE Identity = Identity SDO

7. MITRE Relationship = Relationship SRO

An Attack Pattern SDO describes the TTPs a Threat Actor is using in order to compromise a target. A Course of Action SDO gives instructions on how to respond to the attack. An Intrusion Set SDO provides all the context around a Threat Actor or Threat Group, their motives, the way they are operating, etc. A Malware SDO expresses a malware variant that is used to compromise a target. A Tool SDO describes a tool that can be utilized in order to compromise a system. An Identity SDO simply describes an individual, an organization or a group. A Relationship SRO creates relationships of a specific type between SDOs in order to express that relationship. E.g. an Identity Set is using specific malware, a Course of Action mitigates an Attack Pattern, an Identity is targeted by a tool, etc.

Other SDOs or the Sighting SRO which are not provided by MITRE ATT&CK need to get derived from other sources. E.g. the Indicator SDO can come from a CTI feed. Contextual objects like Report SDOs, Threat Actor SDOs and Tool SDOs can also be delivered as part of a robust and actionable CTI.

Observed Data and Vulnerability SDOs can be created from data collected from an internal Cyber Security defense system like a SIEM, Vulnerability Management system, EDR system, etc. that has matched against a CTI provided indicator in order to express the local relevance. Putting an Indicator SDO into a relationship with an Observed Data SDO is done by the special Sighting SRO.

When operationalizing MITRE ATT&CK and STIX a defending organization can develop SDOs and SROs by leveraging the STIX2 Python APIs2 which are available for free.

Let’s take a closer look at the Indicator SDO. In order to express a suspicious or malicious IOC with all its context a CTI provider can use STIX patterning which is defined in its own document3. STIX patterning allows you to narrow down suspicious or malicious behavior very granularly. In example 1.1 you can see five STIX pattern.

Example 1.1: STIX Patterning

Line 1 is showing a simple pattern where multiple IPv4 addresses are defined and separated out by an OR operator. This pattern is searching for any of these IP addresses. The pattern in line 3 is matching on a malware beaconing to a domain name which is repeating 5 times within 1800 seconds. The pattern in line 5 is matching to a Windows Registry key. Line 7 is showing a pattern matching an email message with a particular “from email address” and “attachment file name” using a regular expression. The most complex of these pattern is shown in line 9. It’s matching on a payload header of an artifact object which is storing a binary PCAP file.

In example 1.2 you can further see how the local relevance of an IOC expressed by an Indicator SDO is defined by a Cyber Observable Object that is part of the Observed Data SDO. In lines 16-23 we can see the source-destination relationship, lines 11-14 are showing the amount of packets and bytes sent and received and the lines between 3 and 10 are defining the timestamps, the type of data and the protocols used. Cyber Observable Objects4 can be far more comprehensive in order to specify any kind of local findings.

Example 1.2: Cyber Observable Object

Figure 1.10 demonstrates the JSON representation – in STIX2 – of the human-readable MITRE webpage for TTP # T1091 shown in figure 1.7

Figure 1.10: MITRE TTP in STIX2 – T1091 (machine code – JSON)

In figure 1.11 you can further see SDOs put into relationships. A small example in the right top corner is showing how an indicator indicates a Campaign which is in turn attributed-to a Threat Actor and targets a Vulnerability. A graph could look like the one in the middle of this illustration if more context is available.

Table 1.1 summarizes the relationships defined by the STIX2 Objects specification. As specified in that document, STIX also allows relationships from any SDO to any SDO that have not been defined.

STIX is primarily focused on the representation of cyber observables. As it only specifies a single Malware SDO there is a requirement to have a complementary language that provides a proper representation of malware objects. MAEC is such a language. It’s goal is to provide structured information included in malware objects pretty much

Figure 1.11: Structured Threat Information Expression – Relationship types

in the same way as STIX is providing this in Domain Objects. MAEC5 defines the following objects: Behaviors, Malware Actions, Malware Families, Malware Instances and Collection. These objects are put into a relationship and can then be merged with an existing STIX graph. See figure 1.12.

Table 1.1: STIX specification-defined relationship summary

Figure 1.12: MAEC intro (pronounced “mike”)