This use case demonstrates how to use IncMan’s integration with LogPoint and R3 Rapid Response Runbooks to quickly respond to an alert indicating potentially malicious network traffic originating from an internal host, destined for an unknown host on the Internet.
Automatically receive alerts for potentially malicious outbound network traffic from LogPoint, create an Incident within IncMan and use IncMan to perform automated Notification, Enrichment and Containment tasks to assess and mitigate any potential risk to the organization.
Configuring LogPoint to Forward Events
Prior to configuring IncMan, LogPoint must be configured to forward relevant events to IncMan. A custom LogPoint plugin is available from LogPoint which makes the setup and maintenance of these forwarding rules quick and easy. LogPoint event forwarding can be configured on a per-rule basis via the alert rule settings, or in bulk via the plugin settings. Once configured, the LogPoint plugin will forward all matching events to the IncMan server via syslog in CEF format.
Creating an R3 Rapid Response Runbook
The first step in creating an automated response to any event forwarded from LogPoint is to create an R3 Rapid Response Runbook which will perform automated actions as part of the response to the event. We will assume that the alert has provided a minimum of a source IP address and a destination IP address, although the alert will likely contain much more detailed information. In addition to the LogPoint integration, this use case will use integrations with Hacker Target, Palo Alto Networks NGFW, Microsoft SQL Server, and VirusTotal, as well as some of IncMan’s built-in Enrichment functions, to perform Enrichment, Notification and Containment actions. The specific integrations used in this use case could easily be replaced with other similar technology already deployed in the organization.
The Runbook begins by performing several basic information gathering Enrichment actions; a WHOIS query, IP Geolocation and a reverse DNS query on the malicious external destination IP address. In this case, this information is not used as part of the automated decision-making process, although it easily could be. Instead, this information will be automatically saved as part of the Incident and will be available to the security analyst to review at any time.
Following these basic information gathering Enrichment actions, an integration with Palo Alto Network’s NGFW is used to perform a Containment action, blocking the malicious external destination IP address at the network perimeter.
Once the immediate threat has been contained by blocking the malicious external destination IP address at the perimeter, IncMan’s integration with LogPoint is used to query further information from LogPoint via an Enrichment action. A specially crafted LogPoint search query is used to query LogPoint for a list of all IP addresses the internal source IP address has communicated within the past 30 minutes. This list of IP addresses is then passed to an additional Enrichment action which will perform threat reputation queries on each of the IP addresses. In this use case, IncMan’s integration with VirusTotal is used to perform the threat reputation queries, however, another threat reputation source could easily be substituted here as well (for example, Cisco Umbrella, McAfee ATD or Recorded Future).
Following the threat reputation queries, a decision point is reached at which point any other external IP addresses the original internal source IP address has been observed communicating with which have now been deemed malicious through the threat reputation service will continue to be processed further. This further processing begins by performing the same set of Enrichment and Containment actions on the additional malicious external IP addresses that the original malicious external IP address received.
After basic Enrichment has been performed on these additional malicious external IP addresses and these addresses have been blocked at the perimeter, the Runbook again utilizes a LogPoint Enrichment action to query further information from LogPoint. This time, a specially crafted LogPoint query is used to search LogPoint for a list of any other internal hosts which have been observed communicating with any of the additionally identified malicious external IP addresses.
Since these additionally identified malicious external IP addresses have already been blocked at the perimeter firewall, no additional containment actions are necessary at this point. However, it is important that security analysts follow up on each of the internal hosts which have been identified as communicating with malicious external IP addresses. To that end, an Enrichment action is used to query a Microsoft SQL Server database containing the organizations IT asset inventory. While this information is not used in further automated actions, it will help the security analysts identify and prioritize the investigation of these hosts. Finally, to ensure that each additionally identified internal host is properly investigated, a Notification action is used to notify security managers about each individual host which has been identified.
Using IncMan’s integration with LogPoint, this Runbook has not only enriched and contained the information from the original alert, it has also pivoted twice; identifying, enriching and containing any additional external malicious IP addresses that the original internal source IP address may have communicated with, then identifying any other internal hosts which may have communicated with these additionally identified malicious external IP addresses. This automated process closely mirrors the manual process security analysts would have taken to handle this alert, however automating this process has saved the security team hours of manual research and information aggregation.
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 potentially malicious outbound network traffic. 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 Malicious LogPoint Runbook is selected and set to autorun. Each time this template is used to generate an incident, the appropriate information such as the source and destination IP addresses will be used as inputs to the Runbook and the Runbook will be automatically executed.
Once the Incident Template has been defined, all that is left to do is create the rule which will trigger the IncMan Incident to be created based on the template when a matching event is received from LogPoint. These rules can be based on any component of the event, including application name, rule ID, system attributes or matching text. For example:
With the appropriate rule in place, an action must be defined. In this case, the desired action is to create a new Incident using our previously defined Incident Template and assign the incident to the incident queue, as shown:
Finally, we define the variable artifacts that should be automatically extracted from the alert and added to the IncMan Incident. Although the previously defined runbook utilizes only source and destination IP address, additional information may be available and could be added to the Incident. In this case, source and destination port, as well as bytes in and bytes out are also extracted from the event.
Solution in Action
From this point forward, any event received by IncMan which matches the criteria set in the syslog rule will generate a new IncMan Incident according to the previously configured Incident Template and contain the specified variable artifacts extracted from the event. As part of this process, the Runbook created in the previous section will be automatically assigned to the incident and executed, perform Enrichment and Containment on both the original event information, as well as the additional information gathered from LogPoint.
What may have previously take hours of analyst time will be automatically executed in a matter of minutes, potentially completing before an analyst would have had time to even acknowledge the alert.
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.