IncMan Use Case: Meltdown and Spectre Vulnerabilities

This use case demonstrates how to use IncMan’s integrations and R3 Rapid Response Runbooks to quickly respond to hosts exposed to the Meltdown and Spectre vulnerabilities, reducing the risks posed by these potentially critical issues.

Goal:

Automatically receive alerts for host which have been identified as being vulnerable to Meltdown or Spectre, create an Incident and perform automated Notification, Enrichment and Containment tasks to reduce the risk these vulnerabilities present to the organization.

Integrations Used:

Implementation

Creating an R3 Rapid Response Runbook

The first step in reducing the risk from the Meltdown and Spectre vulnerabilities is to create a runbook to handle alerts for newly detected vulnerable hosts.  In this use case, we will use integrations with Jira, McAfee ePO, McAfee Web Gateway, MSSQL Server and QRadar to perform Notification, Enrichment and Containment actions; however, this can easily be adapted to include any other technology integrations as well.

meltdown-1

 

Using a Jira Notification action, a new Jira issue is created.  This Notification action should notify the IT or Infrastructure teams and initiate the organizations normal vulnerability management process.

Next, an MSSQL Server Enrichment action is used to query an IT asset inventory for the host name of the vulnerable host, which is passed to the runbook automatically when the incident is created.  This asset information is then available to the analyst for further review.

Once the IT asset information is retrieved, a decision point is reached.  If the IT asset information indicates that the host is a server, one path (the top path) is taken.  If the IT asset information indicates that the host is not a server, another path (the bottom path) is taken.  

If the asset is determined to be a server the Jira Enrichment action is used to update the Jira issue, informing the appropriate parties that the host has been determined to be a server and should be treated as a higher priority.  Next, two McAfee ePO Enrichment actions are performed. The first Enrichment action queries McAfee ePO for the system information of the given hostname, providing the analyst with additional information. The second Enrichment action uses McAfee ePO to tag the host with the appropriate tag. Finally, a Task is added to IncMan reminding the analyst to follow up with the appropriate teams to ensure that the vulnerability has been appropriately mitigated.

If the asset is determined not to be a server, the two previously mentioned McAfee ePO Enrichment actions are immediately be run (System Info and TAG). Following these two Enrichment actions, a McAfee Web Gateway Containment action is used to block the host from communicating outside of the network. This Containment step is completely optional but is performed here on non-servers only to minimize the Containment action’s potential impact on critical systems.

Utilizing the R3 Rapid Response Runbook

Once the new runbook is created, IncMan must be told how and when to automate the use of this runbook. This is achieved by creating an Incident Template, which will be used any time an incident is generated for a Meltdown or Spectre vulnerability. Through this incident template, critical pieces of information such as Type, Summary, Category can be automatically applied to the newly created incident.

meltdown-2

 

From the Runbook tab of the Incident Template wizard, the previously created Meltdown and Spectre runbook is selected and set to autorun. Each time this template is used to generate an incident, the appropriate information such as hostname and host IP address will be used as inputs to the runbook and the runbook will be automatically executed.

meltdown-3

 

In this use case, alerts from QRadar are utilized to initiate automatic incident creation within IncMan.  However, another SIEM integration, syslog or email could also be utilized to achieve the same outcome. A new QRadar Incoming Event Automation rule is added and the defined action is to generate a new incident from the previously created Meltdown and Spectre Incident Template.

 

meltdown-4

Solution in Action

When a QRadar Alert is generated matching the criteria defined for a Meltdown or Spectre vulnerability detection, IncMan will automatically generate a new incident based on the Meltdown and Spectre Incident Template.

meltdown-5

Without requiring any action on the part of an analyst, the Meltdown and Spectre runbook is automatically initiated, performing the defined Notification, Enrichment and Containment actions (in the example shown here, the ‘server’ path is taken).

meltdown-6

 

This entire process has taken place in a matter of minutes, likely before anyone has even had time to acknowledge the alert.  As an analyst begins to manually examine the alert, many of the mundane tasks have already been completed, allowing the analyst to focus on the tasks which require human intervention and reducing the time required to remediate this issue, ultimately reducing risk to the organization.

R3 Rapid Response Runbook for Spear Phishing

According to Verizon’s Data Breach Investigations report 2017, social engineering was a factor in 43% of breaches, with Phishing accounting for 93% of social attacks.

DFlabs has worked closely with our customers to draft and deploy Phishing specific runbooks. In this article, we take a look at an example R3 Phishing runbook below.

The Premise
Our premise is that an incident appears to be a Spear Phishing attempt has been forwarded to the SOC. The SOC team must qualify the incident and determine what needs to be done to mitigate the attack.

We begin our investigation with an incident observable, a fully qualified domain name (FQDN).

We will correlate the FQDN with several external threat intelligence services to assess whether this is truly an ongoing Phishing attempt or a benign false positive. We have used VirusTotal and Cisco Umbrella in this example, but other threat intelligence and malware services could be used instead.

We have 3 different potential outcomes and associated decision paths:

R3 Rapid Response Runbook for Spear Phishing 7


The R3 Runbook

1. The FQDN is automatically extracted from the incident alert and then sent to Cisco Umbrella Investigate for a classification.

R3 Rapid Response Runbook for Spear Phishing 1

 

2. Depending on the outcome – whether Cisco Umbrella Investigate classifies the FQDN as benign or malicious – we can take one of two different paths.

R3 Rapid Response Runbook for Spear Phishing 2

 

3. The FQDN will be rechecked with VirusTotal to verify the result. We do this whether the first classification was malicious or benign. At this point we do not know whether one of the two services is returning a false positive or a false negative, so we do a double check.

R3 Rapid Response Runbook for Spear Phishing 3

 

4. IF both external 3rd party queries confirm that the FQDN is malicious, we have a high degree of certainty that this is a harmful Phishing attempt and can step through automatically to containment. In our example, we automatically block the domain on a web gateway.

R3 Rapid Response Runbook for Spear Phishing 4

 

5. Alternatively, if only one of the two queries returns a malicious classification, we need to hand the runbook off to a security analyst to conduct a manual investigation. At this point, we cannot determine in an automated manner where the misclassification resides. It could be that one of the services has stale data, or doesn’t include the FQDN in its database. With the ambiguous result, we lack the degree of confidence in the detection to trust executing fully automated containment.

R3 Rapid Response Runbook for Spear Phishing 5

 

6. If both VirusTotal and Cisco Umbrella Investigate return a non-malicious classification, no further action will be necessary at this point. We will notify the relevant users that the incident has been resolved as a false positive and can close the case for now.

R3 Rapid Response Runbook for Spear Phishing 6

 

This R3 Phishing Runbook demonstrates the flexibility and efficiency of automating incident response . Incident Qualification is automated as much as is feasible but keeps a human in the loop when cognitive skills are required. It only automates containment when the degree of confidence is sufficient. It eliminates false positives without requiring human intervention.