Secure by Design · Threat Modeling
Most threat models are a document written once and never opened again. Alvor anchors every threat to the component it targets, maps each one to the control that stops it, and tracks the gaps in real time. STRIDE, MITRE ATT&CK, and kill-chain analysis, built into the design phase.
The discipline
Threat modeling is a structured way to find what can go wrong with a system before an attacker does, and before a line of code is written. You build a model of what you are creating, reason about the threats against it, decide what to do about each one, and check your work. The whole practice comes down to four questions, framed by Adam Shostack and adopted across the industry.
Model the system as it really is: components, datastores, the data flows between them, the external entities it talks to, and the trust boundaries the data crosses. You cannot defend what you have not drawn.
Walk every element and ask how it can be attacked. STRIDE gives you six questions to ask of each one, so threats are found by method instead of by memory.
Decide each threat: mitigate it with a control, accept it with a documented rationale, or rule it out of scope. Every mitigation links to the control that delivers it.
Measure coverage. Count the threats still open with no control behind them, and review the model when the design changes, so the analysis stays true instead of going stale.
The taxonomy
STRIDE is the most widely used threat taxonomy. Each letter is a category of threat and the security property it breaks. Run all six questions against every element of the model and you find threats by method, not by whatever you happened to think of that day. We keep a full walkthrough of the six categories with worked examples, and a comparison of STRIDE against PASTA and LINDDUN for when you are weighing methodologies.
An attacker pretends to be someone or something they are not: a forged token, a stolen session, an impersonated service.
Data or code is modified in transit or at rest: a manipulated request, a poisoned queue, an altered record.
Someone performs an action and then denies it, because nothing logged it in a way that holds up.
Data reaches someone who should never have seen it: an exposed store, a verbose error, a leaky API response.
The system is made unavailable to legitimate users: a flood, a resource exhaustion, a poison-pill input.
A user gains rights they were never granted: a broken access check, a confused deputy, a path to admin.
Inside Alvor
Threat modeling in Alvor is four moves on one canvas. The model is an object in the system, not an artifact filed away from it.
Register each element of your design as a node: components, datastores, data flows, external entities, and trust boundaries. Every element is numbered (C1, DS1, DF1, EE1, TB1) and can link straight to the asset it represents in your inventory.
Add threats where they live, on a node or a flow, not in a separate document. Each carries a STRIDE category, a severity from low to critical, and a status: open, mitigated, accepted, or not applicable. Pull from the threat library or write your own.
Link each threat to the control that addresses it, as a primary or supporting mitigation, with notes on how. The control is assigned to the project automatically and flagged as threat-driven, so the design carries its own justification.
Coverage analytics count elements, threats, and status at a glance, with the unmitigated count front and centre: every open threat that still has no control behind it. Change the diagram and the model follows, so it never quietly goes stale.
Payment Gateway · Threat Model
2 unmitigatedModel with AI
The AI Threat Modeling Studio reads the diagram you have open and works phase by phase, each phase arriving as a batch you review. You spend your judgment on the threats, not on the data entry.
Diagram shapes become STRIDE elements: components, datastores, data flows, external entities, trust boundaries.
Threats enumerated per element, reusing your threat library before inventing anything new.
Mitigating controls from your control library. Mapped controls become required, threat-driven build controls.
One card per batch. Statuses update, coverage recounts, and the register grows as you model.
One deliberate limit: past high-level design, the studio will not change a baselined model. That is a governed architecture change, and it belongs to a human.
Approval required
Spoofed client tokens at the API gateway
HighSpoofing · EE1 → C1
Tampering with settlement queue messages
MediumTampering · DF3
Disclosure of export bucket contents
HighInfo disclosure · DS2
One approval card for the whole batch, not one per row.
Standards, not guesswork
Threats are not invented from scratch each time. Alvor ships a reusable threat library seeded from the standard sources, and it grows as your teams model: write a threat once and it is recorded for the next project, deduplicated by title and source, tagged with the element kinds it applies to and an external reference back to the technique it came from.
System entries stay fixed for consistency. Custom entries are yours to shape. Retired entries keep their history without cluttering the picker.
STRIDE
The core six-category taxonomy, applied per element.
MITRE ATT&CK
Real adversary techniques, referenced by ID (T1110).
Cyber Kill Chain
Where a threat sits in the attacker's sequence.
OWASP
Web and API risk categories (A03:2021 and more).
CAPEC
Common attack patterns, cross-referenced to threats.
NIST
Control families the mitigations map back into.
The loop that closes
The point of the exercise is not the diagram. It is knowing, at any moment, which threats are still unanswered. Alvor keeps that number in front of you and ties it back to the controls, the assets, and the approval gates of the Secure by Design workflow, so an open threat is a decision someone has to make, not a line nobody reads.
5
STRIDE element kinds
Component, datastore, data flow, external entity, trust boundary
4
Threat statuses tracked
Open, mitigated, accepted, not applicable
0
Unmitigated is the goal
Every open threat with no control is counted, not hidden
Evaluating threat modeling tools? See how Alvor stacks up against IriusRisk, ThreatModeler, SD Elements, and OWASP Threat Dragon.
Questions
Threat modeling is a structured way to find what can go wrong with a system before an attacker does, ideally before the system is built. You model what you are creating, enumerate the threats against it, decide how to handle each one, and verify your work. The practice is usually framed as four questions: what are we building, what can go wrong, what are we going to do about it, and did we do a good enough job. It is a design-time discipline, not a scan you run after the fact.
Further reading
How threat modelling gives APRA-regulated entities defensible evidence for CPS 234's design-time control obligations, and a process that fits alongside CPS 230.
How to threat model AI systems: STRIDE extended for LLM applications, the OWASP LLM Top 10 mapped to design-time decisions, and a worked RAG example.
A step-by-step threat modeling guide: scope the system, draw the data flow diagram, mark trust boundaries, enumerate threats with STRIDE, map controls, and decide.
Get started
Whether you lead security, run IT, manage compliance, or sit in the C-suite - we'll show you your view.