12.3 SOAR Playbooks, Enrichment, and TI Integration

What SOAR Adds on Top of a SIEM

Security Orchestration, Automation, and Response (SOAR) platforms sit beside the SIEM. They do not replace log collection. They connect the SIEM, endpoint detection and response (EDR), ticketing, chat, email, identity provider, firewall, and threat intelligence (TI) tools so a playbook can run the same steps every time instead of an analyst copy-pasting at 03:00.

Break the acronym down:

• Orchestration — wiring tools together with APIs, queues, and credentials.
• Automation — executing steps without a human click on every one.
• Response — the outcome: notify, document, contain. Response may still require a human approval gate.

SAL1 training content presents SOAR as platforms, automated responses, playbooks, data enrichment, and integration with threat intelligence platforms. You are not expected to administer a specific vendor. Names you will hear include Palo Alto Cortex XSOAR, Splunk SOAR (Phantom), Microsoft Sentinel automation rules and Logic Apps, Swimlane, Torq, TheHive/Cortex, and Shuffle. The ideas transfer.

SIEM without SOAR: you copy an IP from Splunk, paste it into VirusTotal, paste it into a firewall worksheet, type a ticket. Slow, inconsistent, easy to skip a step.

SOAR without a detection source: a well-organized robot with nothing to trigger on. Alerts still have to start in a SIEM, EDR, mailbox, or similar.

SOAR is not “fully automatic IR.” The valuable junior skill is knowing which steps are cheap to automate and which steps change production.

Playbooks

A playbook is a documented workflow: trigger → tasks → decision branches → close or escalate. A wiki checklist is a playbook. A SOAR playbook is that checklist encoded as tasks, scripts, and API calls with logs of who (or what) ran each step.

Typical skeleton:

1. Trigger — new SIEM notable matching “brute force,” EDR “malware blocked,” user-reported phishing.
2. Extract — src_ip, user, host, URL, file hash from the alert JSON.
3. Enrich — always-on context (next subsection).
4. Decide — branches on TI confidence, asset criticality, allow-lists, whether the action is reversible.
5. Act — create/update a ticket, notify chat, maybe isolate or block if gated.
6. Document — write artifacts back to the ticket and to the SIEM notable so the case report has a machine timeline.

Good playbooks are safe to rerun (a second trigger should not double-page twelve people and stack duplicate firewall rules) and fail visibly (a 403 from VirusTotal must not close the alert as false positive). They also respect rate limits and Traffic Light Protocol (TLP) markings: TLP:RED indicators from a partner TIP should not be auto-copied to a public Slack channel.

Automate questions; gate answers that change production

Safe default for an entry-level analyst: automate questions. Put a human on answers that change production state until the organization publishes a narrow exception (for example, auto-isolate only lab VMs tagged in the asset lookup, or auto-block only IPs with TI confidence at or above an agreed threshold and not present on internal/VPN/partner lists).

Escalating a suspected production outage is the example to remember. A burst of errors, a SIEM spike, and users in chat saying “the portal is down” can be ransomware encryption, a certificate expiry, or a bad deploy. A playbook can gather EDR isolation state, change-calendar hits, and CPU/disk from monitoring. A playbook should not page the whole company with “ransomware confirmed” or pull the plug on checkout systems without a human who can tell IR apart from operations.

The Auto-Block Trap

A playbook that takes src_ip from a 4625 brute-force notable and pushes it to the perimeter firewall without context will eventually:

• Block the company’s own NAT gateway or VPN concentrator (thousands of users appear as one source IP against Active Directory).
• Block a cloud provider shared address and knock out SaaS.
• Block a customer or partner office after a stolen-password spray that originated on their network.
• Honor a spoofed source if the log device does not sit behind anti-spoofing.
• Block a scanner jump box that was authorized, creating an outage during a scheduled test.

Auto-block is only defensible with guards: not RFC1918; not in the VPN/asset/partner lookup; TI confidence and expiry; time-limited block; documented reversal. If those lookups fail open (“if lookup fails, block anyway”), the playbook is dangerous. Fail toward human review.

The same trap exists for auto-disable user. A password spray against 400 accounts must not disable 400 employees. Enrich and cluster first. Tightly scoped disable (for example, only if a successful 4624 came from a known-bad IP for one account) is a policy exception, not the default branch.

