I want to Threat Model, but I don't know where to start.

  • 29 August 2023
  • 6 replies
  • 203 views
chrdal75
Rank
Userlevel 2

One question I am often asked by the many organizations I work with is where do I begin ? How do I get started Threat Modeling? What do I Threat Model, and what do I need to be concerned with? As with everything you do, you must be willing to take the first step. Taking on a new challenge is often very intimidating and the fear of failure is real. 

My advice is to start with the smallest, most simple application or workflow you have. Keep your model small and specific to a singular process. 

If you identify 1 new threat today, then you have accomplished something significant. 

I also encourage people to not take this task on by themselves. Threat Modeling is a collaborative process. No one know everything, so leverage the knowledge of your teams.  And because you have kept your model compartmentalised, your collaborators will not feel overwhelmed. 

Finally, I highly encourage people to move the process of Threat Modeling left. By this I mean, start the process very early in the software development process. It is much easier to change the design of an application or workflow during the early stages, vs. an application that is ready to go into production. 

I am curious as to what advise others may have on this topic. 

6 replies

Ajay
Rank
Userlevel 2

Agree. Threat modelling, an activity which can go by other names such as,  Architectural Risk Analysis, Threat Analysis, Risk Modeling etc is a collaborative activity and shifting left allows you to “bake in” security right from the start.

Michael Bernhardt
Rank
Userlevel 4
Badge +1

There has been a vast amount of information out there on the methodology of Threat Modeling. Yet, I have to agree (and remember myself being in the position back then) that it is hard to see how to get it started. A few recommendation based on my experience:

  • Get familiar with the methodology: Based on the pre-work of the TM-inventors, there are a multitude of formal methods available. Get familiar with Attack Trees, PASTA, STRIDE and alike. I particular recommend to know STRIDE - it is initially a bit overwhelming but will give you the strategic advantage to drive the discussion with the teams in a structured way. Over the time it becomes more natural and more lean. For understanding where the concepts are coming from, I recommend to follow some of the historic discussions by Adam, Larry Osterman, David LeBlanc and others, e.g. The Trouble with Threat Modeling | Microsoft Security Blog + additional reading about Bruce Schneier’s attack tree concept and how he initially applied it. They are a bit controversal at time but really help to understand how the methodologies that we use today have been build up over time.
  • Get the right team onboard: Starting off means starting research. You might consider yourself being confronted with a development crowd that does not aspire the new methodology. Though, especially when you are in research state, the cards are in your hands. Look for a small/not-too-big project but also an open-minded team. Most of the times you find them with the technology-evangelist teams that build the fancy stuff but are also keen to learn new stuff that help them to build their stuff in higher quality. Let them know that you are doing research and that their feedback is valued for defining the future methodology for the organization.
  • Work solution oriented: With TM it is not about blaming the team has done something wrong. Be curious to understand what were their challenges to solve the business requirements and how the translated it into technology. Identifying an issue among that, your job is now to help them to find a resolution while still considering their business objectives. This will ensure the team’s acceptance for future assessments.
  • Just get started: Nothing can go wrong from here as long as you consider that phrase “You can’t be everbodies darling” and being mindful that in every critique there is a grain of thruth which may help you to improve the methodology over the period of time.

All above is what is also compiled by the TM Manifesto Threat Modeling Manifesto. Definitely worth a read. Good luck!

"We are all apprentices in a craft where no one ever becomes master" [E. Hemingway]
JamesR
Rank
Userlevel 3
Badge

It's great to see your enthusiasm for diving into Threat Modeling and helping organizations navigate this crucial aspect of security. Starting out can indeed be daunting, but your advice is spot-on. Here are a few additional insights that might further guide those who are looking to embark on their Threat Modeling journey:

  1. Understand Your Assets and Scope: Before you begin Threat Modeling, it's essential to have a clear understanding of what you're trying to protect. Identify the assets, data, processes, and components involved in your application or workflow. This understanding will help you focus your efforts on the most critical aspects.

  2. Choose a Methodology: There are different methodologies for Threat Modeling, such as STRIDE, DREAD, and PASTA. Research and choose a methodology that aligns with your organization's needs and preferences. Each methodology provides a structured way to identify, analyze, and mitigate threats.

  3. Threat Library and Attack Catalog: Maintain a threat library or attack catalog that documents common threats and vulnerabilities relevant to your application's technology stack. This can serve as a reference point during your Threat Modeling sessions, helping you identify potential risks more effectively.

  4. Data Flow Diagrams: Creating data flow diagrams can be immensely helpful. These diagrams visually map out how data flows through your application or system, aiding in understanding potential attack vectors and points of entry for threats.

  5. Adapt to Your Environment: Keep in mind that Threat Modeling is not a one-size-fits-all approach. Customize your methodology and process based on the complexity of your application, the technologies you're using, and the specific security concerns of your industry.

  6. Automated Tools: Consider using Threat Modeling tools that can automate some parts of the process. These tools can help streamline the identification of potential threats and vulnerabilities, making the process more efficient.

  7. Threat Monitoring and Adaptation: Threat Modeling isn't a one-time task; it's an ongoing process. As your application evolves, so do the threats it faces. Regularly review and update your Threat Model to account for changes in your application's design, architecture, and functionality.

  8. Training and Education: Invest in training your development and security teams about Threat Modeling. The more team members understand the process, the more effectively they can collaborate to identify and mitigate potential threats.

  9. Engage with the Community: Participate in security forums, attend conferences, and engage with the security community. Learning from the experiences of others and staying updated on emerging threats and best practices can enhance your Threat Modeling process.

  10. Iterate and Improve: Just like any other skill, Threat Modeling improves with practice. After completing each Threat Modeling session, reflect on what went well and what could be improved. Continuously refine your approach based on lessons learned.

