Threat modeling
Threat modeling only pays off when engineers can run it themselves. I facilitate the first models on systems that matter, then hand over templates, a definition of done and a review rhythm so the practice survives.
Updated
Format
01Session 1
Diagram the system together: components, data flows, trust boundaries, assets, assumptions and relevant external parties.
02Session 2
Run a STRIDE pass per data flow, process, data store and external entity, capturing threats as testable statements rather than vague concerns.
03Session 3
Rank the threats in the context of the system, then design mitigations and hand off a backlog with owners, dependencies and acceptance criteria.
04Enablement
Provide a template, facilitation guide, examples from your own systems and a review checkpoint in the SDLC so the practice survives the first workshop.
The model is useful only when it changes delivery work. I connect each material threat to a design decision, requirement, backlog item or test case, and record conscious risk acceptance.
Reopen the model when an integration, data class, privileged workflow or AI tool changes what the system trusts; when architecture changes; before a material release; and after an incident or near miss.
| Category | Question | Typical control |
|---|---|---|
| Spoofing | Can identity be faked? | Strong authentication, workload identity, mTLS |
| Tampering | Can data or code be altered? | Integrity checks, signing, least privilege |
| Repudiation | Can actions be denied? | Tamper-evident audit logs |
| Information disclosure | Can data leak? | Encryption, scoping, redaction |
| Denial of service | Can it be exhausted? | Quotas, rate limits, isolation |
| Elevation of privilege | Can a boundary be crossed? | Authorisation checks, segmentation |
Frequently asked questions
Do we need a tool?
No. A diagram, a facilitator and a backlog beat any tool. Tooling helps at scale, once the practice exists.
Related
Threat modeling
A practical STRIDE-based threat modeling method for cloud, application and AI systems, built to be run by engineering teams.
STRIDE for AI systems
Applying STRIDE to LLM and agentic applications: what each category means when untrusted text can act as instructions, where STRIDE stops covering multi-agent failure modes, and the controls per element.
Cloud architecture review
Design-stage review of cloud and hybrid architecture: trust boundaries, identity model, segmentation, key management and detection design.
Penetration Testing
Adversarial testing of approved applications, APIs and exposed services, with evidence, risk context and a remediation retest.
Confidence
Recorded CONFidence talk: threat modeling at the scale of Allegro, from STRIDE to a process engineering teams actually run.
4Developers
Speaking at 4Developers, a large Polish conference for software engineers, on secure design and AI security.