In a world where AppSec is dominated by offensive or red-team security, not a whole lot of thought goes into designing software to be secure. Security features need to be implemented as early as possible in the SDLC in order for them to be effective.
With that in mind, you literally can't get earlier in a software dev cycle than the design phase. This is when the basic features, architecture, stack, and other foundational aspects of the software are decided. Teams that put a lot of forethought into the security of their apps start thinking about AppSec at this early stage, figuring out what sort of security controls they'll need to have in the final product.
This is where threat modeling comes in. Threat modeling is a framework to continuously perform threat assessments and organise your security program. At every stage of the SDLC, you'll need to create a threat model of your environment to determine:
At every stage of the dev cycle, right from design to deployment and beyond, threat modeling can help you better understand the meat and bones of your software. From creating user and abuser stories, to generating an SBOM, to prioritising your vulnerabilities, it's a lot of work, but it's entirely worth the effort in the long run.
But not a lot of teams 'get' threat modeling. Even if they understand why it's important, they're often held back by misconceptions and myths surrounding the process.
That's why we've prepared this list of the 5 biggest myths about threat modeling in the security industry. By being aware of these common pitfalls, you and your team can work towards building a comprehensive threat model for your products.
Get hands-on skills in Threat Modeling with these courses by AppSecEngineer.
This is pretty common among teams that don't really understand what threat modeling is. Too many professionals assume security is a perfectly simple process: you build a product, you run a few security tests on it to find the vulnerabilities, and have your developers fix them.
Unfortunately, the reality is far more complex, and you simply can't expect to find all the security flaws in your apps with a pentest or code review. While those are obviously crucial, they're a different part of the security process.
Think of threat modeling more like a blueprint for security. You're not exactly looking for vulnerabilities, you're establishing the kinds of potential threats and threat vectors your software could harbour at various stages of development. Even secure code and thorough pentests can't account for every kind of security weakness out there.
Are you planning to release just one build of your software and never update it again? If so, skip to the next one.
But let's be real, you're probably releasing new builds of your product every month, week, or even day. It's evolving rapidly, with new code, libraries, and dependencies being added all the time. With all of these additions, any security tests, threat models, etc. of the older builds will be obsolete.
Threat modeling, much like security testing, is a continuous and ongoing process. It's also important to note that you'll need to create threat models at various stages of the product's lifecycle in order to understand how your security posture changes over time.
This one seems to make sense at first glance. After all, your product is what users are interacting with. Shouldn't that be the only thing you need to look at?
That would be true...if your software was created in a vacuum. But any software you build will use third party databases/libraries, open source dependencies, cloud and/or container infrastructure, etc. All of these are potential threat vectors in your app.
You also need to take into account security once the build is in production, because a lot of unexpected issues can crop up in the deployment environment.
Is it good to have a security expert on the team? Of course. But is it absolutely critical? Not really.
Threat modeling, at its core, is really about getting to know your applications better. And who knows your software best? Your team, of course! It's actually easier (and cheaper!) to get your architects and developers involved in the threat modeling process.
They know their apps & understand where the systems can fail. By working backwards, they can help build an effective threat model.
You can actually teach architects and developers how to 'break' the app they're building. The best way to do that is through hands-on training: show them how security works in a real-world scenario.
AppSecEngineer has a massive library of courses for every member of the product team. Train your architects in advanced AppSec, or get your developers skills in secure coding.
Even if you're reading this article after having built and deployed your app, it's not too late to start threat modeling. Whatever you've done to secure your app, production always brings unanticipated challenges that you have to be prepared for.
Your system will change over time as new builds are tested and released. Consequently, so will the threat profile of your environment. There's no such thing as a static security posture: tech is evolving faster every day, and nothing is sacred anymore.
Threat modeling will benefit any app that you're still actively working on, because it will get you to create detailed documentation of your system on a granular level.
Learn how to perform threat modeling in a real-world environment with AppSecEngineer's hands-on courses. Try them out today.
Aneesh Bhargav is the Head of Content Strategy at AppSecEngineer. He has experience in creating long-form written content, copywriting, producing Youtube videos and promotional content. Aneesh has experience working in Application Security industry both as a writer and a marketer, and has hosted booths at globally recognized conferences like Black Hat. He has also assisted the lead trainer at a sold-out DevSecOps training at Black Hat. An avid reader and learner, Aneesh spends much of his time learning not just about the security industry, but the global economy, which directly informs his content strategy at AppSecEngineer. When he's not creating AppSec-related content, he's probably playing video games.