The integration between DFLabs’ IncMan R3 Rapid Response Runbooks and Carbon Black Defense’s next-generation antivirus and EDR solution allows companies to automate evidence gathering and threat containment efforts, and cut dwell times down to a manageable level.
Equipped with strong evidence data gathered from Carbon Black Defense, analysts and security teams can quickly disposition and act to remediate an incident. Carbon Black Defense uses their award-winning Streaming Prevention technology to take a holistic approach to an organization’s critical infrastructure.
Sophisticated attacks that organizations have been experiencing cause traditional antivirus to become ineffective. Signature-based detection mechanisms can still detect known threats, but the new generation of non-malware attacks are going undetected in our networks and lying dormant for extended periods of time, enabling attackers to use our environments as their own personal playground.
To manage these deficiencies, Security Operation Centers are employing a wider range of tools to close the gap created by their antivirus solution. Evidence gathering across these tools have added to an analyst’s investigational times, which are allowing our adversaries ample time to secure their foothold in our networks.
Three common problems include:
- Attack vectors have morphed from file to file-less tactics which have caused traditional, signature-based antivirus to no longer be an effective detection mechanism
- Dwell time is being measured in days which have exceeded triple-digit figures
- Manual evidence gathering costs Security Operations teams valuable time when investigating possible incidents
DFLabs and Carbon Black Solution
An incident can turn into a breach in a few minutes, and this makes early detection and remediation a crucial aspect of an organization’s security program. Utilizing IncMan’s integration with Carbon Black Defense allows organizations to automate evidence gathering at their endpoints and present their analysts with critical information such as running processes, system information, and historical event detail to accelerate their decision-making ability to quickly remediate an issue.
These remediation tasks range from terminating processes on a victim machine to completely removing it from the network to allow for hands-on investigation and recovery.
About Carbon Black Defense
Carbon Black Defense is a next-generation antivirus and endpoint detection and remediation solution which utilizes Carbon Black’s proprietary Streaming Prevention technology to protect organizations from the full spectrum of malware and non-malware attacks.
By leveraging event stream processing, Streaming Prevention in Carbon Black Defense continuously updates risk profiles made from endpoint activity and when multiple potentially malicious events are observed, Carbon Black Defense will take action to block the would-be attack. This next-generation antivirus solution is proving why Carbon Black Defense will be the industry’s de facto standard in the following years.
An IDS alert is received and triggers an incident in IncMan. Through an R3 Rapid Response Runbook, enrichment actions are initiated by first querying IP reputation services for the source of the suspicious activity. A second IP reputation service is then queried to verify the results of the first query. Once the reputation checks have been completed, the priority of the incident is set according to the results of the reputation checks and a ticket is opened in the organization’s ticket management system.
IncMan continues to process the runbook by gathering additional enrichment data for the incident handler. User account information is pulled from Active Directory and Carbon Black Defense is queried to collect system information, including all running processes on the victim machine. In addition to system information, IncMan also queries Carbon Black Defense events from the victim machine observed in the last 30 days.
Once the enrichment information is gathered, the incident handler will receive notification of the incident. The incident handler will be prompted with a User Choice decision to determine if containment actions may be appropriate. The incident handler can review the information gathered up to this point to determine if automated containment actions should be performed at this point. If the incident handler determines the activity is malicious and automated containment actions are appropriate, the machine will be quarantined from the network and the source address will be blocked at the firewall.
Carbon Black Defense Actions
- Directory Listing
- Download File
- Event Details
- List Processes
- Memory Dump
- Policies List
- Search Into Events
- Search Process
- System Info
- Change Device Status
- Delete File
- Terminate Process
Carbon Black Defense is an extremely powerful endpoint solution, capable of detecting advanced threats, supporting detail data enrichment, and enabling rapid incident response. Orchestrating actions between Carbon Black Defense and other third-party solutions through IncMan integrations allows organizations to harness the power of Carbon Black Defense at any stage of the incident response process, providing a more efficient and effective response process.
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.
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.
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 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.
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.
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).
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.
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.
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:
The R3 Runbook
1. The FQDN is automatically extracted from the incident alert and then sent to Cisco Umbrella Investigate for a classification.
2. Depending on the outcome – whether Cisco Umbrella Investigate classifies the FQDN as benign or malicious – we can take one of two different paths.
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.
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.
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.
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.
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.