Chapter 5 — Security literacy | Technologist Cloud and container security

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 5 — Security literacy

Lesson map

Lesson 05 published. Map, example, EX013.

flowchart TD
  N0["Learning outcomes"]
  N1["5.1 Three goals"]
  N2["5.2 Shared responsibility"]
  N3["5.3 Common failures"]
  N4["5.4 Threats and vulnerabilities"]
  N5["5.5 Risk"]
  N6["5.6 Ethics of access"]
  N7["Words to use"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX013"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["5.1 Three goals"]
  N2["5.2 Shared responsibility"]
  N3["5.3 Common failures"]
  N4["5.4 Threats and vulnerabilities"]
  N5["5.5 Risk"]
  N6["5.6 Ethics of access"]
  N7["Words to use"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX013"]

[Learning outcomes]
    |
    v
[5.1 Three goals]
    |
    v
[5.2 Shared responsibility]
    |
    v
[5.3 Common failures]
    |
    v
[5.4 Threats and vulnerabilities]
    |
    v
[5.5 Risk]
    |
    v
[5.6 Ethics of access]
    |
    v
[Words to use]
    |
    v
[Worked example] --> [Exercise EX013]

Learning outcomes

You will (1) explain confidentiality, integrity and availability; (2) describe the shared responsibility model; (3) recognise common cloud security failures.

5.1 Three goals

Confidentiality keeps data from the wrong people, integrity keeps it accurate, and availability keeps it usable when needed. A booking system needs all three: patient details must stay private, appointments must be correct, and the site must be up. Each of the three goals maps to a different kind of failure. A leak of contact details is a confidentiality failure; a changed appointment time or a deleted booking is an integrity failure; a booking page that does not load on a Monday morning is an availability failure. Controls often favour one goal, and some trade against each other, so Priya learns to name which goal each control protects.

5.2 Shared responsibility

AWS, Azure and Google Cloud each publish a shared responsibility model: the provider secures the underlying infrastructure, and the customer secures what they configure and run. Cobalt, as a hosting company, adds a third layer: it manages clusters for clients, who still own their data and users. For Riverside Dental, this means the cloud provider secures its data centres and the managed database service, Cobalt configures the cluster, network rules and storage buckets, and the dental group decides which of its staff may use the booking system and what patient data it collects. Each party needs to know exactly where its own duties start.

5.3 Common failures

Public storage buckets, overly broad permissions, unpatched images and missing logs appear again and again in cloud incidents. None requires a clever attacker; all are configuration problems. Priya meets versions of most of these during her placement: unpatched public images in the inventory, broad permissions held by old-admin and the CI bot, and missing audit logs on client-b. A public bucket is not among her findings, but the pipeline later blocks a change that would have created one. Because these are configuration problems, they can be found by comparing settings with an expected value, which is what her later baseline and pipeline checks do.

5.4 Threats and vulnerabilities

A threat is something that could cause harm; a vulnerability is a weakness it could use. The old Node image is a vulnerability; whether it matters depends on how the workload is exposed. The distinction helps Priya decide what to do when an advisory arrives. The advisory describes a vulnerability in the image; the threat is someone able to reach the workload and use that weakness. Booking faces the internet, so a threat can reach it directly, while an internal workload with no internet ingress is harder to reach. The same vulnerability can therefore deserve different urgency in different places, which is why Priya later records exposure beside every finding.

5.5 Risk

Risk combines how likely harm is and how bad it would be. Priya learns to describe risk in words before using numbers. In words, a risk statement says what could happen, how likely it seems and how much harm it would cause, with a reason for each judgement. For example, an outdated public image in the internet-facing booking workload is fairly likely to be targeted, and exposure of patient contact details would harm both patients and the dental group. Numbers can come later, once there is data to support them. Writing reasons down lets Kwame and the client challenge a judgement instead of accepting or rejecting a bare score.

5.6 Ethics of access

Placement students see client systems. Priya signs Cobalt's confidentiality agreement and only accesses what her tasks require. The agreement covers what she may see, what she may copy and what she must report. In practice Priya works from synthetic copies of configuration and logs wherever possible, and uses read-only access under supervision when a task needs a real system. She does not browse client data out of curiosity, even when her access would technically allow it. If she notices something outside her task, such as an unexpected account, she reports it to Kwame rather than investigating alone. These habits protect the clients and also protect Priya, because every access she makes can be explained.

Words to use

Priya keeps a short glossary for client conversations, defining terms such as vulnerability and patch in one sentence each.

Worked example

Kwame asks Priya who is responsible if a client's storage bucket is made public. She answers that the provider secures storage infrastructure, Cobalt is responsible if it configured the bucket, and the client is responsible for deciding which data goes there. Kwame agrees and adds that the contract should say this clearly.

Synthetic case. Cobalt and its clients are synthetic.

Errors and limits

The shared responsibility model divides duties; it does not remove any.

Exercises

EX013 — Three goals. Apply confidentiality, integrity and availability to the booking system. Rubric: 3 = private details, correct appointments, site up; 2 = two; 1 = one; 0 = none.
EX014 — Responsibility layers. Describe the three responsibility layers at Cobalt. Rubric: 3 = provider infra, Cobalt config, client data/users; 2 = two; 1 = one; 0 = none.
EX015 — Configuration failures. Name three common cloud failures that are configuration problems. Rubric: 3 = public buckets, broad permissions, unpatched images, missing logs; 2 = two; 1 = one; 0 = none.

Synthesis

Security goals and responsibilities must be clear before controls make sense.

Continue studying — chapter 05 of 30

← Chapter 04 (draft) · Course chapter index · Chapter 06 (draft) →