Phishing SOAR Reliability, Least Privilege, and Approval Gates
Orion Media's SOAR handles 1,200 user-reported phishing emails per week. The 'Phishing Triage' playbook detonates URLs, quarantines messages, and notifies the user. About 35% are duplicates. The playbook fails 18% of runs because the mailbox integration uses a service account whose OAuth secret expires every 90 days without alerting. That account also has tenant-wide mailbox read and purge rights, which an auditor flagged. A destructive mailbox purge runs without approval when the URL verdict is malicious. The SOC has 12 analysts across three shifts and no dedicated SOAR engineer. Mean time to respond is 42 minutes; the target is 20. Support tickets with the vendor are slow because the team cannot find correlation IDs.
1. How would you fix reliability and least privilege for the mailbox integration? What controls would you add?
Read the worked answer
Separate the integration identity from a human admin. Create a dedicated OAuth app or service principal for mailbox access with the minimum permissions needed, such as read and move or quarantine rather than tenant-wide purge. If purge is required, use a separate role and require approval. Store the secret in a vault, rotate on a schedule shorter than the expiry, and alert at 30, 14, and 7 days. Add a startup self-test that calls a harmless endpoint and fails the playbook early with a clear correlation ID. Monitor playbook success rate and authentication failures in SOAR health. Remove standing tenant-wide rights and use just-in-time elevation for purge. Document the permission model for the auditor and review quarterly. The 18% failure rate is a reliability and security issue; fix authentication before adding new automation.
2. How would you deduplicate and prioritize 1,200 weekly reports without adding another full-time SOAR engineer?
Read the worked answer
Deduplicate on message-ID and normalized URL or attachment hash before enrichment. Group duplicates into one case and increment a report count rather than running full detonation each time. Prioritize by sender reputation, URL and domain age, attachment type, authentication results such as SPF, DKIM, and DMARC, and whether the recipient clicked. Auto-close only low-risk, high-confidence duplicates with a clear reason; route ambiguous reports to a queue. The playbook should enrich first, then decide quarantine, then notify. Add idempotency keys so a retry does not send duplicate notifications or purge twice. Measure auto-triage rate, false-positive quarantine rate, and MTTR. With 12 analysts and no SOAR engineer, keep the playbook modular and owned by a named analyst with a change log.
3. What approval, audit, and vendor support changes would you make for destructive actions and recurring failures?
Read the worked answer
Destructive actions such as mailbox purge need an approval step with a named approver, a reason code, and an audit record. Configure the approval in SOAR, not in email only; email approvals are spoofable and hard to audit. Add a two-person rule for tenant-wide or executive mailbox actions. Log the message IDs, verdict, approver, and timestamp in the case. For vendor support, capture the correlation ID, playbook run ID, timestamp, integration name, and error text before opening the ticket; attach sanitized logs. Escalate by severity and business impact, and track time to resolution. After the fix, run a post-incident review of the 14 lockouts and the purge actions, and update the playbook with guardrails and tests.