How do I apply Threat Modeling in my organization?
No two organizations are the same. Even if we take two car manufacturing firms, the likelihood is, there will be nuances, varying processes, different sized teams, and their own culture and attitude towards security. Sure, there will be commonalities in standards they conform to, and a high regard for good quality products. But the way two companies may choose to use threat modeling, can be quite different.
What if you don’t have a Security Champions Program?
What if you’ve got an already stretched Development Team?
Maybe you just introduced some new processes or other technologies already.
Maybe you are working on a Beta product limiting overall resources.
What if you’re brand new to threat modeling, and have never even tried manual approaches?
Maybe you have a methodology you already want to adhere to.
Perhaps you don’t have a methodology at all.
Let’s stop there!
You may now be asking, where do I begin, should I threat model one application or an entire system made up of many components. And how can I get buy-in from other teams and senior management.
How to get started.
We want to help you get started, and so we have grabbed some of the best advice we can to help you to decide what is the ideal approach for your company.
Here is some advice from a fantastic article from Threat Modeling Connect, a free global threat modeling community:
When should I do a threat model?
There is also a lot of conversation about when is the right or best time to do a threat model. I think anytime is the best time if one hasn’t already been done. But having said that, if we think about our house, designing in our ideas at the beginning keeps cost vastly lowered as opposed to going back and saying that we really need a secret panic room which will require a teardown of one of the other existing rooms, rewiring for security and pulling plumbing for emergencies if it takes a while to be rescued! So clearly, earlier can reduce some of those costs. This can also reduce cost and potential impact on our developers, as well as maintain application integrity rather than bolting things on in the end.
While we want to do a threat model early on, we don’t want to limit our thinking to just planning. If anything changes – design or requirements, deployment environment, you will want to think about updating your existing threat model. Even for applications already in production, it isn’t too late to do a threat model.
Once we have identified threats, we will want to analyze and assess the risks as well as rank and prioritize them. There are different models to do this, such as STRIDE.1
Choosing the right threat modeling methodology
It can be daunting to know where to begin. This is in part due to the range of threat modeling methodologies that companies can make use of, as each is a unique approach and provides varied benefits. Among these, the most common are STRIDE, OCTAVE, TRIKE AND PASTA. We will unpack these methodologies and how to assess which is right for your organization. Take a look at our Methodologies Page.
Defining scope.
If you are stuck on how to define the scope of your threat modeling efforts, we highly recommend this article from Threat Modeling Connect, which has been written by IriusRisk's Senior Solution Architect. The write up covers:
- Introduction
- Delivering Value
- Assessing Risk
- Criticality Framework
- What are you Threat Modeling?
- Aligning Teams and Processes
- ‘Perfection is the enemy of progress’
Security Champions. The unsung heroes.
Because champions are a part of development teams or are co-located with or assigned to development teams, they can more readily ensure that security is integrated into every aspect of the development process organically and naturally, including threat modeling. One of the most important benefits of a champion vs a central team: the champion is an integral part of the development effort, not someone interposed from outside. Which means that threat modeling becomes a natural part of developing software, integral to how each development team designs and constructs software.
In order for security champions to successfully deliver threat modeling with their development teams, most champion programmes must typically include the following functions:
- Training
- Consistency and governance
- Documentation
- Archive or repository
We’ve gone a step further and created a Security Champions Guide to support you in finding your Security Superheros, and rolling out a Program with them. Get your copy.
Feeling ready to rollout?
Great! We’ve got you covered. Get your free copy of our ‘Rolling out a Threat Modeling Program’, to help guide you through the process of stakeholder buy-in, engaging across teams and more. If you’ve still got questions, don’t worry. We really can help. Get your Guide.
We even have a series of educational workshops, to help walk you through various stages of the threat modeling process. The topics for getting started are:
Whiteboarding Workshop from our partner, Toreon.
Diagramming Workshop from one of our Subject Matter Experts (SMEs) and Senior Solution Architects.
Automated Tools vs Manual Methods featuring Adam Shostack.
Rolling out threat modeling workshop from the IriusRisk team.
We’re here if you need us. But the fact you’re reading this blog shows that you’re ready to begin. Enjoy your journey.
References
