Chapter 16 — Security operations and blue team: methods II
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Sequences"]
N2["16.2 The BrightSmile sequence"]
N3["16.3 Building the rule"]
N4["16.4 Tuning"]
N5["16.5 Severity"]
N6["16.6 Testing"]
N7["16.7 Value of earlier alerts"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Sequences"]
N2["16.2 The BrightSmile sequence"]
N3["16.3 Building the rule"]
N4["16.4 Tuning"]
N5["16.5 Severity"]
N6["16.6 Testing"]
N7["16.7 Value of earlier alerts"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 Sequences]
|
v
[16.2 The BrightSmile sequence]
|
v
[16.3 Building the rule]
|
v
[16.4 Tuning]
|
v
[16.5 Severity]
|
v
[16.6 Testing]
|
v
[16.7 Value of earlier alerts]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) build sequence detections linking several events; (2) correlate account creation with privilege changes; (3) tune sequences to client behaviour; (4) explain sequences in alert text.
16.1 Sequences
Many attacks show a sequence: access, then privilege, then impact. A rule that looks for steps in order is stronger than any single step.
For BrightSmile the order was a logon as reception at 01:19, then support2 created at 01:22, then support2 added to Administrators, and finally renames at 01:34. Single-step rules caught pieces of this; a rule that knows the order can recognise the pattern while it is still at the second or third step. Each step is also visible on its own in the logs, so the sequence rule adds certainty without needing any new data source at the client.
16.2 The BrightSmile sequence
Logon from an external address, then account creation by that session, then the new account added to Administrators within 30 minutes. Each step alone is sometimes legitimate; together they are rare.
A contractor creating an account for a new receptionist is legitimate, and a remote logon by the contractor is legitimate. What makes BrightSmile's case rare is that the same external session did all three things within minutes, at night, from an account that should never create accounts. Requiring all three steps cuts the false alarms that each step alone would produce.
16.3 Building the rule
Mei's rule joins three event types on host and session within 30 minutes. The alert text lists all three steps with times, so analysts do not have to search.
Joining on session means the account creation must come from the same logon that arrived from outside, not merely from the same host. That detail prevents an unrelated local account change, made by someone else on the server, from being stitched to an external logon that happened to occur at about the same time.
16.4 Tuning
At one client, the IT contractor routinely creates admin accounts for new staff after logging in remotely through the VPN. The rule excludes sessions from the contractor's VPN addresses during support windows but still alerts outside them.
The exclusion is deliberately narrow: it needs both the contractor's VPN address and a time within the agreed support window. If the contractor's account were stolen and used at night, or from somewhere other than their VPN, the sequence would still alert. That keeps routine onboarding of staff quiet without blinding the rule to the supplier scenario of chapter 13.
16.5 Severity
Sequences on high-criticality hosts at night are rated high and page the on-call analyst.
The BrightSmile sequence on CLINIC2-SRV at 01:22 meets both conditions: high criticality and night time. Paging means the on-call analyst is alerted by phone rather than waiting for someone to look at the queue, which is what the 15-minute acknowledgement target from chapter 10 assumes for high-severity alerts. The same sequence on a medium-criticality reception PC during opening hours is rated lower and waits in the queue for the analyst on shift. Mei writes both cases on the rule page, so the on-call analyst can see why a page arrived and how the rating was reached.
16.6 Testing
Mei tests the rule against the BrightSmile events: it fires at 01:22, twelve minutes before the rename spike.
The rule fires at 01:22 because that is when the third condition could be met: support2 was created by the external session and added to Administrators. The firing time is set by the attacker's last step, not by when the rule runs, so it is as early as the data allows. The test also confirms that the alert text lists the logon at 01:19, the creation at 01:22 and the group change, as the rule design requires.
16.7 Value of earlier alerts
Earlier detection gives more time. If this rule had existed, isolation could have happened before any file was renamed.
In the real incident isolation came at 01:36, two minutes after the spike, and 985 files were renamed before it took effect. The sequence rule shifts the alert twelve minutes earlier, which in the quick case moves isolation ahead of the first rename and in the slow case still shortens the encryption time considerably. Mei is careful to call this an estimate from the replay, because nobody can know exactly how the attacker would have reacted to an earlier isolation.
Maintaining exceptions
Exceptions expire after six months unless renewed with a reason, so old contractor arrangements do not linger as blind spots.
Worked example
Raj asks Mei to estimate the benefit. She replays the incident: the sequence rule fires at 01:22; with the 15-minute acknowledgement target and a two-minute isolation, the server could have been isolated by about 01:39 at worst, or by 01:25 if acknowledged quickly — before the 01:34 spike in the quick case.
Synthetic case. Events and timings are invented.
Errors and limits
Sequence rules depend on all event types being logged; one missing step silences them.
Exercises
- EX046 — Sequence steps. What three steps does the rule join? Rubric: 3 = external logon, account creation, admin group add within 30 min; 2 = two; 1 = one; 0 = none.
- EX047 — Contractor exception. How was the contractor's routine work handled? Rubric: 3 = exclude VPN addresses during support windows; alert outside; 2 = partial; 1 = exclude all; 0 = none.
- EX048 — Benefit estimate. What did the replay show about timing? Rubric: 3 = fires 01:22, 12 min before spike; quick ack could isolate before 01:34; 2 = partial; 1 = vague; 0 = none.
Synthesis
Sequence detections catch attacks earlier by linking steps, provided exceptions are narrow and all steps are logged.
Continue studying — chapter 16 of 30
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →