Chapter 22 — Security operations and blue team: automation
Lesson map
Lesson 22 published. Map, example, EX064.
flowchart TD
N0["Learning outcomes"]
N1["22.1 What to automate"]
N2["22.2 Automated containment"]
N3["22.3 Guard rails"]
N4["Lab — containment guard"]
N5["22.4 Reading the result"]
N6["22.5 Testing"]
N7["22.6 Review"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX064"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 What to automate"]
N2["22.2 Automated containment"]
N3["22.3 Guard rails"]
N4["Lab — containment guard"]
N5["22.4 Reading the result"]
N6["22.5 Testing"]
N7["22.6 Review"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX064"]
[Learning outcomes]
|
v
[22.1 What to automate]
|
v
[22.2 Automated containment]
|
v
[22.3 Guard rails]
|
v
[Lab — containment guard]
|
v
[22.4 Reading the result]
|
v
[22.5 Testing]
|
v
[22.6 Review]
|
v
[Worked example] --> [Exercise EX064]
Learning outcomes
You will (1) identify SOC tasks suitable for automation; (2) design automated containment with guard rails; (3) test automation safely; (4) review automated actions.
22.1 What to automate
Repetitive, well-understood steps suit automation: enriching alerts, opening contractor tickets, isolating a host on a high-confidence spike. Judgement calls do not.
Enriching alerts and opening tickets follow fixed steps that a script does the same way each time. Isolating on a spike is also fixed once the conditions are agreed. Deciding whether a contractor's late logon is legitimate needs context a script does not have, such as a phone call, so it stays with an analyst. Each automated step is listed on a page with its trigger and its limits, so analysts know exactly what the system will do without them.
22.2 Automated containment
After BrightSmile, Copperleaf automates isolation for rename spikes on clinic servers and PCs, for clients whose agreements allow it, so containment does not wait for an analyst.
The reason is the timing on the incident night: the spike began at 01:34 and isolation came at 01:36, and 985 files were renamed over those minutes. Automated isolation acts in the minute the spike is detected, which removes the time an analyst needs to read the alert, check the client and reach Raj for approval.
22.3 Guard rails
Automation can go wrong at scale: a bad rule could isolate every PC in a clinic. A guard limits automatic isolation to two hosts per client per hour; beyond that, the on-call analyst is paged.
The limit is a trade-off: a real outbreak could affect more than two hosts in an hour, but then a person should be deciding anyway. Paging the on-call analyst at that point means a faulty rule cannot cut a whole clinic off its server and PCs, while a real outbreak still gets a quick human decision.
Lab — containment guard
"""Automated containment with a safety guard: isolate at most 2 hosts per client per hour (synthetic)."""
alerts = [("BrightSmile", "CLINIC2-PC1", "rename spike"), ("BrightSmile", "CLINIC2-PC2", "rename spike"),
("BrightSmile", "CLINIC2-PC3", "rename spike"), ("Oakfield Law", "OAK-PC4", "rename spike")]
isolated = {}
for client, host, kind in alerts:
n = isolated.get(client, 0)
if n < 2:
isolated[client] = n + 1
print(f"ISOLATE {host} ({client})")
else:
print(f"PAGE ON-CALL: guard reached for {client}; {host} not auto-isolated")
Run with python3 lab_guard.py. Verified output:
ISOLATE CLINIC2-PC1 (BrightSmile)
ISOLATE CLINIC2-PC2 (BrightSmile)
PAGE ON-CALL: guard reached for BrightSmile; CLINIC2-PC3 not auto-isolated
ISOLATE OAK-PC4 (Oakfield Law)
22.4 Reading the result
Two BrightSmile PCs are isolated automatically; the third triggers a page instead because the guard is reached. Oakfield Law's PC is isolated because that client's count is separate.
The guard counts per client, which is why OAK-PC4 at Oakfield Law is isolated even though BrightSmile has already reached its limit. A global limit would have let one client's outbreak use up the automation for every other client. Mei checks the printout against the code: two isolations, one page, then one isolation for the second client.
22.5 Testing
Automation is tested in the lab with synthetic alerts, then enabled in monitor mode (logging what it would do) for two weeks before acting.
Monitor mode shows what the automation would have done on real alerts without acting on them. Two weeks gives time for routine events such as software updates to appear. The worked example shows the value: the X-ray update would have caused one wrong isolation, and it was found before any clinic PC was cut off. Only after monitor mode shows no unexplained actions is the automation switched to act, and the switch date is recorded on the rule page.
22.6 Review
Every automated action is reviewed the next morning; wrong actions lead to rule or guard changes.
The review asks two questions for each action: was the host really in trouble, and did isolation help. A wrong isolation leads to a change, such as the exclusion for the X-ray vendor's signed update process. Each change is recorded so the next review can check whether it worked. The reviewer also checks automated actions that were correct, because a correct isolation still needs the client informed and the host later released. A host left isolated after the threat is cleared stops a clinic working just as surely as the attack would have.
Client consent
Automated isolation runs only where the client's agreement allows it. Some clients prefer a phone call before any action; their profiles mark this, and the automation pages an analyst instead. Mei reviews agreements with account managers so automation settings match what each client has signed.
Worked example
In monitor mode, the automation would have isolated one PC wrongly: an X-ray system update renamed hundreds of files. Mei adds a check excluding the X-ray vendor's signed update process, and the review records the change.
Synthetic case. Alerts come from the lab script; the monitor-mode finding is invented.
Errors and limits
Guard rails slow response in genuine large outbreaks; the page ensures a human decides quickly.
Exercises
- EX064 — Automation fit. Which tasks suit automation and which do not? Rubric: 3 = repetitive well-understood steps vs judgement calls; 2 = partial; 1 = all; 0 = none.
- EX065 — Lab behaviour. What did the guard do in the lab? Rubric: 3 = isolated 2 BrightSmile hosts, paged for third; Oakfield isolated separately; 2 = partial; 1 = wrong; 0 = none.
- EX066 — Monitor-mode finding. What did monitor mode reveal and how was it fixed? Rubric: 3 = X-ray update renames would isolate; exclude signed vendor update process; 2 = partial; 1 = vague; 0 = none.
Synthesis
Automate well-understood steps with guard rails, staged testing and daily review.
Continue studying — chapter 22 of 30
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →