> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/tutorials/cortex-xsoar-tutorials/readme/ingest-incidents-from-a-siem-using-splunk.md). # Ingest Incidents from a SIEM Using Splunk This tutorial shows you how to design a use case based on the incident lifecycle using Splunk, from ingesting to closing security events. The incident lifecycle is intended 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 will have configured your Splunk integration, set up a basic flow, and started ingesting incidents from Splunk to Cortex XSOAR. The analyst can then start investigating an incident. ### Architect Flow 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](/tutorials/cortex-xsoar-tutorials/readme/ingest-incidents-from-a-siem-using-qradar.md). **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 flow In 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 the **Splunk** content pack, which includes Splunk classifiers, although you do not need to define a classifier, as all Splunk incidents are ingested as the **Splunk Notable Generic** incident type (when you assign incident type to the integration in Cortex XSOAR). * Pre-process incoming incidents Usually 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 incident After the security event is ingested, classified to a Cortex XSOAR incident type, and filtered through the pre-processing rules, the default playbook for the incident type is run on the incident. In most cases, the default playbook does one or more of the following: * Extracts and enriches indicators * Determines the incident severity * Assigns the incident to an analyst for manual review Depending on how you design the workflow for the incident type, when the playbook completes its run the incident data is presented for the first time to analysts in the layouts and dashboards. The Splunk content pack out of the box includes the Spunk Generic default playbook. ### Analyst Flow Depending on how you design the incident life cycle, many actions are performed automatically before the analyst even sees an incident. For example, incidents may be closed as duplicates or false positives, data is enriched, and more. For most incidents, the analyst will: 1. Pick up an open incident. 2. View enough data to be able to make decisions including what steps have already been taken (Incident Summary, Work Plan). 3. Easily collect additional data by running commands on third-party tools. 4. Collaborate with SOC team members in the War Room; ask questions, post comments, and more. 5. Make an informed decision on how to handle the incident. A typical flow is to design the incident page to include a set of buttons that the analyst can select from (Escalate, Close, etc.) 6. Activate one of several possible responses either within Cortex XSOAR or externally (e.g., open a ticket for IT). 7. Close the incident and specify a close reason. ### Incident Lifecycle 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 (pre-processing). * 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). ### Prerequisites 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. 1. Install the Cortex XSOAR server and verify that it is running. 2. Configure the following integrations by installing the required content packs in Marketplace. | Integration Types | Examples | | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Messaging | [Gmail](https://xsoar.pan.dev/docs/reference/integrations/gmail) or [Microsoft Graph Mail](https://xsoar.pan.dev/docs/reference/integrations/microsoft-graph-mail) | | Outgoing email | [Mail Sender](https://xsoar.pan.dev/docs/reference/integrations/mail-sender-new) | | Provision Cortex XSOAR users | [Active Directory](https://xsoar.pan.dev/docs/reference/integrations/active-directory-query-v2) or [Okta](https://xsoar.pan.dev/docs/reference/integrations/okta-v2) | | Data enrichment and threat intelligence | [Wildfire](https://xsoar.pan.dev/docs/reference/integrations/wild-fire-v2) | ### 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](https://splunkbase.splunk.com/app/3448). 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 **Create Demisto Event**. When sending a single alert or event, it needs to be configured every time in Cortex XSOAR. * **SplunkPy** This tutorial uses the SplunkPy integration. It is set up on Splunk’s API port, so you control which events can be ingested into Cortex XSOAR, and you do not need to go to Splunk each time you ingest. Everything is configured when you map the fields in Cortex XSOAR. The SplunkPy integration enables you to run queries on Splunk, edit notable events, fetch results from Splunk, and parse raw events, as well as do the following: * **Splunk Notable Event Queries** In 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 enrichment** You can enable relevant enrichment for notable events when setting the integration instance parameters. The fetched notable events can contain the results of **`drilldown`** searches. 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 lookup 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** By enabling the mirroring option (can be inbound, outbound, or both), selected fields can be mirrored from Splunk 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. For example, if a Splunk user closes Notable Events this also closes the incident in Cortex XSOAR. Conversely, closing an incident in Cortex XSOAR closes it in Splunk Mirroring from Cortex XSOAR to Splunk is available for version 6.2 and above. You can use the **`!splunk-notable-event-edit status=`** Cortex XSOAR command to update the status of an incident in Splunk. Possible values are: 0 - Unassigned, 1 - Assigned, 2 - In Progress, 3 - Pending, 4 - Resolved, 5 - Closed. * **Onboarding** The Splunk 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 the Splunk Generic playbook, which enables you to manage cases and alerts. * **Searching** You can search in Splunk using the **`!splunk-search query`** Cortex XSOAR command and by creating a query using [Splunk Search Processing Language (SPL)](https://www.tutorialspoint.com/splunk/splunk_search_language.htm#:~:text=The%20Splunk%20Search%20Processing%20Language,terms%20from%20the%20result%20set): To set up your SplunkPy integration you need to install the Splunk content pack from Marketplace. Before you begin, ensure that you have your Splunk credentials. 1. Install the Splunk content pack. 1. Go to Marketplace. 2. Search for Splunk. 3. Click the content pack and click **Install**. 4. Click **Install** again to confirm the installation. 2. Configure the SplunkPy integration instance.

Note

For the purposes of this tutorial, use the default values for the parameters that are not mentioned in these steps. For information about all the parameters, see the SplunkPy integration documentation.

