Chapter 41 — Cloud and container security: system optimization
Lesson map
Lesson 41 published. Map, example, EX121.
flowchart TD
N0["Learning outcomes"]
N1["41.1 Finding waste"]
N2["41.2 Redundant controls"]
N3["41.3 Noisy alerts"]
N4["41.4 Cost"]
N5["41.5 Risk value"]
N6["41.6 Guarding against over-optimisation"]
N7["41.7 Results"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX121"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["41.1 Finding waste"]
N2["41.2 Redundant controls"]
N3["41.3 Noisy alerts"]
N4["41.4 Cost"]
N5["41.5 Risk value"]
N6["41.6 Guarding against over-optimisation"]
N7["41.7 Results"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX121"]
[Learning outcomes]
|
v
[41.1 Finding waste]
|
v
[41.2 Redundant controls]
|
v
[41.3 Noisy alerts]
|
v
[41.4 Cost]
|
v
[41.5 Risk value]
|
v
[41.6 Guarding against over-optimisation]
|
v
[41.7 Results]
|
v
[Worked example] --> [Exercise EX121]
Learning outcomes
You will (1) optimise the secured platform for cost, effort and risk together; (2) identify waste; (3) remove redundant controls; (4) prioritise improvements by value.
41.1 Finding waste
Elena reviews where time and money go: duplicate scanners checking the same images, alerts that never lead to action, idle node pools reserved for exceptions that ended.
Waste matters for security as well as budget, because effort spent on duplicate work is effort not spent on real gaps, and noisy tools teach people to ignore output. Elena gathers pipeline timings, alert outcomes, cloud bills and the operational-load log, then lists every item that costs time or money without changing a decision. The list is a set of questions to investigate, not a removal plan: each item still needs evidence before anything is switched off.
41.2 Redundant controls
Two image scanners ran in the pipeline with overlapping results. Comparing six months of findings shows one found everything the other did plus more; the weaker one is retired, saving pipeline time.
The comparison matches findings by image digest and vulnerability identifier across both tools for the same builds. Overlap alone would not justify removal; what matters is that the remaining scanner missed nothing the other caught in six months of real images. The retired scanner's configuration is kept in the repository's history, and the decision record notes the comparison period, so the choice can be revisited if the remaining tool's coverage changes.
41.3 Noisy alerts
Alerts are ranked by how often they led to action. Three alert rules with no action in six months are reviewed: two are tuned, one removed with the reason recorded.
An alert that never leads to action either fires on harmless events or detects something nobody owns. Tuning narrows the two useful rules, for example by excluding a known batch job that triggered one of them nightly. The removed rule duplicated a detection that another rule already covered with better context. Each decision is recorded with the six months of data behind it, so a later reviewer can see the rule was not dropped simply because it was annoying.
41.4 Cost
The dedicated node pool for privileged workloads now hosts only the node agent; it is right-sized to the smallest suitable machines.
The pool was sized when several privileged workloads needed isolation; exceptions have since ended as their teams fixed the underlying needs. Keeping it separate still matters, because the node agent has broad host access and should not share nodes with ordinary services. Right-sizing keeps the isolation while cutting the cost. Elena checks the agent's resource use over a month before choosing the machine size, so it does not run short of memory under peak load.
41.5 Risk value
Each improvement candidate is scored on risk reduced per engineer-day. Top items: add fix hints to admission rejection messages, add egress limits to two namespaces, and test restoring the signing key from its backup.
Scores are rough estimates agreed by two engineers, which is enough to rank items rather than to predict outcomes precisely. Fix hints in rejection messages help the developers who found rejections unclear in the survey, and cost little. Egress limits close paths that the threat analysis marked as open for data leaving those namespaces. The restore test checks that the signing key backup works, since losing that key would stop every deployment until a new trust chain was set up.
41.6 Guarding against over-optimisation
Removing a control requires evidence it is redundant, not just inconvenient.
Evidence means data showing that another control already covers the same risk, or that the risk itself has gone. A control that rarely fires may be working, since attackers and mistakes are uneven over time. The drift report is the example: it looked redundant because GitOps reverts drift, yet the data showed it catching security-relevant changes outside GitOps. The owner's sign-off adds a second check by someone who knows what the control was for.
41.7 Results
Optimisation saves about 15% of platform security spending and four engineer-hours a week.
The savings come mainly from the retired scanner, the right-sized node pool and fewer alerts to review. Elena reports the figures as estimates for the first year, with the method used to calculate them, so they can be checked at the next yearly review. She also states what did not change: the controls retained, detection results and the number of exceptions. Savings presented without that context could encourage removing controls next time.
Sharing savings
Elena reports savings alongside the risk measures, showing that coverage and detection stayed the same or improved while cost fell. This reassures leadership that optimisation did not quietly weaken security.
Next review
The optimisation review repeats yearly, using the same scoring method so results can be compared.
Owner sign-off
Each removal is signed off by the control owner.
Worked example
One proposal is to drop the weekly drift report because GitOps reverts most drift. Elena checks: in six months, the report found four security-relevant drifts outside GitOps-managed resources. The report stays.
Synthetic case. Figures are synthetic.
Errors and limits
Optimisation that removes controls without evidence trades visible savings for invisible risk.
Exercises
- EX121 — Redundant scanner. How was the redundant scanner identified? Rubric: 3 = six months comparison, one superset; 2 = partial; 1 = vague; 0 = none.
- EX122 — Score. How are improvements prioritised? Rubric: 3 = risk reduced per engineer-day; 2 = partial; 1 = vague; 0 = none.
- EX123 — Drift report. Why did the drift report stay? Rubric: 3 = found 4 drifts outside GitOps; 2 = partial; 1 = vague; 0 = none.
Synthesis
Optimise with evidence, keeping controls that still find problems.
Continue studying — chapter 41 of 50
← Chapter 40 (draft) · Course chapter index · Chapter 42 (draft) →