Automation, orchestration and getting time back

Why this matters

Objective 1.5 is about efficiency and process improvement, and it is the part of the exam most likely to be dismissed as management filler. It is not. The binding constraint in every SOC is analyst hours, and automation is the only lever that changes that constraint rather than redistributing it.

The exam tests judgement here: what is worth automating, what happens when automation is wrong, and how you tell whether an improvement improved anything. Those are the same questions that decide whether a real SOC scales or drowns.

The lesson

What is worth automating, and what is not

The usable test has three parts. Automate a task when it is repetitive, deterministic, and cheap to verify.

Strong candidates:

• Enrichment. Look up the reputation of a hash, the owner of an asset, the geolocation of an address, the user's department and manager. Every analyst does this on every alert, it is mechanical, and it produces no risk.
• Correlation gathering. Pull the other alerts on this host in the last 24 hours, the process tree around the event, recent logins for the user.
• Ticket creation and routing, including priority from asset criticality.
• Known-benign closure, where a specific, documented pattern is conclusively benign — with the reason recorded, not just the closure.
• Containment of unambiguous cases, such as isolating a host on confirmed ransomware behaviour, where waiting costs more than a rare false positive.
• Bulk retrospective search when new intelligence arrives, per lesson 13.

Poor candidates:

• Judgement calls under ambiguity — exactly the triage decisions from lesson 9, where the answer depends on context no rule has.
• Anything whose failure is expensive and hard to reverse. Automatically disabling accounts sounds efficient until a credential-stuffing wave locks out half the workforce, which is a denial of service you performed on yourself.
• Rare tasks. Automating something done twice a year costs more than it saves and rots between uses.
• Unstable processes. Automating a process nobody has standardised hard-codes whatever it happened to be that week.

The highest-value target is almost always enrichment, because it shortens every single alert rather than eliminating a few.

Playbooks, runbooks and SOAR

The vocabulary, since the exam uses it precisely:

• A runbook is the procedure for a task: the steps, in order, with the commands. Usually written for a human.
• A playbook is the response to a scenario: what to do about suspected ransomware, or a phishing report. Broader, includes decision points and escalation.
• SOAR — security orchestration, automation and response — is the platform that executes playbooks across tools: query the SIEM, ask the EDR to isolate, update the ticket, notify a channel.

What makes a playbook good rather than decorative:

• It names decision points explicitly, and says who makes each one. "Escalate if the account is privileged" is actionable; "use judgement" is not.
• It states the authority. Can the analyst isolate the host themselves, or do they need approval? Written down, before 3am.
• It includes the communication step, which is the one most often missing and the one that causes most of the pain afterwards.
• It is tested, ideally in a tabletop, as covered in the IR preparation lesson.
• It has an owner and a review date, or it silently describes a tool you decommissioned last year.

SOAR's genuine benefit is consistency as much as speed: every alert of a type gets the same enrichment and the same steps, whoever is on shift and however tired they are.

Its genuine risk is that it acts at machine speed on machine judgement. Which leads directly to the last section.

Enrichment as the highest-value automation

Worth its own treatment, because it is the recommendation that survives contact with reality most reliably.

Consider the arithmetic. An analyst spends five to fifteen minutes gathering context on an alert before they can even begin to judge it: who owns this host, is this hash known, has this user been flagged before, what else fired nearby. Multiply by the daily alert count and the cost is enormous — and none of that time is analysis. It is fetching.

Automated enrichment attaches all of it to the alert before a human opens it. The analyst starts with the context instead of assembling it. Typical gains:

• Triage time falls sharply, often by more than half.
• Consistency improves: every alert gets the same context, not whatever the analyst thought to check.
• Quality improves, because analysts make better decisions with more context, and enrichment supplies context that a rushed human would skip.
• The risk is close to zero, because enrichment only adds information. A wrong enrichment misleads, which is why sources should be labelled — but it changes no system state.

If a SOC can automate exactly one thing, this is it.

Measuring whether an improvement improved anything

The failure mode of process improvement is confident change with no measurement, and the second failure mode is measuring the wrong thing.

Measure before you change, or you have nothing to compare with. Useful measures:

• Time to triage per alert type, which is what enrichment should move.
• Alerts closed per analyst hour, with the caveat that speed without accuracy is worse than slow.
• True positive rate per rule, which tells you which detections deserve to exist.
• Escalation accuracy — how many escalations were genuinely warranted, which catches both over- and under-escalation.
• Coverage, per the frameworks lesson: how many techniques you can detect at all.
• Dwell time and MTTD/MTTR, with the sampling caveats from lesson 1.

The traps, which the exam does poke at:

• Vanity metrics. Total events ingested, total alerts generated, "threats blocked". None describe whether you are safer.
• Goodhart's law. Any metric used as a target stops measuring what it measured. Target time-to-close and cases close fast; quality is the variable that gives.
• Attributing change to your intervention when something else moved — a quiet month, a decommissioned noisy system, a staffing change.
• Averages over skewed data, as with MTTD.

A fair claim looks like: "Median triage time for phishing alerts fell from 11 minutes to 4 after automated enrichment, measured over 60 days before and after, with alert volume unchanged." That sentence can be checked, which is what makes it worth writing.

Automation that fails safely

Automation acts faster than a human can intervene, so its failure modes need designing, not discovering.

Principles that keep it safe:

• Bias towards reversible actions. Revoking a session, requiring re-authentication and quarantining a file are cheap to undo. Deleting a mailbox and wiping a device are not.
• Graduate by confidence. High-confidence detections may act; medium ones enrich and escalate; low ones only tag.
• Human in the loop for destructive steps, with the automation preparing everything so the human only approves. This preserves most of the speed and all of the judgement.
• Blast-radius limits. A playbook that would isolate more than N hosts should stop and ask. That single guard turns "the automation contained the ransomware" and "the automation isolated three thousand machines because a rule misfired" into different outcomes.
• Exclusions for critical assets, so nothing automatically isolates a domain controller or a life-safety system.
• Full logging of automated actions, because during an incident you must be able to tell which changes were the attacker and which were your own tooling. An analyst chasing a mysterious mass logout that turned out to be their own SOAR playbook has lost hours that mattered.
• A kill switch, known and tested, to stop all automated response at once.
• Fail closed or fail open, deliberately. If the enrichment source is down, does the playbook stop or proceed without context? Either can be right; the wrong thing is not having decided.

The underlying idea is the same one from the tuning section of lesson 10 and the containment lesson later: speed is valuable, and irreversibility is the thing that makes speed dangerous. Automate the reversible aggressively, and make the irreversible wait for a person.

Topics this lesson owns

• [x] What is worth automating, and what is not
• [x] Playbooks, runbooks and SOAR
• [x] Enrichment as the highest-value automation
• [x] Measuring whether an improvement improved anything
• [x] Automation that fails safely