Driving adoption for your threat modeling program

In a recent webinar, it was discussed what you need to drive adoption for your threat modeling program. Several topics were discussed including process integrations and how to incorporate threat modeling as an activity in existing workflows or patterns of work. We discussed how Security Champions can really support adoption, as well as what technology can support you. 

You can see the webinar in full below, or read a roundup of the key takeaways in this blog.

‍

‍

What do we need and how do we drive adoption?

“Threat modeling adoption can be driven by needs from compliance, regulatory forces and simply the desire to make things more secure. You need time to drive adoption. It will take time, don’t expect everyone to be modeling overnight.”

‍

You need to accept early on that this will take time, it isn’t an overnight process, but will evolve with people over time. People naturally get involved at different paces too. Set expectations and plan in your time to evolve and grow the program. No matter your organization size, remember this is a time-consuming and an evolving process when done correctly. 

‍

There are several compliance and standards that are coming up or are already approaching that consider threat modeling. Such as the OWASP Top 10 from 2021 which has Insecure Design as number four, and NIST SP 800-53 which calls out threat modeling. All of this gives us more reason to initiate threat modeling programs and to encourage engagement across teams to develop products which are secure by design.

‍

Who do we need to drive adoption?

“Driving threat modeling is like driving any other program or new process in your organization. It’s not different.”

‍

To help with encouraging adoption, show the value right away to demonstrate its benefits and increase understanding. It can help to start small to gather support or to take a grassroots approach. It is important to go forward with this as you would any other program! Think of who is best suited to model first and start there. Example roles may include: 

1. Developers
2. Solution engineers
3. Architects
4. Security teams
5. App teams

‍

Process Integrations and maximizing existing efforts 

“Many times, we forget that threat modeling is an everyday process and we all do it. There are opportunities where we can bring threat modeling into existing processes to not add additional burden to the team. The last thing we want to do is have a team tell us “It’s just another thing Security wants us to do.”

‍

Here are some tips on how to bring threat modeling in to compliment existing activities, as it is important for those you want to be involved to know this is not extra work. It will go alongside existing efforts and processes:

‍

• Understand your organization product development lifecycles
• Find the right place for threat modeling to exist
• Make sure people understand and see value where it applies to them
• Keep entry simple 

‍

If you stick to the above, you are more likely to achieve a natural fit into what these teams are already doing and thinking about. Which makes introducing threat modeling much easier and feels more accessible. Finally, it demonstrates that you have considered the path of least resistance for these teams, and have understood at what points threat modeling can coexist in their processes. 

‍

“Finding the right place with the right teams will go a long way. Solution Engineers, Architects, Developers are already creating diagrams, user and data flows for products they are creating.”

Meet a team where they are and use what they have already been working on. Developers are already building features and user stories, or perhaps they already drew their own diagram manually or in a drawing tool. All of this allows you to leverage what they are doing already. Some organizations have requirements for design documents. These can be used too for inputs to build models. BE sure to be looking at what already occurs that you can augment further. 

‍

Leverage Security Champions 

“Security Champions are great advocates and partners, and can become some of the greatest threat modelers within your organization. If you haven’t built a champions program you should consider doing so.”

‍

What can the Champions do?

• Provide the extra resource to make models within your product development community - you can't be everywhere all at once! 
• Train others on threat modeling - helps to drive that adoption in process and share experience to keep the program growing and evolving 
• Partner with Security and bridge the gap - not everyone is a security expert, but that doesn’t mean other teams don’t care about security, this can help plug the gaps in knowledge 
• Reduce friction by being the partner through trust - demonstrates threat modeling adds value and advocates for the program 

‍

Here are some great resources for creating Security Champions:

https://owasp.org/www-project-security-champions-guidebook/ 

https://securitychampionsuccessguide.org/ 

‍

Tooling 

“Automated tooling can provide organizations platforms that everyone can use that most are already familiar with.”

‍

Learning the threat model manually first can be hugely beneficial to understand the process fully, but tooling can assist depending on your goals. It can scale and augment the efforts that have already been happening. It is crucial to understand threat modeling as an activity first before automating with tooling - this helps drive adoption overall.

‍

Know what you need before you make your choices. Here are some considerations: 

‍

1. Diagramming tools – many architects and Solution engineers already build their diagrams using a variety of tools. Leverage that work to build your models
2. Threat Modeling tools - these have diagramming capability so it can serve two purposes making the entry to threat modeling even easier. It can assist at a larger scale
3. Centralization and standardization - this helps build efficiency, as well as consistency in training others 
4. Automation of threats and countermeasure can increase speed, standardize quality but has its limits
5. Specialized tooling can help those with less security experience with the learning curve

‍

Key takeaways

For success in driving adoption, you can remember the following points - in particular the time it takes to create a program and grow it: 

1. Time is needed. This is not overnight. Adoption takes time
2. Show your value immediately to drive adoption 
3. Grassroots growth
4. Target existing teams to model based on their roles (Solution Engineers, Architects, etc.)
5. Make the entry into threat modeling as easy as possible
6. Don’t add on, use existing processes. No reason to create additional friction or burdens
7. Leverage Security Champions if you have them 
8. Use existing technology or consider threat model specific tooling - where relevant to do so 

‍