KHAGAN AYDIN
Writing

What is Threat Modeling?

Threat modeling sounds like a heavy process with diagrams and frameworks. Strip that away and it is four plain questions you ask before you build, not after.

· 4 min read

Here are the four, in order:

  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 job?

Everything else, the diagrams, STRIDE, the scoring, is just a way to answer those four well. The reason to bother is plain economics. A flaw caught on a whiteboard costs an hour. The same flaw caught in production costs an incident. Threat modeling is the cheapest security work there is, because it moves the fix to the cheapest possible moment.

Let me walk it through on a real situation: a food delivery app that runs in New York, is expanding to Seattle, and is adding live driver tracking on the way. New city, new feature, new things that can go wrong. That is exactly when to model.

What are we building

You cannot find what can go wrong until you can see the system, so draw it. Not a beautiful diagram, an honest one: the customer app, the restaurant app, the new driver app, the load balancer, the servers, the database, and the cloud it runs on. Then draw the arrows. Who talks to whom, and where does data cross a boundary, from the phone to your server, from your server to the database, from your system out to a payment provider.

Customer app ─┐                      ┌─ Restaurant app
              ├──▶ Load balancer ──▶ │
Driver app  ──┘                      └─▶ Server ──▶ Database
                                              │
                                         Payment provider

The boundaries are where you spend your attention, because a boundary is where trust changes hands, and trust handed off without a check is where most bugs live.

What can go wrong

This is where STRIDE earns its keep. It is a checklist of six ways a part of a system gets attacked, and its only job is to stop you forgetting a category. Walk each component and ask all six:

  • Spoofing: can someone pretend to be a customer, a driver, or the restaurant? A fake driver account that intercepts orders.
  • Tampering: can someone change data in transit or at rest? Altering an order’s address or total between the app and the server.
  • Repudiation: can someone act and then deny it, with no record? A driver who claims an order never arrived, and no log to settle it.
  • Information disclosure: can someone read data they should not? One customer’s address and order history leaking through the new driver feature.
  • Denial of service: can someone make it unavailable? Flooding the checkout endpoint so real customers cannot order.
  • Elevation of privilege: can someone get more access than they should? A normal account reaching an admin function.

Six questions per component. Most answers will be “not a concern here,” and that is fine. The value is that you asked, so the one that matters does not slip through because nobody thought of it.

What are we going to do about it

For each real threat, one of four choices: fix it, reduce it, accept it with eyes open, or decide the feature is not worth the risk. The fixes are usually old and boring, which is the point:

  • Spoofing: real authentication, and take identity from the session, never from a parameter.
  • Tampering: TLS everywhere in transit, integrity checks at rest.
  • Information disclosure: fetch only what this user is allowed to see, enforced in your own code. The classic miss here is IDOR.
  • Denial of service: rate limits and input caps.

Write the decision down next to the threat. A model that lists risks but records no decisions is a worry list, not a plan.

Did we do a good job

The part everyone skips. Before you ship, check: did we cover every component and every boundary? Did the fixes actually get built, or only written down? Then after launch, watch, because the model was a prediction and production is the truth.

A word on scoring, and DREAD

You will see DREAD recommended for ranking: score each threat on Damage, Reproducibility, Exploitability, Affected users and Discoverability, then total it. Use it if it helps the conversation, but know its weakness, the reason Microsoft itself moved away from it. The numbers are guesses dressed as math. Two reasonable people score the same threat differently, and the total feels precise when it is not. For most teams a plain impact times likelihood, rated High, Medium or Low, is honest and good enough. The goal is to agree on what to fix first, not to produce a decimal.

The point

None of this needs a security team or a tool budget. It needs an hour, a whiteboard, and the discipline to ask what could go wrong before the code exists to make it expensive. Almost every serious bug I have found in twenty years was something a half hour of this would have surfaced, if anyone had sat down to ask.

So the next time you add a feature or move into a new market, do not start with the code. Start with the four questions. The cheapest security work you will ever do is the thinking you do before the first line is written.