Remember, Threat Modeling is about proactive risk management. By identifying and addressing threats early in the development process, you're building a more secure foundation for your applications and workflows. Your willingness to ask for advice and seek continuous improvement is an excellent sign that you're dedicated to enhancing your organization's security posture.

James Rabe
B
Rank

The broad approach that I take for adopting any new or unfamiliar process is to get as much knowledge about the domain that I can.

Having started with Threat Modelling a little over 18 months ago (new job, new domain), I did as much background research as I could. I’m cheap, and took advantage of the free introductory offer for linkedin learning, and Adam Shostacks, STRIDE courses 😁. But there are lots of resources and reference materials, books etc, that explain the various methodologies, approaches etc.

OWASP (Open Worldwide Application Security Project) is a must for anyone in the AppSec field.

Then get some hands on, there is only so much you can learn by reading/watching videos or ppt presentations, to reuse a phrase “just do it”.

Decide the what you’re going to threat model, it doesn't need to be overly complicated

  • pick something familiar
  • get more eyes on the problem (collaborate)
  • dont get hung up on perfect, you know what you know today, deal with that, things change (even after having a good nights sleep).
  • prioritise what you are going to fix, and review the impact it has. Your threat models are not static
  • It doesn't matter where or what your use to capture, pencil and paper if needs be (you can always progress to technology down the line). This also allows you to creates a resource that you can re-use

Ultimately practice makes perfect; well it generally means that you get better, perfection is as always just out of reach.

**Disclaimer** The views expressed are solely that of the author and does not necessarily reflect the views of IriusRisk or other associated parties.
adedayo
Rank

A lot of good advice have already been given. I’d like to add another angle to the approach based on my experience in my organisation. 

 

I think that the success and sustainability of a threat modelling practice within an organisation also requires a mindset shift as well as cultural changes to position the threat modelling practice as an essential part of the SDLC.

In my org, one of the first thing that we (the security team) did was to get the Engineering leadership aligned that threat modelling was going to be an essential part of the SDLC, and part of the quality gates for the design process. Has this new feature or proposed design been threat modelled and the identified threats and mitigations added to the pen-testing and validation reviews down the line? This was a requirement in order to get your code into production. New things were threat modelled, and we prioritised existing system based on the criticality and worked our way through that.

We also created a set of “security champions” across development squads who were trained by the AppSec and Security teams on how to threat model. The security champions in turn cascaded their training and knowledge to their respective squads. This had a double-sided benefit. Firstly, the security champions saw the training and the attention that they were getting from the security teams as a career development opportunity, and they were made to feel an “extension of the security team” - who doesn’t want to be seen as part of the “sexy security team”! Part of the pre-work was to negotiate with the various squad managers to reserve a percentage of the security champion’s time for security-focused tasks: threat modelling, security reviews etc. etc. This was possible because of the aforementioned alignment and buy-in that we got from the Engineering leadership. Secondly, the other massive benefit to the security team was that this was truly a “shift left” strategy, allowing the security team to scale to the pace of the much larger engineering organisation by empowering engineers to threat model and do other security-related tasks!

Engineers, who naturally had a deeper understanding of their platforms were doing the foundational lifting for their own threat modelling with support from the security team, which ultimately reviews and approves the threat model, sometimes with feedback on how to improve the threat model, with many teachable opportunities and moments along the way as the engineers became more skilled at conducting threat modelling sessions for their systems almost independently.

I would say that a large part to the success and durability of the threat modelling program was due to the cultural shift, with alignment from engineering leadership and a consistent focus on “teach a man to fish” approach by the security teams and also a sense of “as a security champion in your engineering squad, you are one of us now”.  So instead of an adversarial relationship with the security team “finding flaws”, the engineers identified the issues and got advice and support from the security team on “how best to address” the issues. Collaboration + Partnership = Success

mohamed.aboelkheir
Rank

I have created a series of stories discussing threat modeling and how to embed it in the SLDC process with some examples. Hope you find it useful.

 

Here’s the link: https://medium.com/@mohamed.osama.aboelkheir/list/threat-modeling-handbook-309a70ec273f

Reply


Terms and Conditions, Community Guidelines and Privacy.Cookie settings
V2