Threat Modeling: Bridging the Gap Between Developers and Security Architects

By Stephen de Vries, Co-Founder and CEO of IriusRisk

The application security world is known for friction between security and development teams. However, this tension can be eradicated through a development security strategy to bring developers and security architects together: threat modeling.

Protection before it’s too late 

Threat modeling is the act of conducting security analysis before a system is finalised, or even built, to detect weaknesses and vulnerabilities in the design of the system and to plan for mitigating insecure design. It’s looking left and right on the street before crossing, rather than checking for cars when you’re in the middle of the road – looking for threats is better done sooner rather than later.

Threat modeling can traditionally be done manually using a whiteboard, running as a workshop where security experts show the product team which practices to avoid or embrace to enhance security. It can also be done through integrated tools that run the process at scale, across teams and users. Automating threat modeling means developers will be notified of the security gaps during the development process, so changes can be made immediately, as opposed to retrospectively when the product is fully developed.

Threat modeling is an excellent engineering practice as it allows organisations to start security left, building a product that’s secure by design to make the process from ideation to launch much smoother. Developers aren’t always security experts, so by doing this they can learn to look for some of the weaknesses that regularly appear in the design phase, which has a positive impact on the security culture within an organisation.

Businesses that integrate threat modeling to their product development process have the potential to obtain better quality software and reduce costs as well: fixing finished software is expensive, especially if they have been in production for several years. Threat modeling is a way to identify technical debt that you may not want to take on, as well as a way to identify risk.

Business benefits: Collaboration and team learning

As benefits become more obvious, a growing number of companies are adopting threat modeling as a software development practice. It’s especially important for businesses that are growing fast, for whom building a secure product is a top priority: companies don’t want to lose the secure culture they spent so much time and effort creating.

Threat modeling as a practice also brings development and security teams together, enabling easy collaboration. This type of collaboration – as opposed to security teams acting as a bottleneck to release products after testing – has great advantages for cyber teams, but also for the product engineers themselves. Security teams can’t consistently look at every piece of code that’s been written, which is why empowering the development team is crucial to scale security practices. Threat modeling essentially allows companies on a fast-growth journey to grow their security practices as they do, ensuring their products remain secure by design.

Learning is a big aspect of collaboration through threat modeling and we see it very clearly in our clients. Developers are not expected to be security champions, but there are great benefits from the security team explaining retrospectively what worked and what didn’t. Once the mistake is understood, it can be avoided. Multiply this by dozens or even hundreds of common security mistakes in the development process, and a business can save massive amounts of time, money and resources by avoiding discovery of these changes at a later stage.

However, this is where we find a challenge: developers don’t always want to invest in doing threat modeling and be able to see the benefits. Developers aren’t always aware of the consequences of not integrating threat modeling into the development process, or the benefits of doing so. The solution is to make developer teams aware of the many benefits of thinking about security from the very beginning and starting security left.

What’s next for threat modeling?

Threat modeling is already part of the development process in many businesses and we’ll continue to see it grow and become a common industry practice. Beyond threat modeling for security issues and cyber attacks on the system, we will see it be applied to prevent conflict, trolling, bullying and even AI biases. In the future we will have a more integrated security process that will give development teams a chance to think about the implications of the decisions they are making for user’s security inside and outside the platform.

We will continue to see threat modeling develop to become as frictionless and easy to implement as possible, even as a company grows and the technology is used at scale across a product portfolio. More and more organisations are integrating threat modeling with their existing tool kit, which works around standard developer flows.

The current momentum around threat modeling is not just a trend. As more businesses adopt threat modeling as a practice and the security and financial benefits become more obvious, it will evolve from a ‘nice to have’ to a must in application and software development, bringing engineering and security teams closer together and helping businesses scale securely.

About the Author

Stephen de Vries is the Co-Founder and CEO of IriusRisk. He has a diverse technology background starting as a software developer, firewall engineer, penetration tester and software security consultant. Stephen has over 20 years’ experience in information security; the last six dedicated to building a threat modeling platform. He was a founding leader of the OWASP Java Project and contributor to OWASP ASVS and Testing projects, and contributor to the Threat Modeling Manifesto.

Stephen can be reached online at @stephendv and at www.iriusrisk.com