Delivered at ISACA Silicon Valley – January 16, 2025
On January 16, I had the honor of speaking at ISACA Silicon Valley on a topic that’s close to my heart: Threat Modeling—Building Resilient Systems with Security by Design. In a world where systems are becoming more interconnected and attackers more sophisticated, it’s not enough to bolt on security at the end. We need to start designing with security in mind from day one.
A Real-World Wake-Up Call
I kicked off my talk by sharing a breach story involving a well-known startup in the biotech space (I’ll keep the name anonymous). Their security team was focused on blocking direct attacks—but overlooked a more subtle yet equally damaging threat: credential stuffing.
Because they didn’t adequately rate-limit access to their “relatives” feature, attackers were able to scrape sensitive data by simply reusing breached credentials from other platforms. It’s a classic case of threat modeling gaps—a failure to ask “what could go wrong?” beyond the obvious.
This incident reinforced why threat modeling must be comprehensive, continuously updated, and part of the product lifecycle—not just a one-time checklist.
What is Threat Modeling?
At its core, threat modeling is a structured approach to identifying, assessing, and mitigating potential risks in a system before they can be exploited. But it’s not just for security engineers—anyone involved in building or managing systems should understand the basics.
I like to use a simple analogy: when we go out in cold weather, we’re instinctively doing threat modeling.
- Asset = our body
- Threat = cold weather
- Vulnerability = our body’s inability to regulate temperature
- Mitigation = wearing a jacket
- Risk = chance of getting sick
We do it naturally in daily life. Now we just need to bring that same mindset to software design.
The Four Essential Questions
Effective threat modeling can often be boiled down to four critical questions:
- What are we building/protecting?
- What can go wrong?
- What are we going to do about it?
- Did we address everything effectively?
These questions can guide us through everything from whiteboarding a new architecture to reviewing changes in a legacy system.
My Approach: Methodologies & Frameworks
I use a mix of methodologies depending on the system and team I’m working with. Here are a few that I find most helpful:
STRIDE
Developed by Microsoft, this framework helps categorize threats:
- Spoofing
- Tampering
- Repudiation
- Information Disclosure
- Denial of Service
- Elevation of Privilege
DREAD
This model helps prioritize threats based on: Damage, Reproducibility, Exploitability, Affected Users, and Discoverability.
PASTA
The Process for Attack Simulation and Threat Analysis goes deeper into attacker perspectives and system-specific simulations.
Tools I Use
You don’t need fancy tools to start threat modeling. Some of the ones I regularly use include:
- OWASP Threat Dragon – Great for visuals and open-source teams
- Microsoft Threat Modeling Tool – Integrates well with enterprise environments
- Whiteboarding – Still the fastest way to align cross-functional teams
Common Challenges I See
Threat modeling isn’t always smooth sailing. Some of the common obstacles I run into are:
- Lack of data flow diagrams or system documentation
- Misalignment between engineering and security teams
- Inconsistent buy-in from leadership
- Failing to revisit models after architecture changes
Best Practices That Work for Me
To overcome these challenges, I follow a few best practices:
- Start small and iterate often
- Embed security into existing workflows like Agile and CI/CD
- Foster collaboration across teams—not just engineers, but product managers and QA too
- Treat your threat model as a living document, not a static PDF
Threat Modeling in the Age of AI
One area I’m increasingly focused on is how threat modeling must evolve for AI-driven and cloud-native systems. With dynamic workloads, opaque ML models, and sprawling supply chains, the old assumptions don’t always hold.
We now need to consider:
- Model inversion and prompt injection attacks in AI
- API and cloud permission abuse
- Open-source dependency poisoning in CI/CD pipelines
As we build smarter systems, our threat models must also get smarter—and that includes factoring in regulatory compliance like HIPAA, GDPR, and NIST AI RMF.
Key Takeaways
If there’s one thing I wanted the ISACA audience to walk away with, it’s this:
Threat modeling isn’t a one-time activity. It’s a mindset, a process, and a collaboration.
It allows us to:
- Catch risks early
- Reduce cost and rework
- Align with compliance
- Build trust into our systems from the ground up
If you want to explore how to bring threat modeling into your teams or products, feel free to connect. Whether you’re just getting started or scaling your security program, I’m always happy to chat and share ideas.
Until next time—stay curious and stay secure.
– Krutik
Presentation for Download –