Chapter 2 — Quantum and post-quantum security: service and stakeholder context

Lesson map

Lesson 02 published. Map, example, EX006.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Services and data lifetimes"]
  N2["2.2 Mosca's rule"]
  N3["2.3 Practical activity — Lab M"]
  N4["2.4 Stakeholders"]
  N5["2.6 Practice task"]
  N6["2.8 Revisiting the list"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX006"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Services and data lifetimes"]
  N2["2.2 Mosca's rule"]
  N3["2.3 Practical activity — Lab M"]
  N4["2.4 Stakeholders"]
  N5["2.6 Practice task"]
  N6["2.8 Revisiting the list"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX006"]

[Learning outcomes]
    |
    v
[2.1 Services and data lifetimes]
    |
    v
[2.2 Mosca's rule]
    |
    v
[2.3 Practical activity — Lab M]
    |
    v
[2.4 Stakeholders]
    |
    v
[2.6 Practice task]
    |
    v
[2.8 Revisiting the list]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX006]

Learning outcomes

You will (1) map MTI's services to the data they carry and how long it must stay protected; (2) apply Mosca's rule across several timeline assumptions; (3) identify stakeholders and what each needs; (4) set a first priority list; and (5) explain priorities to non-specialists.

2.1 Services and data lifetimes

List each service, the data it handles and how long that data must stay confidential or trustworthy. Use contracts, regulations and retention schedules as sources, and ask data owners when unsure. For MTI: life-policy archive 40 years; claims records 10 years; broker portal sessions carry personal data relevant for about 7 years; quote requests are short-lived.

Where sources disagree, take the longer lifetime and record the disagreement. For example, a reinsurance contract may require claims data to be kept longer than the internal schedule says. A lifetime with no source is a guess and should be graded as one.

2.2 Mosca's rule

Mosca (2018): if data must stay secure for x years, migration takes y years, and a capable quantum computer may arrive in z years, then data is already at risk when x + y > z. Since nobody knows z, try several values.

For MTI the archive's x of 40 years exceeds any plausible z on its own, so the decision does not depend on the forecast. Quote requests, with x close to zero, are never at risk however short z is. The interesting cases lie in between, such as claims records, where the answer changes with z.

2.3 Practical activity — Lab M

# Lab M (ch 2): Mosca's inequality x + y > z for synthetic Marlow & Tide Insurance data, sweeping z.
assets = [  # (name, shelf-life x in years, migration time y in years) - synthetic
    ("life-policy archive", 40, 4), ("claims records", 10, 3), ("quote requests", 0.1, 1), ("broker portal traffic", 7, 2)]
for z in (10, 15, 20):  # years until a cryptographically relevant quantum computer: an assumption, not a forecast
    late = [n for n, x, y in assets if x + y > z]
    print(f"z={z:>2}: at risk now -> {', '.join(late) if late else 'none'}")

Expected output:

z=10: at risk now -> life-policy archive, claims records
z=15: at risk now -> life-policy archive
z=20: at risk now -> life-policy archive

The life-policy archive is at risk under every assumption; claims records only if z is ten years. That pattern is the basis of a priority list that does not depend on predicting the future.

Change the inputs to see how sensitive the list is. If migration of claims records took five years instead of three, claims would be at risk at z = 15 as well. Record such sensitivities next to the table: they tell the sponsor which estimates deserve better evidence.

2.4 Stakeholders

Data owners (underwriting, claims) set lifetimes; system owners (IT teams) make changes; suppliers control products; procurement writes contracts; legal and compliance track obligations; executives approve budgets and accept risk; auditors check evidence. List what each needs from the workflow and what you need from them.

At MTI, underwriting owns the life-policy lifetime and claims owns the 10-year claims lifetime; the infrastructure team owns the reinsurer SFTP servers. Write each name into the stakeholder map with a contact, so requests reach a person rather than a department.

2.5 Worked example

MTI's first priority list: 1) transfers of life-policy records between offices and the archive; 2) reinsurer SFTP exchanges carrying claims data; 3) broker portal; 4) internal CA planning (forge-later, long validity). Quote requests are deprioritised. The list is explained to the executive sponsor as "protect what must stay secret longest, first".

Each place on the list has a reason that can be traced to Lab M or to exposure class. The internal CA appears despite carrying no secrets because its long validity makes it a forge-later concern. Keep the reasons with the list so it can be defended.

2.6 Practice task

Build a five-row table of MTI services with data, lifetime, source of lifetime and owner; run Lab M with your own values.

Source each lifetime from a retention schedule, contract or owner statement, and write which. Then compare your Lab M output with the book's: if a service moves in or out of the at-risk list, explain why in one sentence. Ask a peer to check that each owner named actually controls the service, not just uses it. Keep the table in your portfolio.

2.7 Common errors and limits

• Lifetimes guessed instead of sourced.
• A single assumed quantum date.
• Forgetting procurement and legal as stakeholders.

Each error weakens the priority list in a different way. A guessed lifetime cannot be defended to an auditor. A single quantum date makes the list look like a forecast and invites argument about the date rather than the data. Leaving out procurement and legal means contract clauses and obligations surface late, after suppliers have already set their roadmaps. Check your own table for each of them.

2.8 Revisiting the list

Priorities change when facts change: a new contract extends a retention period, a supplier ships hybrid support, a service is retired. Review the priority list each quarter with data owners and system owners, record what changed and why, and keep the old versions. Auditors and executives trust a list that visibly evolves with evidence more than one that never changes.

At MTI a typical trigger would be the archive vendor publishing dates for ML-DSA support, which would change how the forge-later item is planned.

Exercises

• EX006 — Mosca. For claims records (x = 10, y = 3), state the timelines under which they are at risk. Rubric: 3 = z < 13.
• EX007 — Lifetime source. Name two sources for data lifetimes at an insurer. Rubric: 3 = contracts/regulation/retention schedule with owner confirmation.
• EX008 — Stakeholder map. List five stakeholders and one need each. Rubric: 3 = five relevant pairs.
• EX009 — Priority. Why is the life-policy archive first? Rubric: 3 = at risk under all assumptions; longest lifetime.
• EX010 — Plain explanation. Explain the priority list to an executive in three sentences. Rubric: 3 = clear, accurate, decision-oriented.

Synthesis

Service maps with sourced lifetimes, Mosca's rule across several assumptions and a stakeholder map produce a priority list that is robust and explainable.

Continue studying — chapter 02 of 12

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →