Indicator concepts - Administrator Guide - Threat Intel Management Guide - 8 - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR Cloud Documentation

Cortex XSOAR
Creation date
Last date published
Administrator Guide

Before you start customizing and investigating you should be familiar with the following terms


Indicators are artifacts associated with security incidents and are an essential part of the incident management and remediation process. They help correlate incidents, create hunting operations, and enable you to easily analyze incidents and reduce Mean Time to Response (MTTR).

Fetch indicators

Cortex XSOAR includes integrations that fetch indicators from either a vendor-specific source, such as TAXII, or from a generic source, such as a CSV or JSON file.

Indicator ingestion

Cortex XSOAR automates threat intel management by ingesting and processing indicator sources, such as feeds and lists, and exporting the enriched intelligence data to SIEMs, firewalls, and any other system that can benefit from the data. These capabilities enable you to sort through millions of indicators daily and take automated steps to make those indicators actionable in your security posture.

Indicators are added to Cortex XSOAR via the following methods:



Classification and Mapping


Feed integrations: Fetch indicators from a feed, for example, TAXII, Office 365, and Unit 42 ATOMS Feed.

Indicator classification and mapping is done in the Feed Integration and not in the Cortex XSOAR Settings & InfoSettingsObject SetupIndicatorsClassification & Mapping tab.

Indicator extraction

Indicators are extracted from selected incidents that flow into Cortex XSOAR, from an integration.

Only the value of an indicator is extracted, so no classification or mapping is needed.


  • Command line

  • Mark: The user marks a piece of data as an indicator.

  • STIX file: Manually upload a STIX file on the Threat Intel (Indicators) page.

Data is inserted manually via the UI so no classification or mapping is needed.

If importing a STIX file, mapping is done via the STIX parser code.

Common indicator data model

When indicators are ingested, regardless of their source, they have a unified, common set of indicator fields, including traffic light protocol (TLP), expiration, verdict, and tags.

Indicator smart merge

The same indicator can originate from multiple sources and be enriched with multiple methods (such as integrations, scripts, and playbooks). Cortex XSOAR implements a smart merge logic to make sure indicators are accurately scored (verdict) and aggregated. Indicator fields are merged according to the source reliability hierarchy. When there are two different values for a single indicator field, the field is populated with the value provided by the source with the highest reliability score. For multi-select and tag fields, new values are appended, rather than replacing the original values.

Indicators enrichment cache (Insightcache)

To avoid exceeding API quotas for third-party services, indicators are only updated after the cache expiration period. By default, the cache expires 4,320 minutes (3 days) after an indicator is updated, and cannot be cleared manually. The cache expiration can be set in the indicator type parameters. Indicator enrichment cache expiration only applies to automatic enrichment, triggered by the enrichIndicators command, and does not apply when you run reputation commands such as !ip.

Indicator timeline

The indicator timeline displays an indicator’s complete history, such as the first-seen and last-seen timestamp and changes made to indicator fields.

Indicator expiration

When ingesting and processing many indicators daily, it’s important to control whether or not they are active or expired and to define how and when indicators are expired. Cortex XSOAR offers multiple options to set indicator expiration.

Exclusion list

Indicators added to the exclusion list are disregarded by the system and are not created or involved in automated flows such as indicator extraction.


Administrators can define a job to trigger a playbook when the specified feed or feeds finish a fetch operation that includes a modification to the list. The modification can be a new indicator, a modified indicator, or a removed indicator.