Threat Modelling for Non-Security Engineers: A 2-Hour Process

Most engineers assume threat modelling is the domain of dedicated security teams. It isn't. You don't need a CISSP to identify what could go wrong with your system—you just need a structured approach and two hours.

Threat modelling is fundamentally an engineering discipline: identify assets, map data flows, find weak points, and decide what to fix. At LavaPi, we've guided dozens of teams through this process, and the pattern is always the same. Here's how to run it yourself.

The Setup (15 minutes)

Gather the right people: a product manager, a backend engineer, a frontend engineer, and ideally someone from ops. You need breadth, not depth. Book a whiteboard or open a collaborative document.

Define your scope narrowly. "Threat model our authentication system" works. "Threat model our entire platform" does not. A focused session produces actionable results; a sprawling one produces nothing.

What You Need

• System diagram (boxes and arrows showing services, databases, external APIs)
• Data classification (what's public, confidential, sensitive?)
• Access patterns (who talks to what, when, and why?)

If your diagram doesn't exist, spend 20 minutes building one. Precision isn't critical—rough is fine.

Identify Threats (60 minutes)

Use STRIDE, a taxonomy that covers six threat categories:

• Spoofing: Can someone pretend to be someone else?
• Tampering: Can data be modified in transit or at rest?
• Repudiation: Can someone deny they performed an action?
• Information Disclosure: Can sensitive data be exposed?
• Denial of Service: Can the system be made unavailable?
• Elevation of Privilege: Can someone gain higher access than they should?

Walk through each data flow in your diagram. For each flow, ask: "What STRIDE threats apply here?"

Example: Your API sends user data to a third-party analytics service.

typescriptCopy
// Current implementation
fetch('https://analytics.external-service.com/track', {
  method: 'POST',
  body: JSON.stringify({
    userId: user.id,
    email: user.email,
    purchaseAmount: order.total
  })
});

Threats:

• Tampering: Data is sent over HTTP (hypothetically)—it could be intercepted and modified.
• Information Disclosure: Email and purchase amounts are exposed to a third party.
• Spoofing: A man-in-the-middle attacker could impersonate your service.

Document each threat as a one-liner with the affected flow. Don't over-explain.

Expect 15–25 threats in a two-hour session. Most will be low-risk; some will surprise you.

Prioritize and Assign (45 minutes)

Not every threat deserves a fix. Use this simple matrix:

| Risk | Likelihood | Impact | Action | |----------|---|---|---| | High | Probable | Severe | Fix now | | Medium | Possible | Moderate | Schedule fix | | Low | Unlikely | Minor | Document, monitor |

For each threat, discuss:

• How realistic is this attack?
• What's the worst outcome?
• Do we already mitigate this (existing controls)?

pythonCopy
# Example: rate limiting mitigates DoS risk
from flask_limiter import Limiter

limiter = Limiter(app, key_func=lambda: request.remote_addr)

@app.route('/api/search')
@limiter.limit("30 per minute")
def search():
    query = request.args.get('q')
    return perform_search(query)

If you can't agree on priority, err on the side of fixing it. A medium-risk issue ignored is often a high-risk incident waiting to happen.

Assign owners. Vague ownership means nothing gets done. "Maria will create a ticket to upgrade TLS" is better than "we should upgrade TLS."

The Output

You should leave with:

1. A list of identified threats ranked by priority
2. Specific owners and rough timelines for fixes
3. A note to repeat this quarterly—systems change, threats evolve

Don't overcomplicate the documentation. A spreadsheet with columns (Flow, Threat, Impact, Owner, ETA) works. A 40-page risk register doesn't.

The Payoff

Two hours of structured thinking prevents months of firefighting. You'll catch design flaws before they reach production. You'll make better decisions about third-party integrations, data retention, and access controls.

Threat modelling isn't a security specialist's job. It's an engineering responsibility. Run it yourself.