Chapter 15 — Security fundamentals
Lesson map
Lesson 15 published. Map, example, EX029.
flowchart TD
N0["Learning outcomes and connection"]
N1["15.1 Assets, adversaries and properties"]
N2["15.2 Controls as claims"]
N3["15.3 Assurance and evidence"]
N4["15.5 Residual risk"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX029"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["15.1 Assets, adversaries and properties"]
N2["15.2 Controls as claims"]
N3["15.3 Assurance and evidence"]
N4["15.5 Residual risk"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX029"]
[Learning outcomes and connection]
|
v
[15.1 Assets, adversaries and properties]
|
v
[15.2 Controls as claims]
|
v
[15.3 Assurance and evidence]
|
v
[15.5 Residual risk]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX029]
Learning outcomes and connection
After this chapter you can (1) state assets, adversary capabilities and security properties precisely; (2) translate a control into a claim with stated assumptions; (3) identify evidence that would support or refute each claim; and (4) record residual risk with an owner. It prepares Chapters 18, 23, 38 and 45.
15.1 Assets, adversaries and properties
An asset is something whose loss matters: a user account, a case record, the ability to page responders. An adversary model states capabilities: what the attacker knows, can reach and can do — for example "holds one user's password and session cookie; can send phishing; cannot read the identity provider's database". Security properties are statements about assets under that model: confidentiality (only authorised parties read), integrity (only authorised changes, detectably), availability (service when needed), and for response systems also accountability (actions attributable to identities) and non-bypassability of controls. Avižienis et al. (2004) give the standard taxonomy of dependability and security attributes.
15.2 Controls as claims
A control is useful only as a claim that can be checked: "Multi-factor authentication prevents account takeover" is too broad. "For interactive logons to the case platform, possession of the password alone is insufficient to obtain a session, assuming the second factor is phishing-resistant and recovery flows require equal strength" is a claim with assumptions. NIST SP 800-63B describes authenticator assurance levels that make such assumptions explicit. Claim P1 in the HVSS phishing case is written in that form.
15.3 Assurance and evidence
Assurance is justified confidence that properties hold. It comes from evidence: tests (including negative tests), inspection of configuration, analysis, and operational monitoring. For each claim, ask what observation would show it false. If nothing could, the claim is not engineering.
In the HVSS phishing case, P2 had a falsifying observation ready: an IMAP login success in the webmail logs. Because that observation was named in advance, the investigation could show that the legacy protocol was still enabled for one mailbox class. P3 had one too, file access after the reset time, and the absence of any revocation left that claim unsupported rather than confirmed.
15.4 Worked example (synthetic): account compromise across services
A synthetic HVSS staff member's credentials were phished. The attacker used them on the webmail service (password only, legacy protocol), then attempted the case platform (MFA enforced) and the file-sharing service (single sign-on with a session that lasts 14 days).
| Property claim | Evidence that supports | Evidence that refutes |
|---|---|---|
| P1 Case platform session requires second factor | IdP logs: password success, MFA failure, no session | any session without MFA event |
| P2 Legacy webmail protocol disabled | config export; negative test login fails | IMAP login success in logs |
| P3 Existing SSO sessions ended after reset | session list empty after revocation timestamp | file access after reset time |
| P4 Mailbox rules unchanged | audit log: no rule creation | forwarding rule created |
The investigation found P2 false (legacy protocol still enabled for one mailbox class) and P3 unsupported (no revocation was performed; the password reset did not end sessions). Residual risk was recorded: "file-sharing sessions may persist up to 14 days after credential reset; owner: identity service manager; mitigation: revoke sessions in reset playbook; due: 30 days." Chapter 38 returns to the general problem of verifying containment.
15.5 Residual risk
Every control leaves risk. Write it down with an owner, a review date and the condition that would trigger re-evaluation. Unowned residual risk becomes nobody's problem until it becomes an incident (NIST SP 800-30 Rev. 1 frames risk as likelihood and impact under stated threats).
The HVSS residual-risk note on 14-day file-sharing sessions has all three parts: the identity service manager owns it, mitigation is due in 30 days, and the review would be triggered by any file access after a credential reset.
15.6 Errors and limits
- Controls stated without adversary model.
- Claims with no falsifying observation.
- Password reset assumed to end sessions.
- Residual risk without owner.
The HVSS phishing case from the worked example shows each of these errors in turn. Without an adversary model naming a stolen password and session cookie, "MFA protects us" could not be checked against the file-sharing service. The investigators assumed that resetting the password had ended the attacker's 14-day sessions, but no revocation had been performed. The risk became manageable only once the identity service manager was named as its owner with a deadline.
Exercises — chapter 15
EX029 — Write claims. Objective: precise security claims. Inputs: the evidence store of HVSS, with signed manifests and a shared admin account. Steps: write two properties with adversary model and assumptions; give a refuting observation for each. Expected evidence: claims and observations. Rubric: 3 = precise, falsifiable, assumptions include key custody and shared account; 2 = partial; 1 = vague; 0 = none.
EX030 — Residual risk register. Objective: record residual risk. Inputs: worked example findings P2 and P3. Steps: write two register entries with owner role, mitigation, due date and re-evaluation trigger. Expected evidence: entries. Rubric: 3 = complete and specific; 2 = missing a field; 1 = vague; 0 = none.
Chapter synthesis
Security engineering states assets, adversaries and properties precisely, turns controls into falsifiable claims, gathers evidence for and against them, and records the remaining risk with an owner.
Continue studying — chapter 15 of 50
← Chapter 14 · Course chapter index · Chapter 16 →
Continue to the next authored lesson.