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
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.
and here is the enriched event in Splunk:
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:
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.
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...