We have written before about what threat modeling entails and its many forms. Organizations can take different approaches, particularly when building manual threat models. This is unsurprising. Different organizations have different needs, technology stacks, and expertise.
With the widespread adoption of rapid development methodologies like DevOps, traditional threat modeling was difficult. Taking weeks of time senior development and security professionals was incompatible with a strategy of quickly responding to customer needs.
Recognizing the importance of threat modeling – particularly in a rapid development environment – in 2020 a group of 15 experienced threat modelers joined together to redefine threat modeling as core values and principles. The resulting Threat Modeling Manifesto acknowledges there is no single “best” threat modeling process. Instead, it distills the process to answering four key questions:
1. What are we working on? Define the project, its components, and its environment.
2. What can go wrong? Identify the threats to the project, including its deployment environment.
3. What are we going to do about it? Define the threat countermeasures and security controls.
4. Did we do a good enough job? Validate that the countermeasures are implemented properly, and work as designed.
Why you should care about Threat Modeling
Threat modeling allows teams to anticipate weaknesses in an application that an adversary could exploit and identify countermeasures and controls to mitigate those weaknesses. These countermeasures and controls become non-functional security requirements development and operations can implement alongside the functional product requirements. This proactive approach reduces the number of vulnerabilities that would otherwise be identified by security testing later in the development process (or completely overlooked!).
How to use the Threat Modeling Manifesto
The Manifesto is not prescriptive regarding how one should answer the four key questions. Rather, it relies on guiding values, principles, and beneficial patterns for performing threat modeling.
Meeting the values can require organizations to change the way they think about threat modeling. Successful programs are not rigid and fixed. Rather than meeting minimum compliance requirements, the first value recommends building “a culture of finding and fixing design issues.” Others recognize that successful threat modeling is a “journey of understanding,” and a need for “continuous refinement” of the process.
Principles are “fundamental truths of threat modeling.” These can help an organization determine “how” they will approach the task. Principles include using threat modeling early and frequently. Threat modeling must be an iterative process as a threat model for an application can quickly become out of date. The principles also recognize that threat modeling exercises will differ depending on the development practices of the organization or team and must be “scoped to manageable portions of the system.”
The Manifesto helpfully provides “patterns” that benefit or inhibit successful threat modeling. Beneficial patterns include taking a systematic approach. To be thorough and repeatable, threat modeling should be a structured process. While the process may change (continuous refinement) it is important to apply organizational knowledge consistently. A second beneficial pattern is to use “tools that allow you to increase your productivity, enhance your workflows, enable repeatability and provide measurability.”
The Manifesto’s “anti-patterns” call out behaviors to avoid. These include the “Hero Threat Modeler” where organizations assume that threat modeling must be confined a small group of people with unique skills. Threat modeling requires a diverse team that understands the strengths and weaknesses of programming languages, deployment environments, and internal capabilities. It also requires an understanding of applicable regulatory requirements. In short, “everyone can and should do it.”
How SD Elements helps
Adhering to the principles and beneficial patterns can be challenging when conducting manual threat modeling. Traditional threat modeling can be inconsistent. Output from manual threat models reflect the knowledge and biases of those participating in the exercise. As team members change identified threats and controls will also change. Teams often maintain the threats and countermeasures identified in a manual threat model in a spreadsheet or shared document. This provides poor evidence of compliance with corporate policies and regulatory standards.
Organizations require automation and a developer-centric approach to achieve scalable, consistent, and auditable threat modeling. Security resources are scarce across all organizations. The BSIMM 13 report published by Synopsys in 2022 surveyed the application security resources and processes at 130 enterprises. On average, it found 1 software security resource for every 122 developers and 43 applications.
SD Elements is a developer-centric threat modeling solution that helps organizations extend scarce security resources. It enables self-service threat modeling that identifies weaknesses and compliance requirements at the beginning of a project, then delivers consistent and approved developer-friendly secure coding best practices and countermeasures directly to developers, significantly reducing cyber risks. Developers can quickly update threat models as features and requirements change, without waiting for security resources.
The economic benefits of this approach are significant, increasing developer productivity and reducing security rework later in the development lifecycle. A study by Forrester Consulting found that using SD Elements produced benefits of increased productivity, reduced costs, and avoided vulnerability remediation totaling over $2.8 million and a 332 percent return on investment.
How to start threat modeling in your organization.
You can learn more about the different methodologies to threat modeling in our white paper: Threat Modeling: Finding the Best Approach for Your Organization.