◇ OpenCyber Academy
Engineering · Chapter 15 · English

Chapter 15 — Security fundamentals

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 15 — Security fundamentals

Lesson map

Lesson 15 published. Map, example, EX043.

flowchart TD
  N0["Learning outcomes"]
  N1["15.1 CIA for meterhub"]
  N2["15.2 Assets"]
  N3["15.3 Threats"]
  N4["15.4 Defence in depth"]
  N5["15.5 Shared responsibility"]
  N6["15.6 Zero trust"]
  N7["Workload identity"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX043"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["15.1 CIA for meterhub"]
  N2["15.2 Assets"]
  N3["15.3 Threats"]
  N4["15.4 Defence in depth"]
  N5["15.5 Shared responsibility"]
  N6["15.6 Zero trust"]
  N7["Workload identity"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX043"]

[Learning outcomes]
    |
    v
[15.1 CIA for meterhub]
    |
    v
[15.2 Assets]
    |
    v
[15.3 Threats]
    |
    v
[15.4 Defence in depth]
    |
    v
[15.5 Shared responsibility]
    |
    v
[15.6 Zero trust]
    |
    v
[Workload identity]
    |
    v
[Worked example] --> [Exercise EX043]

Learning outcomes

You will (1) apply confidentiality, integrity and availability to meterhub; (2) identify assets and threats; (3) use defence in depth; (4) understand shared responsibility.

15.1 CIA for meterhub

Confidentiality: readings and customer details stay private. Integrity: readings are not altered, since bills and grid planning depend on them. Availability: ingest keeps up so data are not lost.

Each property has concrete consequences. A confidentiality breach exposes households' routines; an integrity failure could produce wrong bills or mislead grid planning; an availability failure loses readings that cannot be recollected. Elena uses these to rank risks during design. She also notes that integrity failures may go unnoticed longer than outages, since wrong values look normal.

15.2 Assets

Readings, customer data, cloud credentials, container images, cluster configuration and the deployment pipeline. The leaked key showed that credentials and images are assets as important as data.

Listing assets broadly avoids focusing only on the database. A cloud credential can unlock many resources at once; a container image can carry secrets or vulnerabilities into production; the pipeline can deploy anything. Protecting these is as important as protecting the data itself. Each asset has a named owner in Solent's register, together with its sensitivity and where it is stored.

15.3 Threats

Credential leaks, misconfigured access, vulnerable images, compromised dependencies, insider misuse and outages. Each threat maps to controls.

Mapping each threat to controls shows where defences are strong and where they are thin. Credential leaks map to secret scanning and short-lived keys; vulnerable images to scanning and patching; outages to redundancy and backups. Threats with no mapped control become priorities. Insider misuse is easy to overlook in a small co-operative where everyone knows each other, but access logs and separation of duties still apply. Outages are included because availability failures can lose readings permanently.

15.4 Defence in depth

The key leak could have been prevented (no secrets in images), detected (secret scanning before push), limited (key with narrow permissions, egress limits) and recovered from (fast revocation). Several layers each reduce risk.

Any one of these layers might have stopped the leak from causing harm. Together they make it much less likely that a single mistake leads to a breach. Elena uses the key leak as a worked example when explaining layered controls to Solent's managers. She shows how each layer applies to other threats too.

15.5 Shared responsibility

The AWS, Azure and Google Cloud shared responsibility documents agree that customers secure identities, data, configurations and workloads; providers secure the physical infrastructure and managed service internals. Managed Kubernetes moves the control plane to the provider but leaves workloads to the customer.

Misunderstanding the split is a common cause of cloud incidents: customers assume the provider secures their storage permissions, which it does not. Managed Kubernetes relieves Solent of patching the control plane but not of configuring pods, network policies and access. Elena lists Solent's responsibilities explicitly in the design note.

15.6 Zero trust

NIST SP 800-207 recommends authenticating and authorising every request; network location alone is not trusted. This principle drives meterhub's service authentication and network policies.

In meterhub, being inside the cluster no longer grants access by itself: each service proves its identity and is authorised for specific actions. Network policies limit who can even attempt a connection. If one pod is compromised, it cannot freely reach everything else simply because it shares a network. Every connection decision is logged, so denied attempts become evidence for investigation.

Workload identity

Workload identity lets a pod obtain short-lived cloud credentials tied to its Kubernetes service account, instead of a long-lived key stored in a file or image. If such a credential leaked it would expire within an hour and could only be used with the narrow permissions of that service. This removes the class of problem behind the opening case.

Worked example

Elena maps the key leak to the four layers and finds Solent had only the last one (revocation). The project plan adds the other three: build-time secret checks, pre-push scanning, and narrow, short-lived credentials from a workload identity service.

Synthetic case. Assets and events are synthetic.

Errors and limits

Defence in depth fails if every layer depends on the same assumption.

Exercises

Synthesis

Layered controls and clear responsibility protect cloud systems.

Continue studying — chapter 15 of 50

← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →