In this article, we will approach threat modeling according to the Software Security Maturity Model, also known by the acronym SAMM. It is part of a series of articles published based on the OWASP SAMM project.
You can also listen to this article:
To be more specific, it deals with the Threat Modeling flow, in practice Threat Assessment, from the Design business area.
The history of threat modeling
Threat modeling has origins that go back to war strategies, with the prediction of possible enemy attacks for better positioning of defensive fronts. In software, we can cite some important historical events such as:
- The use of technology dates back to the early 1960s in scientific papers; In 1977, Christopher Alexander presented the first methodology;
- In 1988 Robert Barnard successfully developed and applied a profile-based attack model;
- In 1994 Edward Amoroso presented a visual model called the attack tree; In 1998 Bruce Schneier presented a study on the attack tree;
- In 1999 Loren Kohnfelder and Praerit Garg from Microsoft presented the STRIDE model.
Microsoft’s adoption of the practice with the STRIDE methodology is what made threat modeling popular in the information technology field.
But what is threat modeling? How and who should use it? What are the advantages of using the technique? That’s what we’ll see next.
What is Threat Modeling?
As indicated by Howard and Lipner (2006), the threat modeling process assumes the need to understand the entire application scenario, in order to visualize possible gaps that could compromise the security of assets, violating their security restrictions.
The NIST definition is: “a form of risk assessment that simulates aspects of the attack and defense of a logical entity, such as a data component, application, host, system, or environment.” NIST SP 800-53 Rev. 5(2022)
To understand the threat modeling process, let’s have a look at a couple of terms:
Threat: it consists of an event with the potential to cause damage to an organization and/or application.
Threat agent: the author who intentionally or unintentionally exploits a vulnerability that puts confidential data of the target architecture at risk.
A potential threat exists when the combined probability of the threat occurring and the impact it would have on the organization create a significant risk.[1] Then, from the threat assessment process, it is possible to plan and insert prevention, detection, and response security controls to identified threats, testing their efficiency throughout the software life cycle.
How and who should use threat modeling?
Perform threat modeling for each project you want to build. Use it continuously throughout software development too. The first phase of the process is to collect information.
The more security-affecting information you own, the better your modeling will be. If it is interesting, design the solution, and create a modeling of the system for a better understanding. We strongly recommend that you draw a data flow diagram before doing threat modeling, as this will help assess the likelihood and potential impact of potential threats that will be identified.
And to identify possible threats and help organize the modeling, you can answer to four questions:
- What are we working on?
- What can go wrong?
- What are you going to do about it?
- Did we do a good job? [1]
Execute the threat modeling with the help of POs (Product Owners), architects, security personnel, and testers. All those involved must work together to raise awareness and, if not, start the AppSec culture within the company, creating a shared vision about the system’s security.
Image 1 shows a generic example of systems architecture from the point of view of different stakeholders [2].
It will identify the likely worst-case scenarios for the software under development in each project team.
What are the advantages of using the technique?
This technique enables greater mastery of the effort deployed for security, clearly defining potential threats based on realistic data. More convincing arguments are then produced to defend the security of an application. Another advantage is homogeneous communication regarding security issues and application risks for everyone involved in the development process. Now that we know more about its context and its benefits, let’s understand the view of threat modeling as per SAMM.
Threat Modeling According to SAMM
For SAMM, threat modeling is a structured activity used to identify, assess and manage system threats, in addition to verifying deficiencies in the design architecture to reduce them according to security recommendations.
This procedure assists in risk management and awareness of the secure development stages, as it makes it simple to translate technical aspects of the systems and processes that are analyzed. For the development of secure applications, threat modeling is essential, once it allows the company to save time and resources, directing its efforts to address real and/or critical risks and reducing friction between the development and security teams.
If we apply security from the beginning of the development cycle, then we are applying Shift-Left (a very popular concept in Application Security). Since it is based on a maturity model, threat modeling is performed differently at each level. Starting simple and becoming more complex as the organization gains experience.
Maturity Level 1 – Threat modeling to identify and manage design flaws
As the first level of maturity, threat modeling aims for high-risk applications, using simple lists of threats that meet specific demands. Here the modeling must be iterative, meaning that new functionalities are added to the application, and only what was modified or inserted will be examined instead of the entire application.
Document the results of discussions so you can later revisit and modify them, so lists and diagrams can become templates (models). After all, at this level, the goal is security awareness resulting in a process agreed upon with the whole team.
Maturity Level 2 – A standard methodology aligned with your application risk levels
The second level of maturity, it’s expected the standardized use of a methodology that supports the performance of threat modeling at scale, aligned with the risk levels of the applications. The methodology should include: diagramming, threat identification, mitigation of design failures, and how to validate its artifacts to provide a clear understanding of the environment and application engineering.
At this point, in addition to using threat checklists, such as STRIDE, a list of threats specific to the business context is also used; adding remediation controls to support those involved in dealing with specific threats, as well as a failure management process.
The modeling results must be documented within the tools used by the development teams. Certain knowledge and experience are required for the correct use of threat modeling practice. This is reflected in a knowledge base and training for architects, security champions, and other stakeholders. This understanding cannot be automated, which is why investment in people is reinforced. Furthermore, it would not be a maturity model if we do not have a definition of when to update this threat model. The trigger could be a migration to a new environment or a technology change. However, there must be a recurrence of the review.
Maturity Level 3 – Regularly review and updates the threat modeling methodology for your applications
The highest level of security maturity is reached when threat modeling is part of the company’s culture, that is when there is integration with the application development cycle and the focus becomes the optimization of the methodology. Based on the organization’s threat models, reusable risk patterns are created and improved, comprising threat libraries, design flaws, and security mitigations.
To improve the methodology, lessons learned are used and relevant threat categories are reviewed, keeping models updated regularly (annually, for example) to make sure that a new threat is not present in the applications.
So, at this point, automation is part of the threat modeling process with the integration of security tools. Examples: security scanning tools and risk tracking tools.
Now, as a tool for application security by identifying security requirements in a consistent, scalable and intelligent way, we can mention one of our five Conviso Platform’s product, Security by Designer that protects your applications by supporting threat modeling.
Read more about threat modeling:
Microsoft Security Development system
What can we conclude?
As defined by NIST (2013), a threat is any event that has the potential to adversely impact the operations, assets, or individuals of an organization through unauthorized access, destruction, or modification of information. Threat modeling assumes that to properly protect a system or process, it is necessary to understand well what or who you want to defend against.
As defended by OWASP, this process is essential at the beginning of a system’s design, as it allows saving time and resources by directing security efforts to address real risks without wasting resources with generic approaches, in addition to allowing reviewing aspects of architecture and project. Therefore, the threat modeling process must always be taken into account when designing critical systems.
References:
[1] Drake,Victoria. Threat Modeling. Owasp.org, 2022
[2] Kruchten, Philippe . Architectural Blueprints —The “4+1” View – Model of Software Architecture. IEEE Software 12 (6), pp. 42-50.
[3] OWASP. Threat Modeling Cheat Sheet. 2021
Authors:
Evandro Pinheiro – Information Security Analyst
Luciene Oliveira – Information Security Analyst
Luiz Henrique Custódio – Application Security Analyst
SAMM article series
- Governance according to SAMM: Strategy and Metrics in Application Security
- Governance according to SAMM: Policies and Conformities in Application Security
- Governance According to SAMM: Application Security Education and Guidance
- Design according to SAMM: Threat Modeling in Application Security
- Design According to SAMM: Security Requirements in AppSec
- Design according to SAMM – Secure Architecture in Application Security
- Implementation according to SAMM: Secure Build in Application Security
- Implementation according to SAMM: Secure Deployment in Application Security
- Implementation According to SAMM: Defect Management in AppSec
- Verification according to SAMM: Application Security Architecture Analysis
- Verification according to SAMM: Requirements-Driven Testing in Application Security
- Verification according to SAMM: Security Tests in Application Security
- Operations according to SAMM: Application Security Incident Management
- Operations according to SAMM: Environment Management and Application Security
- Operations according to SAMM: Operational Management in Application Security
