Toreon Office | Grotehondstraat 44 1/1 - 2018 Antwerpen | +32 3 369 33 96
52nd Edition – April 2026
Welcome to this month’s edition of Threat Modeling Insider! In this edition, Petra Vukmirovic takes a look at possible cases for a post-risk cyber world.
Next, on the Toreon Blog, Georges Bolssens shares his latest discovery of a vulnerability in a Wi-Fi range extender and what threat modelers can learn from this.
There’s plenty of other actionable insights ahead, so settle in and let’s get started!
Welcome to this month’s edition of Threat Modeling Insider! In this edition, Petra Vukmirovic takes a look at possible cases for a post-risk cyber world.
Next, on the Toreon Blog, Georges Bolssens shares his latest discovery of a vulnerability in a Wi-Fi range extender and what threat modelers can learn from this.
There’s plenty of other actionable insights ahead, so settle in and let’s get started!
Guest Article
Breaking out of optimised failure: Is there a case for a post-risk cyber world?
Toreon Blog
When the air becomes the attack surface: CVE-2026-6058 and a lesson in threat modeling
Curated content
Noise vs. Signal: The Central Paradox of LLMs in Threat Modeling
Curated Content
Secure-by-Design in the AI Age: From Risk Identification to Ongoing Control
Tips & tricks
The application security podcast
Training update
An update on our training sessions.
Fair warning: I am going to debate myself in this post. And I am going to drag you into it.
For years we have taken our risk-centric approach for granted. Perhaps less so for us threat modellers — threat-centricity is quite literally in the job description — but for the cybersecurity industry as a whole, risk management has long been the unexamined default, that has not been questioned. We settled into it comfortably.
The central thesis of this article is not to debunk that. It is to put out there the question: is there a case for a post-risk cyber world? I will provide some history, some expert voices, some arguments, and mostly surface the mixed feelings and inner debate I have around this topic. And hopefully, dear Threat Modeling Insider reader, I will drag you into the debate with me.
What this is not saying
I am not arguing we should stop all our current practices or burn down the ISO 27001 certification.
What this is proposing
A critical examination of the risk-centric approach — questioning foundational assumptions, exploring alternatives, assessing outcomes vs. theoretical benefits.
Let’s start with that.
2X
Incident growth year-on-year
NCSC Annual Review 2025. M&S. Jaguar. Airport attacks. Supply chains got disrupted — affecting the national economy, local communities, and human lives.
And yet, here we are. With our risk registers. Our risk appetites. Our residual risk scores. I wonder if these incidents were sitting somewhere in a forgotten corner of an enterprise risk register.
One might ask: how’s that working out for us?
Last year at OWASP Global AppSec Adam Shostack challenged the industry to stop
managing risk altogether.
Risk management... has been given... an axiomatic truth. It doesn't deserve it
That statement sent me down a rabbit hole of inquiry — I still haven’t fully climbed out of. Were we wrong all along? Is cyber risk management a carefully maintained delusion of control? Or do we simply need to do better?
How did we get here in the first place? Cyber risk management has a lineage worth understanding, because the lineage explains a lot of the current problems.
The cyber risk management lineage
1974
FIPS PUB 31 explicitly links computer security with “risk management” —
ARPANET worms like Creeper and Reaper start causing concern.
1988
The Morris Worm pushes the field significantly forward.
1993-1995
UK DTI/BSI Code of Practice (BS 7799) forms the foundation
for later ISO standards.
2002-2004
FISMA, NIST SP 800-30, and COSO ERM — cyber finds its place
in the enterprise risk register.
2005-2008
ISO/IEC 27001 and 27005 published — risk-based information security
management becomes the global standard.
The story makes sense. We wanted to get out of the basement, have a seat at the leadership table, speak to boards, influence the business. Integrating cyber into enterprise risk management (ERM) was the key step.
So, we borrowed the frameworks, the artefacts, the vocabulary, but we never quite got around to doing the maths. And honestly? That’s understandable. Quantifying cyber risk is genuinely hard. Attackers adapt and evolve in ways financial markets simply
don’t — there’s no historical price series for a zero-day, no actuarial table for a nationstate threat actor pivoting tactics mid-campaign.
Financial risk
Stationary. Bounded. Modellable.
Markets are adversarial in a loose sense.
You can define loss distributions. You can
model tail risk. The data exists and
stabilises.
Cyber risk
Adversarial. Non-stationary. Fat-tailed.
Attackers adapt deliberately. A P4 ticket
and an extinction-level event live in the
same distribution. Brook Schoenfield calls
it casino maths — rigorous-looking but
unreliable.
And then there’s the reality of the job itself. We wear too many hats. We’re expected to
be technically credible, commercially fluent — and now, apparently, avid
mathematicians too. Something had to give. The maths gave.
Risk registers accumulate artefacts. Every compliance non-conformity gets logged as a risk. The register grows, nobody acts on it, and the business becomes fatigued — overwhelmed by a document designed to demonstrate due diligence, not to drive decisions.
And then there are the risk committees!
Observer effect
Somewhere along the way, we started treating risk like a quantum particle — as if observing it carefully enough in a meeting room will cause it to behave differently. We report it, review it, re-score it, present it upward.
We don’t share incident data. We don’t have public datasets comparable to aviation accident investigation. Cyber insurance companies have the data — and they monetise it back to us through expensive tooling that, if you don’t customise it to your industry, produces numbers that are effectively meaningless. When I presented this thesis at the London Tech Show in March 2026, I asked hands up if anyone in the room attempted genuine risk quantification — something like FAIR. A good number went up. I asked them to keep the hand up if they had enough real-world data to produce evidence-based risk scores with direct, quantifiable links to business impact. Fewer hands. Then to keep it up if they did it without expensive tooling that ended up costing more than the exercise was worth. Nobody kept their hand up. Not one person in the room.
We are all guilty of engaging in “The Prioritisation Games”. In ERM, cyber risks compete against other risk categories which have a far clearer impact attribution and easier quantification. Commercial risks are derived directly from revenue and are an easy sell — in this unstable market everyone wants to keep their jobs and get bonuses.
Clinical and safety risk impacts stem from decades of peer-reviewed data and carry a moral weight. The ultimate prize is resource allocation — and cyber keeps losing.
Departments score their own risks. When everything is deemed “critical,” you don’t get prioritisation — you get a race to the bottom.
Ultimately sometimes things get done if the security leadership is charismatic and authoritative enough to convince the board to take action. Do we really have to resort to cyber theatre and be dramatic just to be secure?
So why are we so bad at managing risk?
TVERSKY & KAHNEMAN
We estimate probability using
availability — what comes to
mind easily. One vivid incident
outweighs a boring base rate.
SLOVIC & SUNSTEIN
Under pressure, “risk as feelings”
beats “risk as analysis.” We fixate
on bad outcomes and stop properly
weighting their likelihood.
GOODHART / CAMPBELL
When a measurement becomes
a decision target, it becomes
gameable. When every risk is
critical, critical means nothing.
We do not reason statistically about probability. We tell stories about it.
So, we borrowed the frameworks, the artefacts, the vocabulary, but we never quite got around to doing the maths. And honestly? That’s understandable. Quantifying cyber risk is genuinely hard. Attackers adapt and evolve in ways financial markets simply
don’t — there’s no historical price series for a zero-day, no actuarial table for a nationstate threat actor pivoting tactics mid-campaign.
Ross Young
Former CIA – Enterprise CISO, CISO in Residence, Team 8
Markets are adversarial in a loose sense.
You can define loss distributions. You can
model tail risk. The data exists and
stabilises.
Adam Shostack
Threat Modeling Expert, author, former Microsoft SDL
Attackers adapt deliberately. A P4 ticket
and an extinction-level event live in the
same distribution. Brook Schoenfield calls
it casino maths — rigorous-looking but
unreliable.
Adam Shostack
Threat Modeling Expert, author, former Microsoft SDL
Attackers adapt deliberately. A P4 ticket
and an extinction-level event live in the
same distribution. Brook Schoenfield calls
it casino maths — rigorous-looking but
unreliable.
Ross Young
Former CIA – Enterprise CISO, CISO in Residence, Team 8
Markets are adversarial in a loose sense.
You can define loss distributions. You can
model tail risk. The data exists and
stabilises.
Debates are arising amongst cyber thought leaders, the industry is starting to
question. At the London Tech Show when asked if the audience understood the
challenge I proposed to risk management and is in favour of change — 25% of them
raised their hands.
25%
The tipping point rule
A sufficiently large committed minority can trigger a tipping point in social convention.
Centola et al., Science (2018)
I’m not asking for a majority. Just enough of us to make this question impossible to ignore.
We do not anticipate the world with our dogmas but instead attempt to discover the new world through the critique of the old.
Yes, I just quoted Marx in a threat modelling newsletter. Bear with me.
So if I see cyber risk management as problematic, what is a viable alternative? Step one is admitting when something isn’t working. I’m not here to hand anyone a fully designed utopia. The central piece of this article is deliberately critique-first.
Nevertheless, I will try to offer some solutions. I spent years as an emergency medicine doctor before I decided it was time to save computers instead of people. And there’s something medicine does that cyber has not yet figured out.
Evidence-based clinical scoring – built on real-world data
Heart Score
Quantifies risk of major adverse
cardiac events. Statistical prediction
from real-world patient data —
EKG, age, risk factors.
CURB-65
Assesses pneumonia severity and
mortality risk. Derived from extensive
population studies across thousands
of patients.
ABCD² Score
Predicts stroke risk after a TIA.
Statistical analysis of patient
outcomes — age, blood pressure,
clinical features, duration.
"To my patients I used to say: I cannot guarantee you will not die of a heart attack. But I can tell you you are not likely to die in the next month. That's where my job is done."
Each of those scoring systems came from years of research, pooled datasets, and a culture of publishing outcomes — including unflattering ones. Imagine if we rolled up our sleeves and did the same?
Is what we’re doing just pseudoscience dressed up as risk management? Is the lack of data a solvable problem — a data-sharing and standardisation challenge we need to tackle collectively as an industry? Do we get together and fix the data problem? Or do we throw our toys out of the pram?
The lack of shared, structured data is exactly what motivated me to kick start the OWASP Threat Model Library. The Library is a community-driven catalogue of threat models, documented consistently, openly, and reusably. It is a small piece of a much larger puzzle. We need more of these efforts — more structured collection, more willingness to publish, more of us treating threat and incident knowledge as a commons rather than something to hoard.
As I said at the beginning I am not here to start a revolution, more an iterative reform. It’s not all “burn it down.”
Safety Engineering — Treats cyber incidents as chains of small failures, not binary events. Disciplines that assume failure rather than trying to prevent it have a great deal to teach us. One of the most useful tools from this world is Fault Tree Analysis (FTA) — a top-down method that starts with an undesired outcome and works backwards to map every combination of failures that could cause it. Originally developed for nuclear and aerospace engineering, FTA forces you to think in terms of causation chains rather than isolated vulnerabilities. In cyber, this means instead of asking “how likely is this asset to be compromised?” you ask “what sequence of failures would have to occur for this to go badly?” — which is a far more actionable question. It also gives you a principled basis for prioritisation: fix the nodes that appear in the most failure paths first.
Chaos Engineering — Instead of relying on theoretical risks, continuously break your systems to test resilience. Find out what’s fragile empirically, rather than probabilistically.
Threat-Centric Approaches — Avid threat modellers might recognise the FTA structure. Attack trees, popularised by Bruce Schneier in 1999, are FTA adapted for an adversarial context. Where FTA asks “how could this system fail?”, an attack tree asks “how would an attacker achieve this goal?” — same structure, different perspective. Used together, they become a prioritisation tool. Run FTA to identify which failure combinations appear most frequently. Build attack trees to find the paths an attacker can reach with fewest steps. The nodes that show up in both are where your budget does the most work.
Key Risk Indicators — Instead of using static artefacts logged in your risk register, take a page from the medical approach and use leading indicators that are proven to move before incidents. Objective, actionable, trend-based.
FAIR — If you decide to take the reformative approach and continue doing risk management but do it “better,” consider Factor Analysis of Information Risk, which offers a defensible path to financial quantification — but only if calibrated to your context and derived from real, credible data sources.
1 – Question Core Assumptions — Challenge whether risk management is truly the primary goal or simply the most familiar framework. What would change if your objective was “ensure rapid recovery” instead of “manage risk exposure”?
If our cyber risk approach isn't delivering, do we have the courage to reimagine it — or will we keep optimising a failing system?
2 – Consider if the lack of data is a solvable problem — As an industry we need to demand more, publish more, and stop hoarding incident information behind NDAs and expensive tooling. Open datasets are how medicine built its evidence base.
3 – Explore Alternative Approaches — Look beyond process metrics. Are you actually experiencing fewer successful attacks? Can you demonstrate harm reduction, not just risk documentation?
4 – Have the Difficult Conversation — Bring this question to your teams and leadership: are we reducing harm, or are we optimising a failing system?
// Author
Brook Schoenfield
Former CISO
Security Architecture Leader
Securing Systems
Secrets of a Cyber Security Architect
PV
Petra Vukmirovic
Head of Information Security at Numan Fractional Head of Product at DevArmor
OWASP Threat Model Library Co-Lead · LF AI & Data Security Workgroup Co-chair
Patent author / inventor · Former emergency medicine doctor · Public speaker at
OWASP Global AppSec, Teiss, and beyond · Competitive athlete (volleyball)
Shostack, A. (2024). Keynote address. OWASP Global AppSec Conference.
Shostack, A. (2014). Threat Modeling: Designing for Security. Wiley.
Tversky, A. & Kahneman, D. (1973). Availability: A heuristic for judging frequency and probability.
Cognitive Psychology, 5(2), 207–232.
Slovic, P., Finucane, M., Peters, E. & MacGregor, D.G. (2004). Risk as analysis and risk as feelings. Risk
Analysis, 24(2), 311–322.
Sunstein, C.R. (2002). Risk and Reason: Safety, Law, and the Environment. Cambridge University Press.
Goodhart, C. (1975). Problems of monetary management: The U.K. experience. Papers in Monetary Economics,
Reserve Bank of Australia.
Campbell, D.T. (1979). Asshole for the social scientist. American Behavioral Scientist, 23(3), 85–95.
Centola, D., Becker, J., Brackbill, D. & Baronchelli, A. (2018). Experimental evidence for tipping points in
social convention. Science, 360(6393), 1116–1119.
Schneier, B. (1999). Attack trees: Modeling security threats. Dr. Dobb’s Journal.
Schoenfield, B. (2015). Securing Systems: Applied Security Architecture and Threat Models. CRC Press.
Schoenfield, B. (2021). Secrets of a Cyber Security Architect. CRC Press.
Schoenfield, B. (2024). [Casino maths etc.]. LinkedIn posts and OWASP Slack conversations.
Young, R. (2024). [On scenario-based security decision making]. LinkedIn post.
Lantzy, S. (2024). [On killing the risk matrix]. LinkedIn post.
Marx, K. (1843). Letter to Arnold Ruge. Deutsch-Französische Jahrbücher.
NCSC (2025). Annual Review 2025. National Cyber Security Centre, UK.
OWASP Threat Model Library. https: /owasp.org/www-project-threat-model-library/
When we think about “validating untrusted input”, we usually picture a text field in a web form, a login box, a URL-parameter or a JSON string sent to an API.
But what happens when input is pulled directly from the air?
This blog post describes CVE-2026-6058, a vulnerability I recently discovered in the Zyxel WRE6505 v2 Wi-Fi range extender. It is a straightforward, Medium-severity “Denial-of-Service” bug in the device’s management interface that is not weaponizable on a large scale. It does however highlight a critical lesson in threat modeling and demonstrates exactly why EU-regulators are forcing manufacturers to pay closer attention to the security of their products.
A talk by Vikramaditya Narayan argues that relying solely on LLMs for threat modeling leads to inconsistent, non-explainable results, and proposes a hybrid approach combining deterministic NLP systems with LLMs for better reliability and insight.
Key takeaways:
This Toreon article explains that in the AI era, “secure by design” means embedding security, risk management, and governance into AI systems from the very start, rather than trying to fix vulnerabilities afterwards. AI introduces fundamentally new and faster-evolving threats.
Key takeaways:
When we think about “validating untrusted input”, we usually picture a text field in a web form, a login box, a URL-parameter or a JSON string sent to an API.
But what happens when input is pulled directly from the air?
This blog post describes CVE-2026-6058, a vulnerability I recently discovered in the Zyxel WRE6505 v2 Wi-Fi range extender. It is a straightforward, Medium-severity “Denial-of-Service” bug in the device’s management interface that is not weaponizable on a large scale. It does however highlight a critical lesson in threat modeling and demonstrates exactly why EU-regulators are forcing manufacturers to pay closer attention to the security of their products.
A talk by Vikramaditya Narayan argues that relying solely on LLMs for threat modeling leads to inconsistent, non-explainable results, and proposes a hybrid approach combining deterministic NLP systems with LLMs for better reliability and insight.
Key takeaways:
this Toreon article explains that in the AI era, “secure by design” means embedding security, risk management, and governance into AI systems from the very start, rather than trying to fix vulnerabilities afterward, because AI introduces fundamentally new and faster-evolving threats.
Key takeaways:
This podcast is a great way to learn and to stay up to date with the latest developments in application security and threat modeling. Hosted by Chris Romeo (Kerr Ventures) and Robert Hurlbut (Toreon), with new guests (whom you might recognize from our guest articles) every episode, this podcast series is a must watch.
This is also their 10th year doing this series, so happy anniversary to them.
Threat Modeling Practitioner training, hybrid online, hosted by DPI, US Cohort
Starting April 28th 2026
Advanced Whiteboard Hacking – aka Hands-on Threat Modeling, NorthSec Training, Montreal
May 11-12 2026
3-Day Training: AI Whiteboard Hacking aka Hands-on Threat Modeling Training, in-person, OWASP Global AppSec EU, Vienna Austria
June 22-24 2026
Threat Modeling Practitioner training, hybrid online, hosted by DPI, US Cohort
June 2026
AI Whiteboard Hacking aka Hands-on Threat Modeling Training, TROOPERS
June 22-23 2026
Threat Modeling Practitioner training, hybrid online, hosted by DPI, Europe Cohort
September 2026
Threat Modeling Practitioner training, hybrid online, hosted by DPI, US Cohort
Starting April 28th 2026
Advanced Whiteboard Hacking – aka Hands-on Threat Modeling, NorthSec Training, Montreal
May 11-12 2026
3-Day Training: AI Whiteboard Hacking aka Hands-on Threat Modeling Training, in-person, OWASP Global AppSec EU, Vienna Austria
June 22-24 2026
Threat Modeling Practitioner training, hybrid online, hosted by DPI, US Cohort
June 2026
AI Whiteboard Hacking aka Hands-on Threat Modeling Training, TROOPERS
June 22-23 2026
Threat Modeling Practitioner training, hybrid online, hosted by DPI, Europe Cohort
September 2026
Making security a design activity, not a tax
When embedded early and done well, threat modeling becomes a powerful design activity that helps teams build secure systems without adding friction.
In this session, we’ll show how to make threat modeling a natural, seamless part of security operations, reducing friction for engineering teams while embedding security from the start. You will discover why threat modeling matters, how it strengthens secure technology, and how approaching it as a continuous journey can unlock long-term, secure-by-design success for their organizations
Is security becoming prompt-driven?
As prompt-driven development, AI agents, and modern architectures reshape engineering workflows, security teams are asking an important question: if AI can analyze code, reason about architecture, and surface vulnerabilities so quickly, what is the future role of AppSec?
Join Sebastien Deleersnyder and Hovsepyan, Aram for a practitioner-focused discussion exploring how AI is influencing application security, why threat modeling is becoming even more critical, and how teams can turn security insights into structured action.
