Incidents are potential security data threats that analysts identify and remediate in Cortex XSOAR.
Cortex XSOAR incidents can be created manually, from a JSON file, or from an integration feed.
You can define integrations with your third-party security and incident management vendors. You can then trigger events from these integrations that become incidents in Cortex XSOAR. Once the incidents are created, 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, you can use rules and automation 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-duplicating 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 Post Processing for Incidents.
The following diagram explains the incident lifecycle in Cortex XSOAR.
Before you begin configuring integrations and ingesting information from third parties, consider the following:
Used to display information from third-party integrations and playbook tasks when an incident is created or processed. For more information, see Incident Fields.
Create incident types
Classify the different types of attacks with which your organization deals.
Create incident layouts
Customize your layouts for each incident type to make sure the most relevant information is shown for each type. For more information, see Customize Incident Layouts.
This is an iterative process. After you initially create your fields and incident types, as well as implement them in your incident layouts, you can start the process of ingesting information. You can then see how accurately you have mapped out your information. Make changes as you go along and learn more about the information you are receiving. Information that is not mapped to fields is available in labels, but it is much easier to work with the information when it is properly mapped to a field and displayed in the relevant layouts.
You configure integrations with your third-party products to start fetching events. Events can be potential phishing emails, authentication attempts, SIEM events, and more.
Once you configure the integrations, you have to determine how the events ingested from those integrations will be classified as incidents. For example, for email integrations, you might want to classify items based on the subject field, but for SIEM events, you will classify by event type. In addition, you have to map the information coming from the integrations into the fields that you created in the planning stage. For more information, see Classification and Mapping.
Pre-processing rules enable you to perform certain actions on incidents as they are ingested into Cortex XSOAR directly from the UI. Using the 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 Create Pre-Process Rules for Incidents.
Based on the definitions you provided in the Classification and Mapping stage, as well as the rules you created for pre-processing events, incidents of various types are created. The incidents all appear in the Incidents page of the Cortex XSOAR user interface, where you can start the process of investigating.
Playbooks are triggered either when an incident is created or when you run them manually as part of an investigation. When triggered as part of an incident that was created, the playbooks for the type of incident that was classified will run on the incident. Alternatively, if you are manually running a playbook, you can 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.
Once the incident is complete and you are ready to close it out, you can run various post-processing actions on the incident. For example, send an email to the person who opened the incident informing them that their incident has been resolved, or close an incident in a ticketing system.