Chapter 28 — Cryptography and trust services: failure analysis

Chapter 28 — Cryptography and trust services: failure analysis

Lesson map

Lesson 28 published. Map, example, EX082.

flowchart TD
  N0["Learning outcomes"]
  N1["28.1 The scenario"]
  N2["28.2 Timeline and causes"]
  N3["28.3 Actions"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX082"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["28.1 The scenario"]
  N2["28.2 Timeline and causes"]
  N3["28.3 Actions"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX082"]

[Learning outcomes]
    |
    v
[28.1 The scenario]
    |
    v
[28.2 Timeline and causes]
    |
    v
[28.3 Actions]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX082]

Learning outcomes

You will (1) analyse a key compromise scenario; (2) build a timeline and causal chain; (3) define corrective and preventive actions.

28.1 The scenario

In a tabletop exercise, Tidewell simulates a compromise: the portal's TLS private key was found in a public code repository, committed by a contractor months earlier. Priya leads the analysis. Immediate questions are what the key allows an attacker to do, impersonate the portal to patrons if they can intercept traffic, and what must happen now: revoke the certificate, issue a new key and certificate, deploy them and check for misuse. The exercise uses no real key. Facilitators play the roles of attacker and contractor.

28.2 Timeline and causes

Priya builds a timeline from the simulated evidence: the contractor copied server configuration into a repository for convenience, the repository was public, no secret scanning was in place and the key was never rotated. She draws a causal chain and identifies contributing factors: unclear contractor rules, no inventory alert for keys outside approved locations and long certificate lifetimes. She avoids blaming the contractor alone, since the process made the mistake easy. She presents the timeline on a single page so participants can see how small decisions accumulated into a serious exposure.

28.3 Actions

Corrective actions: revoke and replace the certificate, rotate related credentials, and search Certificate Transparency logs and access logs for misuse. Preventive actions: secret scanning in repositories, contractor guidance, shorter certificate lifetimes with automated renewal, and keys generated on servers so they never pass through people's hands. Priya assigns owners and dates and schedules a follow-up exercise to check the actions work. Grace assigns the secret-scanning action to the development lead and the contractor guidance to procurement. Priya notes that generating keys on servers also simplifies future rotation, because nobody needs to move keys between machines.

Worked example

Priya analyses a simulated leaked TLS key, builds a timeline with process causes, and defines corrective and preventive actions with owners.

Synthetic case. The scenario is invented and uses no real key.

Errors and limits

Revocation checking is uneven in clients, so short lifetimes matter. Blame-focused analysis misses systemic causes.

Exercises

• EX082 — Attacker capability. What could an attacker do with the leaked portal key? Rubric: 3 = impersonate the portal to patrons whose traffic they intercept;; 2 = impersonate;; 1 = read database;; 0 = none.
• EX083 — Contributing factors. Name two contributing factors. Rubric: 3 = two of unclear contractor rules, no inventory alert, long lifetimes, no secret scanning;; 2 = one;; 1 = blame contractor;; 0 = none.
• EX084 — Preventive action. Give two preventive actions. Rubric: 3 = two of secret scanning, contractor guidance, short lifetimes with automation, server-generated keys;; 2 = one;; 1 = revoke;; 0 = none.

Synthesis

Failure analysis of key compromise focuses on process causes and pairs corrective with preventive actions.

Continue studying — chapter 28 of 40

← Chapter 27 (draft) · Course chapter index · Chapter 29 (draft) →