◇ OpenCyber Academy
Engineering · Chapter 27 · English

Chapter 27 — Security operations and blue team: control design

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 27 — Security operations and blue team: control design

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 Detective and responsive controls"]
  N2["27.2 Playbooks"]
  N3["27.3 Automated actions"]
  N4["27.4 Safeguards"]
  N5["27.5 D3FEND mapping"]
  N6["27.6 Testing controls"]
  N7["27.7 Case"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 Detective and responsive controls"]
  N2["27.2 Playbooks"]
  N3["27.3 Automated actions"]
  N4["27.4 Safeguards"]
  N5["27.5 D3FEND mapping"]
  N6["27.6 Testing controls"]
  N7["27.7 Case"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX079"]

[Learning outcomes]
    |
    v
[27.1 Detective and responsive controls]
    |
    v
[27.2 Playbooks]
    |
    v
[27.3 Automated actions]
    |
    v
[27.4 Safeguards]
    |
    v
[27.5 D3FEND mapping]
    |
    v
[27.6 Testing controls]
    |
    v
[27.7 Case]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) design detective and responsive controls with defined triggers and actions; (2) specify playbooks for common alerts; (3) design safeguards against harmful automated actions; (4) map controls to D3FEND techniques.

27.1 Detective and responsive controls

A detective control finds activity; a responsive control acts on it. For portal takeover, detection is the possible-takeover rule; response is locking the account, invalidating sessions and contacting the customer.

Each needs the other. A detection with no planned response leaves analysts unsure what to do at 3 a.m., while a response with no reliable detection either never triggers or triggers on the wrong accounts. Designing them together lets Amara match the strength of evidence to the strength of action: a likely takeover justifies invalidating sessions, while a mere attempt does not justify locking the customer out.

27.2 Playbooks

A playbook lists the steps an analyst follows for an alert type: verify, scope, contain, notify, record. It names the data to check and the decision points. NIST SP 800-61r3 places such response activities within the broader risk-management cycle.

Decision points are where the playbook asks the analyst to judge rather than follow: is the success from the customer's usual device? Has the address already been changed? Naming the data to check at each point stops analysts from skipping evidence under pressure. The playbook also says when to stop and escalate, so analysts know the limits of their own authority during an incident.

27.3 Automated actions

Some steps can be automated: invalidating a session is low-risk and fast. Others, such as blocking a network range, can harm legitimate users and need a human decision.

Invalidating a session forces a fresh login; if the customer is genuine, they simply sign in again, so a wrong decision costs little. Blocking a network range might cut off a mobile carrier serving thousands of customers, so a wrong decision costs a great deal. Amara sorts each candidate action by the cost of being wrong and only automates those where a mistake is cheap and easily reversed.

27.4 Safeguards

Automation needs limits: maximum actions per hour, exclusions for critical accounts, and automatic alerts if limits are reached. A runaway automation can lock out thousands of customers.

A rule bug or a flood of synthetic test events could trigger the automation thousands of times in minutes. A cap on actions per hour turns a potential disaster into a contained one. Critical accounts, such as those used by depot systems, are excluded because locking them would stop deliveries. Reaching a limit pauses the automation and pages an engineer, who decides whether to continue.

27.5 D3FEND mapping

D3FEND names defensive techniques such as authentication event thresholding and account locking. Mapping controls to it clarifies what each control actually does and helps find gaps.

Product names and marketing terms vary, which makes it hard to tell whether two tools overlap or leave gaps. D3FEND gives a shared vocabulary describing what a control does to the adversary's activity. Mapping Lindqvist's portal controls shows thresholding and account locking are present, while nothing yet analyses session behaviour after login, which suggests where to invest next.

27.6 Testing controls

Each control is tested with safe synthetic events, and response playbooks are rehearsed in exercises.

Synthetic events check that detection fires and that automation acts within its limits. Exercises check the human parts: does the analyst find the playbook, does customer service know what to tell a locked-out customer, does the escalation contact answer? Exercises often reveal small problems, such as an out-of-date phone number, that no technical test would catch. Findings from each exercise are logged with an owner and a date for the fix.

27.7 Case

Amara designs the possible-takeover playbook with Paolo and the customer service manager.

Involving customer service early matters because they will speak to customers whose accounts were locked. The manager asks for a short script explaining why access was reset and how to regain it, and for a field in the alert showing whether the customer has already been contacted. Both requests go into the playbook before it is tested. The finished playbook is rehearsed once with a synthetic alert before go-live, with the customer service manager playing the customer.

Customer experience

Responsive controls touch customers. The hold message on the portal explains that the account is paused for safety and gives the support number, so legitimate customers are not left confused.

Worked example

The playbook automates session invalidation and a temporary account hold, capped at 20 accounts per hour; above that, automation pauses and pages the on-call engineer. An analyst confirms within 30 minutes, contacts the customer through the registered phone number and records the outcome.

Synthetic case. The playbook is invented.

Errors and limits

Playbooks age as systems change; review after each use.

Exercises

Synthesis

Design controls as detection plus response, automate low-risk steps with limits, and map controls to named defensive techniques.

Continue studying — chapter 27 of 50

← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →