Ingest Incidents from a SIEM Using Splunk
Step-by-step tutorial for ingesting and handling incidents and events from Splunk.
This tutorial shows you how to design the incident lifecycle using Splunk, from ingesting to closing security events.
The incident lifecycle is designed for Cortex XSOAR (SOC) engineers or architects. The aim is to automate as much of the process as possible and leave the analyst to make accurate and confident decisions when needed.
By the end of this tutorial, you should have configured your Splunk integration, set up a basic flow, started ingesting incidents from the Splunk to Cortex XSOAR, which enables the analyst to start investigating an incident.
This tutorial includes the following stages.
Depending on how you design the incident lifecycle, many actions are performed automatically even before the analyst investigates an incident. For example, incidents may be closed as duplicates, closed as false-positives, data is enriched, etc.
Usually, the analyst does the following:
- Selects an open incident.
- Analyzes enough data to make decisions based on the steps that have already been taken (in the Incident Summary, and Work Plan, etc).
- Collects additional data by running commands on third-party integrations, such as VirusTotal, WildFire, etc.
- Collaborates with SOC team members in the War Room (ask questions, post comments, etc).
- Decides how to handle the incident. Usually the architect designs the Incident page to include a set of buttons that the analyst can select from (Escalate, Close, etc.)
- Activates one of several possible responses either within Cortex XSOAR or externally (for example, open a ticket for IT).
- Closes the incident and specify a closed reason.
To explain the architect flow we need to define and design the incident lifecycle using Splunk.
Define the incident Type
The first step when planning your incident identification and response is to create a basic outline of the flows that your SOC handles. Consider the same information in the Architect Flow in using QRadar.
Plan the workflow for each incident type
This section describes the aspects of the workflow that occur before the analyst is assigned.
- Assign incidents to the flowIn Cortex XSOAR, incident classification is the process by which an incoming security event/alert is assigned to a Cortex XSOAR incident type. When you fetch security events from Splunk, the event data is ingested in JSON format. You classify the security event based on the fields (keys) from the event JSON.Install theSplunkContent Pack, which includes Splunk Classifiers, although you do not need to define a classifier, as all Splunk incidents are ingested as theSplunk Notable Genericincident type (when you assign incident type to the integration in Cortex XSOAR).
- Pre-process incoming incidentsUsually you want to eliminate false-positives and deduplicate incidents, which enables you to maintain a clean set of incidents for analysts.Pre-processing rules enable you to perform certain actions on security events before they are ingested as incidents in Cortex XSOAR. You perform actions when the condition of a rule is met. For example, link the incoming incident to an existing incident, or under configured conditions, drop the incoming incident altogether. You can also run a script on the incident when the conditions are met. For an example, see the Phishing Pre-Process Tutorial.
- Run a playbook on the incidentAfter the security event is ingested, classified to an Cortex XSOAR incident type, and filtered through the pre-processing rules, the default playbook for the incident type is run on the incident. Usually, the default playbook extracts one or a combination of the following:
Depending on how you design the workflow for the incident type, when the playbook completes its run, it is the first time that the incident data is presented to analysts in the layout. Although Splunk comes out of the box with theSplunkPyplaybook, consider the following when customizing or creating your own playbook.
- Extracts and enriches indicators
- Determines the incident severity
- Assigns the incident to an analyst for manual review
- Plan the incident process per incident type (full-automated, manual, or hybrid).
- Steps an incident goes through.
- Analyst intervention in the incident (communication tasks, ad-hoc tasks, and manual tasks).
- How data is displayed in Cortex XSOAR.
Incident Lifecycle using Splunk
Using Cortex XSOAR, you can define integrations with your security products, your security services and any other component that makes up your security operations environment. You can then ingest events from these integrations and transform them into incidents in Cortex XSOAR.
After the incidents are created, you can run playbooks on these incidents to enrich them with information from other products and services, which helps you complete the picture. Usually, you can use automation to determine if an incident requires further investigation or can be closed based on the findings. This enables your analysts to focus on the minority of incidents that require further investigation.
- Analyze SOC’s current workflows and categorize the incident types you expect to handle.
- Plan what the process should be per each type of incident (fully automated or manual or hybrid).
- Put your plan in action, by defining the following per each incident type:
- What incidents are going to be included in this flow (classification).
- In many cases you might want to eliminate false positives and duplicate incidents early (preprocessing).
- What steps each incident should go through (playbook).
- When analyst intervention is required, if at all (also in the playbook, and dashboards).
- How the incident data is going to be presented (mapping).
- How the incident details would be presented to the analyst (layouts, dashboards).
- What happens when the incident is over (for example, close incident and force or encourage analyst to specify close reason).
This tutorial assumes you already have components installed and configured in your Cortex XSOAR instance, as workflows require their functionality. For example, a playbook task might send an email notification to users, but if you do not have an outgoing email integration configured, you cannot complete the playbook workflow.
- Install the Cortex XSOAR server and verify that it is running.
- Configure the following integrations by installing the required Content Packs in the Marketplace:To install and configure the Splunk Content Pack, see Set up your Splunk integration instance.
Set up your Splunk integration instance
In Cortex XSOAR you can ingest Splunk notable events, queries and alerts through one of the following:
- Demisto Add on for Splunk from the Splunkbase.The Demisto Add on for Splunk works inside the Splunk platform. It is installed on Splunk and it is used to establish a connection between Splunk and Cortex XSOAR. You create an alert or event by selecting aCreate Demisto Event. When sending a single alert or event, it needs to be configured every time in Cortex XSOAR.
- Enables you to run queries on Splunk, edit notable events, fetch results from Splunk, parse raw events, etc. This is setup on Splunk’s API port, so you have control over which events can be ingested into Cortex XSOAR. You do not need to go to Splunk each time you ingest. Everything is configured when you map the fields in Cortex XSOAR. This tutorial uses the SplunkPy integration.
To set up your Splunk integration you need to install the Splunk Content Pack from the Marketplace. The integration enables you to do the following:
- Splunk Notable QueriesIn Cortex XSOAR, the query fetches notable events from Splunk Enterprise Security (ES). The integration uses the Splunk ES Notable macro, which leverages built-in Splunk ES capabilities that provide additional data with every notable fetched event.
- Native enrichmentYou can enable relevant enrichment notable events, when defining the integration instance. The fetched notable events can contain the results ofdrilldownsearches. Splunk searches are configured by the user within the Splunk alerts. Users can run additional searches, so those search results are returned in Cortex XSOAR incidents.When fetching incidents, data may be returned from the look-up table, which contains data about the assets and identities that are detected within the notable event. This means you do not need to run additional playbooks or view additional commands. This is all part of the initial fetch.
- Mirroring CapabilitiesBy enabling the mirroring option (can be inbound, outbound, or both), selected fields can be mirrored from Spluk ES to Cortex XSOAR and vice versa. Some specific fields are supported from Splunk to Cortex xSOAR, such as owner. Urgency and status can be mirrored in both directions. If a Splunk user closes Notable Events this effectively closes the incident in Cortex XSOAR. You can also do this on Cortex XSOAR, which closes the Splunk side.Outbound mirroring is recommended for Cortex version 6.2 and above.
- OnboardingThe Content Pack includes mappers, so that you can see all relevant fields that exist on the notable events, assets, identities, and on the drill down events. All of this data is easily mapped into incident fields in Cortex XSOAR.In addition the Content Pack contains a Splunk playbook, which enables you to manage cases, assist with adjusting your alerts.
Before you begin, ensure that you have your Splunk credentials.
- Install the Splunk Content Pack.
- Go to the Marketplace.
- Search for Splunk.
- Click on the Content Pack and clickInstall.
- ClickInstallagain to confirm the installation.
- Configure the SplunkPy instance.Before you configure the instance:
- Ensure you have your Splunk authentication details.
- Define your email sender integration and the SIEM admin email address.
- Select.SettingsIntegrationsServers & ServicesSplunkPy
- ClickAdd Instance.
- SelectFetches incidents.
- UnderClassifier, selectN/A.
- UnderIncident Type, selectSplunk Notable Generic.You do not need to specify the classifier as all Splunk incidents are ingested as Splunk Notable Generic. As you become more familiar with Cortex XSOAR, you can create custom incident types as needed instead of using the Splunk Notable Generic incident type.
- UnderMapper (incoming), selectSplunk - Notable Generic Incoming Mapper.
- UnderMapper (outgoing), selectSplunk - Notable Generic Outgoing Mapper.
- Type the Host -ip, username, password, and Port.
- Keep theGet notable events EQ queryas is, as we use the Notable macro when ingesting events. You can create a more granular search by specifying specific conditions such as specific security domain, event ID, etc.
- Keep the defaults for fetch limit, first fetch timestamp, earliest time to fetch and latest time to fetch.
- To add mirroring in both environments, in theIncident Mirroring Directionfield, selectIncoming and Outgoing.Outgoing miroriring is recommended for Cortex XSOAR version 6.2 and above. If you enable mirroring, you need to add the timezone of the splunk server (in minutes). For example, if using GMT and the timezone is GMT +3 hours, set the timezone to +180. For UTC, set the timezone to 0. Set this only if the Splunk server is different than the Cortex XSOAR server. This is relevant only for fetching notable events.
- SelectClose Mirrored XSOAR IncidentandClose Mirrored Splunk Notable Event, so when closing in one environment, it closes in the other.
- In theEnrichment Typesfield, selectAsset,DrilldownandIdentity.This enrichment provides additional information about Assets, drilldown, and identities that are related to the notable events you ingest.
- ClickTestand thenSave & exit.
- Go to theIncidentspage and verify that incidents are being ingested.
Run a Playbook
After you define the instance and start ingesting incidents, the
Spunk Genericdefault playbook assigned to the Splunk incident type automatically processes the incoming incidents. No additional steps are required from the analyst to initiate the playbook run/incident-handling process.
You can change the default playbook by selecting
. You need to either duplicate or detach the incident type to edit.
Splunk Notable Generic
Every playbook has inputs that help determine how the playbook flows. The inputs (and outputs) are configured at the beginning of the playbook, under
- Enrich: Determines whether you want the playbook to enrich all of the indicators in the incident (default is true). As enrichment can be a very resource intensive operation, you may want to change this setting to false and enrich only specific indicators and only using certain integrations.If you do want to enrich indicators, you should ensure that you have enabled at least some of the out-of-the-box enrichment integrations, such as AutoFocus, VirusTotal, etc.
- UseCalculateSeverity: Determines if the severity of the incident is set based on the Calculate Severity playbook, or if you want to set the severity based on the Splunk severity value. By default, this input is set to true.
In the playbook inputs, if you select to enrich all of the indicators from the incident, the playbook extracts the indicators and uses whichever integrations you have enabled for the enrichment. Enriched indicators provide the analyst with more information about each indicator.
Entity Enrichment - Generic v2playbook checks for information about all kinds of indicators, including malicious URLs, domains, or IP addresses. It can also check against a list of VIP assets in your organization that might have been targeted, or detonate a file that was attached to the incident.
While these capabilities are available in the playbook, they are only available if you have enabled or installed integrations for these checks, such as VirusTotal, Threat Crowd, etc. For information about enabling additional integrations, refer to the integration documentation.
If you also configured the playbook to use the Calculate Severity playbook, the playbook takes the information from the enriched indicators and provides a severity based on the DBot score.
After the playbook gathers all of the necessary an SLA timer is triggered and the incident is assigned to an analyst for manual investigation. The manual investigation task requires that the analyst intervene to determine if the incident is a true positive or false positive.
If the incident is a true positive, an incident report is generated and the necessary remediation steps are taken.
If the incident is a false positive, the analyst can use the
Provide data for rule adjustmenttask (
Questionstab) to provide information that can help fine-tune the system for future cases.
The feedback from the analyst is sent to the Splunk administrator so they can review the suggested changes and make any necessary adjustments.
After events are fetched into Cortex XSOAR, the notable events appear as incidents in the Incidents page. All the information that is displayed in the respective tabs is determined by the layout you designed for the Splunk Notable Generic incident type.
The layout appearance, including which tabs, their order, names, etc., is customizable.
The analyst can click on the ID of any incident to view additional incident data that you configured for the incident type.
Incident Info View
Incident Infotab provides information about the incident itself. For example, when was the incident opened and updated, what’s the severity of the incident and from where did it originate. It gives you easy access to all of the indicators extracted from the incident, what is the current state of the incident, etc.
For example, in the
Work Plansection, you can see that the incident is currently on hold waiting for the analyst to manually investigate the incident.
The Notable Summary tab fetches the data from Splunk and provides it to you in one tab within Cortex XSOAR. For example, you can see how many of the events associated with the event were fetched (default is 50), the Splunk severity, status, urgency, etc.
The view includes all of the network data that is available from Splunk.
Drilldowntab, shows detailed drilldown data that was enriched from the Splunk Server, such as Error code, event code, event ID, etc.
Assetstab presents information about any critical assets that were involved in the event, whether they were targeted or tangentially related.
Identitiestab shows enriched identity information that was involved in the event, such as the source email address, identity tag, etc.
Recommended For You
Recommended videos not found.