Chapter 24 — Security operations and blue team: controls
Lesson map
Lesson 24 published. Map, example, EX070.
flowchart TD
N0["Learning outcomes"]
N1["24.1 Controls around detection"]
N2["24.2 After the campaign"]
N3["24.3 Side effects"]
N4["24.4 D3FEND naming"]
N5["24.5 Control ownership"]
N6["24.6 Testing controls"]
N7["24.7 Cost and benefit"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX070"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["24.1 Controls around detection"]
N2["24.2 After the campaign"]
N3["24.3 Side effects"]
N4["24.4 D3FEND naming"]
N5["24.5 Control ownership"]
N6["24.6 Testing controls"]
N7["24.7 Cost and benefit"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX070"]
[Learning outcomes]
|
v
[24.1 Controls around detection]
|
v
[24.2 After the campaign]
|
v
[24.3 Side effects]
|
v
[24.4 D3FEND naming]
|
v
[24.5 Control ownership]
|
v
[24.6 Testing controls]
|
v
[24.7 Cost and benefit]
|
v
[Worked example] --> [Exercise EX070]
Learning outcomes
You will (1) relate SOC detections to preventive and responsive controls; (2) recommend controls after incidents; (3) evaluate controls for side effects; (4) map controls using D3FEND names.
24.1 Controls around detection
Detection works best alongside prevention and response. For phishing: mail filtering and DMARC enforcement prevent; mailbox-rule monitoring detects; password resets and session revocation respond.
In the campaign, prevention was weak, since filtering only added a banner, and detection was slow, so response had to clean up more than it should have. Strengthening prevention reduces what detection has to catch, and faster detection reduces what response has to undo. The control changes below address all three. Lucas's control table has a column for each.
24.2 After the campaign
The campaign response produced four control changes: required student MFA, disabled legacy mail protocols, blocked automatic external forwarding by default, and added a report button in the mail client.
Each change maps to a step in the attack. MFA and legacy blocking address the use of stolen passwords. The forwarding block stops the exfiltration seen in s2047's mailbox. The report button speeds up the first signal, which came from people in both cases studied. Together they target the points where the campaign succeeded.
24.3 Side effects
Blocking external forwarding affects staff who forward mail to personal accounts. The university publishes an exception process requiring manager approval and a business reason.
Lucas counted existing forwarding rules before the block was applied: a small number of staff had them, mostly to personal accounts. Each was contacted with instructions for the exception process. Doing this before the change avoided a wave of complaints and missed mail on the day the block took effect. The exception list is reviewed each term.
24.4 D3FEND naming
MITRE D3FEND names defensive techniques precisely, such as multi-factor authentication and user behaviour analysis. Naming controls this way helps compare them with other organisations and spot gaps.
Using D3FEND's terms, Lucas's control table names MFA and behaviour analysis precisely, rather than writing vague entries such as "better login security". When Riverton compared notes with another university, both could see that the other monitored mailbox rules but neither had user behaviour analysis for research servers, a shared gap. Precise names made the gap visible.
24.5 Control ownership
Each control has an owner: identity team for MFA, mail team for forwarding, SOC for monitoring rules.
Ownership matters when a control fails or causes trouble. When the forwarding block stopped a research mailing list, the mail team owned the fix and used the exception process. Without a named owner, the SOC might have been asked to change a mail setting it did not control, and the fix would have been delayed. Owners also decide on exceptions to their control.
24.6 Testing controls
After deployment, the SOC tests each control: a test account tries to create an external forwarding rule; the block works and an alert fires.
Testing showed one gap: the block applied to new rules created in the web interface but, at first, not to rules created through an older mail client. The mail team extended the policy, and the test was repeated through both routes. Deploying a control without such a test would have left the gap open. The test is now repeated after every mail-system update.
24.7 Cost and benefit
Lucas estimates time saved: forwarding blocks would have prevented the 37 messages leaving s2047's mailbox.
Those 37 messages included the three containing other students' marks, which led to the DPO's notification decision. Preventing them would have avoided the notification, the work to identify affected students and the worry it caused. Against that, the forwarding block's cost was an exception process and one brief disruption, described below under rollback. Lucas's estimate was rough, but it made the trade-off clear enough for the university to accept the block. He also noted that the block would not have stopped the s3310 deletion rule.
Rollback
Every control change has a way back. When the forwarding block briefly stopped an automated research mailing list, the mail team added an exception within an hour using the documented process.
Worked example
Three weeks after the MFA requirement, Lucas compares risky sign-in alerts: successful foreign sign-ins without MFA fall from 14 per week to 2, both from accounts not yet enrolled during a grace period. He reports the trend with the caveat that attackers may shift to MFA fatigue prompts.
Synthetic case. Controls and figures are invented.
Errors and limits
Controls change behaviour; attackers adapt, so monitoring must follow.
Exercises
- EX070 — Control changes. List the four controls adopted after the campaign. Rubric: 3 = student MFA, legacy disabled, forwarding blocked, report button; 2 = three; 1 = one; 0 = none.
- EX071 — Forwarding side effect. How was the forwarding block's side effect handled? Rubric: 3 = exception process with manager approval and reason; 2 = partial; 1 = ignored; 0 = none.
- EX072 — MFA trend caveat. What caveat did Lucas attach to the MFA results? Rubric: 3 = attackers may shift to MFA fatigue prompts; 2 = partial; 1 = vague; 0 = none.
Synthesis
Pair detections with preventive and responsive controls, test them, and watch for side effects and attacker adaptation.
Continue studying — chapter 24 of 40
← Chapter 23 (draft) · Course chapter index · Chapter 25 (draft) →