Following on from my recent blog post entitled “Meltdown and Spectre – What They Mean to the Enterprise” published in January, I wanted to take a closer look at how these types of hardware vulnerabilities could (and should) easily be detected, managed and mitigated using Security Orchestration, Automation and Response (SOAR) technology, for example with a platform such as IncMan from DFLabs.
Using Meltdown and Spectre as a use case, I wanted to enlighten you about the automated processes an organization can undertake. There are many pros and cons for using automation, but if used in the correct way it can significantly improve Security Operations Center (SOC) efficiencies, saving security analyst many man hours of mundane tasks. Alerts can also potentially be responded to and contained before an analyst has even been notified. Using IncMan’s integrations and R3 Rapid Response Runbooks, SOCs can quickly respond to such an alert when a vulnerability is detected. The overall goals would be as follows, in order to reduce the risk these vulnerabilities present to the organization.
1) Automatically receive alerts for the host which have been identified as being vulnerable to Meltdown or Spectre.
2) Create an Incident and perform automated Notification, Enrichment and Containment tasks.
Let’s move on to the implementation stages. Where should you start? For ease I will break it down into 3 simple sections, creating a runbook, utilizing the rebook and seeing the runbook in action. So, let’s begin…
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.
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 host name, 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.
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.
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 host name and host IP address will be used as inputs to the runbook and the runbook will be automatically executed.
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.
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.
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).
How easy was that? The 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.