Chapter 13 — Cloud and container security: risk scenarios
Lesson map
Lesson 13 published. Map, example, EX037.
flowchart TD
N0["Learning outcomes"]
N1["13.1 Writing scenarios"]
N2["13.2 Four scenarios"]
N3["13.3 Rating"]
N4["13.4 Prioritising"]
N5["13.5 Residual risk"]
N6["13.6 Sharing"]
N7["Scenario register"]
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 Writing scenarios"]
N2["13.2 Four scenarios"]
N3["13.3 Rating"]
N4["13.4 Prioritising"]
N5["13.5 Residual risk"]
N6["13.6 Sharing"]
N7["Scenario register"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX037"]
[Learning outcomes]
|
v
[13.1 Writing scenarios]
|
v
[13.2 Four scenarios]
|
v
[13.3 Rating]
|
v
[13.4 Prioritising]
|
v
[13.5 Residual risk]
|
v
[13.6 Sharing]
|
v
[Scenario register]
|
v
[Worked example] --> [Exercise EX037]
Learning outcomes
You will (1) write plain risk scenarios; (2) rate likelihood and impact; (3) prioritise fixes.
13.1 Writing scenarios
A scenario states what could go wrong, how, and what the result would be, without describing attack steps. For example: an outdated booking image contains a known flaw; if exploited, patient contact details could be exposed. Priya keeps scenarios at the level of what and why, never how, so the register can be shared with clients without becoming a set of instructions. Each scenario names the asset, the weakness, the likely route in general terms and the harm. The booking example names the asset, booking; the weakness, an outdated image; and the harm, exposure of patient contact details.
13.2 Four scenarios
Priya writes four: outdated public images in booking; the client-b cluster without audit logs, so misuse would go unseen; a leftover admin account; and the unencrypted email flow. Each scenario comes directly from a finding earlier in the placement: the booking image from the inventory, the audit logging gap from her review of client-b's settings, the old-admin account from the access review, and the email flow from the flow list. Writing them as scenarios turns separate findings into one list that can be compared and ordered by risk.
13.3 Rating
She rates likelihood and impact as low, medium or high, recording a sentence of reasoning for each. The booking image, for example, is rated high impact because patient contact details could be exposed, and medium likelihood because the image is reachable from the internet but no exploitation has been seen. Three levels are coarse, but they are enough to order four scenarios, and the reasoning sentence makes each rating open to challenge. When two people rate the same scenario differently, they compare reasons and agree a rating together.
13.4 Prioritising
High impact and medium or high likelihood come first: outdated booking image and missing audit logs. The admin account was already removed; the email flow is fixed. The two remaining scenarios share a feature: neither can be fixed with a one-line change. Rebuilding booking needs the client team's work and testing, and enabling audit logs on client-b needs a change window agreed with the client. Ranking them first ensures they receive time and attention instead of being left behind the quick fixes.
13.5 Residual risk
After fixes, some risk remains; the scenario record notes it. For booking, residual risk remains after the rebuild because any new image can later receive its own advisory; the inventory and pipeline reduce the time to respond rather than removing the risk. For the email flow, encryption protects data in transit, but the email provider still stores the reduced name and time. Each residual risk statement names the person who has accepted it. Accepted residual risks are reviewed on the same date as the scenario itself, so they are revisited regularly. A risk accepted once is not assumed to stay acceptable after the system changes.
13.6 Sharing
Scenarios are shared with clients in plain language as part of Cobalt's service review. Riverside Dental's practice manager receives the four scenarios written without technical terms, with a short note on what Cobalt has done and what remains. Plain language matters because the client must agree to change windows and accept residual risk; a scenario the manager cannot understand cannot be agreed to. The manager's questions are recorded with the answers given, so the next review can start from them. Her question about audit logs is the first entry in that record.
Scenario register
Scenarios are stored in a register with an owner, rating, reasoning, linked controls and review date. When a control is added, the register shows which scenarios it addresses. When an incident or advisory occurs, the team checks whether it matches an existing scenario or reveals a new one. This keeps the register alive instead of becoming a document written once and forgotten.
Priya also notes that likelihood ratings change: once the booking image is rebuilt, its scenario's likelihood drops, and the register is updated.
Worked example
Riverside Dental's practice manager reads the scenarios and asks what "audit logs" means. Priya explains they are records of who did what in the cluster, needed to investigate any problem. The manager agrees to the change window for enabling them.
Synthetic case. Scenarios are synthetic.
Errors and limits
Ratings are judgements; record the reasons so others can challenge them.
Exercises
- EX037 — Scenario parts. What three parts does a scenario state? Rubric: 3 = what, how in general, result; 2 = two; 1 = one; 0 = none.
- EX038 — Top priorities. Which two scenarios came first? Rubric: 3 = outdated booking image, missing audit logs; 2 = one; 1 = vague; 0 = none.
- EX039 — Client explanation. How did Priya explain audit logs to the client? Rubric: 3 = records of who did what; 2 = partial; 1 = vague; 0 = none.
Synthesis
Plain scenarios with reasons help clients and staff agree on priorities.
Continue studying — chapter 13 of 30
← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →