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.
Toreon Office | Grotehondstraat 44 1/1 - 2018 Antwerpen | +32 3 369 33 96
Threat Modeling Playbook – Part 3 Train your people to threat model
Threat Modeling Playbook - Part 3 Train your people to threat model
Unveiling a successful threat modeling strategy hinges on garnering support from stakeholders and strategic resource distribution. In this series of blogs, we unravel the complexities of involving key participants, addressing their concerns, and showcasing potential benefits through our Threat Modeling Playbook. We explore various approaches to acquiring threat modeling proficiency, ranging from a self-initiated start to engaging experts or implementing comprehensive training programs. Importantly, we stress the significance of showcasing a return on investment by aligning recommendations with tangible security enhancements.
Identify Stakeholders
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 treath model process.
Reference roles in threat modeling.
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.
Create a threat modeling specialist role
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 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:
Responsibilities:
- Act as a threat model point of contact for the squads and their security
- Responsible for leading threat model-related activities within the
- Act as a liaison between the stakeholders and squad
Tasks:
- Raise the overall security awareness and threat modeling knowledge within the
- Organizes and facilitates threat modeling workshops for the
- Assures that lessons learned of threat modeling is communicated towards the
- Develops and improves your organization threat modeling
- 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.
Required skills and experience:
- At least 2 years of experience in threat
- Expert knowledge of threat model techniques and
- Excellent communication and meeting moderation
- Proven to be a team
- Have an interest in security and willingness to learn and grow to meet the security needs of the
- 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.
Train your people
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 STRIDE5)
- 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 threat modeling culture
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.