Hey everyone, I'm pretty new to the SOAR side of things. I've been setting up some basic Cortex XSOAR content packs at work, but I'm struggling to visualize what a *real*, useful playbook looks like in practice beyond the simple "fetch and alert" demos.
Could someone share a concrete example of a workflow you've built or use? I'm especially curious about:
- How you handle a common alert, like a phishing email or a suspicious login, from ingestion to closure.
- What integrations you use most (like ticketing, DNS, Active Directory).
- Any logic or decisions you've added that saved real time.
Just trying to bridge the gap between the tutorials and actual daily use. Thanks in advance for any insights! 🙏
Absolutely, that gap between tutorials and production is a real thing. Let me walk you through a phishing email playbook we've been running for about a year now. The core concept is enrichment and pre-qualification to keep the vast majority of alerts from ever needing a human.
Our workflow triggers from our email security gateway alert. The playbook's first job is enrichment: it pings VirusTotal for the URL hash, checks the sender domain against our internal domain allow-list, and runs the attached file hash (if any) against our EDR's global threat intelligence. We set conditional checks after each step. If the VT score is above a certain threshold *and* the domain isn't internal, it auto-quarantines the message via O365, adds the IOCs to our block lists in the firewall and DNS, and creates a ticket in Jira Service Management with all the context pre-populated for review. The case closes as a true positive automatically.
The key integrations for us are, in order: the email security product (like Mimecast or Proofpoint), VirusTotal (or a similar threat intel aggregator), Microsoft Graph for O365 actions, our EDR platform (like CrowdStrike) for hash checks, and our DNS filtering service for blocking. Active Directory comes in mainly for looking up the recipient user's department and manager if we need to send a notification.
The logic that saved us the most time was the "internal sender" check. A huge percentage of our phishing alerts were internal test campaigns from our security team. By immediately checking if the sender's domain is in our approved internal list, we bypass all other enrichment and close the incident immediately, adding a note that it was a controlled test. This cut our analyst touch points by about 30% right away.
That's a solid example of tiered automation. I'd add a caveat about the auto-closure after enrichment though. We tried a similar model and found a small percentage of false positives came from compromised legitimate domains, which would pass your allow-list check but still be malicious.
We added a final manual review step for any auto-qualified case with a high confidence score before closing the ticket. It adds maybe 10% back to the analyst's plate, but it caught a few sneaky ones that pure automation missed. The balance is always shifting based on your own alert volume and risk tolerance.
—AF
Your point about compromised legitimate domains is critical. We hit the same issue, particularly with SaaS providers that got phished.
Our solution was to add a time-based decay function to the domain allow-list check. If the domain had been seen in legitimate traffic within the last 24 hours, it passed the initial check but was automatically routed for a brief manual review, exactly as you described. If the last sighting was over a week old, the automation treated it with high suspicion, regardless of the allow-list status. This cut the manual review load down to about 4-5% of cases.
The data showed these 'stale' legitimate domains were disproportionately involved in the false negatives. It's a good example of where simple boolean logic fails and you need to inject some temporal context.