Common concepts in Cortex XSOAR.
Commands
Cortex XSOAR uses the following commands:
System commands: Commands that enable you to perform Cortex XSOAR operations, such as clearing the playground or closing an incident. These commands are not specific to an integration. System commands are entered in the command line using a
/
.External commands: Integration-specific commands that enable you to perform actions specific to an integration. For example, you can quickly check the reputation of an IP address. External commands are entered in the command line using a
!
. For example,!ip
.
Content packs
All Cortex XSOAR content is organized in packs. Packs are groups of artifacts that implement use cases in the product. Content packs are created by Palo Alto Networks, technology partners, consulting companies, MSSPs, customers, and individual contributors. Content packs may include a variety of different components, such as integrations, scripts, playbooks, and widgets.
Content repository
The content repository functionality built into Cortex XSOAR allows you to sync content between development and production machines using a built-in or private repository.
Context data
Different commands and playbook tasks are tied together by the Cortex XSOAR context. Every incident and playbook has a place to store data called the context. The context stores the results from every integration command and every automation script that is run. It is a JSON storage for each incident. Whether you run an integration command from the CLI or from a playbook task, the output result is stored in the JSON context in the incident or the playground. For example, the command !whois query="paloaltonetworks.com"
returns the data and stores the results in the context.
Dashboards
Dashboards include visualized data, including Cortex XSOAR incident, indicator, and system data, displayed for a rolling, relative time frame. Dashboards enable you to track metrics, analyze trends that appear in your Cortex XSOAR data, and identify areas of concern. Dashboards can be customized with widgets that focus on the data points most relevant to your organization.
Engines
An engine is a proxy server application that is installed on a remote machine and enables communication between the remote machine and the Cortex XSOAR tenant. You can run playbooks, scripts, commands, and integrations on the remote machine and the results are returned to the tenant.
You mainly use engines for the following:
Integration instances for On-prem applications. For example, the GitLab v2 integration enables you to run commands on GitLab instances.
Execute scripts and commands that require access to On-prem resources. For example, the Active Directory v2 integration enables you to run commands in Active Directory.
Generic Indicator export service. In Cortex XSOAR, you can configure an EDL to share a list of Cortex XSOAR indicators with other products in your network, such as a firewall or SIEM. For example, your Palo Alto Networks firewall can add IP address and domain data from the EDL to block or allow lists.
Load balancing which enables the distribution of the command execution load.
Incidents
Incidents are potential security data threats that SOC administrators identify and remediate. There are several incident triggers, including:
SIEM alerts
Mail alerts
Security alerts from third-party services, such as SIEM, mailboxes, data in CSV format, or from the API
Cortex XSOAR includes several out-of-the-box incident types, and users can add custom incident types with custom fields, as necessary.
Incident fields
Incident fields are used for accepting or populating incident data. You create incident fields to hold information received from third-party integrations, manual input, or via the API.
Incident lifecycle
You can define integrations with your third-party security and incident management vendors. You can then trigger events from these integrations that become incidents. After 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 scripts 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.
Indicators and Indicator types
DBot can simplify your incident investigation process by collecting and analyzing information and artifacts found in War Room entries. Cortex XSOAR analyzes indicators to determine whether they are malicious. Using indicator types reveals predefined, regular expressions in the War Room.
Hits are indicators that are determined to have a malicious verdict and were previously identified in the network. The verdict is the indicator's level of maliciousness, determined manually or by hypersearch scripts. If a hypersearch script identifies an indicator, the source is DBot.
There are many out-of-the-box indicator types, but you can add custom indicator types as necessary. The following is a list of some of the indicator types, but the list is not exhaustive:
IP address (IP4, IP6)
Registry key
URL
Email
File hash (SHA-1, MD5)
Domains
CIDR
When you add an indicator type, you can add formatting, enhancement, and reputation scripts, as well as reputation commands. Formatting scripts modify how the indicator is displayed in the War Room and reports. Enhancement scripts enable you to gather additional data about the highlighted entry in the War Room. Reputation scripts calculate the reputation score for an entry that DBot analyzed, for example, DataIPReputation
, which calculates the reputation of an IP address. Reputation commands (such as !ip
for IP addresses) are an alternate way to calculate an indicator’s reputation score (verdict) and gather additional data about the indicator. Reputation commands and reputation scripts are executed when enriching a specific indicator type (for example, when the indicator is extracted from an incident).
Integrations
Integrations are third-party tools and services that the Cortex XSOAR platform works with to orchestrate and automate SOC operations.
Note
Cortex XSOAR 8 currently does not support the IoT Security Third-party Integrations Add-on. For more information, see the IoT Security documentation.
In addition to third-party tools, you can create your own integration using the Bring Your Own Integration (BYOI) feature.
The following lists some of the integration categories available in Cortex XSOAR. The list is not exhaustive, and highlights the main categories:
Analytics and SIEM
Authentication
Case Management
Data Enrichment & Threat Intelligence
Database
Endpoint
Forensics and Malware Analysis
IT Services
Messaging
Network Security
Vulnerability Management
Integration instance
A configuration of an integration. You can have multiple instances of an integration, for example, to connect to different environments. If you are an MSSP and have multiple tenants, you can configure a separate instance for each tenant.
Jobs
You can create scheduled events using jobs. Jobs are triggered either by time-triggered events or feed-triggered events. For example, you can define a job to trigger a playbook when a specified TIM feed finishes a fetch operation that included a modification to the list.
Marketplace
Marketplace is the central location for installing, exchanging, contributing, and managing all of your content, including playbooks, integrations, scripts, fields, layouts, and more.
When a content pack is available for update, you see an Updates waiting in Marketplace notification in the side menu. You can update to the latest content version or to a specific version. All dependent content packs update automatically with the content pack. We recommend periodically reviewing your installed Marketplace packs for any available updates, and updating, as required.
Playbooks
Playbooks are self-contained, fully documented prescriptive procedures that query, analyze, and take action based on the gathered results. Playbooks enable you to organize and document security monitoring, orchestration, and response activities. There are several out-of-the-box playbooks that cover common investigation scenarios. You can use these playbooks as-is, or customize them according to your requirements. Playbooks are written in YAML file format using the COPS standard.
A key feature of playbooks is the ability to structure and automate security responses, which were previously handled manually. You can reuse playbook tasks as building blocks for new playbooks, saving you time and streamlining knowledge retention.
Playground
The Playground is a non-production environment where you can safely develop and test scripts, APIs, commands, and more. It is an investigation area that is not connected to a live (active) investigation.
To erase a playground and create a new one, in the Cortex XSOAR CLI run the /playground_create
command.
Reports
Reports include visualized data, including Cortex XSOAR incident, indicator, and system data, which can be run for a specific time frame and automatically sent via email to internal or external stakeholders.
Scripts
The Scripts page is where you manage, create, and modify scripts. These scripts perform a specific action, and are comprised of commands associated with an integration. You write scripts in either Python or JavaScript. Scripts are used as part of tasks, which are used in playbooks and commands in the War Room.
The Scripts section includes a Script Helper, which provides a list of available commands and scripts, ordered alphabetically.
War Room
The War Room is a collection of all investigation actions, artifacts, and collaboration pieces for an incident. It is a chronological journal of the incident investigation. You can run commands and playbooks from the War Room and filter the entries for easier viewing.