Implementation – Related IP Addresses – steps 11-15

IBM Resilient SOAR, Recorded Future CTI, STIX

By Rukhsar Khan on Sunday, December 23, 2018

Verify Related IP Addresses – only relevant IPs – steps 11-15

Figure 1.27 is illustrating steps 11-15 of our solution draft. Now we want to take advantage of our actionable CTI. The goal is to verify the related IP addresses of the two RF matched destination IP addresses 81.7.11.83 and 93.184.220.29 that have been communicated as part of their corresponding CTI. We are verifying all related IP addresses against the QRadar Ariel database and are only considering the ones that have a local relevance, i.e. local-to-remote network traffic that matched against a related IP address. Finally we are taking those matching related IP addresses into the Resilient Incident Artifacts tab.

On the top left corner of figure 1.28 we can see that a menu-item rule under the name RECORDED FUTURE: Verify Indicator Related IP address that relates to an incident artifact has been provisioned. Once we trigger this action against an IP address artifact another window pops up (bottom left) where we have to define a start and end time for the QRadar query. We are no longer specifying the query start time as the incident discovered date as we want to extend our search window to a selective value. The menuitem rule calls a corresponding workflow which has now two functions. See figure 1.29.

The first function Test db related indicator processes steps 11 and 12. It reaches out to our Postgres test database by defining a Postgres select statement as the value to our function input variable (inputs.postgres_sql_query), reads out the CTI for our artifact.value and returns a list of related IP addresses. Let’s elaborate on our select statement which is specifically crafted for querying Postgres jsonb columns (see example 1.6). Line 1 shows the select statement and starting from line 3 there is an extract of the Recorded Future CTI for IOC 93.184.220.29.

•IP_lookup is the name of the column which is of the jsonb data type.

•data is the first key element of the JSON string stored in the jsonb column. This key holds the complete CTI that has been loaded for an RF matched IP address.

•relatedEntities is a subkey of the data key element. It stores all related entities like e.g. related IP addresses.

•The entity key in the where clause is a subkey of the data key element.

•The name key is a subkey of the entity key element. It stores the IOC value which in our example is the IP address 93.184.220.29.

•incident.id is the id number of the Resilient incident that is triggering a rule. This is required because we are storing the incident id along with the CTI in our Postgres test database.

Example 1.6: PostgreSQL select statement for jsonb

Starting from line 12 we can see a list of related IP addresses. These are all provided back as part of the result set (step 12). We are giving the result set of function Test db related indicator the output name destinationip_where_clause. By defining an output name to a function you can buffer the result set for later use in the same workflow. As you can see further down in figure 1.29, we are taking this function output into the value (workflow.properties.destinationip_where_clause) of our second function’s (QRadar function01) input variable (inputs.ariel_sql_query) in order to satisfy steps 13-14. In other words, this second function queries the QRadar Ariel database with the defined Ariel Query Language select statement and a where clause which is partially derived from the first function’s output.

Figure 1.29: Steps 11-15 – Rule / Workflow

Finally we can see the post-process script of the second function (bottom) which is firstly storing the query start and end time in pre-defined Resilient incident fields (lines 1-2) and then iterating over the result set coming from QRadar (lines 4-8). This result set is provided in the QRadar JSON format and it includes only related IP addresses that have a local relevance. For every related IP address a new artifact of the Resilient custom artifact type related_ip_address with the description "RECORDED FUTURE Related IP address for this original destinationip: artifact.value" is created.

As we want to populate the “Observed data network traffic” table of the Resilient incident with the local context of the related IP addresses and we also want to create STIX bundles for these, we are using the same automatic rule that we’ve been using for steps 7-10. We only needed to extend our match condition in order to additionally match on related IP addresses. See figure 1.30. Figure

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