Threat Modeling for People Who Hate Threat Modeling

Summer is over, the team is back, and someone just put "threat modeling session" on the calendar. You can practically hear the collective groan from across the office. Or the Slack channel. Or wherever your team pretends to be excited about process.

Here's the thing: threat modeling has a reputation problem. It sounds academic. It feels like homework. And most guides make it way more complicated than it needs to be. But done right, it's one of the most valuable hours your team can spend together. Let me show you how.

What Is Threat Modeling, Really?

Strip away the jargon and threat modeling is just asking four questions:

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

That's it. You don't need a PhD. You don't need to buy expensive software. You need a whiteboard, a framework to keep you focused, and about an hour.

STRIDE: The Framework That Actually Makes Sense

STRIDE is Microsoft's threat classification model, and it's popular for a reason: each letter maps to a specific type of thing that can go wrong. Instead of staring at a diagram and trying to think of "threats" in the abstract, you walk through each category one at a time.

• S - Spoofing: Can someone pretend to be a user or system they're not?
• T - Tampering: Can someone modify data they shouldn't be able to touch?
• R - Repudiation: Can someone do something bad and then deny it happened?
• I - Information Disclosure: Can sensitive data leak to the wrong people?
• D - Denial of Service: Can someone make the system unavailable?
• E - Elevation of Privilege: Can someone gain access above their permission level?

The beauty of STRIDE is that it turns a vague question ("is this secure?") into six specific ones. And specific questions get specific answers.

Walking Through a Real Example: SaaS Login Flow

Let's make this concrete. Say you're building a standard SaaS application with a login flow. The user enters their email and password, your server validates credentials against a database, issues a session token, and the user lands on their dashboard. Pretty standard stuff.

Now let's run STRIDE against each component.

The Login Form (Client Side)

• Spoofing: An attacker could create a phishing page that looks identical to your login form. Users enter their real credentials on the fake page. Mitigation: enforce HTTPS, use HSTS headers, and educate users to verify the domain.
• Tampering: If the form submits over HTTP instead of HTTPS, someone on the same network could intercept and modify the request. Mitigation: TLS everywhere, no exceptions.
• Information Disclosure: Does the form auto-complete store passwords insecurely? Does the page source reveal API endpoints or internal structure? Review what the client exposes.

The Authentication API

• Spoofing: Can an attacker replay a valid authentication request? Mitigation: use anti-replay mechanisms like nonces and short-lived tokens.
• Tampering: Could someone modify the request payload to change the user ID or role during authentication? Mitigation: validate and sign tokens server-side. Never trust client-supplied role data.
• Repudiation: If a user claims they never logged in, can you prove they did? Mitigation: log all authentication events with timestamps, IP addresses, and user agents. Keep audit trails immutable.
• Denial of Service: Can an attacker flood the login endpoint with requests? Mitigation: rate limiting, CAPTCHA after failed attempts, and account lockout policies with sensible thresholds.

The Session Token

• Spoofing: Can an attacker guess or steal a session token? Mitigation: use cryptographically random tokens with sufficient entropy. Set HttpOnly and Secure flags on cookies.
• Information Disclosure: Is the token stored in localStorage where any XSS vulnerability could grab it? Mitigation: prefer HttpOnly cookies over localStorage for session management.
• Elevation of Privilege: Can a regular user modify their token to gain admin access? Mitigation: store permissions server-side, not in the token. If using JWTs, validate the signature on every request.

The Database

• Tampering: Could SQL injection allow an attacker to modify or delete user records? Mitigation: parameterized queries, always. No concatenated SQL, ever.
• Information Disclosure: Are passwords stored in plaintext or with weak hashing? Mitigation: bcrypt or Argon2 with proper salt. Never MD5 or SHA-1 for passwords.
• Elevation of Privilege: Does the database connection use a service account with more permissions than necessary? Mitigation: principle of least privilege for database accounts.

"You don't find every threat in one pass. You find enough threats to make the next version meaningfully safer than the last one."

STRIDE vs. PASTA vs. Attack Trees

