Lesson 6 of 6 · 20 min read

Choosing & Critiquing Playbooks — Disposition Quality and Tagging

Playbooks are tools, not rules. An experienced analyst knows when to follow the playbook exactly, when to pivot across classes, and when the playbook itself is wrong for the situation. This lesson teaches playbook meta-skills: recognizing misrouting, writing dispositions that pass review, and tagging that produces useful metrics.


When the Playbook Is Wrong

Three scenarios where you need to cross playbooks:

Cross-class chained attacks

A BEC phishing email (email playbook) → credential capture → OAuth consent grant (identity playbook) → file download (endpoint playbook) → exfil to cloud storage (network playbook).

Each class has its own evidence. Staying in the email playbook means you miss the OAuth grant that keeps the attacker in even after password reset. Staying in identity means you miss the files that were exfiltrated.

How to handle: identify the primary class for the initial detection, complete that playbook first, then open additional playbooks for each correlated artifact.

Novel technique without a playbook

An alert fires for a detection rule targeting a technique your SOC doesn’t have a formal playbook for (e.g., firmware-level persistence, a vendor-specific API abuse).

How to handle: follow the generic 7-step triage workflow. Escalate to L2 with the enrichment you’ve gathered and be explicit: “This technique doesn’t have a documented playbook. Here’s what I found and here’s what I think L2 should investigate next.”

Playbook designed for a different environment

Your org runs Linux servers; the playbook references EVTX event IDs. Your org uses Google Workspace; the playbook references M365 UAL.

How to handle: adapt the pivot chain to your environment’s data sources. The questions are the same; the log sources differ. If the playbook is systematically wrong for your environment, flag it to the playbook owner.


Disposition Quality: What Good Looks Like

The five-line standard for closed alerts

FP — adequate:

RULE: POWERSHELL_ENCODED_COMMAND — fired on svchost.exe (system account)
ENRICHMENT: Host = patching server (P3), User = SYSTEM, 09:00 scheduled
PIVOT: Decoded command = SCCM software inventory query, matches known-FP pattern
DISPOSITION: FP — SCCM-triggered scheduled task. Matches allowlist entry #847.
ACTION: Close. No tuning needed (existing allowlist covers this).

FP — inadequate:

Looks like a FP. Closed.

The escalation standard for TPs

TP escalation — adequate:

ALERT: SURICATA_ET_MALWARE_COBALT_STRIKE_JA3 — CORP-PC-018 → 185.220.101.5:443
USER: jsmith (developer, MFA on, no admin)
HOST: CORP-PC-018 (P2, engineering workstation)
PIVOTS: Zeek conn.log: 4-hour session, 87KB out / 2.1MB in, service=-
Zeek ssl.log: JA3 matches known CS default. Cert self-signed (issued 3 days ago).
Sysmon 3: process = chrome.exe at 09:23, PIDs match. Opened by jsmith manually.
HYPOTHESIS: Active C2 — Cobalt Strike beacon initiated by jsmith clicking a link at 09:23.
ATT&CK: T1071.001, T1571. DISPOSITION: TP. ESCALATE P1.
L2 ACTIONS: (1) Isolate CORP-PC-018 via EDR. (2) Check all hosts connecting to 185.220.101.5 in last 48h. (3) Pull browser history for jsmith at 09:23. (4) Check for lateral movement from CORP-PC-018 post-09:23.

TP escalation — inadequate:

Suspicious beacon. Bad IP. Escalating.

ATT&CK Tagging Discipline

Every TP disposition must include at least one ATT&CK technique ID. This is not administrative overhead — it feeds the coverage matrix, the threat intel correlation, and the monthly reporting.

Rules for tagging:

  1. Tag the specific sub-technique when you have enough evidence (T1059.001 vs just T1059)
  2. Tag multiple techniques if the activity spans multiple — a PowerShell download-and-execute tags T1059.001 + T1105
  3. Don’t tag a technique you can’t justify — “I think this might be T1003” is not a justification
  4. When uncertain between two techniques, tag both and note your uncertainty

SOAR Handoff: What’s Safe to Automate

Not every triage response action is safe for automation. The test: is this action reversible if wrong?

ActionSOAR-able?Notes
IP reputation lookupYes — autoRead-only. Always safe.
User identity enrichmentYes — autoRead-only. Always safe.
URL detonation (sandbox)Yes — autoRead-only. Always safe.
Block IP at firewallYes — with approvalReview the IP first; blocking a CDN IP can break production.
Block URL/domainYes — with approvalCheck for shared domain with legitimate services.
Send user notificationYes — with approvalWording matters; a poorly-worded auto-email creates panic.
Revoke user sessionYes — with approvalDisrupts the user’s work; confirm TP before executing.
Disable user accountNo — manual onlyHigh blast radius if wrong. Requires explicit manager approval.
Isolate host via EDRNo — manual onlyProduction host isolation can cause outage.
Mass password resetNo — manual onlyNever automate for more than 1 account at a time.