Before you configure the instance: * Ensure you have your Splunk authentication details. * Define your email sender integration and the SIEM admin email address. 1. Select Settings → INTEGRATIONS → Instances → **SplunkPy**. 2. Click **Add Instance**. 3. Select **Fetches incidents**. 4. Under **Classifier**, select **N/A**. You do not need to specify the classifier since 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. 5. Under **Incident Type**, select **Splunk Notable Generic**. 6. Under **Mapper (incoming)**, select **Splunk - Notable Generic Incoming Mapper**. 7. Under **Mapper (outgoing)**, select **Splunk - Notable Generic Outgoing Mapper**. ![splunk-integration.png](/files/7eAlz326MskGi84Bu4Fw) 8. Enter the **Host - IP**, **Username**, **Password**, and **Port**.

Tip

Use the default for Fetch events query, since Cortex XSOAR uses the Notable macro when ingesting events. You can create a more granular search by specifying specific conditions such as specific security domain or event ID.

9. (Optional) Set up mirroring between Splunk and Cortex XSOAR. Mirroring from Cortex XSOAR to Splunk is available for version 6.2 and above. For this tutorial, set the following mirroring parameters. For more information on incident mirroring with Splunk, see the [SplunkPy integration documentation](https://xsoar.pan.dev/docs/reference/integrations/splunk-py). 1. In the **Incident Mirroring Direction** field, select **Incoming and Outgoing**. 2. Set the **Timezone of the Splunk server, in minutes** parameter. For example, if using GMT and the time zone is GMT +3 hours, set the time zone to +180. For UTC, set the time zone to 0. Set this only if the Splunk server is different than the Cortex XSOAR server. This is relevant only for fetching and mirroring Notable Events. 3. Select **Close Mirrored XSOAR Incident** and **Close Mirrored Splunk Notable Event**, so when closing in one environment, it closes in the other. 10. In the **Enrichment Types** field, select **Asset**, **Drilldown** , or **Identity**. This enrichment provides additional information about assets, drilldown, and identities that are related to the notable events you ingest. 11. Click **Test** and then **Save & exit**. ![splunk-int-success.png](/files/eEfHdK1gYbiu6Y3k84Se) 3. Go to the **Incidents** page and verify that incidents are being ingested. ![splunk-incidents.png](/files/gDYu62FEqGeKmq6gveKx) ### Run a Playbook After you define the instance and start ingesting incidents, the **Spunk Generic** default 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 Settings → OBJECTS SETUP → Incidents → Types → Splunk Notable Generic → **Edit**. You need to either duplicate or detach the incident type to edit. **Playbook Inputs** Every playbook has inputs that help determine how the playbook flows. The inputs (and outputs) are configured at the beginning of the playbook, under **Playbook Triggered**. For a full description of each of the inputs for this playbook, see the [playbook documentation](https://xsoar.pan.dev/docs/reference/playbooks/q-radar-generic). For this tutorial, we focus on the following [Splunk Generic](https://xsoar.pan.dev/docs/reference/playbooks/splunk-generic) playbook inputs: * **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 one of the out-of-the-box enrichment integrations, such as VirusTotal. * **UseCalculateSeverity**: Determines if the severity of the incident is set based on the Calculate Severity playbook (default is true), or if you want to set the severity based on the Splunk severity value. If you 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. **Enrich Indicators** 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. The **Entity Enrichment - Generic v2** playbook 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 or Threat Crowd. For information about enabling additional integrations, see the [integration documentation](https://xsoar.pan.dev/docs/reference/index). **Manual Investigation** After the playbook gathers all of the relevant data, 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 adjustment** task (**Questions** tab) to provide information that can help fine-tune the system for future cases. ![tutorial-siem-which-rules.png](/files/UjKiC2UYl6kprVORQ4KY) The feedback from the analyst is sent to the Splunk administrator so they can review the suggested changes and make any necessary adjustments. ### Analyze Data 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, and tab names 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** The **Incident Info** tab provides information about the incident itself. For example, when the incident was opened and updated, the severity of the incident, and where it originated. It also gives you easy access to all of the indicators extracted from the incident and the current state of the incident. For example, in the **Work Plan** section, you can see that the incident is currently on hold waiting for the analyst to manually investigate the incident. ![splunk-incident.png](/files/sYG99A39PRwmJ1LArkZ6) **Notable Summary** The Notable Summary tab fetches the data from Splunk and provides it to you in one tab in Cortex XSOAR. For example, you can see how many of the events associated with the event were fetched (default is 50), and the Splunk severity, status, and urgency. ![splunk-summary.png](/files/hFtBDMpBOnvruW0QZFuB) The view includes all of the network data that is available from Splunk. **Drilldown** The **Drilldown** tab shows detailed drilldown data that was enriched from the Splunk server, such as Error code, event code, and event ID. ![splunk-drilldown.png](/files/GfVEymMMoDfYLM9yt9Jg) **Assets** The **Assets** tab presents information about any critical assets that were involved in the event, whether they were targeted or tangentially related. ![splunk-assets.png](/files/HsG5HFunzOTozjOtNIpo) **Identities** The **Identities** tab shows enriched identity information that was involved in the event, such as the source email address and identity tag. ![splunk-ids.png](/files/GF12ii8WKZ98aCbaCotl) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/tutorials/cortex-xsoar-tutorials/readme/ingest-incidents-from-a-siem-using-splunk.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.