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 220.127.116.11 and 18.104.22.168 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.
Figure 1.27: Steps 11-15 – Functions diagram
Figure 1.28: Steps 11-15 – RECORDED FUTURE: Verify Indicator. . .
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 22.214.171.124.
•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 126.96.36.199.
•artifact.value is derived from triggering the menu-item rule RECORDED FUTURE: Verify Indicator Related IP address.
•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
Figure 1.30: Steps 7-10 – Same automatic rule for related IP addresses