Resilient Workflows and Playbooks

IBM Resilient SOAR, QRadar, MITRE Att&ck

By Rukhsar Khan on Thursday, January 3, 2019

Resilient Workflows and Playbooks

As we have learned, all the TTPs potentially used by a known MITRE Intrusion Set are put into relationship by the Relationship SROs that are provided as part of the Att&ck framework. Since we have loaded the complete framework in STIX2 format in our Postgres test database, we can identify these TTPs recursively by verifying the relationships of the Intrusion Set.

Figure 1.37: MITRE workflow calls APT28 workflow

A SOAR tool like IBM Resilient can further help us by providing workflows and playbooks in order to trigger additional automation actions and giving instructions to an analyst. Depending on which Intrusion Set / Threat Actor has been identified, a generic workflow can call another workflow in order to satisfy the analysis requirements implemented for the corresponding TTPs. E.g. figure 1.37 is illustrating how a generic workflow named MITRE is calling the workflow MITRE: APT28 after identifying APT28 as the Threat Actor. The MITRE: APT28 workflow extract can be seen on the right side of this illustration. This workflow combines the creation of task instructions (e.g. MITRE: T1003/Credential Dumping, MITRE: T1056/Input Capture) that are provided to the analyst in the form of a playbook and the calling of another workflow named MITRE: T1059/Command-Line Interface (top right) that is triggering an automation script for additional data collection and enrichment for satisfying TTP # T1059 requirements.

Figure 1.38 is further elaborating on how the playbook that is eventually providing task instructions to the analyst looks like. All the TTP task instructions regarding APT28 have been loaded into the incident’s Tasks tab as part of this playbook.

Figure 1.38: MITRE Playbook loads TTPs for APT28

The output of workflow MITRE: T1059/Command-Line Interface can be seen in table 1.2. MITRE T1059, on a very high level, is instructing us to search for all cmd.exe processes that have been spawned by a parent process other than explorer.exe. These might be suspicious and require further attention.

For the rest of this feed we will demonstrate how we are implementing the individual TTP detection and mitigation instructions with workflows and playbooks. For this, we will firstly integrate with additional Cyber Security systems and tools and secondly we will extend our solution draft in building Stage 1/2 Analysis capabilities.

Table 1.2: MITRE T1059/Command-Line Interface automated action

The goal is to help Security Operations and DFIR in streamlining deep security and forensic analysis, drastically reducing analysis and response time as well as understanding and keeping track of the full scope and complete impact of an attack.

Figure 1.39 is itemizing our currently biggest challenges along with exemplary product roadmaps of the vendors we have included in our solution draft. The latter shall give us some idea on where the journey in terms of MITRE Att&ck and STIX2 is going.

One of the biggest challenge during our development process was heavy data re-formatting and conversion. Commercial vendors as well as open source tools are currently not providing result sets of queried data in STIX2 format. We needed to convert their native JSON formats into STIX2. Also, if the CTI is not providing any Threat Actor, mapping out the MITRE TTPs can be a nightmare.

Current biggest challenges:

Heavy data re-formatting and conversions required.

Commercial vendors as well as open source tools are currently NOT providing results sets of data queries in STIX2 format.

Mapping out TTPs if NO Threat Actor is present in CTI

Product roadmaps:

Upcoming QRadar release will map all rules to MITRE TTPs.

Figure 1.39: Current biggest challenges – Product roadmaps

But vendors have identified the power of MITRE Att&ck and STIX2 and many have these on their roadmaps. E.g. the upcoming Q4/2018 QRadar release will have a mapping to MITRE TTPs for every detection rule. Vendors like Carbon Black have already built a lot of MITRE mapping into their products which is constantly improving.

Figure 1.40 is showing more details on our upcoming plans.

We will extend our workflows and playbooks and include a lot of investigative questions which will dictate the path to go in the workflows.

As part of the Stage 1 Analysis provisioning, we will integrate with CB Response, an A10 SSL interception proxy and a Cuckoo Sandbox.

Since CB Response has the limitation that it can’t detect in-memory attacks, we will integrate with the forensic tool Volatility in order to fill this gap. We will provision an automation action against the CB Response REST API that will create a forensic memory image which we will load on a forensic system for the Stage 2 Analysis.

We will further integrate with forensic tools like Plaso and Log2timeline in order to create forensic timelines as part of the Stage 2 Analysis.

For the network forensic part of the Stage 2 Analysis we will integrate with QRadar Incident Forensics and we are planning to convert PCAPs to JSON and to STIX2 if required.

Once integrated with the above systems and tools, we are planning to either extend or reduce the relevance graph as we will be progressing through our Stage 1 and Stage 2 Analysis.

Investigative questions during all stages of the analysis in order to dictate the path in the workflow.

with commercial and non-commercial products and tools from IBM, Recorded Future, Carbon Black, A10 Networks, Volatility and more . . .

This class is about Incident Response in a post-compromised environment.

In this class we will show you the major reasons why Security Operations is currently doing bad and what is required within Security Operations in order to produce high value results that can be consumed by a Threat Hunting and Forensic team. We will also focus on how to streamline security analysis, starting off with the initial triage within Security Operations to Threat Hunting to Forensics in case of an advanced targeted attack by quickly forming up a defense team that is able to collaborate directly from within IBM Resilient as the central hub for Incident Response.

The goal is to rapidly identify and respond to advanced adversaries that have gained a foothold in a compromised environment (post-compromise). The initial triage will be conducted by the Security Operations team (L1) which will hand-off valuable results to the Threat Hunting team (L2) which will in turn produce results that will be consumed by the DFIR team (L3) for a deep dive forensic analysis focusing on a few affected systems out of hundreds or thousands of systems... Read more