◇ OpenCyber Academy
Technologist · Chapter 13 · English

Chapter 13 — Security operations and blue team: risk scenarios

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 13 — Security operations and blue team: risk scenarios

Lesson map

Lesson 13 published. Map, example, EX037.

flowchart TD
  N0["Learning outcomes"]
  N1["13.1 What a scenario is"]
  N2["13.2 Scenarios for clinics"]
  N3["13.3 Likelihood and impact"]
  N4["13.4 Mapping to detection"]
  N5["13.5 Gaps"]
  N6["13.6 Review after incidents"]
  N7["13.7 ATT&CK link"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX037"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["13.1 What a scenario is"]
  N2["13.2 Scenarios for clinics"]
  N3["13.3 Likelihood and impact"]
  N4["13.4 Mapping to detection"]
  N5["13.5 Gaps"]
  N6["13.6 Review after incidents"]
  N7["13.7 ATT&CK link"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX037"]

[Learning outcomes]
    |
    v
[13.1 What a scenario is]
    |
    v
[13.2 Scenarios for clinics]
    |
    v
[13.3 Likelihood and impact]
    |
    v
[13.4 Mapping to detection]
    |
    v
[13.5 Gaps]
    |
    v
[13.6 Review after incidents]
    |
    v
[13.7 ATT&CK link]
    |
    v
[Worked example] --> [Exercise EX037]

Learning outcomes

You will (1) write risk scenarios for small-business clients; (2) link scenarios to detection and response needs; (3) prioritise scenarios by likelihood and impact; (4) review scenarios after incidents.

13.1 What a scenario is

A risk scenario describes how harm could happen: who, through what route, to which asset, with what impact. For BrightSmile: "an external attacker guesses a password on exposed remote desktop, gains admin rights and encrypts patient records".

Each part of the BrightSmile scenario points to something to watch. "External attacker" points to the firewall log, "guesses a password" to failed logons, "gains admin rights" to new administrator accounts and "encrypts patient records" to file activity on the server. Written that way, a scenario is already half a detection plan.

13.2 Scenarios for clinics

Copperleaf uses five for small healthcare clients: ransomware via remote access, email account takeover leading to invoice fraud, lost unencrypted laptop, insider misuse of patient records, and supplier compromise (for example the IT contractor's account).

Each of the five matches something Copperleaf's clinics actually have: exposed or remote access, cloud email used for supplier payments, laptops carried between clinics, staff with access to records, and an outside contractor holding administrator rights. A scenario that does not match a client's assets, such as one involving a data centre, is left off the list.

13.3 Likelihood and impact

Each scenario gets a rough rating. Ransomware via remote access is high likelihood (before the VPN change) and high impact.

The rating is kept rough on purpose, using high, medium and low rather than percentages that would suggest precision nobody has. For BrightSmile before the VPN change, likelihood was high because the port was exposed and attracting 41,000 attempts a week, and impact was high because the server held all patient records. Mei writes one sentence beside each rating explaining it, so the rating can be challenged on its reasons rather than on its label.

13.4 Mapping to detection

For each scenario, the team lists detections that would catch its steps — failed logons, new admin accounts, rename spikes — and response actions.

For the ransomware scenario the mapping is concrete: failed logons from outside cover guessing, the new-administrator rule covers privilege, and the rename spike covers encryption. Each detection has a planned response, such as isolating the host or disabling an account. A step with no detection beside it is a gap, which is exactly what the next measure looks for.

13.5 Gaps

The supplier-compromise scenario had no specific detection: a contractor logon looks normal. Mei proposes alerting on contractor logons outside agreed support windows.

The contractor is supposed to log on to BrightSmile's systems, so rules about remote logons or administrator activity cannot tell their normal work from an attacker using their account. Support windows give a reference: a contractor logon at a time no support was scheduled is worth asking about, even though it may still turn out to be legitimate.

13.6 Review after incidents

After the BrightSmile incident, the ransomware scenario's likelihood is reduced for that client (VPN and MFA added) but kept high for clients without them.

The change is client-specific because the reason for the high rating changed only at BrightSmile. Clients that still forward remote desktop from the internet keep the high rating, and Mei's table records why each client's rating differs, so a later reviewer can see that the difference rests on a control, not on guesswork. The table keeps the earlier rating beside the new one, so the effect of the VPN and MFA change on BrightSmile's risk is visible to the client.

13.7 ATT&CK link

Scenario steps are tagged with ATT&CK techniques for consistency across clients.

Tagging lets Copperleaf ask questions across its forty clients, such as which scenarios rely on valid accounts or on remote services, using one shared vocabulary. Mei uses the ATT&CK names published by MITRE rather than inventing her own labels, so another analyst or the client's contractor can look each technique up independently. The tags do not replace the scenario text; they sit beside each step so that the same step is labelled the same way for every client in Copperleaf's records.

Sharing scenarios with clients

Mei explains each scenario to the office manager in one sentence and asks which would hurt the business most. The manager ranks lost patient trust above downtime, which raises the priority of the insider-misuse scenario for BrightSmile.

Worked example

Mei's scenario table for BrightSmile lists the five scenarios, ratings, detections and gaps. Raj approves adding the contractor-window rule and asks the IT contractor to share their support schedule.

Synthetic case. Scenarios and ratings are invented.

Errors and limits

Ratings are judgements; revisit them when the threat or client changes.

Exercises

Synthesis

Risk scenarios connect threats to detections and responses and show where coverage is missing.

Continue studying — chapter 13 of 30

← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →