Chapter 8 — Cloud and container security: supervised case analysis
Lesson map
Lesson 08 published. Map, example, EX036.
flowchart TD
N0["Learning outcomes"]
N1["8.1 How roles grew"]
N2["8.2 How vulnerabilities piled up"]
N3["8.3 Process causes"]
N4["8.4 Recommendations"]
N5["8.5 Supervision"]
N6["Comparing with guidance"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX036"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 How roles grew"]
N2["8.2 How vulnerabilities piled up"]
N3["8.3 Process causes"]
N4["8.4 Recommendations"]
N5["8.5 Supervision"]
N6["Comparing with guidance"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX036"]
[Learning outcomes]
|
v
[8.1 How roles grew]
|
v
[8.2 How vulnerabilities piled up]
|
v
[8.3 Process causes]
|
v
[8.4 Recommendations]
|
v
[8.5 Supervision]
|
v
[Comparing with guidance]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX036]
Learning outcomes
You will (1) analyse how the audit findings arose; (2) identify process causes; (3) recommend lasting changes.
8.1 How roles grew
Permissions were added during early testing and urgent fixes, with no review afterwards. Nobody owned role hygiene. Hannah traces the history of the permissions she removed. Reporting's iam.admin was added during an early test and never taken away; storage.admin on permits-app was added during an urgent fix. In each case, a permission granted for a short-term need stayed because nobody was responsible for reviewing roles. She finds no evidence that any permission was added carelessly; the problem was the absence of a routine to remove them later.
8.2 How vulnerabilities piled up
The scanner existed, but results went to an inbox nobody watched, and there was no rule for what to fix first. The council had invested in scanning but not in what happens after a scan. Without a rule for ordering findings, the long list looked unmanageable, so nothing was fixed systematically. Without an owner, nobody was asked why findings remained. Hannah notes that tiering and a named owner address both gaps, and that the tool itself was never the problem.
8.3 Process causes
Missing ownership, missing review cadence and missing prioritisation method. Each cause is a gap in process rather than a technical failure. Nobody owned role hygiene or scan results, so nobody reviewed them. There was no review cadence, so permissions granted for short-term needs stayed indefinitely. There was no prioritisation method, so a long list of findings had no clear starting point. Hannah's recommendations answer each cause directly, so the same problems should not build up again after the project ends. She shows the link in her report to Dev as a short table pairing each cause with the routine and owner that answers it. Problems grew slowly because nothing prompted anyone to look. Scheduled reviews with owners provide that prompt and make neglect visible.
8.4 Recommendations
Quarterly role reviews owned by the platform team; weekly scan triage owned by the digital team; temporary permissions that expire; findings tracked in the normal work queue. Each recommendation names an owner and a frequency, so it can be checked later. Quarterly role reviews give unused permissions a regular chance to be removed. Weekly triage keeps findings from piling up. Expiring permissions stop short-term grants from becoming permanent. Tracking findings in the normal work queue puts them where developers already plan work, as the digital team later suggested. Each recommendation becomes a tracked action with an owner and due date, and Dev reviews progress monthly until all are complete.
8.5 Supervision
Dev reviews the analysis and challenges one point: whether expiry for temporary permissions is practical. They agree to pilot it. Dev's concern is that developers might need a permission longer than expected, and that expiry could interrupt their work. Hannah suggests a pilot with a clear process for requesting more time. After a month, the pilot review found that no grant had lingered and no work had been delayed, so they record the result and decide to continue using expiry for temporary grants.
Comparing with guidance
Hannah compares the process causes with CSA CCM v4, which includes controls for regular access reviews and vulnerability management. The council's policies referred to these in general terms, but nobody had turned them into scheduled tasks with owners. Mapping recommendations to CCM v4 controls helps audit see that the changes meet a recognised framework.
She also checks the CIS Benchmark for the council's cloud provider, which recommends reviewing unused credentials and permissions; the quarterly review satisfies this.
Worked example
In the pilot, a developer requests temporary storage.write for a migration. It is granted for 48 hours and expires automatically; the developer finishes in time and nothing lingers.
Synthetic case. Synthetic.
Errors and limits
Recommendations without owners rarely happen.
Exercises
- EX036 — Role growth. How did roles grow too broad? Rubric: 3 = added in testing and fixes, never reviewed; 2 = partial; 1 = vague; 0 = none.
- EX037 — Inbox problem. Why did vulnerabilities pile up? Rubric: 3 = results to unwatched inbox, no priority rule; 2 = two; 1 = one; 0 = none.
- EX038 — Process causes. Name the three process causes. Rubric: 3 = ownership, review cadence, prioritisation; 2 = two; 1 = one; 0 = none.
- EX039 — Pilot result. What happened in the expiry pilot? Rubric: 3 = 48h grant expired automatically; 2 = partial; 1 = vague; 0 = none.
- EX040 — Owners. Who owns role reviews and scan triage? Rubric: 3 = platform team; digital team; 2 = partial; 1 = vague; 0 = none.
Synthesis
Fix the process that let problems grow, with named owners.
Continue studying — chapter 08 of 12
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →