PLATFORM

Splunk Data Stream Processor & Splunk Phantom - The Need For Speed

What is the benefit of combining the power of Data Stream Processor (DSP) and Splunk Phantom? I will give you a hint - the answer involves speed and extensibility.

In today's security landscape, speed to detect and mitigate security attacks or outages is of the utmost importance. A slow response to a security incident can have a detrimental impact to your organization's bottom line. 

In order to respond to incidents faster, security analysts need their security tools to provide rapid access to contextual information about a security incident or outage. This provides actionable insights that allow the analyst to respond faster and more efficiently. For instance, wouldn't it be great if you had the ability to automatically add temporal context to an event, such as geo-locating its IP address or running its IP reputation, before sending it to Splunk?

Let’s review a few scenarios.

Scenario 1: Detection and Response Automation

This is achieved by combining DSP’s ability to detect outliers with Phantom’s ability to automate response and remediation from within the stream itself, resulting in lightning speed detection and response. The breadth of use cases for this category spans across security, fraud, IT operations, and more. 

To illustrate this set of use cases, let's highlight a few examples:

  • When 3 consecutive failed login attempts from a given IP are detected in DSP, send the source IP to Phantom for the IP to be contained and blocked in the firewall automatically
  • When the number of application errors per minute exceeds a given threshold, trigger an automated action to restart the application nodes
  • Real-time detection of connection from known bad IP addresses resulting in an action being triggered to lock an account in active directory

Diagram illustrating the corresponding data flow for such use cases

Splunk Phantom

Scenario 2: Enrichment and Schema at Write

This is achieved by using the full breadth of Phantom’s out of the box investigative actions and making them available to execute from any DSP pipeline. This set of use cases expects to have filtering on a given DSP stream prior to invoking Phantom actions. It’s critical to ensure the Phantom cluster is properly sized to scale to the expected volume generated from the DSP side.

What makes this set of use cases so powerful is that it opens up a wide range of enrichment and automated investigation capabilities, and makes them available on any DSP pipeline. Compliance is another use case, where DSP can be used to apply enrichment or investigative actions on raw events before masking the sensitive parts. 

Consequently, any Splunk user can reap the benefits of accessing the results of investigative tasks without necessarily exposing sensitive parts of the event. 

Let's pick an example:

For events where an IP address is detected to have high traffic > fetch the IP reputation > run a DNS lookup on that IP address before merging the results > send enriched event to Splunk.

Splunk Phantom

and here is the enriched event in Splunk:

Splunk Phantom

How powerful is that? Wait, that's not all...

Scenario 3: Phantom Event or Case Ingestion

Here, DSP acts as an ingestion source for Phantom events or cases. With DSP’s ability to filter and process events, select events can be configured to land on Phantom event or case queues. The same detection techniques described in the previous sections can be used here to trigger events or cases in Phantom. The key difference is that the automated response is in the form of an event or case instead of an action or playbook. It’s worth noting that the event or case can be configured to automatically kick off orchestration. 

Below is a sample DSP pipeline that triggers a Phantom event when a critical application error is found in the stream of events:

Splunk Phantom

Note the "throttle" and the “concatenate” steps in the above pipeline. The concatenate step captures the response from Phantom (which includes the Phantom container ID) and merges it with the original body of the event. The container ID can be used in Splunk for contextual drill down to Phantom. 

Splunk Phantom

How to Get Started Now? 

Simply download the Phantom plugin from this GitHub page. The page also includes instructions on how to use and deploy the plugin, in addition to sample pipeline templates to help you get up and running faster with it. 

The plugin comes with the following functions that can be used at any point in a DSP pipeline.

  • Phantom Action: allows you to trigger any Phantom action and capture the corresponding response from the DSP server. The action can be any containment or investigative action. The response from the action can be used for data enrichment purposes of the initial event.
  • Phantom Playbook: allows you to trigger any playbook to orchestrate a response from the DSP pipeline.
  • Phantom Event or Case:  allows you to trigger events or cases in Phantom.

Give this plugin a try and stay tuned for more updates on this topic. Until then... 

Happy Splunking!!

Elias Haddad
Posted by

Elias Haddad

Elias is an Emerging Market Presales Architect working out of the Dubai office. Prior to that, he was a Product Manager responsible for Splunk data ingestion and held various pre-sales, post-sales and business development positions. Elias lives in Dubai and graduated from Purdue University with a master’s degree in computer engineering.