An incident goes through various processes in Cortex XSOAR including defining an incident, classification and mapping, pre and post-processing, and running a playbook.
Incidents are potential security data threats that SOC analysts identify and remediate. There are several incident triggers, including:
SIEM alerts
Mail alerts
Security alerts
These alerts are generated from third-party services, such as SIEMs, mailboxes, and data.
Cortex XSOAR includes several out-of-the-box incident types, fields, and layouts, which can be customized to suit your use case. You can also create incident types, custom fields, and layouts as necessary. Incidents can be created manually, from a JSON file, the Cortex XSOAR Restful API, or an integration feed.
You can define integrations with your third-party security and incident management vendors. You can trigger events from these integrations that become incidents in Cortex XSOAR. You can run playbooks on these incidents to enrich them with information from other products in your system, which helps you complete the picture.
In most cases, use rules and scripts to determine if an incident requires further investigation or can be closed based on the findings. You can filter the incidents that are ingested into Cortex XSOAR by manually de-duplicating incidents, setting up pre-process rules to perform certain actions, or automatically de-duplicate incidents. This enables your analysts to focus on the minority of incidents that require further investigation. After you close an incident you may want to automate an additional action such as closing a remedy ticket. For more information, see Use post-processing scripts in an incident.
The following diagram explains the incident lifecycle in Cortex XSOAR.
Planning
Before you begin configuring integrations and ingesting information from third parties, consider the following:
Phase | Description |
|---|---|
Incident types | Incident types classify the events that are ingested into Cortex XSOAR. Use out-of-the-box types, or create incident types to classify the different types of attacks with which your organization deals. For more information, see Create an incident type. |
Incident fields | Displays information from third-party integrations and playbook tasks when an incident is created or processed. Use out-of-the-box fields, or create fields for your use case. For more information, see Create an incident field. |
Incident layouts | Customize your layouts by adding custom or system fields for each incident type, so that the most relevant information is shown for each type. For more information, see Incident layout customization. |
This is an iterative process. After you've configured incident types, fields, and layouts, and you've classified and mapped your incident type and fields, start ingesting information, which enables you to assess how you've mapped out your information. As you see the data coming in, you can make adjustments to improve your mapping and gain a deeper understanding of the information you're collecting. Although unmapped information is available in labels, it's significantly easier to work with, when assigned to a specific field and displayed in the appropriate layouts.
Configure integrations
Configure integrations with third-party products to start fetching events, such as potential phishing emails, authentication attempts, and SIEM events. For more information, see Configure integrations.
Classification and mapping
Once you configure integrations, you should determine how the events ingested from those integrations will be classified as incidents. For example, you can classify items based on the subject field for email integrations, but for SIEM events, you should classify them by event type. During the planning stage, it's important to define how the information ingested from your integrations will be mapped to the fields you're creating. For more information, see Classification and mapping.
Pre-Processing
Pre-processing rules enable you to perform certain actions on incidents as they are ingested into Cortex XSOAR. Using rules, you can select incoming events on which to perform actions, for example, link the incoming event to an existing incident, or based on configured conditions, drop the incoming incident altogether. For more information, see Pre-process rules.
Create an incident
Based on the definitions provided in the Classification and Mapping stage, and the rules you created for pre-processing events, incidents of various types are created. The incidents all appear on the Incidents page, where you can start investigating incidents.
Run a playbook
Playbooks are triggered when an incident is created or run them manually as part of an investigation. When triggered as part of a created incident, the playbooks for the type of incident that was classified run on the incident. Alternatively, if you are manually running a playbook, select whichever playbook is relevant for the investigation. For example, playbooks can take IP address information from one integration and enrich that IP address with information from additional integrations or sources.
Post Processing
Once the incident is complete and you are ready to close it, you can run various actions on the incident using a post-processing script. For example, an email is sent to the person who opened the incident informing them that their incident has been resolved or close an incident in a ticketing system. For more information, see Use post-processing scripts in an incident.