IncMan Use Case: LogPoint Integration

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.

Goal:

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.

Integrations Used:

Implementation:

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.

 

logstash-1

 

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.

logstash-2

 

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.

logstash-3

 

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:

logstash-4

 

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:

logstash-5

 

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.

logstash-6

 

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.  

IncMan Use Case: Malicious Outbound Network Traffic

This use case demonstrates how to use IncMan’s integrations 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.

Goal:

Automatically receive alerts for potentially malicious outbound network traffic from a device such as a web gateway or IDS/IPS, create an Incident and perform automated Notification, Enrichment and Containment tasks assess and mitigate any potential risk to the organization.

Integrations Used:

Implementation:

Creating an R3 Rapid Response Runbook

The first step in creating an automated response to this type of incident is to create an R3 Rapid Response Runbook which will perform Enrichment, and if necessary, Containment actions as part of the response.  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 this use case, we will use integrations with Cisco Threatgrid, Hacker Target, McAfee Web Gateway, PostgreSQL and VirusTotal, as well as some of IncMan’s built-in Enrichment functions, to perform Enrichment 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; IP Geolocation, a WHOIS query and a reverse DNS query. 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, additional Enrichment actions are utilized to query two different threat reputation services. In this case, we have chosen to use both VirusTotal and Cisco Threatgrid, although IncMan also has integrations with several other threat reputation and intelligence services, such as Recorded Future and Threat Connect.  Following each of these two queries, an automated decision point is reached. These automated decision points will examine the information returned by each threat reputation service and determine if the results meet a certain user-defined threshold.  This user-defined threshold could be based on any of the information returned by each service, such as the overall threat score or the number o records returned.

If neither threat reputation service returns information which meets or exceeds the user-defined thresholds, no further automated actions will be taken and the information will be saved as part of the Incident and will be available to the security analyst to review at any time.

If either threat reputation service returns information which meets or exceeds the user-defined thresholds, the Runbook will continue by performing a query of the IT asset inventory using a PostgreSQL Enrichment action. Like the previous basic information gathering Enrichment actions, this information will not be used directly for automated decision making; however, it will also be available to the security analyst to review as part of the Incident record.

The final Enrichment action utilizes the same PostgreSQL integration, this time to query a database of known-good, or whitelisted hosts to see if the external destination IP address matches a known-good host.  This assumes that the organization has pre-populated the table with the IP addresses, hostnames and other information regarding hosts which are known to be non-malicious or should not be blocked for one reason or another.  

Following this final Enrichment action, another automated decision point is reached. This decision point will determine if the query of the known-good host database yielded any results. If the external destination IP address matches a known-good host, the runbook will conclude without further actions.  If no matches were found, a special type of decision point will be reached; a User Choice decision. A User Choice decision will temporarily halt the automatic execution of the Runbook and will prompt the security analyst to make a manual decision.  In this case, the security analyst is prompted with the question “Would you like to block the destination IP address?” While the Runbook is temporarily paused, the security analyst has the opportunity to examine the results of all the previous Enrichment actions as part of the manual decision-making process. This step is entirely optional, however, adds an additional layer of assurance that the blocking the destination IP address will not result in adverse consequences. Once the security analyst makes a decision and selects the appropriate option, the automated execution of the Runbook will continue.

If the security analyst determines that the destination IP address should not be blocked, the Runbook will conclude without further action. If the security analyst determines that the destination IP address should be blocked, a Containment action will utilize IncMan’s integration with McAfee Web Gateway to block the address. Following this Containment action, the Runbook will conclude.

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.

 

Malicious outbound network traffic 2

 

From the Runbook tab of the Incident Template wizard, the previously created Malicious Outbound Traffic 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.

 

Malicious outbound network traffic 3

 

In this use case, an alert received from a simulated web gateway is used to initiate automatic incident creation within IncMan.  However, a SIEM integration or email could also be utilized to achieve the same outcome. A new syslog Incoming Event Automation rule is added and the defined action is to generate a new incident from the previously created Malicious Outbound Traffic Incident Template.

 

Malicious outbound network traffic 5

 

Solution in Action

When a syslog message matching the criteria pre-defined for the detection of malicious outbound network traffic, IncMan will automatically generate a new incident based on the Malicious Outbound Traffic Incident Template.

Without requiring any action on the part of an analyst, the Malicious Outbound Traffic Runbook is automatically initiated, performing the Enrichment actions and pausing at the User Choice decision point.  At this point, the security analyst has the opportunity to review all of the information gathered from the previous Enrichment actions, including the information returned from VirusTotal.

 

Malicious outbound network traffic 6

 

In this case, VirusTotal has returned dozens of results matching the destination IP address.  Based on this information, the security analyst has determined that blocking the destination IP address is the appropriate action and approves the User Choice decision. At this point, the automation continues and the McAfee Web Gateway Containment action is executed before the Runbook execution concludes.

 

Malicious outbound network traffic 7

 

This entire process, from receipt to containment, has taken place in a matter of minutes, likely before a security analyst would have been able to even manually acknowledge the alert under normal circumstances. IncMan’s automation and orchestration functions automated the initial response and provided the security analyst with all the information necessary to make an informed decision and contain the threat immediately.