Chapter 8 — Cloud and container security: failure modes
Lesson map
Lesson 08 published. Map, example, EX029.
flowchart TD
N0["Learning outcomes"]
N1["8.1 How it happened"]
N2["8.2 Common causes"]
N3["8.3 Classifying"]
N4["8.4 Matching controls"]
N5["8.5 Blameless review"]
N6["Lessons from research"]
N7["Recording causes"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX029"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 How it happened"]
N2["8.2 Common causes"]
N3["8.3 Classifying"]
N4["8.4 Matching controls"]
N5["8.5 Blameless review"]
N6["Lessons from research"]
N7["Recording causes"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX029"]
[Learning outcomes]
|
v
[8.1 How it happened]
|
v
[8.2 Common causes]
|
v
[8.3 Classifying]
|
v
[8.4 Matching controls]
|
v
[8.5 Blameless review]
|
v
[Lessons from research]
|
v
[Recording causes]
|
v
[Worked example] --> [Exercise EX029]
Learning outcomes
You will (1) explain how cloud misconfigurations happen; (2) classify causes; (3) connect causes to controls.
8.1 How it happened
The developer needed to share a file, had permission to change the policy, and no check stopped him. Three conditions combined: a missing service, broad permission and no guardrail. Any one of those conditions missing would have stopped the incident. With a partner file service, dev-sam would not have needed a public bucket; without policy permission, he could not have set one; with an account-level block, the policy change would have been refused. The review therefore aims to restore all three barriers rather than rely on any single one.
8.2 Common causes
Cloud failures often come from manual console changes, copied examples with insecure defaults, permissions broader than needed and lack of review. Fairway's March incident was a manual console change, and the driver-photos bucket, discovered later, came from a copied example with no encryption setting. Both of those causes appear in the list of common failures above. Tomás uses the list as a prompt when reviewing other buckets and the cluster, asking for each setting whether it was set by hand, copied or reviewed.
8.3 Classifying
Tomás groups causes as process (no partner transfer service), access (broad permissions) and technical (no public access block). Grouping the causes this way helps Grace assign each action to an owner. The process cause belongs to whoever arranges partner services, the access cause to the identity administrators, and the technical cause to the cloud platform team. Without grouping, every action would land on Grace by default, and the missing partner service in particular might never be fixed. Each group is written into the review with one sentence of evidence from March.
8.4 Matching controls
Process: provide a secure way to share files. Access: remove policy permissions from developers. Technical: enable account-level public access blocking. Each control maps to one cause, and each gets an owner and a date in the action list. The signed-link service arrives later as the partner file service, developer policy permissions are removed in the configuration work, and the account-level block is the first change Tomás applies because it stops the pattern at once. Grace reviews the list at the follow-up date one month later and marks each action done or late.
8.5 Blameless review
The review focuses on conditions, not the developer. dev-sam made a reasonable choice with the tools and permissions he had, under pressure to help a partner. Blaming him would teach staff to hide mistakes and would leave the three conditions in place for the next person. The review notes his openness in explaining what he did, which made the causes clear quickly. The review document names conditions and controls, and does not name dev-sam as a cause. He reads the draft before it is shared with all developers and agrees with how it describes events. His explanation of the hard-to-guess link becomes a teaching point for the whole team rather than a mark against him.
Lessons from research
Cloud misconfiguration is widely reported. Armbrust et al. (2010) noted early that cloud computing shifts operational work to customers in new ways; the shared responsibility pages from AWS, Azure and Google Cloud all place access configuration with the customer. Fairway's incident fits this pattern: the provider's storage worked as designed, and the exposure came from configuration.
Tomás uses this to explain to the team that the fix is about Fairway's own practices, not about changing providers.
Recording causes
Each cause is recorded with its matching control and an owner, so the review leads to actions rather than only understanding.
Follow-up date
Grace sets a review date one month later to check that every action was completed.
Sharing lessons
A short summary of causes is shared with all developers.
Worked example
dev-sam joins the review and explains he believed the link was hard to guess. Grace thanks him for being open, and the team notes that obscurity is not access control.
Synthetic case. Synthetic.
Errors and limits
Fixing only one cause leaves the others to combine again.
Exercises
- EX029 — Three conditions. Which three conditions combined? Rubric: 3 = missing service, broad permission, no guardrail; 2 = two; 1 = one; 0 = none.
- EX030 — Cause groups. Name the three cause groups. Rubric: 3 = process, access, technical; 2 = two; 1 = one; 0 = none.
- EX031 — Technical control. Which technical control matches? Rubric: 3 = account-level public access block; 2 = partial; 1 = vague; 0 = none.
- EX032 — Obscurity. Why is a hard-to-guess link not enough? Rubric: 3 = obscurity is not access control; 2 = partial; 1 = vague; 0 = none.
Synthesis
Fix every contributing condition, not just one.
Continue studying — chapter 08 of 18
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →