Before starting with the definition of an actual threat modeling process, care must be taken that the relevant people are identified, trained, and adopt the right mindset. In Chapter 4.1, we talk about identifying the relevant stakeholders for threat modeling. In Chapter 4.2, we focus on the creation of a threat model specialist role, who will serve as the focal point for threat model activities. In Chapter 4.3, we highlight the importance of appropriate training to support threat modeling. In Chapter 4.4, we end by talking on how to create and nurture a positive threat modeling culture in which threat modeling can flourish.
One of the strengths of threat modeling is that it brings together various stakeholders involved in the security of an IT system or project and ensures that they are aligned. Threat modeling helps this group of people to share a common understanding of the business value of the system or project. At the same time, it also helps those people share a view on the main threats and what mitigations can be put in place to address them.
But who are those stakeholders? Involve too few, and the threat modeling exercise loses its main benefit as it does not create a shared understanding of business value and threats. Involve too many, and the exercise runs the risk of devolving into a costly set of meetings. You know the situation: most of the participants are too busy checking their e-mail and, in the end, nothing gets decided. In our experience, threat modeling is best performed within a core team of limited size. Ideally, at least the following roles are represented:
| Role | Motivation |
|---|---|
| Business stakeholder | Ensure that business value and potential business impact is clear. |
| Architect | Provide a high-level overview of the application ecosystem and the underlying rationale. |
| Developer | Provide details on used libraries, frameworks, and coding guidelines. |
| Security and/or DevOps engineer | Provide details on existing security and/or infrastructure configuration. |
| Project manager | Validate proposed mitigations in terms of timing and budget. |
| Threat model specialist | Ensure proper execution of the threat model process. |
This team composition can be very powerful, as it contains stakeholders with complementary views. First, it contains people with in-depth technical know-how, such as developers, security, and DevOps engineers. Second, it contains people that have a broader view, either technical such as architects, or non-technical such as business stakeholders and project managers. This is a proven recipe for productive discussions, as one might imagine. If managed well, this protects the threat modeling exercise from threats such as not representing reality, underestimating certain technical risks, or missing the point by failing to appropriately frame the uncovered risks with respect to their business impact.
Of course, there is a drawback too. These people are usually extremely busy, and their time is a valuable resource. It is therefore not ideal to simply invite everyone for all threat modeling meetings. You must prepare the threat modeling workshops for them to be efficient and optimize the time spend by the participants, which we will revisit in Chapter 5 when we talk about processes. An important role who will achieve this is the threat model specialist. The specialist role will be explained next.
The primary purpose of a threat model specialist is to help incorporate threat model practices and a strong security culture into all aspects of an organization’s development processes. Threat model specialists are typically permanent staff that act more like floating specialists supporting the squads 4 as needed. They provide threat modeling advice, support squads, and occasionally drop in for a sprint or two.
An example “job description” for a threat modeling specialist could look like this:
- Act as a threat model point of contact for the squads and their security champions.
- Responsible for leading threat model-related activities within the squad.
- Act as a liaison between the stakeholders and squad members.
- Raise the overall security awareness and threat modeling knowledge within the squads.
- Organizes and facilitates threat modeling workshops for the squads.
- Assures that lessons learned of threat modeling is communicated towards the squads.
- Develops and improves your organization threat modeling methodology.
- Selects, introduces, and maintains threat modeling tooling to support and automate your organization threat modeling practice.
- Lead efforts in identification and remediation of weaknesses and vulnerabilities in the product design and development processes of the squads.
- Develop security-focused user stories for squads using agile development strategies and designing unit and integration tests together with the squad’s test engineer.
- Organize threat modeling education and training, advocate for security-focused culture changes, and recruit, mentor, and train additional threat model specialists and squad champions.
- At least 2 years of experience in threat modeling.
- Expert knowledge of threat model techniques and tools.
- Excellent communication and meeting moderation skills.
- Proven to be a team player.
- Have an interest in security and willingness to learn and grow to meet the security needs of the squads.
- Knowledge of security concepts, tools, and practices in development (automated security testing, dependency checking) are a plus.
Once you have this role figured out for your organization, you second step is to find or hire candidate threat modeling specialists within your organization to help you start and improve your threat modeling practices.
As mentioned earlier, it is important to train the involved people on how to do practical threat modeling. Before anything else, the people in your threat modeling sessions need to understand the why and how of threat modeling.
Start to gradually involve people from your different DevOps teams in lunch & learn sessions that explain and demonstrate what threat modeling is all about.
Once people have a basic understanding, start with a role-based training program. People in the roles of architects, security champions, testing engineers and security specialists should follow thorough threat modeling training that covers at least the following topics:
- Threat modeling as part of a secure development lifecycle
- The threat modeling stages and process
- Threat modeling methodologies (covering at least STRIDE 5 )
- Diagramming
- Threat identification
- Threat mitigation
- Risk management concepts
- Hands-on exercises, preferably based on your organization systems
Ideally you include organization specific playbooks and templates, examples, and lessons learned. Also make sure to adapt the training to your technology stack and project governance. Assure that the learning objectives are clear and met, that you focus on outcome, techniques and that you perform hands-on exercises in group to mimic real live threat modeling workshops.
Other people will be involved in threat modeling tangentially or are stakeholders or recipients of your threat modeling actions. Examples are developers, DevOps engineers, business analysts or product owners. For these roles you provide a high-level introduction training on threat modeling.
Create a positive culture around threat modeling to get the most out of threat modeling. Threat modeling is not an audit, but an activity to align the involved team on a shared vision on the security of the products that they are working on.
When you start threat modeling as a practice, you should make it clear that a no-blame culture is the right starting point to do threat modeling. People make mistakes. During the workshops you will discover issues and design flaws. Take these as learning points to do it better next time, do not point fingers or blame the involved people for making errors. Look for root causes and learn from past mistakes to improve your product and DevOps processes.
Likewise, when you do threat modeling, leave your ego at the door. Make sure you focus on the bigger picture of the threat model and not just your own vision and understanding. When doing threat modeling workshops, apply active listening and be open for the position of everyone involved. This means that you actively involve all the participants in your threat modeling session. By doing so, participants will get the full picture of your threat model which will result in support from your team. It also requires mutual respect, inclusivity, and the establishment of a space that is safe enough for the participants to speak their minds.
As threat modeling is an activity where people with different backgrounds and skill levels will participate, you spend time to gain a good common understanding of the system in scope, including business and technical aspects. Make sure that everyone understands the terminology and concepts, if needed provide some reading materials before the workshops.
Creating a threat model is fun. But do not forget the objective of your activity: aligning your stakeholders on the security vision you created, together with the people that were involved in the workshops. Make sure not to simply “toss your threat model over the cubicle wall” but take your time to go and explain it to the affected people or groups, ideally in-person. Translate your threat model outcome to the target audience. E.g. for senior management be prepared to map your technical findings to business risks and the involved budget impacts. Another example is to provide input for security testing towards your testing engineers in a way that they understand the technical implications of the discovered flaws in your threat model.
Threat modeling is all about breaking your “tunnel vision” on the security aspects of your system. Tunnel vision originates from looking too far in the future, only looking at what is familiar in terms of security, and not being aware of external threats to your system. By involving other people and creating an open culture around threat modeling you will be able to break free from this tunnel vision trap and discover more and other security issues than you ever imagined.
| << Previous page | Main page | Next page >> |
|---|