XSOAR Misrouting and False Clean Verdicts at an MSSP
Sentinel MSSP operates Cortex XSOAR 8 for 38 tenants. It processes 14,000 incidents per month, mostly phishing, malware, and impossible-travel. The phishing classifier misroutes 27% of credential-harvest emails into the malware incident type because the subject contains 'invoice' and the attachment is an HTML file. The Enrich Endpoint sub-playbook calls a tenant EDR integration; 9 of 38 tenant instances hit HTTP 429 after 600 requests per minute, and the task timeout is 30 seconds. The playbook then continues with empty endpoint context, producing false clean verdicts. Analysts spend 19 minutes per phishing incident; the SLA is 15 minutes. The team has one automation engineer and cannot rewrite all playbooks. Some tenants share an integration instance, and credential-harvest HTML files have no malware payload.
1. What is the highest-leverage fix for the 27% misrouting, and how would you implement it without rewriting every playbook?
Read the worked answer
Fix routing before fixing individual playbooks. At 14,000 incidents per month, 27% is about 3,780 incidents routed to the wrong workflow, which creates rework and inflates handle time. The classifier is upstream of every playbook, so correcting it improves all tenants at once. Implement a separate credential-phishing incident type and route on evidence that distinguishes it from malware: HTML attachment, credential-harvest URL patterns, subject and sender signals, and absence of a binary payload. Use a pre-processing rule or classifier condition, not a hard-coded subject keyword alone. Then map the new type to the existing phishing playbook and add a small sub-playbook for HTML credential-harvest analysis. Test against 200 historical incidents, including the 'invoice' subjects that currently fail, before enabling for all tenants. This avoids rewriting every playbook and fixes the upstream cause.
2. Why are 9 tenants producing false clean verdicts, and what changes to the integration and playbook would you make?
Read the worked answer
The false clean verdict is a data-quality failure, not an endpoint result. Nine tenant instances hit HTTP 429 after 600 requests per minute, the task times out at 30 seconds, and the playbook continues with empty endpoint context. A shared integration instance makes the rate limit worse because multiple tenants consume the same quota. Change three things. First, give each affected tenant its own integration instance or credential where possible, and batch or cache lookups to stay under the rate limit. Second, increase the timeout and add retry with exponential backoff for 429 responses. Third, and most important, gate the verdict: if endpoint context is empty, set the verdict to Unknown and create a manual task or a follow-up enrichment task, never Clean. Add an error path that records the failed command and tenant. The SLA may slip on those incidents, but a wrong clean verdict is worse than an honest unknown.
3. Given one engineer and a 15-minute SLA, what would you automate first, and what would you deliberately leave manual? Use the numbers.
Read the worked answer
Automate the classifier fix and the false-clean gate first. The classifier affects roughly 3,780 incidents per month; the rate-limit issue affects 9 of 38 tenants, about 24% of the estate. Both are high-leverage and do not require rewriting every playbook. Build one reusable enrichment sub-playbook with retry, timeout handling, and an explicit Unknown branch. Automate ticket creation, indicator extraction, and standard verdicts when context is complete. Leave manual: ambiguous HTML credential-harvest cases with no payload and no clear URL verdict, novel sender infrastructure, and any case where the EDR lookup failed after retries. Those need analyst judgment, not a forced automation. Track handle time for the corrected path against the 15-minute SLA. The goal is not to automate 100% of incidents; it is to remove the 27% rework and stop false clean closures.