@burkhard wrote about this extensively in his latest newsletter.
Summary
Stop “Managing Risk.” Start Engineering Security.
The core idea
Cybersecurity “risk management” (likelihood × impact) usually can’t be done honestly, so we should stop pretending and treat security as an engineering problem with clear rules, thresholds, and outcome measurements instead.
The problem
- Cyber incidents are one‑off and adversarial, so we rarely have good data for “likelihood × impact” estimates.
- “Risk scores” become guesswork, fuel arguments, and still don’t reflect how leaders actually decide (cost, safety, uptime, regulation).
- The word “risk” drags in an illusion of actuarial rigor that doesn’t fit our domain and slows down real security improvements.
What we should be doing
- Change the language
Talk about hazards, dangers, threats, and consequences. Reserve “risk” for the rare cases where you have actual measurement. - Use engineering rules, not gut‑feel risk
Define explicit bug bars and release criteria:- “Any remotely exploitable vuln in a privileged process is release‑blocking.”
- “Any vuln that can brick a device or endanger safety requires emergency response.”
- Adopt shared thresholds
Where possible, use (or push for) standard numbers instead of inventing “acceptable risk” locally every time, e.g.:- Target phishing click‑through rates.
- Patch timelines by severity class.
- Minimum MFA coverage ratios.
- Measure outcomes like public health
Track incident rates and how they move when you add controls, for example:- Credential‑phishing incidents per 10,000 users per quarter, before and after rolling out FIDO.
- Remote‑code‑execution incidents per 1,000 devices per year, before and after hardening.