Chapter 29 — Capstone build
Lesson map
Lesson 29 published. Map, example, EX085.
flowchart TD
N0["Learning outcomes"]
N1["29.1 The capstone"]
N2["29.2 Requirements"]
N3["29.3 Building"]
N4["29.4 Testing"]
N5["29.5 Guard rails"]
N6["29.6 Documentation"]
N7["29.7 Peer review"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX085"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["29.1 The capstone"]
N2["29.2 Requirements"]
N3["29.3 Building"]
N4["29.4 Testing"]
N5["29.5 Guard rails"]
N6["29.6 Documentation"]
N7["29.7 Peer review"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX085"]
[Learning outcomes]
|
v
[29.1 The capstone]
|
v
[29.2 Requirements]
|
v
[29.3 Building]
|
v
[29.4 Testing]
|
v
[29.5 Guard rails]
|
v
[29.6 Documentation]
|
v
[29.7 Peer review]
|
v
[Worked example] --> [Exercise EX085]
Learning outcomes
You will (1) build a capstone improvement for the managed SOC; (2) integrate detection, automation and reporting; (3) test the build safely; (4) document it for operations.
29.1 The capstone
Mei builds a "ransomware early warning" package for all healthcare clients: the sequence rule, the rename-spike rule with automated isolation and guard, heartbeat-gap alerts on servers, and a monthly coverage report.
Each component of the package answers one step of the BrightSmile incident. The sequence rule catches the account creation that took place at 01:22, the rename-spike rule with isolation stops encryption like that which started at 01:34, heartbeat gaps catch an attacker or fault silencing a server, and the coverage report shows each client what is protected.
29.2 Requirements
Detect the BrightSmile sequence within 5 minutes of the admin-group change; isolate on rename spikes within 2 minutes; page on server heartbeat gaps over 15 minutes at night; no more than one false page per client per month.
The requirements are written as numbers so they can be tested. Five minutes for the sequence alert leaves room within the 15-minute acknowledgement target; two minutes for isolation matches the fastest trainees in the chapter 15 lab; 15 minutes for heartbeat pages separates a reboot from a real loss; and the false-page limit protects the two night analysts.
29.3 Building
Rules are written in the SIEM, automation in Copperleaf's playbook tool, reports from SIEM queries. Everything is stored in version control with change notes.
Using Copperleaf's existing tools means the package can be maintained by the team after Mei leaves rather than needing a new system. Version control with change notes gives the history that the runbooks and the evaluation rely on, so anyone can see which version of a rule was running when a given alert fired. Each change note links to its lab test, so a reviewer can check that a rule was tested in the form it was deployed.
29.4 Testing
Each component is tested in the lab with synthetic events: the BrightSmile replay, the rename spike and a stopped agent.
Each of these tests uses a scenario whose correct answer is known in advance. The BrightSmile replay should produce a sequence alert after the admin-group change, the rename spike should trigger isolation, and a stopped agent should produce a heartbeat page. Synthetic events keep the tests safe, and known answers make a failure obvious, as the heartbeat test showed. Mei writes the expected result of each test before running it, as she did with her first parser in chapter 3.
29.5 Guard rails
The isolation guard from chapter 22 is reused; heartbeat paging respects client maintenance windows.
Reusing the guard means the limit of two automatic isolations per client per hour, tested in chapter 22, applies here too. Respecting maintenance windows stops the heartbeat rule paging when a contractor reboots a server on schedule, which would otherwise break the requirement of no more than one false page per client per month. Maintenance windows are taken from each client's profile, so an undocumented window can still cause a false page, as the assessment later found.
29.6 Documentation
Runbooks for each alert, a client-facing summary and an owner list.
Each runbook follows the pattern from chapter 26, so analysts meet familiar steps for the new alerts. The client-facing summary tells an office manager in plain language what the package watches and what Copperleaf may do automatically, and the owner list names who maintains each rule after Mei's placement ends. The documentation is stored in version control with the rules, so a change to a rule and its runbook are reviewed together. Each runbook names the requirement its alert serves, which lets an analyst see at night why the alert matters and how quickly it must be handled.
29.7 Peer review
A senior analyst reviews logic and runbooks before deployment.
The senior analyst checks that each rule's logic matches its requirement and that the runbooks give clear decisions at night. A reviewer who did not build the package is more likely to see an unstated assumption, such as a maintenance window that is not documented for every client, which later caused one false page. Review comments and Mei's responses are kept with the change notes, so the reasoning behind each design choice remains available to the future owner. The reviewer also checks that every requirement has a test, so nothing in the package goes live untested.
Version control and change notes
Every rule and playbook in the package is stored with a change note that explains what changed, why, who reviewed it and how it was tested. If an alert misbehaves after go-live, the team can see exactly which change caused it and roll it back to the previous version within minutes. Mei tags the first deployable set as version 1.0 so later comparisons have a clear baseline, and links each tag to its test results in the lab.
Worked example
Lab tests: sequence alert in 2 minutes after the admin-group event; isolation 70 seconds after spike detection; heartbeat page 16 minutes after the agent stopped — one minute over the target because the check runs every five minutes. Mei changes the check interval to two minutes and retests: 13 minutes.
Synthetic case. The build and test results are invented.
Errors and limits
Lab timings exclude real-world delays such as slow client links.
Exercises
- EX085 — Package parts. List the four parts of the package. Rubric: 3 = sequence rule, rename spike with isolation, heartbeat gaps, coverage report; 2 = three; 1 = one; 0 = none.
- EX086 — Requirements. State two requirements of the package. Rubric: 3 = e.g. sequence within 5 min; isolate within 2 min; heartbeat page >15 min; ≤1 false page/month (two); 2 = one; 1 = vague; 0 = none.
- EX087 — Heartbeat fix. Why did the heartbeat test miss its target and what fixed it? Rubric: 3 = 5-min check interval; changed to 2 min; 13 min; 2 = partial; 1 = vague; 0 = none.
Synthesis
A capstone build integrates rules, automation and reporting, tested against explicit requirements.
Continue studying — chapter 29 of 30
← Chapter 28 (draft) · Course chapter index · Chapter 30 (draft) →