threat-modelling

Threat Modelling (STRIDE / SDL)

Threat modelling is a structured Microsoft Security Development Lifecycle (SDL) practice for identifying, communicating, and mitigating threats early in design - before code is written, and re-applied whenever the design materially changes.

When to use

Designing a new system, significantly changing an existing one, evaluating an architecture for security, or running a formal security design review.

Do not use this skill for:

• Org-wide security architecture or roadmap (use security-architecture)
• Runtime detection or incident response (use sentinel / defender-xdr)
• Code-level vulnerability scanning (use SAST/DAST tooling)

STRIDE - the six categories at a glance

Letter	Threat	Security property it breaks	Typical mitigation
S	Spoofing	Authentication	MFA, mutual TLS, signed tokens
T	Tampering	Integrity	Signing, hashing, write-protected stores
R	Repudiation	Non-repudiation	Audit logging, signed transactions
I	Information disclosure	Confidentiality	Encryption (rest+transit), authorization
D	Denial of service	Availability	Rate limiting, quotas, autoscale, WAF
E	Elevation of privilege	Authorization	Least privilege, input validation, sandboxing

Rule of thumb: walk each element of the data-flow diagram against all six STRIDE categories. Skipping categories because "they don't apply here" is the most common way real threats are missed.

Approach

1. Define scope and assumptions - State what is in scope, what is out, the trust model (who you trust to do what), and the assets being protected. A threat model without scope is an opinion. Verify: a one-page scope statement names assets, actors, in-scope components, and explicit out-of-scope items.
2. Build the data-flow diagram (DFD) - Draw external entities, processes, data stores, data flows, and trust boundaries. Trust boundaries are where authority/data crosses between principals - that is where most threats live. Verify: every data flow crossing a trust boundary is highlighted; no boundary-crossing flow is missing.
3. Enumerate threats with STRIDE per element - For each element/flow, walk through all six STRIDE categories. For each applicable threat, write a one-line description. Verify: every element has been evaluated against all six letters; you can show the coverage matrix.
4. Rank threats by risk - Use DREAD or a simple high/medium/low based on likelihood and impact. Triage so the team works the top tier first. Verify: top 10 threat list is risk-ranked, not order-of-discovery.
5. Map each threat to a concrete mitigation - Mitigation = a specific control (MFA, input validation, signing, encryption, rate limiting, least privilege) plus an owner and a target date. Abstract "we should secure that" is not a mitigation. Verify: every top-tier threat has a named mitigation, an owner, and an implementation target.
6. Validate mitigations are implemented - During build, confirm each mitigation lands in code, configuration, or process. During review, test that the mitigation actually blocks the threat (negative test). Verify: mitigation tests exist in the test suite or in a security review checklist.
7. Re-model on material change - Treat threat modelling as iterative. Every new trust boundary, new external integration, new data classification, or major refactor is a trigger to re-model the affected slice. Verify: the team has a written trigger list and the model is updated after the most recent trigger event.
8. Use tooling where it helps - The Microsoft Threat Modeling Tool generates STRIDE threats per DFD element automatically. Threat-modelling cards / templates work well for workshops without tooling.