Skip to content

Latest commit

 

History

History
76 lines (48 loc) · 11.3 KB

2. Get stakeholder buy-in.md

File metadata and controls

76 lines (48 loc) · 11.3 KB

2. Get stakeholder buy-in

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:

  1. Time of the people involved in creating the threat model
  2. Threat modeling expertise (especially if you are just starting out)
  3. 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.

2.1 Involve people and allocate time

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
  • Need to allocate time of valuable team members for the threat modeling exercise, which might delay other activities
  • Wants to see return on investment but might not see the added value of a threat model (especially if threat modeling is new for your organization).
  • Might be hesitant to have all potential threats made explicit, i.e., “if I know about it, I will have to do something about it”.
Application owner
  • Might already have indications of existing threats and might not want for those threats to become explicitly documented.
  • Faced with a strict roadmap, hesitant to have someone add a potentially long list of mitigations to that roadmap.
  • Will need to invest some time to assist in the threat modeling workshops.
Architect
  • Might feel that the threat model is like an exam: An external team is reviewing the architecture and will assign a grade.
  • Will need to invest some time to assist in the threat modeling workshops.
Developer
  • Might feel that the threat model is like a code review and that he or she will be graded on their secure coding skills
  • Might be hesitant that the threat model will highlight that the developer does not have some specific security skills
  • Will need to invest some time to assist in the threat modeling workshops.
Security and/or DevOps engineer
  • Might be hesitant that the threat model is like a review and will highlight gaps in the current security.
  • Will need to invest some time to assist in the threat modeling workshops.
Project manager
  • Already faced with several (probably very strict) deadlines, hesitant to add more work to the project roadmap.
  • Hesitant that threat modeling exercise and results will derail the project roadmap completel.

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
  • Demonstrate that they are taking a proactive stance on security.
  • Useful as an argument for e.g. GDPR compliance and privacy and security by design..
  • Might be hesitant to have all potential threats made explicit, i.e., “if I know about it, I will have to do something about it”.
  • Useful part of an information security management system (ISMS), e.g., for ISO 27001.
  • Having an explicit list of risks enables risk-based security management: Management can show that they are investing their security budget to address the highest risks first.
Application owner
  • Having an explicit list of risks and suggested mitigations enables risk-based security management: The application owner can assign priorities based on evidence.
  • The threat model can serve as a tool to request additional security budget.
Architect
  • A threat model is not a review, but should lead to constructive advice on improving the architecture.
  • Might lead to reusable security patterns that can be instantiated in other parts of the architecture, or for other application domains.
Developer
  • A threat model is not a review, but should serve as constructive security advice.
  • Might be used as a driver to request additional security budget (for, e.g., a security specific training).
Security and/or DevOps engineer
  • A threat model is not a review, but should serve as constructive security advice.
  • Might be used as a driver to request additional security budget (for, e.g., a security specific training).
Project manager
  • A threat model is an ideal exercise to get all stakeholders on the same page, and ensure that there is a coherent view on security.
  • A threat model can serve as a tool to request additional security budget.

2.2 Inject threat modeling expertise

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.

The do-it-yourself approach

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.

Hiring an 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.

Threat modeling training

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.

2.3 Threat modeling return on investment

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 >>