A threat model can only achieve its goal, i.e., to reduce risk and increase security, if there is sufficient buy-in of all the stakeholders involved. Specifically, in order to implement the playbook, you will need the following resources:
- Time of the people involved in creating the threat model
- Threat modeling expertise (especially if you are just starting out)
- Time, resources, and authority to address the resulting threats.
As these are important to get management buy-in and commitment to manage your risks with threat modeling. Let us look at these in turn.
It is easy to underestimate the number of people that are directly or indirectly involved in creating a threat model, but you will need to address their concerns in order to get them to collaborate. In order to do that, you first need to understand what it will cost them, and what they can potentially see as obstacles to investing time in the threat model. Note that we do not mention the threat modeling champion in this listing, as their motivation to do threat modeling is assumed.
Business stakeholder | Cost, obstacles for the stakeholder |
---|---|
Management |
|
Application owner |
|
Architect |
|
Developer |
|
Security and/or DevOps engineer |
|
Project manager |
|
In order to defuse some of these arguments and convince the stakeholders that threat modeling is also in their best interest, it is necessary to first listen to their concerns and acknowledge them.
Business stakeholder | Potential gains |
---|---|
Management |
|
Application owner |
|
Architect |
|
Developer |
|
Security and/or DevOps engineer |
|
Project manager |
|
A second ingredient you need to acquire in order to make threat modeling a success, is the relevant expertise. In Chapter 2, we mentioned the importance of finding a threat modeling specialist and to train your people. In order to obtain the relevant expertise, there are three approaches you can take. Let’s look at these in turn.
In organizations that are just starting with dipping their toes into the proverbial threat modeling pond, one option is to start acquiring threat modeling expertise by reading books and accessing some freely available online resources. This is especially the case where there are no extensive security budgets, or if the current need is low.
The advantages of this approach are that it can start right away and does not take a lot of preparation or budgeting. The downside, however, is that threat modeling can be tricky when you are just starting out, especially for people without prior security expertise. In that case, a failed first ad-hoc threat modeling attempt might undermine the goodwill of the rest of the stakeholders to invest further in setting up a threat modeling approach. This approach also does not scale for larger organizations.
Therefore, the recommendation is to only start with and ad-hoc approach if the people involved have some prior security exposure, and there is a willingness to experiment (and possibly fail). For other cases, it might be better to start off by hiring an external expert.
A good, fairly lightweight way to start adopting a threat modeling approach, is to have a threat model done by an expert, in close collaboration with your team. In that way, the team gets to see hands-on how threat modeling is performed, and there is a larger guarantee that the first threat model will be a success.
The advantages of this approach are that it is significantly lower risk than the ad-hoc approach and can create a lot of goodwill and willingness to adopt a broader threat modeling approach in a fairly short time. Furthermore, it scales reasonably well, as the same expert can be hired to perform follow-up threat models for other teams. The downsides of this approach are that it does require a larger budget than the ad-hoc approach, and it does not automatically scale to large organizations with dozens or hundreds of applications in their portfolio.
Therefore, hiring an expert should be considered by organizations that are just starting out with threat modeling and want to get some experience, or small organizations with only a few applications in their portfolio. For larger organizations that want to systematically adopt threat modeling throughout various teams, external threat modeling training programs are more suitable.
With a threat modeling training program, a trainer is hired to train an initial core team of people to threat model. The trainees should be highly motivated people that can subsequently take up the role of threat modeling specialists (or even evangelists) within that organization.
The advantages of this approach are that it scales extremely well and has the highest chance for success that your organization is able to fully adopt and internalize threat modeling. The downsides, however, is that it takes a while before results are produced, as the training should still be followed by actually creating initial threat models. It also requires a larger up-front investment, which might be a hurdle for organizations in which threat modeling has not proven its value yet.
Lastly, an extremely important aspect of setting up a sustainable threat modeling initiative within an organization, is to demonstrate return on investment (ROI) and get management commitment on this. A threat modeling approach is only able to show ROI if it results in a demonstrable improvement of the security of that organization, or its products.
Some things that need to be considered, are:
- To lead to security improvements, a threat modeling approach should result in recommendations that are clearly documented to the relevant stakeholders. A document on a file share which no one knows exists, will never lead to ROI.
- To lead to change, the recommendations of a threat model should be realistic and implementable. If the recommendations exceed the timing, budget, expertise, or other constraints of a project, they will not effect change and not lead to ROI. It is crucial that the threat modeler has a good understanding of the project constraints before making recommendations!
- To show that the change is effective with threat modeling, mitigations and recommendations made in a threat model should be clearly linked to development artefacts such as new user stories, bug fixes, JIRA tickets, and so on. If you can measure the number of projects, user stories, or tickets that are impacted by threat modeling, you can more easily track the level of adoption of threat modeling throughout your organization, and its effect. That, in turn, makes it easier to demonstrate ROI.
Finally, to show that the change is positive, the changes effected by threat modeling should be linked to the number of security bugs or incidents that are reported after go-live of the system that was threat modeled. An important consideration is to distinguish between the number of security issues that are reported as a direct result of threat modeling (this number should be high!) and the number of security issues that are reported after the fact (this number should go down). By making it clear that threat modeling is responsible for detecting and fixing more security issues proactively, you can clearly show ROI.
<< Previous page | Main page | Next page >> |
---|