Chapter 38 — Capstone implementation
Lesson map
Lesson 38 published. Map, example, EX112.
flowchart TD
N0["Learning outcomes"]
N1["38.1 Building the package"]
N2["38.2 Tests"]
N3["38.3 Change control"]
N4["38.4 Staged deployment"]
N5["38.5 Monitor-only findings"]
N6["38.6 Going live"]
N7["38.7 Evidence"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX112"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["38.1 Building the package"]
N2["38.2 Tests"]
N3["38.3 Change control"]
N4["38.4 Staged deployment"]
N5["38.5 Monitor-only findings"]
N6["38.6 Going live"]
N7["38.7 Evidence"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX112"]
[Learning outcomes]
|
v
[38.1 Building the package]
|
v
[38.2 Tests]
|
v
[38.3 Change control]
|
v
[38.4 Staged deployment]
|
v
[38.5 Monitor-only findings]
|
v
[38.6 Going live]
|
v
[38.7 Evidence]
|
v
[Worked example] --> [Exercise EX112]
Learning outcomes
You will (1) implement the capstone detection package; (2) follow change control and testing; (3) deploy in stages; (4) record implementation evidence.
38.1 Building the package
The package contains the 6-hour correlation rule, the keyword-deletion rule and a new mass-mailing rule: alert when an account that had a risky sign-in in the past day sends to more than 50 internal recipients it has never mailed before.
The mass-mailing rule's threshold of fifty new recipients comes from the campaign: s2047 mailed far more than that, while ordinary students rarely mail more than a handful of new people in a day. Restricting it to accounts with a recent risky sign-in keeps it focused on likely compromise rather than busy organisers.
38.2 Tests
Each rule has unit tests in the SOC's test harness and a set of synthetic events. Tests run before each change.
Unit tests check each rule's logic with small inputs, including boundary cases such as exactly fifty recipients. The synthetic events replay realistic sequences, such as s3310's slow deletion rule. Running both before each change catches mistakes before they reach the monitor-only stage. The harness reports pass or fail for each test and stops a change from being submitted if any fails. Lucas added tests for the two slow-attacker scenarios as soon as they were written, so they were checked throughout development.
38.3 Change control
Lucas submits each rule through the SOC's change process with a description, test results and rollback steps. Dr. Kim approves.
Rollback steps state how to disable each rule quickly if it floods analysts. Dr. Kim's approval confirms that the tests passed and the change fits the SOC's capacity. The change record also links to the capstone log, so assessors can see the operational approval for each part of the project. The process added a day or two to each change, which Lucas planned for in his timeline.
38.4 Staged deployment
Rules run in monitor-only mode for two weeks, recording matches without alerting analysts. Lucas reviews every match.
Monitor-only mode shows how rules behave on real traffic without adding work for analysts. Lucas reviewed each match against the account's activity to decide whether it was a true or false alert. The review let him adjust rules before they affected anyone, as the next finding shows. He recorded his decision for every match in a table with the account, the rule, the reason for the match and whether it was a true or false alert. The table became part of the dossier and later fed the false-alert evaluation.
38.5 Monitor-only findings
The mass-mailing rule matches a student society officer who emailed new members after signing in from abroad on holiday. Lucas adds a check: alert only if the messages share a subject with messages already reported as phishing, or if links point to domains first seen that week.
The added check uses signals specific to phishing: a subject already reported, or links to newly seen domains. The society officer's message had neither, so the revised rule stayed quiet. Lucas reran the synthetic tests after the change to confirm that the campaign-like scenarios still alerted.
38.6 Going live
After a clean second week, the package moves to alerting for analysts.
A clean week means no false alerts from the revised rules. Lucas told the student analysts about the new alerts before they appeared, with a short guide to each. Going live on a Monday, rather than before a weekend, ensured the staffed SOC could react to any early problems. Lucas stayed available during the first live week to answer analysts' questions, and recorded each question as a possible improvement to the alert text or the rule documentation.
38.7 Evidence
Commits, test outputs, change tickets and monitor-only reviews are filed for the capstone dossier.
Filing as he went meant the dossier was complete when the evaluation began. Each item is named by date and rule, and the dossier index links each requirement to the evidence for it. An assessor can follow any claim back to commits and tests without asking Lucas. Lucas also kept a short diary of decisions and their reasons. When writing the thesis months later, the diary explained choices that the commits alone did not, such as why the recipient threshold was set where it was.
Documentation for maintainers
Each rule in the package has a page: purpose, logic, thresholds and why they were chosen, known benign matches, tests and owner. The student analysts who maintain the rules after Lucas graduates can change them without guessing his intentions.
Worked example
In the first live week, the package alerts once: a compromised account sends 120 messages with a link to a domain registered four days earlier. The account is contained within 25 minutes of the first message, inside the 30-minute requirement.
Synthetic case. Rules and events are invented.
Errors and limits
A week of live data shows early behaviour only.
Exercises
- EX112 — Mass-mailing rule. State the mass-mailing rule. Rubric: 3 = risky sign-in in past day + >50 new internal recipients; 2 = partial; 1 = vague; 0 = none.
- EX113 — Society officer. How was the society officer match handled? Rubric: 3 = added check for reported subjects or new domains; 2 = partial; 1 = ignored; 0 = none.
- EX114 — Live result. What happened in the first live week? Rubric: 3 = one alert; 120 messages, new domain; contained in 25 min; 2 = partial; 1 = vague; 0 = none.
Synthesis
Implement with tests, change control and monitor-only stages, adjusting rules from observed matches.
Continue studying — chapter 38 of 40
← Chapter 37 (draft) · Course chapter index · Chapter 39 (draft) →