OpenCyber AcademyLesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 Classes of failure"]
N2["20.2 Lessons for Tidewell"]
N3["20.3 Separating causes"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 Classes of failure"]
N2["20.2 Lessons for Tidewell"]
N3["20.3 Separating causes"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 Classes of failure]
|
v
[20.2 Lessons for Tidewell]
|
v
[20.3 Separating causes]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) analyse documented classes of trust failure; (2) extract lessons for an organisation like Tidewell; (3) separate cryptographic from procedural causes.
20.1 Classes of failure
Priya studies classes of failure documented in public sources and textbooks. Certificate authorities have issued certificates to the wrong parties because of weak validation; organisations have suffered outages when certificates expired; software has accepted certificates without checking names; and private keys have leaked through misconfigured servers. She classifies causes as cryptographic, such as weak algorithms, or procedural, such as poor validation or monitoring. Most cases she reads are procedural; the mathematics held while people and processes failed. She keeps a summary table of cases and causes.
20.2 Lessons for Tidewell
For each class Priya writes a lesson: monitor Certificate Transparency logs for certificates issued for Tidewell names, which would reveal misissuance; automate renewals and alert before expiry; test applications against certificates with wrong names; and keep private keys on servers with restricted access and inventory them. Grace adopts the expiry and monitoring lessons immediately, since an expired certificate took the catalogue offline for half a day the previous year. Priya also adds a quarterly check that scans for certificates with wrong names, using only the consortium's own authorised hosts.
20.3 Separating causes
Priya practises separating causes using Tidewell's catalogue outage. The certificate expired because renewal was manual and the person responsible had left; no alert existed; and the replacement took hours because nobody knew which server held the key. None of these causes involved cryptographic weakness. She writes a short analysis with timeline, causes and actions: automated renewal, an owner for each certificate and an inventory of key locations. This becomes the template for later failure analyses. The template is stored in the shared drive.
Worked example
Priya classifies trust failures as mostly procedural and analyses Tidewell's catalogue outage into three non-cryptographic causes with matching actions.
Synthetic case. The outage is invented; failure classes are drawn from public literature.
Errors and limits
Blaming individuals hides process causes. Rare cryptographic failures still occur, so algorithm choices matter too.
Exercises
- EX058 — Dominant cause. What kind of cause dominated the cases Priya read?
Show marking criteria
Rubric: 3 = procedural, not cryptographic;; 2 = procedural;; 1 = cryptographic;; 0 = none. - EX059 — CT monitoring lesson. What does monitoring Certificate Transparency logs reveal?
Show marking criteria
Rubric: 3 = certificates issued for Tidewell names, exposing misissuance;; 2 = misissuance;; 1 = expiry;; 0 = none. - EX060 — Outage causes. Name the three causes of the catalogue outage.
Show marking criteria
Rubric: 3 = manual renewal by departed person, no alert, unknown key location;; 2 = two;; 1 = one;; 0 = none.
Synthesis
Most trust failures are procedural; analysing them without blame yields practical lessons for any organisation.
Continue studying — chapter 20 of 40
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →