Automation with Cortex XSIAM
Automation with Cortex XSIAM
This domain tests how you build, trigger, and troubleshoot automation in Cortex XSIAM. Expect playbooks, scripts, integrations, jobs, lists, and incident fields, plus how the Cortex XSOAR automation engine executes tasks inside XSIAM.
Core rules
- A playbook is event-driven. Its trigger matches incident attributes such as type, severity, or a custom field; it is not a scheduled job.
- Tasks pass data through context keys. Reference outputs explicitly and map them to later tasks or incident fields.
- Use built-in tasks for branching, manual approval, data collection, and setting fields; use scripts for reusable logic; use integrations for product actions.
- Jobs run scheduled XQL queries and can create incidents or update data. Lists store reusable values such as allow/block entries.
- Test in the playbook debugger or playground before enabling; keep tasks idempotent so retries do not duplicate actions.
Worked example
A high-severity phishing incident should check a sender IP, block it if malicious, and isolate the recipient endpoint. The trigger is incident type = Phishing AND severity >= High. Task 1 extracts the sender IP into context. Task 2 calls a reputation integration. A conditional task branches on the score. If malicious, Task 3 adds the IP to a block list and Task 4 isolates the endpoint via the Cortex XDR agent. Reasoning: the trigger scopes execution; context carries the IP; the condition prevents blocking benign senders; isolation is last because it is disruptive.
Traps
- Confusing a playbook trigger with a job schedule.
- Hardcoding values instead of using lists or incident fields.
- Forgetting to map task outputs, so later tasks see empty context.
- Assuming all Python libraries exist in the default Docker image.
- Running disruptive actions without a manual approval task.