Latest / Cybersecurity Business with Fexingo: Security Companies, Breaches, and Enterprise Defense / Why Cybersecurity Teams Are Using Threat Modeling to Fix Security Debt
Transcript
- Lucas: If you've been in enterprise security for more than about six months, you know the feeling: your team has a backlog of unpatched vulnerabilities, outdated configurations, and half-implemented controls that just keep piling up. There's a term for that now — security debt — and it's arguably the biggest unaddressed risk in most organizations. Luna: Security debt. I've heard that compared to technical debt in software engineering. Is it really that analogous? Lucas: Almost exactly. Just like code debt, security debt accumulates when teams take shortcuts — maybe they skip a review to hit a launch deadline, or they deploy a cloud resource with default permissions because it's faster. Each individual shortcut seems small, but compounded over months and years, you end up with a massive exposure surface. Luna: And the tricky part is that unlike a software bug that crashes the app, security debt doesn't give you a clear signal until it's exploited. So how do you even know where to start? Lucas: That's exactly where threat modeling comes in. Instead of reacting to the latest vulnerability scan or breach headline, threat modeling is a structured process to identify, document, and prioritize threats before they become incidents. It flips the approach from reactive patching to proactive design analysis. Luna: So it's not just a fancy way of saying 'think about risks' — there are actual frameworks and diagrams involved? Lucas: Absolutely. There are a few well-established methodologies. The most famous is STRIDE, which Microsoft created — it stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. You apply each category to every component in a system diagram, and you identify where controls are missing. Luna: And that system diagram — you're talking about data flow diagrams, right? Mapping how data moves between users, apps, and databases? Lucas: Exactly. You draw the architecture, label trust boundaries, mark where data crosses from one zone to another. Then you walk through each threat category and ask, 'Could an attacker spoof identity here? Could they tamper with this data in transit?' It's methodical, almost like a checklist, but it surfaces things vulnerability scanners miss because it's looking at the design, not just the code. Luna: I know a lot of teams that do threat modeling once a year at best, and usually just for compliance. But you're saying it should be more frequent? Lucas: That's the old model. Forward-looking security teams are embedding threat modeling into their development lifecycle — every new feature, every major infrastructure change gets a light-weight threat model. Some call it 'threat modeling as code,' where the models are version-controlled and updated as the system evolves. Luna: But that sounds like it would slow down development. Engineers already complain about security reviews. Lucas: It can, if you do it wrong. But the key insight is that you don't need a full STRIDE analysis for every commit. You can tier the effort: critical systems get a deep dive, low-risk internal tools might only need a quick checklist. And once the initial model exists, updates are incremental. Luna: So what's a concrete example where this paid off? I'm thinking of that big bank breach we talked about a few months back — would threat modeling have prevented it? Lucas: Great question. Actually, there's a recent case from a regional bank in the Midwest — it wasn't headline news, but it's instructive. They had an online account aggregation feature that pulled data from external financial APIs. The team built it quickly, and they never did a structured threat model. Luna: Let me guess — an API key stored in a config file that got checked into a public repo? Lucas: Close. Worse, actually. The integration used an outdated OAuth flow that didn't validate redirect URIs. An attacker could trick the system into leaking session tokens. A threat model would have flagged that under 'Spoofing' and 'Information Disclosure' in about fifteen minutes. Instead, it took a penetration test eight months later to find it, and by then, customer data had been exposed. Luna: And the cost of that breach? Lucas: The bank spent roughly $12 million on remediation, legal fees, and regulatory fines. Their entire security budget for the year was $4 million. The threat modeling session would have cost maybe $10,000 in engineering time. Luna: That's a brutal ROI comparison. But I think a lot of CISOs would say, 'We know threat modeling is valuable, but we just don't have the headcount.' How do you scale it? Lucas: You don't need a dedicated threat modeling team. You need to train your architects and senior developers on the basics — a two-day workshop can get them proficient enough to run a simple model. Then you have a central security team review and validate the models. Luna: Is there a tooling ecosystem that helps? I know there are some automated threat modeling tools that can generate diagrams from infrastructure as code files. Lucas: Yes, and that's a growing space. Tools like ThreatModeler, IriusRisk, and OWASP Threat Dragon let teams create models collaboratively. Some integrate with Jira and Azure DevOps so that threats become tickets automatically. But the tool is only as good as the thinking behind it — if you just check boxes, you'll miss the novel attack paths. Luna: Speaking of novel attack paths, one framework I've been hearing about is PASTA — Process for Attack Simulation and Threat Analysis. It's more risk-focused than STRIDE, right? Lucas: PASTA is a seven-stage methodology that aligns threat modeling with business impact. It starts with defining objectives — 'What are we protecting and why?' — then maps out the attack surface, analyzes threats, and finally does vulnerability and impact analysis. It's heavier than STRIDE, but for high-value applications like payment processing or healthcare data, it's worth the effort. Luna: So if a CISO is just starting with threat modeling, which framework would you recommend they adopt first? Lucas: Start with STRIDE. It's well-documented, there are tons of templates, and it's easy to teach. Run it on one critical application end to end as a pilot. Document what you find, measure the reduction in risk, and use that success story to sell the process to the rest of the organization. Luna: But measuring risk reduction is its own challenge. How do you quantify that a threat model made you safer? Lucas: You can't prove a negative — you can't say 'we prevented a breach.' But you can track metrics: number of threats identified, severity distribution, time from threat identification to mitigation. And over time, you correlate that with a decrease in real incidents or pentest findings in those same systems. Luna: Some organizations are tying threat modeling to their cyber insurance applications now too, right? Showing underwriters that you have a structured risk identification process can lower premiums. Lucas: Exactly. I've seen carriers start to ask about threat modeling maturity in their applications. It's becoming a differentiator. If you can demonstrate that you're proactively identifying design flaws, you're a better risk. Luna: Alright, so let's say I'm sold. I want to introduce threat modeling at my company. Where do I start practically next week? Lucas: Pick one application — ideally something that's internet-facing and processes sensitive data. Gather the architecture diagrams. Invite the developer, the architect, and a security person. Spend two hours walking through STRIDE categories. That's it. The first model won't be perfect, but you'll find issues you never knew existed. Luna: And then you start chipping away at that security debt, one threat at a time. Lucas: Exactly. It's not a silver bullet, but it's the most systematic way I know to stop digging the hole deeper. Luna: Honestly, if this conversation was worth a coffee to you — and it's helping you think differently about your security program — that's the link: buy me a coffee dot com slash fexingo. Lucas: And it's what keeps this show ad-free and focused on the stuff that actually matters for people building and running security programs. Luna: So back to the practical side — one thing I want to dig into is how threat modeling fits in with agile development. If you're doing two-week sprints, when do you find time for a threat model? Lucas: You don't do a full model sprint-by-sprint. Instead, you build a threat model during the design phase of an epic — the big feature that spans multiple sprints. Then during each sprint, the team reviews the relevant parts of the model to make sure the implementation doesn't introduce new threats. Luna: And what about existing security debt? The older systems that were never modeled? Lucas: That's the hard part. You can't model everything at once. Prioritize based on risk: the applications that handle the most sensitive data, the ones that are most exposed to the internet, the ones with the highest number of past incidents. Start there and work down. Luna: So it's basically paying down the highest-interest security debt first. Lucas: Exactly. And just like financial debt, the longer you ignore it, the more it compounds. Threat modeling is the tool that helps you see the interest rate on each piece of debt. Luna: That's a great way to frame it. Next episode, I want to talk about how some organizations are using AI to automate parts of the threat modeling process — but that's a whole other conversation. Lucas: It is. And I think the AI piece is still early, but promising. For now, the basics work. Start with a diagram, a framework, and a two-hour meeting. You'll be surprised what you find.