Chapter 24 — Cloud and container security: controls
Lesson map
Lesson 24 published. Map, example, EX070.
flowchart TD
N0["Learning outcomes"]
N1["24.1 Preventive controls"]
N2["24.2 Detective controls"]
N3["24.3 Response controls"]
N4["24.4 Mapping"]
N5["24.5 Control register"]
N6["24.6 Prioritising"]
N7["24.7 Cost and effort"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX070"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["24.1 Preventive controls"]
N2["24.2 Detective controls"]
N3["24.3 Response controls"]
N4["24.4 Mapping"]
N5["24.5 Control register"]
N6["24.6 Prioritising"]
N7["24.7 Cost and effort"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX070"]
[Learning outcomes]
|
v
[24.1 Preventive controls]
|
v
[24.2 Detective controls]
|
v
[24.3 Response controls]
|
v
[24.4 Mapping]
|
v
[24.5 Control register]
|
v
[24.6 Prioritising]
|
v
[24.7 Cost and effort]
|
v
[Worked example] --> [Exercise EX070]
Learning outcomes
You will (1) select and implement controls for StudyHub; (2) cover prevention, detection and response; (3) map controls to frameworks; (4) record them in a register.
24.1 Preventive controls
Organisation guardrails, private registry, admission control for signed images and Restricted pods, default-deny network policies, short-lived identities.
Each of these would have stopped part of the opening case. The guardrail and private registry stop anonymous pulls; short-lived identities remove the secret from the image; signed-image admission stops images from outside the build system. Preventive controls are the first priority because they act before any harm is possible. Default-deny network policies and Restricted pods limit what any compromised workload can reach or do. Each control is configured in code and tested, so its presence can be shown rather than assumed, and the register records its last test result.
24.2 Detective controls
Central audit logs, alerts on high-risk changes, weekly configuration checks, image scanning.
Detective controls answer the question the opening case could not: did anything happen? Central logs record pulls and changes; alerts on high-risk changes notice a repository being made public within minutes; weekly checks catch slower drift; scanning finds vulnerable images. Each feeds a person who is expected to act. Alerts are tuned to avoid noise, since a team that receives dozens of meaningless alerts a day stops reading them. The alert for public registry settings has fired once since it was introduced, during a deliberate test, and the on-call engineer responded within ten minutes.
24.3 Response controls
Runbooks for credential exposure, public resources and suspicious activity; ability to revoke credentials and isolate namespaces quickly.
For a credential exposure like the opening case, the runbook lists the steps: revoke or rotate the credential, check logs for its use, remove it from images and record the timeline. Being able to isolate a namespace quickly matters if a workload appears compromised. Runbooks are rehearsed each term in the test environment. Revocation is tested by revoking a synthetic credential and confirming it stops working everywhere it was used. Isolation is tested by applying a deny-all policy to a test namespace and checking that its pods can no longer reach anything.
24.4 Mapping
Each control maps to CSA CCM v4 domains and relevant CIS Benchmark sections, which helps auditors and shows coverage.
The mapping lets Westmere answer an auditor's question, such as which controls address identity management, by pointing to register entries rather than writing a new explanation. It also shows gaps: a domain with no mapped control needs either a control or a written reason why it does not apply. Samuel keeps the mapping in the register itself, one column per framework, so it stays current when controls change rather than living in a separate document that drifts out of date.
24.5 Control register
A register lists each control, owner, evidence source, test method and last test date.
The register makes each control's status visible at a glance. A control with no recent test date is treated as unverified, whatever its configuration says. The evidence source tells auditors where to look, and the owner column tells the team whom to ask when a test fails. Samuel built the first version from the controls named in earlier chapters, then asked each owner to confirm the details. Several owners discovered controls they had not known they owned, which was itself useful. The register is stored in the team's repository and reviewed monthly.
24.6 Prioritising
Controls addressing the opening case (registry access, secrets in images, logging) come first.
Starting with the opening case's controls is sensible because those weaknesses are known to have existed, not merely possible. Other controls follow by risk, using the threat model and the failure analysis. Samuel's register orders entries by priority so the team works from the top. Registry access, secrets in images and logging each have a preventive and a detective control in the register, so a failure of one is caught by the other. Lower-priority controls, such as the password policy for break-glass accounts, are scheduled after these are verified.
24.7 Cost and effort
Most controls use built-in platform features, keeping cost low.
Guardrails, logging, admission control and workload identity are all features of the platform Westmere already pays for, so their cost is mostly engineer time to configure and test them. The pipeline secret scan uses a free tool. Samuel estimates the effort for each control in engineer-days, which helps the team plan sprints. Where a control would need a new paid product, Samuel's register notes the cost and the risk it reduces, so the decision can be made on evidence. So far, every control in the register uses features Westmere already has, which made approval straightforward.
Testing controls
Each control in the register has a test that can be run safely: a synthetic unsigned image must be refused, a public bucket request must be blocked, a synthetic high-risk change must raise an alert. Tests run monthly and results update the register. Failed tests become findings with owners. In the first round, 17 of 19 tests pass; the two failures are an alert routed to an old mailbox and a test namespace missing its network policy, both fixed within a week.
Register owner
The register is owned by Tom, who reviews it monthly with the team.
Retiring
Obsolete controls are retired with a reason.
Worked example
The register shows that no control detects secrets in images before push. Samuel proposes a scan in the build pipeline that fails builds containing key-like strings, with a reviewed allow list for test placeholders. The cloud team adopts it.
Synthetic case. Controls are synthetic.
Errors and limits
A register is only useful if tests are actually run and dates updated.
Exercises
- EX070 — Control types. Name the three control types with an example each. Rubric: 3 = preventive guardrail, detective alerts, response runbooks; 2 = two; 1 = one; 0 = none.
- EX071 — Register fields. What does the register record? Rubric: 3 = control, owner, evidence, test, last test; 2 = three; 1 = one; 0 = none.
- EX072 — Missing control. What gap did the register show? Rubric: 3 = no pre-push secret detection; 2 = partial; 1 = vague; 0 = none.
Synthesis
Choose controls across prevention, detection and response, and track them.
Continue studying — chapter 24 of 40
← Chapter 23 (draft) · Course chapter index · Chapter 25 (draft) →