Think Like the Attacker or Lose Like the Defender: Flipping Threat Modeling on Its Head

I'm going to say something that's going to annoy a lot of compliance officers: most threat models are basically useless.

Not because the people building them aren't smart. Not because the frameworks are inherently bad. They're useless because they're built from the wrong direction. Security teams sit down, look at their assets, think about what they're afraid of losing, and then try to imagine how someone might attack those assets. It sounds reasonable. It's actually backwards.

Real attackers don't start with your assets. They start with their objectives. And until your threat model starts in the same place, you're going to keep building defenses that protect what you think matters while leaving exposed what actually matters to the person trying to ruin your week.

The Defender's Fallacy

Here's how traditional threat modeling typically plays out in practice. A team assembles, usually some combination of security architects, compliance folks, and maybe an application owner. They enumerate their assets — customer PII, source code, financial records, whatever. They assign sensitivity ratings. They map out data flows. They identify control gaps. They produce a document. That document goes into a shared drive. Everyone feels better.

What that process almost never does is seriously interrogate the question: who specifically would want to attack us, what would they actually be trying to accomplish, and how would someone with their capabilities and motivations realistically go about it?

The result is threat models that are really just asset inventories with a risk rating column. They describe what you have, not how you'd lose it. They're defensive documents built by people who, understandably, think defensively. And they leave massive blind spots — specifically, the blind spots that attackers walk straight through.

Crown Jewels, Attacker Logic

Let's run a quick thought experiment. Suppose you're a financially motivated threat actor — ransomware operator, let's say. You've identified a mid-sized manufacturing company as a target. What's your objective? Maximize leverage. What creates maximum leverage for a manufacturer? Operational disruption. Encrypted OT systems, halted production lines, delayed shipments. That's your pressure point.

Now: does that manufacturer's threat model reflect this? Does it identify their OT network as a crown jewel? Does it map the kill chain from initial access through lateral movement to OT compromise? Does it identify the specific dependencies — the Active Directory trust relationships, the IT/OT network bridges, the vendor VPN accounts — that an attacker would need to exploit to reach that target?

In my experience, probably not. The OT environment is probably treated as an operational concern, not a security concern. The threat model probably focuses on customer data and financial records because those are what compliance frameworks explicitly call out. Meanwhile, the actual leverage point for the most likely attacker sits in a security blind spot.

This is the defender's fallacy in action: protecting what the framework says is sensitive instead of protecting what an adversary would actually go after.

Adversary-Centric Modeling: A Workshop Methodology

Flipping this around isn't complicated, but it does require getting uncomfortable. Here's a methodology your team can run as a working session:

Start with adversary profiles, not assets Before you touch your asset inventory, spend time defining your realistic threat actors. Not abstract categories like "nation-state" or "insider threat" — actual profiles. A financially motivated ransomware affiliate who buys initial access from a broker. A competitor engaging in corporate espionage. A hacktivist group targeting your industry. Make them specific. Give them motivations, capabilities, and constraints.

Define their objectives in their terms For each adversary profile, articulate what success looks like for them. Not "steal our data" — that's too vague. "Exfiltrate customer contracts to sell to a competitor." "Encrypt production systems to extract a $4 million ransom." "Deface our public-facing properties to embarrass us during a public controversy." Specific objectives drive specific attack paths.

Work the kill chain backward from the objective Starting from the attacker's end goal, map backward: what would they need to accomplish one step before that? And one step before that? Keep going until you reach initial access. This is your adversarial kill chain, and it's going to look very different from the kill chains in your existing runbooks because it's built around your specific environment and your specific adversary's goals.

Identify the dependencies At each stage of the kill chain, identify the specific assets, credentials, network paths, and trust relationships the attacker would need to exploit. These are your actual high-value targets — not necessarily the assets your compliance framework flagged, but the enablers of attacker success. An attacker doesn't care about your customer database in the abstract. They care about the service account that has read access to it, the VPN gateway that provides the network path to it, and the AD group that controls permissions to it.

Map your controls against the kill chain, not the asset list Now, and only now, overlay your existing controls. For each stage of the adversarial kill chain, ask: what detection or prevention capability do we have here? Where are the gaps? This is a dramatically more honest picture of your defensive posture than an asset-centric control gap analysis.

Why This Feels Wrong (And Why That's the Point)

This methodology makes security teams uncomfortable for a few reasons. It requires making assumptions about attacker behavior that feel speculative. It surfaces gaps that are politically inconvenient. And it sometimes concludes that the most important assets to protect aren't the ones the CISO has been telling the board about.

Good. That discomfort is signal. It means you're finding something real.

The alternative is to keep building threat models that look great in a compliance audit and fail spectacularly in an actual incident. We've seen this movie enough times to know how it ends. The attackers who hit you aren't reading your threat model — but they're operating on exactly the logic this methodology describes.

Meet them there, or meet them in your incident response war room. Your call.