Chapter 5 — Security literacy
Lesson map
Lesson 05 published. Map, example, EX009.
flowchart TD
N0["Learning outcomes"]
N1["5.1 Core properties"]
N2["5.2 Assets, threats, vulnerabilities, controls"]
N3["5.3 Two quantum threat patterns"]
N4["5.5 Practical activity"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX009"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["5.1 Core properties"]
N2["5.2 Assets, threats, vulnerabilities, controls"]
N3["5.3 Two quantum threat patterns"]
N4["5.5 Practical activity"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX009"]
[Learning outcomes]
|
v
[5.1 Core properties]
|
v
[5.2 Assets, threats, vulnerabilities, controls]
|
v
[5.3 Two quantum threat patterns]
|
v
[5.5 Practical activity]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX009]
Learning outcomes
You will (1) define confidentiality, integrity, availability and authenticity; (2) relate assets, threats, vulnerabilities and controls; (3) explain "harvest now, decrypt later" and "forge later" as threat patterns; and (4) read a simple risk statement critically.
5.1 Core properties
Confidentiality means only authorized parties can read information; integrity means unauthorized changes are detected or prevented; availability means authorized users can use the service when needed; authenticity means we can tell who produced a message. Cryptography mainly serves confidentiality (encryption, key exchange), integrity and authenticity (message authentication codes and signatures). Availability is easy to forget in cryptographic changes: a migration that makes handshakes fail is an availability incident even if it improves confidentiality.
In HCU's case, a gateway that rejects members' older phones after a change of algorithm would be a security failure even if no data leaked.
5.2 Assets, threats, vulnerabilities, controls
An asset is something of value — member data, the ability to approve payments. A threat is a potential cause of harm, usually an actor with a capability and motive. A vulnerability is a weakness the threat can exploit. A control reduces likelihood or impact. Risk is the combination of likelihood and impact for a scenario linking these elements. In quantum security the vulnerability is often not a bug but a mathematical property of an algorithm that becomes exploitable once a new capability exists.
5.3 Two quantum threat patterns
Harvest now, decrypt later (HNDL): an adversary records encrypted traffic today and stores it until a quantum computer can recover the key exchange. The harm happens in the future, but the collection — and therefore the need to act — is now, for any data whose confidentiality must outlast the arrival of such a machine. Forge later: once a quantum computer exists, an adversary can derive private signing keys from public keys and forge signatures, firmware updates or certificates. Unlike HNDL, forgery needs the machine at the time of attack, so signature migration can follow a different timetable — except where signatures must remain trustworthy for many years, such as mortgage documents or devices that cannot be updated.
5.4 Worked example
HCU risk statement, draft: "Risk of quantum attack: high." Improved: "Asset: mortgage archive transfers between branches and the data centre (confidentiality required 30 years). Threat: a well-resourced adversary recording WAN traffic. Vulnerability: VPN key exchange uses ECDH only. Impact if realized: disclosure of member financial histories. Likelihood: collection plausible now; decryption depends on an uncertain future capability. Control options: hybrid post-quantum key exchange, reduced data in transit." The improved statement supports a decision; the draft does not.
The improved version names each element of the risk separately, so readers can disagree with one part without rejecting the whole. It also shows why the risk is urgent despite the uncertain date: collection can happen today. A reviewer can check each part against evidence, such as the VPN configuration or the archive's retention policy.
5.5 Practical activity
Write risk statements in the improved format for two HCU assets: card authorization messages and the mobile app's code-signing key. Note how their time horizons differ.
Card authorization messages need confidentiality only for a short time, so harvest now, decrypt later matters little there; the concern is authentication. The code-signing key matters for as long as old app versions are trusted, which makes forge-later the main concern. Writing both statements in the same format makes these differences visible, and the comparison helps decide which asset to migrate first.
5.6 Common errors and limits
- Treating every cryptographic use as equally urgent.
- Ignoring availability when changing algorithms.
- Confusing a threat (actor) with a vulnerability (weakness).
Urgency depends on how long data must stay confidential and how long signatures must be trusted. Treating every use as equally urgent spreads effort thinly and delays the cases that matter most. Ignoring availability can turn a security improvement into an outage that members notice. Confusing threats with vulnerabilities leads to controls aimed at the wrong thing, such as trying to stop an adversary rather than removing the weakness they would exploit.
Exercises
- EX009 — Pattern sorting. Classify each as HNDL, forge-later or neither: archived VPN traffic, firmware signing for ATMs, AES-256 database encryption, TLS session to the mobile app. Rubric: 3 = all four correct with one-line reasons.
- EX010 — Risk statement. Rewrite "PKI is at quantum risk" as a full risk statement for HCU's internal CA. Rubric: 3 = asset, threat, vulnerability, impact, likelihood and controls present.
Synthesis
Security properties, risk elements and two time-shaped threat patterns — harvest-now-decrypt-later and forge-later — give a vocabulary precise enough to rank quantum risks.
Continue studying — chapter 05 of 40
← Chapter 04 (draft) · Course chapter index · Chapter 06 (draft) →