Implementation – STIX knowledge and relevance graph – steps 16-21

Create STIX knowledge and relevance graph – steps 16-21

Now that we have all the relevant information handy, we eventually want to generate two graphs, a STIX knowledge and a relevance graph.

In order to generate the knowledge graph we are first checking whether a related Threat Actor (step 16) has been provided as part of the CTI, and if yes, we are mapping it out to the MITRE Intrusion Set (step 17). Next we are searching recursively what tools and malware are utilized by that specific Intrusion Set. Then we are creating a STIX file that includes all the identified Tool SDOs and Malware SDOs along with the Intrusion Set SDO, all provided by MITRE. Next, we are further leveraging the CTI in extracting reports and generating a Recorded Future Identity SDO along with Report SDOs and loading these into the same STIX file. Finally we are loading the STIX file that is representing the knowledge graph into the Attachments tab of our Resilient incident (step 18). See figure 1.31.

Figure 1.31: Steps 16-21 – Functions diagram

The goal with the knowlegde graph is to consolidate as much as possible knowledge around a specific Intrusion Set or Threat Actor in a single graph. This allows us to learn very quickly how the Threat Actor is operating.

The goal with the relevance graph is to see at a single glance which CTI provided IOCs and their related entities do have a local relevance, how these are related to each other and what is the local context around these. The relevance graph is generated by pulling in and merging the previously created individual STIX bundles that are stored in our Postgres test database to a single larger bundle (steps 19-20).

The knowledge and relevance graphs are both generated by triggering a corresponding menu-item rule in the Resilient platform and for each of these two actions a seperate file is loaded in the incident’s Attachment tab. See figure 1.32.

Figure 1.32: Steps 16-21 – Build knowledge and relevance graph

Figures 1.33 to 1.34 are further showing the two graphs, which need to get loaded into the STIX Visualizer by manually downloading the incident attachments to the file system of the local machine.

All the nodes in the STIX Visualizer are a graphical representation of their corresponding STIX Domain or Relationship Object. If you klick on a node, the SDO or SRO details are shown on the right side of the browser tab. We have selected the Intrusion Set – APT28 – node in the knowledge graph. We can see an extract of the node details that are part of the Intrusion Set SDO provided by MITRE.

Figure 1.33: Steps 16-21 – knowledge graph

The way we have built the relevance graph is as follows:

• Create a Recorded Future Identity SDO as the root node of the tree.

• Create Indicator SDOs based on the RF matched destination IP addresses found in QRadar, which BTW have increased over time.

• For every Indicator SDO, create a STIX pattern that searches for the Indicator IP address or any of its related IP addresses. E.g. ipv4-addr:value=’93.184.220.29’ OR ipv4-addr:value=’205.185.216.42’. See figure 1.35.

• Create Observed Data SDOs for every source-destination IP address relationship that is related to the Indicator SDO or any of its related IP addresses.

• Create a Sighting SRO in order to put an Indicator SDO into a sighting relationship with all its corresponding Observed Data SDOs.

Figure 1.34: Steps 16-21 – relevance graph

By clicking through the Observed Data SDOs of IOC 93.184.220.29 and its related IP addresses, we quickly found some suspicion (see figure 1.36). The source-destination relationship 192.168.150.203 –> 205.185.216.4 (right column) is showing that the source IP has sent more than 4 MB in 3910 flows in about 150 milliseconds. This definitely needs some closer look. More specifically we need to understand what exactly has been sent and whether that was legitimate network traffic or a malicious data exfiltration. We will cover this kind of drill-down as part of individual TTP detection methods later in this blog series.

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