STRIDE isn't the only game in town. Here's how the major frameworks compare so you can pick the right one for your situation.

STRIDE

Best for development teams who want a structured but approachable way to think about threats. It's category-driven, meaning you systematically check each threat type against each component. The learning curve is gentle, and it works well in workshops. The downside: it doesn't inherently prioritize risks by business impact.

PASTA (Process for Attack Simulation and Threat Analysis)

PASTA is a seven-stage, risk-centric framework. It starts with business objectives and works down through technical analysis to attack simulation. It's more thorough than STRIDE but also heavier. If you're working in a regulated industry or dealing with high-value targets, PASTA gives you the depth to justify security investments to leadership. The trade-off is time and complexity. A full PASTA analysis can take days, not hours.

Attack Trees

Attack trees are visual. You put the attacker's goal at the top of a tree and branch downward into all the ways they could achieve it. Each branch can split further into sub-methods. They're great for exploring specific scenarios in depth and for communicating risks to non-technical stakeholders. The weakness: they can get unwieldy fast, and they don't give you the systematic coverage that STRIDE provides.

My recommendation: Start with STRIDE. It's the right balance of structure and simplicity for most teams. Once you've built the muscle memory, you can layer in PASTA for high-stakes projects or use attack trees when you need to deep-dive a specific threat.

The 1-Hour Threat Modeling Workshop

Here's a format any team can run, no prior experience needed. Put this on the calendar quarterly. Seriously, block it now.

Before the Meeting (5 minutes of prep)

• Pick one feature, flow, or system component to focus on. Don't try to model everything at once.
• Draw a simple diagram showing the components and data flows. A whiteboard sketch or a quick diagram in any drawing tool works fine.
• Share it with the team so people can glance at it before the meeting.

Minutes 0-10: Set the Context

Walk through the diagram together. Make sure everyone understands what the system does, where data flows, and what the trust boundaries are. Trust boundaries are the lines where data moves between zones of different trust levels, like from the user's browser to your API, or from your API to a third-party service.

Minutes 10-40: Run STRIDE

Go through each component in the diagram and ask the six STRIDE questions. Write every threat down, even if it seems obvious or unlikely. You're brainstorming, not filtering. Assign one person to take notes. Use a shared doc or even sticky notes on a wall.

Minutes 40-50: Prioritize

For each identified threat, do a quick gut-check rating: high, medium, or low. Consider two factors: how likely is this to be exploited, and how bad would it be if it were? Don't overthink it. You're not writing a risk register. You're deciding what to fix first.

Minutes 50-60: Assign Actions

For every high-priority threat, assign an owner and a timeline. For medium threats, create tickets in your backlog. For low threats, document them and move on. End the meeting with a clear list of who's doing what.

"The best threat model is the one that actually gets done. A quick-and-dirty session beats a perfect one that never happens."

Tools to Help

Microsoft offers a free Threat Modeling Tool that lets you draw data flow diagrams and automatically suggests threats based on STRIDE. It's not fancy, but it's genuinely useful and costs nothing. You can download it from Microsoft's security engineering site.

If you want something lighter, a shared whiteboard and a spreadsheet work just as well. The tool matters less than the conversation.

Making It Stick: Quarterly Sessions

One threat modeling session is good. Four per year is transformative. Here's why quarterly works:

• Q1 (January): Model any new architecture from the previous year's big projects. Catch what slipped through during the holiday push.
• Q2 (April): Focus on features in active development. You're mid-year, mid-roadmap. Perfect time to model what's being built right now.
• Q3 (September): Back from summer. Review any changes shipped while people were on vacation. This is a natural reset point.
• Q4 (October): Pre-holiday hardening. Model your most critical flows before the end-of-year code freeze.

Put all four on the calendar at the start of the year. Treat them like any other recurring team ritual. The consistency matters more than perfection.

Threat modeling doesn't need to be a dreaded exercise. It's just a structured conversation about what could go wrong, and it's one of the few security activities that makes everyone on the team smarter about the system they're building. Start with STRIDE, keep it to an hour, and do it every quarter. You'll be surprised how quickly it becomes something your team actually looks forward to.