Phishing Playbook Skips Isolation Under Volume
Your Cortex XSIAM tenant processes about 150 phishing issues per day across 2,400 endpoints. A custom playbook named Phish-Triage is triggered on issue creation. It extracts URLs from the email, submits them to a sandbox integration, and, when the verdict is malicious, calls the endpoint response integration to isolate the recipient host and block the URL. The sandbox contract allows 500 submissions per day. Over the last week, the playbook executed 1,050 times because linked alerts re-triggered it, and 38% of issues had no endpoint context (email-only reports). Analysts report that isolation is skipped on many malicious verdicts even though the playbook shows 'completed.' The team has a 30-minute SLA for high-severity phishing and 12 analysts on shift. You must reduce duplicate sandbox submissions, preserve SLA, and make isolation behavior predictable without disabling the playbook. The playbook has one conditional branch that checks 'verdict == malicious' and then runs 'isolate endpoint' with no check for endpoint_id.
1. Why does the playbook report completed while isolation is skipped, and what change makes the behavior explicit?
Read the worked answer
Green playbook status only means the task graph reached the end. The isolation task is probably running with an empty endpoint_id and either has 'continue on error' enabled or returns no result, so XSIAM marks the task complete. The branch checks only the sandbox verdict, not whether an endpoint exists.
Make the failure explicit: insert a validation task before isolation. If endpoint_id is empty, route to a manual resolution task that finds the host from the sender, message headers, or identity mapping, and set an issue field such as response_blocked_reason = no_endpoint. Disable 'continue on error' on the isolation task, and on integration error set the issue back to open or raise severity. Surface the isolation task output in the issue layout so the analyst sees isolated=true/false. This converts a silent skip into a visible exception.
2. Design gating to keep sandbox submissions under 500 per day while preserving the 30-minute high-severity SLA.
Read the worked answer
Use a three-stage gate. First, normalize and deduplicate URLs across the issue and its linked alerts; cache verdicts for 24 hours so the same URL is not resubmitted. At 150 issues/day and roughly 3 URLs each, that is about 450 raw submissions, so even modest dedupe creates headroom under 500. Second, reserve the remaining quota for high-severity issues and messages that fail SPF/DKIM/DMARC; low-severity issues with cached or reputable URLs skip detonation. Third, add a quota guard: a script counts submissions in a key-value store and, above 450, sends only high-severity items and queues the rest for the next window. Keep high-severity runs concurrent to meet the 30-minute SLA. This preserves coverage where it matters and prevents a burst from exhausting the daily allowance.
3. How should the team prevent duplicate playbook execution caused by linked alerts?
Read the worked answer
Duplicate runs usually come from linked alerts or repeated issue creation. Set the playbook trigger to issue creation only, then create a dedupe key from the email Message-ID plus normalized URL. Before sandbox submission, a script checks a short-lived key-value store; if the key exists, reuse the prior verdict and skip the sandbox call. Use a TTL of 6-24 hours. If linked alerts must remain, run the playbook only on the parent issue and relate children to it. Do not dedupe only by sender, because attackers reuse addresses. Track duplicate execution rate and sandbox submissions per issue as playbook metrics so the fix is measurable.