Chapter 23 — Cloud and container security: threat and failure analysis
Lesson map
Lesson 23 published. Map, example, EX067.
flowchart TD
N0["Learning outcomes"]
N1["23.1 Threat categories"]
N2["23.2 Failure analysis"]
N3["23.3 Scenarios"]
N4["23.4 Ranking"]
N5["23.5 Linking controls"]
N6["23.6 Review"]
N7["Using the ranking"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX067"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["23.1 Threat categories"]
N2["23.2 Failure analysis"]
N3["23.3 Scenarios"]
N4["23.4 Ranking"]
N5["23.5 Linking controls"]
N6["23.6 Review"]
N7["Using the ranking"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX067"]
[Learning outcomes]
|
v
[23.1 Threat categories]
|
v
[23.2 Failure analysis]
|
v
[23.3 Scenarios]
|
v
[23.4 Ranking]
|
v
[23.5 Linking controls]
|
v
[23.6 Review]
|
v
[Using the ranking]
|
v
[Worked example] --> [Exercise EX067]
Learning outcomes
You will (1) analyse threats and failures for meterhub systematically; (2) use STRIDE-style categories; (3) consider accidental failures; (4) rank scenarios and link controls.
23.1 Threat categories
Using the STRIDE categories Shostack (2014) teaches: spoofing (a fake meter or service), tampering (altered readings or images), repudiation (unlogged admin changes), information disclosure (public buckets, leaked keys), denial of service (ingest floods), elevation of privilege (privileged pods reaching the node).
STRIDE gives a checklist so that threats are considered systematically rather than only the ones people happen to remember. For each component and flow, Elena asks which categories apply. Where a category does not apply to a flow, she notes why, so a reviewer can see it was considered rather than forgotten.
23.2 Failure analysis
Not all problems are attacks. Failures include expired certificates stopping ingest, a policy change blocking legitimate traffic, a node pool upgrade evicting pods and a misconfigured lifecycle rule deleting data early.
Failures can cause harm just as attacks do: an expired certificate stops ingestion and loses readings; a lifecycle rule set to thirty days instead of thirteen months deletes billing data. Including failures in the same analysis gives a complete view of risk and often leads to the same controls, such as monitoring and change review.
23.3 Scenarios
Each scenario names a cause, a path and an impact: "A developer pushes an image with an embedded key to a public registry; the key allows reading three buckets; readings could be exposed." Scenarios stay at outcome level, without procedures.
Scenarios make risks concrete enough to discuss with managers. Each names who or what causes the problem, how it unfolds and what is lost. Keeping them at outcome level avoids writing attack instructions while still conveying the risk and guiding control choices.
23.4 Ranking
Likelihood and impact are rated with evidence such as past incidents and exposure.
Evidence-based ratings carry more weight than intuition. The key leak raised the likelihood of credential exposure, since it had already happened once. A public-facing ingest endpoint raises exposure to floods. Ratings are explained in a sentence each, so others can challenge them. A simple three-level scale, low, medium and high, is used for both likelihood and impact, with written definitions for each level so different raters apply them the same way. Elena and Rosa rate scenarios separately, then discuss any disagreement until they agree.
23.5 Linking controls
Each scenario lists preventive, detective and recovery controls and their requirement IDs.
Linking each scenario to controls and requirements shows how defences combine. The key-leak scenario links to secret scanning (detective), workload identity (preventive) and fast revocation (recovery). Scenarios with no linked controls are gaps that need attention. The table also shows which controls protect against several scenarios at once, such as workload identity, which reduces both credential leaks and over-broad access. Those shared controls get extra attention, since losing one would weaken many defences together. Elena colours rows without a detective control.
23.6 Review
The analysis is repeated when the architecture changes.
Architecture changes alter risks: adding a new external integration introduces new flows and threats. Repeating the analysis keeps it current. Elena sets a rule that any design record introducing a new component must include an update to the threat analysis. A full review also happens once a year even without changes, because the threat landscape moves: new techniques appear, and old assumptions about attackers' interest in energy data may no longer hold. The review is dated, and the previous version is kept for comparison so changes in ratings are visible.
Using the ranking
The top five scenarios get named owners and dates. Lower-ranked scenarios are reviewed quarterly. Elena notes that the analysis took two workshops of two hours each with platform engineers and developers; involving developers surfaced two failure modes the platform team had not considered, including the lifecycle rule risk.
Scenario register
Scenarios live in a register with owner, controls and review date.
Worked example
The analysis ranks "privileged pod gains node access and reads other pods' data" as high impact; it links to R3 and the node-agent exception. Elena adds a requirement that excepted privileged workloads run on a dedicated node pool, limiting what they could reach.
Synthetic case. Scenarios are synthetic.
Errors and limits
Threat lists can grow endlessly; focus on scenarios that change decisions.
Exercises
- EX067 — STRIDE example. Give an information disclosure example. Rubric: 3 = public bucket or leaked key; 2 = partial; 1 = vague; 0 = none.
- EX068 — Failure example. Name an accidental failure. Rubric: 3 = expired certificate, blocking policy, eviction, lifecycle rule; 2 = one; 1 = vague; 0 = none.
- EX069 — New requirement. What requirement followed the privileged-pod scenario? Rubric: 3 = dedicated node pool for exceptions; 2 = partial; 1 = vague; 0 = none.
Synthesis
Analyse attacks and accidents, then link scenarios to controls.
Continue studying — chapter 23 of 50
← Chapter 22 (draft) · Course chapter index · Chapter 24 (draft) →