Most organizations use security testing before releasing software to identify weaknesses that an attacker could exploit. While static analysis, dynamic analysis, software composition analysis, and penetration testing can find many common vulnerabilities, testing late in the development process can cause release delays.
A better approach, of course, would be to take steps to prevent design and coding errors from entering the code base to begin with. That’s where threat modeling comes in. Software threat modeling is an exercise that examines an application’s architecture and technical stack. It identifies potential weaknesses an attacker could exploit, then prescribes threat countermeasures and security controls software developers, security, and operations teams can implement. In short, threat modeling anticipates threats prior to starting development. This allows organizations to prevent vulnerabilities from entering the application and build secure software more rapidly.
Why Doesn’t Everyone Use Threat Models?
Traditional threat modeling is a manual exercise requiring leadership from senior security and software architecture professionals. Threat modeling teams can spend weeks mapping an application’s data flow, creating “trust boundary” diagrams, and identifying mitigations for implementation by development teams. We have written at length about some of the challenges with manual threat modeling. Briefly, these include:
- Scalability: Allocating senior personnel for days or weeks to threat model every project is not practical in most organizations.
- Shelf life: As teams add new features, microservices, and interfaces to an application, threats it faces change. In a DevSecOps environment with frequent changes and rapid releases, spending several days to update a threat model is impractical.
- Consistency- Manual threat models are subject to the judgements, preferences, and expertise of those people building the models.
- Completeness and Auditability- Tracking hundreds or thousands of threats and countermeasures in a spreadsheet or shared document is cumbersome and prone to mistakes.
Nonetheless, threat modeling is beneficial to organizations of all sizes. Like any initiative, adopting a threat modeling program is a journey.
Understanding Capabilities Maturity Models
A capability maturity model provides a blueprint for assessing and advancing an organization’s practices. Here at Security Compass, when we talk to organizations who want to improve their secure software development process, we tell them one of the best places to start is by conducting a quick, informal assessment of their current software threat modeling maturity process. Furthermore, we also typically encourage them to create their model based on the software-process maturity framework developed by the Department of Defense as “a means to characterize the capabilities of software-development organizations and the Capabilities Maturity Model developed by Watts Humphries and others at the Carnegie Mellon University Software Engineering Institute.
Software Threat Modeling Maturity Model
A Capability Maturity Model recognizes that processes evolve over time, and that as organizations gain experience and knowledge, they can improve their processes to become more efficient, effective, and predictable. The maturity model can be applied to any type of organizational process, including software development, project management, quality assurance, or customer support.
By focusing on process maturity, organizations can identify areas for improvement, develop best practices, and achieve greater consistency and efficiency in their operations. Like the Capability Maturity Model, the Software Threat Modeling Maturity Model (STMMM) we use with many organizations consists of five discrete levels.
Level 1 – Initial
Level 1 maturity is typified by unpredictability and poor controls. Activities are ad hoc and reactive, and results are unpredictable. This does not mean that efforts will fail, however, as extraordinary individual efforts can result in success. However, because processes are poorly defined and documented success is unlikely to be repeatable.
Level 1 maturity for threat modeling is characterized by one or two individuals defining data flow diagrams (DFD), entry points, and likely attack patterns. Threat countermeasures are ad hoc and inconsistent. Engineering must interpret high level descriptions (e.g., “apply least privilege principles”) and translate those into controls for implementation and testing. Reporting is through shared documents or spreadsheets.
Requirements to advance to Level 2
In Level 1, teams have not sufficiently defined and documented processes to enable them to be replicated. Advancing to Level 2 requires additional discipline to define policies and processes to achieve consistency between projects.
Level 2 – Repeatable
At Level 2, teams have defined and documented processes that allow for repeatable results. This does not guarantee that teams will rigorously follow the processes each time, however. For threat modeling, teams operating at Level 2 have documented policies for identifying which applications require threat models. Teams lack the resources to focus on more than one or two high-priority applications.
Level 2 threat modeling is manual and diagrammatic. Documentation remains paper based and therefore diligence is required to ensure repeatability. Teams may begin to document specific threats and countermeasures associated with common frameworks or deployment environments. This allows better consistency between threat models and uniform application of approved controls.
Requirements to advance to Level 3
Level 2 organizations lack information, documentation, and consistency. Teams need to capture and analyze data to identify blockers and missed opportunities. For example, if security testing identifies multiple SQL injection vulnerabilities, threat modelers should respond by considering input validation threats more closely. Training on secure coding can also benefit the team.
Level 3 – Defined
At Level 3, threat modeling becomes proactive. Teams have standardized and documented threat modeling activities integrated into organizational processes. Documenting uniform threats and countermeasures based on the technology stack reduces the organization’s reliance on scarce senior security and engineering personnel and allows multiple teams to produce consistent threat models and countermeasures. In turn, this allows threat modeling of a higher percent of the organization’s application inventory.
Teams having “defined” threat modeling practices are incorporating regulatory requirements in addition to general secure coding standards. This is where automation can accelerate advancing to Level 3. Developer-centric threat modeling solutions like SD Elements provide teams with comprehensive interpretations of standards like NIST 800-53, CCPA, PCI-DSS, CSA Cloud Control Matrix, and others. Automation also allows teams to adopt standardized countermeasures or adjust those to meet internal requirements. Each countermeasure is defined as an actional task and delivered through existing tools (e.g., Jira) for implementation by development, security, or operations.
Requirements to advance to Level 4
Threat modeling teams need to leverage additional data analysis to advance to Level 4 maturity. This includes identifying choke points in the system and analysis of residual findings from security testing to guide process change. Tailored training for development on individual issues can help refine countermeasures.
Level 4 – Managed
Level 4 threat modeling maturity is characterized by processes that are measured and controlled. Teams have customized their threat models to each technical stack and deployment environment, and threat countermeasures are consistent across teams. Proactive security controls with approved standards result in fewer vulnerability findings during security testing. Continuous developer education delivered to desktops instills a security culture.
In a managed environment, automation enables teams to achieve consistency and scale threat modeling across all team members, minimizing variability and the requirement for senior personnel. By leveraging a centralized platform like SD Elements, teams can measure process metrics across a range of personnel and application architectures with near real time visibility to the security profile of each application.
Requirements to advance to Level 5
Level 5 maturity requires a regimented review of data to identify efficiencies. This includes continuous monitoring of the threat space and regulatory environment to maintain awareness of new threats, standards, and countermeasures. It is also advisable to monitor performance between personnel conducting threat models to ensure consistency and identify areas for improvement. The addition of developer-centric eLearning is helpful to close knowledge gaps and create the foundation for a security culture
Level 5 – Optimizing
Teams that perform at level 5 maturity focus on incremental improvement through test, analyze, adjust cycles. Processes are constantly improved through monitoring feedback and introducing innovative methods and functionality. In an automated platform, this may include new survey questions to reduce threat modeling time, more frequent updates to the threat model as software requirements change, or the testing the effectiveness of new countermeasures. Security and engineering scrutinize vulnerabilities to determine if the root cause was a missing item from the threat model, a poorly designed countermeasure, or an ineffective test plan.
SD Elements provides quarterly updates from Security Compass’ security professionals on the threat environment and regulatory requirements. Advanced Reporting makes complex threat, countermeasure, security control, and compliance data accessible and easy to digest. Teams can create rich data visualizations and dashboards that identify the most prevalent threats and weaknesses across the organization’s software portfolio. Teams also have the data, reporting, and analytics capabilities they need to perform in-depth analyses of their software security and compliance posture for individual software projects, as well as across their entire software (or application) portfolio.
Closing
Building a mature threat modeling capability is a process. By focusing initially on key projects, teams can build internal support and capture data on threat mitigation and cost savings. Automation is a key requirement, as manual processes are inconsistent, unauditable, and simply do not scale.
SD Elements helps organizations accelerate their threat modeling initiatives and simplifies maturing programs. It provides an expansive content library of threats, countermeasures, and security and compliance best practices designed specifically to address the needs of developers. This expertise, provided by expert researchers on the SD Elements content team with decades of experience, is coupled with embedded, highly interactive, just in time training modules to enable software developers to quickly understand and comply with changing software security standards and threat landscapes.