Updated: 7 April, 2025
26 April, 2022
Threat modeling yields the highest return on investment when it comes to your Application Security program. Even if your current security posture is close to a zero OWASP SAMM score, you should start by threat modeling first. As opposed to what many might think, threat modeling is not difficult nor time-consuming. It is by far the most underrated security practice out there.
Intro
In this blog series, we will present how Codific implements OWASP SAMM. We focus on a specific security practice in each blog and highlight the processes and tools we use to achieve a certain maturity level. If you want to learn more about OWASP SAMM consider taking the free SAMM training.
Extract from the OWASP SAMM Fundamentals training.
My journey in application security (AppSec) started almost 20 years ago at the DistriNet research lab of the University of Leuven. Back in the days secure software development was what you’d call a “buzzword” today. The release of Microsoft Security Development Lifecycle pushed AppSec to the main stage. One particular development in software security has changed my career. Threat modeling is a concept initially introduced by Frank Swiderski and Window Snyder. Adam Shostack has evangelized those ideas in his “Threat Modeling: designing for security” book. Meanwhile Kim Wuyts and her research colleagues from DistriNet (including myself) have worked on LINDDUN. LINDDUN is a threat modeling methodology for privacy. It is now part of the NIST and ISO standards. Make sure to check out the podcast I did with Kim around privacy threat modeling and the blog post that was written about it!
Key Takeaways
- The starting point for a threat modeling session should be the inherent risk profile for each application. What sort of issues would be catastrophic from the business perspective vs what you could tolerate.
- Threat modeling is a live brainstorming session with up to 10 stakeholders from different backgrounds (including architects, pen testers, application specialists, devs and ops).
- Threat modeling can be as pragmatic as you wish. You don’t need to book days from everyone’s agenda. A timebox of 2 hours per quarter is a great start.
- I strongly believe in threats ending up on issue tracking boards and eventually on a sprint planning. The risk level for each threat determines the priority.
- I haven’t seen much added value from threat modeling tools yet. Happy to hear any counter arguments.
- Threat modeling shapes the culture. It allows your team to sync on risks and threats in a natural setting. It brings all stakeholders together.
Implementing SAMM Threat Assessment
The OWASP SAMM model describes Threat Assessment as a practice that focuses on identifying and understanding of project-level risks. Those risks are based on the functionality of the software being developed and characteristics of the runtime environment. Threat assessment contains 2 closely-related streams, namely Application Risk Profile and Threat Modeling.
Application Risk Profile
Application Risk Profile is an essential activity to estimate the potential business impact every threat might pose to the organization. This practice is often either overlooked or tackled in a very shallow manner. Obviously, every business wants to have no downtime and no breaches for their applications. However the devil is in the details when it comes to risk. Here are the risk profile descriptions for two different products at Codific to further illustrate this point and its importance.
- One of our products is an attendance tracking platform that allows university professors effortlessly track student presence. The uptime guarantees for this application carry the highest risk as any downtime during the class renders the app useless. We can tolerate a single student account breach. Professor account breaches are to be avoided. Mass database breach is a medium risk event, but it is unlikely to end up in a disaster for our company.
- Our flagship product is Videolab, which is a secure video sharing platform used by doctors in training in many healthcare institutions across Western Europe. A single leaked recording is likely to have a catastrophic impact for our firm. Hence, even a single account breach carries maximum risk. Downtime is to be avoided, but it is unlikely to have any impact on our customer satisfaction. Database breach will leak private data on the users in the database and their assessments, but not the recordings. Hence, a database breach carries a high risk, but it is not going to bankrupt the company.
As someone responsible for application security you should communicate the risk profile and its details to all stakeholders, especially the development and QA teams. You should also leverage the risk profile as an input to your threat modeling sessions.
Extract from the OWASP SAMM Fundamentals training.
Threat Modeling in a Nutshell
Threat modeling is a structured activity for identifying, evaluating, and managing system threats, architectural design flaws, and recommended security mitigations. It boils down essentially to four key questions:
- What are we building?
- What can go wrong?
- What are we going to do about it?
- Did we do a good enough job?
In the remainder of this section we will briefly describe each of these activities.
What are we building: Data Flow Diagram
Data Flow Diagrams (DFD) are the ideal means to communicate the system that is being developed. As we all (should) already know “all models are wrong, but some are useful”. The DFDs we create are often updated with more details, however we try to keep them as high-level as possible. Here is a partial sample DFD from the previous generation of our Videolab Product. It provides a good starting point for the remainder of the brainstorming sessions with the stakeholders. Note that DFDs might become extremely extensive and complex. Our advice is to focus on a specific part of the system during each session. You can also draw several DFDs.
What can go wrong: Brainstorming for Threats
Threat elicitation is the meat and the core of threat modeling. The more you threat model the better threats you will be able to come up with. During this threat elicitation brainstorming session we come up with threats and we create a ticket for each identified threat in our issue tracking system. We leverage a relatively simple risk classification for each identified threat. We assign values for likelihood and impact for each threat. The value is one of the following labels: negligible, limited, significant and maximum. Risk is then defined as a product of the likelihood and impact. We then use this risk label to set a priority for each issue on our issue tracking board.
What are we going to do about it: Mitigations
While finding threats you can also discuss possible mitigations with the team. Feel free to add this information to the issue for the relevant threat. At Codific we typically look at mitigations in detail at a later moment when we plan the sprints.
Did we do a good enough job: Architecture Assessment
After implementing the mitigations it is a good idea to run through the DFD and validate whether we did a good enough job. Typically we look into that during the subsequent threat modeling workshop.
Threat modeling workshop format
Threat modeling can be a real pain or a fun teambuilding activity depending on the setup. Here is what works for us after several attempts.
- We run threat modeling workshops with up to 10 stakeholders from different backgrounds (including architects, pen testers, application specialists, devs and ops).
- Adding stakeholders from different projects sometimes results in interesting insights both in terms of threat elicitation as well as mitigations.
- We don’t really iterate around any checklists or mnemonics (e.g., STRIDE/LINDDUN) although everyone is pretty much familiar with them. Attack trees as well as LLMs are an option to consider if your TM session runs out of steam.
- The sessions are time-boxed (+-2 hours) and focused on a specific part of the given application described using DFDs. If necessary, we extend the scope and remove some less interesting parts.
- We start the session by drawing the Data Flow Diagram on a dry-erase board. For larger software systems we might sometimes focus on a specific set of components.
- The output of the threat modeling session is a list of threats. All threats are written down and all of them end up on a backlog. We don’t create any reports as the main goal of TM is to find threats and not create additional bureaucracy.
Sample Data Flow Diagram (DFD) on a whiteboard.
Threat modeling tools
I am a big fan of the old school means to threat model, namely a dry-erase board and a marker. I always assign someone from the stakeholders to take notes of what is being discussed during the session. Often there is a volunteer in the team to create nice DFD diagrams. My experience with threat modeling tools is that they are more likely to be a hassle than a help. With that being said I’d be happy to hear your experiences with threat modeling tools. Here is a list of some of them: IriusRisk, Threat Dragon, Pytm.
Threat Modeling Best Practices
- Keep DFDs high-level but detailed enough to serve as a foundation for brainstorming sessions with stakeholders.
- Assign likelihood and impact values (negligible, limited, significant, maximum) to each identified threat. Calculate risk as a product of likelihood and impact and prioritize issues accordingly.
- Identify possible mitigations during brainstorming sessions and add those strategies to issue tracking systems. Refine them later during sprint planning.
- Conduct time-boxed workshops (approximately 2 hours) with up to 10 stakeholders. Focus on specific parts of the system described using DFDs. The desired outcome of these workshops should be a list of threats added to the backlog and prioritized for sprint planning.
- Regularly reassess threats during subsequent workshops to ensure ongoing security improvements.
- Embed threat modeling into the Software Development Lifecycle (SDLC) to ensure security is considered at every stage of development.
Manage your Application Security Program using the SAMMY tool
SAMMY is an Application Security Program Management tool developed by Codific. We use SAMMY to manage our SAMM posture and plan the improvements in term of application security.
Extract from the OWASP SAMM Fundamentals training.
Summary
Threat assessment is an essential practice for your organization’s application security program. By understanding the inherent risk profile of each application and engaging in collaborative brainstorming sessions with diverse stakeholders, teams can effectively identify and prioritize critical threats. Threat modeling should be part of the process, incorporated into regular sprint planning and issue tracking to ensure ongoing security awareness and remediation. The true value of threat modeling lies in fostering a security-minded culture within the organization, enabling teams to proactively address potential threats and protect the integrity of their applications.
What are the things we build with SAMM and SAMMY?
Codific is a team of security software engineers that leverage privacy by design principles to build secure cloud solutions. We build applications in different verticals such as HR-tech, Ed-Tech and Med-Tech. Secure collaboration and secure sharing are at the core of our solutions.
Videolab is used by top universities, academies and hospitals to put the care in healthcare. Communication skills, empathy and other soft skills are trained by sharing patient interviews recordings for feedback.
SARA is used by top HR-Consultants to deliver team assessments, psychometric tests, 360 degree feedback, cultural analysis and other analytical HR tools.
SAMMY Is a Software Assurance Maturity Model management tool. It helps your organization assess and improve its security posture. That way other companies can help us build a simple and safe digital future. And we off course use it ourselves in all our application, including SAMMY.
We believe in collaboration and open innovation, we would love to hear about your projects an see how we can contribute in developing secure software and privacy by design architecture. Contact us.
Recommended reading:
April 2022