Auto-isolate in EDR is slightly different — it is host-scoped, not internet-scoped — but isolating the wrong production jumphost still causes an outage. Asset criticality and a change window still belong in the decision node.

Data Enrichment

Enrichment attaches extra facts to an indicator or alert so a human or a later branch can decide. It is not containment.

Common enrichments:

• IP: geo, ASN, reverse DNS, cloud-provider flag, blocklist hits, “is this in our VPN pool?”
• Domain / URL: registrar age, hosting, unwrapped redirect chain, sandbox summary.
• File hash: VirusTotal (or equivalent) detection ratio, family name, signer, first-seen. “Pull this hash from VT” is the classic first SOAR lab.
• User: title, manager, VIP flag, recent leaver, MFA registered.
• Host: owner, OS, EDR isolation state, whether it is a domain controller.

Do three operational things:

1. Cache — do not query VT fifty times for the same SHA-256 in one incident.
2. Attribute — store “VT 42/72, queried 2026-09-19 22:14 UTC” so the case report has a source and a time.
3. Fail visibly — an expired API key that returns empty fields is not “zero engines, clean file.” Empty must pause or flag, not take the “allow” branch.

Garbage enrichment is worse than none when the next node treats blank as benign.

Integration with Threat Intelligence Platforms

A threat intelligence platform (TIP) — MISP, OpenCTI, ThreatConnect, Anomali, Recorded Future, or the TI module inside a SOAR product — stores indicators, sometimes campaigns and malware families, with confidence, TLP, and expiry.

SIEM integration: match live logs against indicator lists (Splunk lookups or threat-intel inputs, Elastic threat-match rules). A hit can raise a notable: “this dest is on an internal C2 watchlist.”

SOAR integration: when an alert arrives, the playbook asks the TIP what is already known and writes back new IoCs from the incident (“add 203.0.113.88 as brute-force source, confidence medium, expires in 14 days”). That closed loop is why SAL1 training content pairs SOAR with TI. Chapter 13 goes deeper on feeds, classifying IPs/domains/hashes, and YARA. This section is the automation handshake:

Alert → extract IoC → TIP and/or VirusTotal enrich → score → optional SIEM watchlist update → human or gated action → write-back with expiry.

Do not treat a single unvetted free feed as auto-block gospel. TI has false positives. Confidence, context, and expiry belong in the decision node, not only in a dashboard widget. If TLP:AMBER forbids sharing an indicator outside the SOC, the playbook must not publish it to a company-wide channel.

Worked Playbook: Hash Enrichment plus a Brute-Force IP

Trigger. SIEM notable: workstation WS-018 wrote a file whose SHA-256 is present on the EDR alert, then the same user’s account saw 4625s from 198.51.100.66.

Automated (no production change):

1. Create incident, copy SIEM severity, status New.
2. Extract hash, host, user, src_ip.
3. Query VirusTotal for the hash; query the TIP for hash and IP; cache both responses.
4. lookup (or SOAR asset API): WS-018 is finance, criticality High — raise a human flag; do not auto-isolate finance by default.
5. Ask EDR whether the file was quarantined already.
6. Attach a formatted enrichment card to the ticket: VT ratio, TIP campaign name if any, geo/ASN, “IP in VPN table? no.”
7. If VT malicious count meets your org’s threshold or TIP campaign matches, set severity Critical and page on-call with a recommendation to isolate — still not the isolate API unless policy explicitly allows finance hosts.

Human:

• Confirm the hash is not an internal packaging tool (benign ISO/MSI).
• If malware is confirmed, approve EDR isolate and a password reset, then consider a time-limited block of 198.51.100.66 after VPN/NAT/partner lookups.
• If that IP is the user’s home ISP during travel, do not block a /24 of a residential provider.
• If the “malware” alert and the “portal is down” chat landed together, do not let the playbook label it ransomware outage without checking change calendars and backups — that escalation is human.

Report: playbook name, enrichment timestamps, who approved isolate or block, IoCs written back to the TIP with expiry. Auditors and SAL1-style case scoring both care about that trail. Automation that cannot be narrated in the case report is incomplete automation.