Threat Modeling And Risk Analysis

Purpose

Threat modeling is a structured conversation about what can go wrong and what we should do about it.

It is not a security ritual for specialists only. Developers, QA, architects, product owners, operations, and support all see different risks. A good threat model brings those perspectives together before the system is attacked by reality.

When To Threat Model

Threat model when:

• Building a new product or service.
• Adding authentication or authorization.
• Handling sensitive data.
• Integrating with external systems.
• Creating admin features.
• Processing payments or financial data.
• Uploading files.
• Exposing new APIs.
• Changing infrastructure, networking, or identity.
• Using AI with private data or tool access.

Simple Threat Modeling Flow

Use four questions:

1. What are we building?
2. What can go wrong?
3. What are we doing about it?
4. Did we do a good enough job?

This is simple enough to use in a design review and powerful enough to reveal serious risk.

Assets, Actors, Entry Points

Start by identifying:

• Assets: customer data, credentials, payments, documents, APIs, admin functions, models, source code.
• Actors: customers, admins, employees, services, partners, attackers, compromised accounts.
• Entry points: web UI, API, file upload, webhook, queue, database, mobile app, CI/CD pipeline, admin console.

STRIDE Model

STRIDE is a useful checklist:

Abuse Stories

Write abuse stories alongside user stories.

Examples:

• As an attacker, I try to access another customer's invoice by changing an ID.
• As a compromised employee account, I try to export all customer records.
• As an unauthenticated user, I try to upload a large file to exhaust storage.
• As a malicious integration partner, I send malformed webhook payloads.
• As a user, I try to bypass subscription limits by calling the API directly.

Abuse stories make security concrete. People remember stories better than policy documents.

Risk Rating

Use a simple rating:

• Impact: low, medium, high.
• Likelihood: low, medium, high.
• Detectability: easy, moderate, hard.
• Mitigation owner.
• Target date.

Avoid false precision. The goal is decision clarity, not pretending we can calculate attacker motivation to two decimal places.

Controls

Common control categories:

• Prevent: auth, validation, encryption, least privilege, safe defaults.
• Detect: logs, alerts, anomaly detection, audit trails.
• Respond: incident process, account lock, token revocation, rollback.
• Recover: backups, restore tests, disaster recovery, customer communication.

AI And Threat Modeling

AI can help draft threat models, but humans must validate them.

Good prompts:

• "List possible STRIDE threats for this architecture."
• "Write abuse stories for this admin workflow."
• "Review this API design for broken access control risks."
• "What logs would help detect misuse?"

Never let AI replace context from developers, operations, QA, and product owners.

Team Reference Guide

Guidelines For Teams

• Keep threat models lightweight but real.
• Focus on high-risk flows first.
• Capture decisions in ADRs or design notes.
• Add mitigation tasks to the backlog.
• Revisit threat models after major architecture or data-flow changes.

Reflection Questions

• What is the most valuable asset in this system?
• What can an authenticated but unauthorized user do?
• What would an attacker try first?
• What abuse would our logs fail to show?

Further Study

• OWASP Threat Modeling: https://owasp.org/www-community/Threat_Modeling
• OWASP Threat Dragon: https://owasp.org/www-project-threat-dragon/
• Microsoft Threat Modeling Tool: https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool
• MITRE ATT&CK: https://attack.mitre.org/