◇ OpenCyber Academy
Postgraduate · Chapter 12 · English

Chapter 12 — Final review and transfer

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 12 — Final review and transfer

Lesson map

Lesson 12 published. Map, example, EX056.

flowchart TD
  N0["Learning outcomes"]
  N1["12.1 Review"]
  N2["12.2 Transfer"]
  N3["12.3 Next steps"]
  N4["12.4 Learning"]
  N5["12.5 Sharing"]
  N6["Self-assessment"]
  N7["Carrying it to other controls"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX056"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["12.1 Review"]
  N2["12.2 Transfer"]
  N3["12.3 Next steps"]
  N4["12.4 Learning"]
  N5["12.5 Sharing"]
  N6["Self-assessment"]
  N7["Carrying it to other controls"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX056"]

[Learning outcomes]
    |
    v
[12.1 Review]
    |
    v
[12.2 Transfer]
    |
    v
[12.3 Next steps]
    |
    v
[12.4 Learning]
    |
    v
[12.5 Sharing]
    |
    v
[Self-assessment]
    |
    v
[Carrying it to other controls]
    |
    v
[Worked example] --> [Exercise EX056]

Learning outcomes

You will (1) review the course; (2) transfer methods to other contexts; (3) plan continued learning.

12.1 Review

The course moved from an audit finding to a decision, evidence, design, evaluation, integration, difficult cases, assurance, research and a project. Each step of Inês's work at Beacon built on the one before it. The audit finding led to a decision between options, which needed evidence about enforcement. The evidence shaped the design, which was evaluated before enforcement. Integration made the design part of Beacon's routines, difficult cases tested its limits, and assurance showed whether it worked. Research tested her choices against published work, and the final project turned them into a reusable baseline.

12.2 Transfer

The same pattern applies to other cloud controls: storage access, identity, network policy. For storage access, the same steps would apply: measure which buckets have the intended settings, choose between local and central control, evaluate rules before enforcement, and test that controls survive change. Inês notes that the pattern is not specific to Kubernetes, which is why she plans to use it for identity permissions next. Her final report includes the pattern as a short checklist. For network policy, the same idea applies: deny by default and grant exceptions centrally.

12.3 Next steps

Inês plans to apply the method to identity permissions next. Identity permissions at Beacon share the same risk as admission: settings that drift without anyone noticing. Inês plans to start by measuring which roles have more permissions than they use, then choose a design and evaluate it before enforcement, as she did for workloads. She discusses the plan with the platform team and the risk committee before starting. The identity work would reuse the decision record format, the evaluation method and the quarterly assurance routine, with identity owners taking the places the platform and product teams held here.

12.4 Learning

She keeps reading standards updates and Kubernetes release notes for removed features. The audit finding came from a removed feature: PodSecurityPolicy was dropped and its replacement not configured. Reading release notes for removed or changed features helps Inês spot similar risks before an upgrade. She shares relevant changes with the platform team, so the upgrade checklist can be updated in advance. Standards updates, such as new CSA CCM versions, may also change the framework mapping. She checks release notes before each planned Beacon cluster upgrade, so any removed feature reaches the checklist in advance.

12.5 Sharing

She writes an anonymised case for the practitioners' group. The case removes Beacon's name and any details that could identify it, while keeping the decision, evidence and lessons. Other practitioners can use it to plan their own baselines. Inês asks Beacon's risk officer to approve the anonymised version before sharing, and she cites only public sources in it. The case ends with her answer to a peer: check that controls survive change. The practitioners' group publishes it with the upgrade checklist step as an example others can adapt to their own clusters.

Self-assessment

Inês completes a self-assessment against the course outcomes. She rates herself strong on evidence gathering and evaluation, and weaker on the financial case, where she relied on the finance team's cost estimates without fully understanding them. She plans a short course on cost modelling.

Prof. Rao adds feedback: the work showed good judgement in separating what the data proved from what it suggested, and the exceptions register is a model other teams could reuse.

Carrying it to other controls

For identity permissions, the same steps would apply. The finding might be unused administrator roles; the evidence would be access logs over a period; the alternatives would include central role templates; the evaluation would compare candidate permission sets against a labelled set of real tasks; and assurance would sample accounts quarterly. Writing this outline helps Inês check that the method is general, not tied to Kubernetes. She also notes what does not transfer directly: identity changes affect people's ability to do their jobs immediately, so the rollout would need more communication and a faster exception route than the cluster programme did.

Closing note

Inês closes her final notes with a reminder for herself: every control is temporary until it survives the next change.

Worked example

A peer asks for the one lesson. Inês answers: check that controls survive change.

Synthetic case. Synthetic case.

Errors and limits

Lessons transfer when stated as methods.

Exercises

Synthesis

Carry the method forward.

Continue studying — chapter 12 of 12

← Chapter 11 (draft) · Course chapter index · Worked results ↓ · Next course via chapter index →