TIM (Threat Intelligence Management) playbooks run based on an indicator search query. In most cases, the following workflow applies:
Indicators are added to Cortex XSOAR through feed ingestion. You can configure your integration to automatically tag all new/updated indicators from a particular instance. For example, you can tag them
A job triggered by delta in a feed begins when the ingestion is complete. The job runs a TIM playbook.
The TIM playbook performs an indicator query. In this case, the query might be for all indicators that have the tag
from-feed, and that were added or modified since the last time the job that triggered the playbook was run. For an example, see Process Indicators Using a Job Triggered By Delta.
The TIM playbook runs using the indicators matching the query as input.
If you want to push the enriched indicators to a SIEM, you can set up a time triggered job to run a playbook such as Add All Indicator Types To SIEM.
Indicators and Feed Ingestion
Indicators include IP addresses, CIDRs, domains, URLs, file hashes, etc. Feed integrations enable you to ingest indicators from external sources into Cortex XSOAR. Once indicators are in Cortex XSOAR, they can be enriched and assigned a verdict. Enriched indicators can be used for incident investigations in Cortex XSOAR and can also be pushed to a SIEM or other external system.
When configuring your TIM Playbook to use an indicator query, we recommend you first run your query on the main Threat Intel page. This enables you to view the list of indicators returned and verify you have the results you need for your playbook. You can copy and paste the query to the playbook or you can save the query you run on the Threat Intel page and access that saved query from the playbook. When you type in a query, auto complete options are displayed. Queries use a modified Lucene syntax.
By default, a query run on the Threat Intel page will be limited to the last 7 days, unless otherwise specified. This same limit does not apply when you enter the query in Playbook Inputs and Outputs, but you can add your required time filter to the query.
Large Batches of Indicators
If more than 1000 indicators are returned, the indicators are processed in batches of 1000. For example, if there are 4500 indicators returned, the playbook runs the first time on the first 1000. Each task receives 1000 indicators as a list or, if the task does not support lists, loops over the 1000 indicators. When the playbook reaches the end, it runs again with the next batch of 1000 indicators, and repeats until all indicators have been processed. The playbook loops automatically through batches of indicators, you do not need to configure the playbook to loop. After all indicators have been processed, the playbook automatically closes the incident. You do not need to include a close incident task.
TIM playbooks often process thousands of indicators. By default, quiet mode is enabled for TIM Playbooks. In quiet mode, entries are not written to the War Room and inputs and outputs are not presented for Work Plan tasks. For troubleshooting purposes, you can temporarily disable quiet mode during playbook development. Quiet mode can be disabled in the playbook settings or on a per task basis.
We strongly recommend that you have quiet mode enabled for any playbook that is in production, to prevent possible performance issues.
While quiet mode is disabled, any changes you make to the playbook indicators query will turn quiet mode back on.
TIM Playbook Tasks
The Playbook search query returns all of the indicators that match a particular search, including all fields for each indicator. Individual tasks, however, may only require a subset of that data. If you need to run different tasks for different types of indicators, you can use a conditional task and set the input to check for indicator type. In the TIM - Indicator Auto Processing playbook, for example, Are there IP results? is a conditional task that searches the indicators returned by the original playbook query. If the task finds any indicators with playbookQuery.indicator_type equal to IP, the condition is met. If no IP type indicators are found, the condition is not met and the playbook proceeds to the else branch. Note that you only see Indicator Details as an option for input, after the playbook has been configured to run an indicator search query.
You can also use filters based on indicator attributes. For example, you can limit a task to only run on indicators where the type is IP.
Using playbookQuery.value as an input returns the indicators themselves, such as the IP addresses. Using playbookQuery as an input returns all of the indicator attributes, not only the indicator value.