Application Threat modeling is a structured and methodical approach that allows you to identify potential threats to applications, classify them by risk, and prioritize mitigation efforts. CISOs and other senior leaders leverage threat model ouput to drive decision making based on the technical and business impact certain threats pose to the organization. Application threat modeling has become a mainstay of many organization’s SDLC and, as more enterprises move to the cloud, CDLC. In this post, we summarize the history of application threat modeling, how it has evolved, and the direction it is heading.
Threat Modeling Objectives
The purpose of threat modeling is to visualize either all or parts of an organization’s attack surface for threats and vulnerabilities. Taken together, threats and vulnerabilities constitute risk. A threat model should describe the system in question, and, according to the OWASP Application Threat Modeling page, come up with a list of “assumptions” to check against on an ongoing basis to address future threat landscape developments.
ThreatModeler, for example, is an innovative platform that enables you to map out the different components of a system and, based on your diagram, automatically compile a list of threats to the system. Corresponding to the threat list are security requirements – actions that users should take to address and prevent threats. By sending threat models up the approval chain, users can validate the model and threats. Through its integration with Jira, users can verify that security requirements are implemented.
Why Use Threat Modeling?
Threat modeling is necessary to an SDLC security strategy to secure attack surface entry points against hackers. Once a cybercriminal infiltrates the attack surface – once they’re in – they can orchestrate a more severe cyberattack, such as a distributed denial of service attack. Hackers might employ other forms of social engineering to compromise an organization such as spoofing. In this form of cybercrime, hackers pose as an innocent party, e.g. a legitimate business, to convince victims to reveal their private information.
According to the 2019 Cost of a Data Breach compiled by IBM and the Ponemon Institute, it took organizations approximately 206 days to detect a data breach. The damage is done already. Threat modeling, on the other hand, enables organizations to be more proactive and preventative about security issues as early as in the CDLC design process.
A Brief History of Application Threat Modeling
Application threat modeling began as an ad hoc process to identify threats during the requirements gathering stage and incorporate them into the application design documentation. It was treated as a one-time exercise carried out in the early stages of development or in some cases, after an application was moved to production. This form of threat modeling resulted in burdensome reports with built-in obsolescence, due to the many changes in requirements that normally occur during the software development lifecycle (SDLC).
In addition, early application threat modeling required highly specialized subject matter experts with in-depth knowledge of software architecture and application security, which was not only costly and cumbersome for organizations to try to implement, but also proved to be a challenge finding qualified security professionals with specialized credentials. Plus, the lack of automated threat modeling tools created internal disruption, as organizations attempted to manually integrate their application threat modeling processes into existing workflows.
About Threat Trees
The concept of threat trees was introduced by Dr. Edward Amoroso in 1994 in his book Fundamentals of Computer Security Technology. In 1999, Bruce Schneier proposed the use of attack trees in Dr.Dobbs journal for developers to promote the concept of modeling threats diagrammatically. Subsequently, to complement the STRIDE threat classification methodology, Microsoft introduced its Data Flow Diagram (DFD) based approach to threat modeling, by launching the first version of its public domain software, Microsoft Threat Analysis and Modeling (TAM) in 2004 (credit to Frank Swiderski and Window Snyder).
The genesis of both STRIDE and Microsoft TAM was a consequence of Microsoft’s “Trustworthy Computing Memo” authored by Bill Gates in 2002, which outlined the process required to build secure applications. Microsoft Software Development Lifecycle (SDL), replaced Microsoft TAM in 2011, and more recently, Microsoft launched its successor, Microsoft Threat Modeling Tool (TMT), in March of 2014.
About TRIKE
Trike was introduced as an open source threat modeling methodology and tool introduced in 2006, in an effort to improve the efficiency and effectiveness of existing threat modeling methodologies. While Trike was similar to the Microsoft threat modeling process, it differed in that it offered a risk-based approach with distinct implementation, threat and risk models. However, it remains in an experimental stage, with inadequate documentation and support, making it difficult to understand and implement.
Many larger organizations gravitated to Microsoft’s early approaches to threat modeling, largely because its public domain software was the only tool available since no commercial threat modeling products had not yet been introduced into the marketplace. And while the application threat modeling concepts being promoted by Microsoft were useful from a theoretical standpoint, there were many challenges to implementing these processes in large enterprises. Neither Microsoft TAM nor Microsoft SDL was able to:
- Deliver the scalability needed in large enterprise environments
- Reduce the involvement of subject matter experts
- Make the application threat modeling process less time consuming and tedious to implement
- Provide a meaningful output, or allow for real-time collaboration between stakeholders
While organizations were beginning to understand the inherent value of application threat modeling, the many challenges identified above hindered its adoption, limiting its use to a handful of organizations that had the resolve, determination, resources, and perseverance to try and deploy it in their ongoing development processes.
Application Threat Modeling Processes Used Today
With the widespread use of the Agile development methodology, changes now occur at a much more rapid pace during all phases of the SDLC than in years past. This evolution, coupled with the heightened focus of organizations wanting to build security into applications during the SDLC, have made the implementation of traditional application threat modeling approaches even more difficult, time-consuming, costly, and inefficient.
About P.A.S.T.A. Threat Modeling
P.A.S.T.A. (Process for Attack Simulation and Threat Analysis), a relatively new methodology, has gained a following through its ability to threat model applications more thoroughly and can also be applied to a wide variety of development methodologies. Several organizations in the financial services, healthcare, insurance, and the energy sectors have been the primary adopters of this approach, as these industry verticals have begun to extend the scope of their budgets that were traditionally used for code reviews, vulnerability assessments, and penetration testing, to now include application threat modeling.
The trend of expanding and/or shifting budgets to incorporate application threat modeling has largely been driven by the realization that writing secure code from the ground up is not only a much more effective risk mitigation strategy, but it also reduces the high cost of fixing production vulnerabilities. And while application threat modeling continues to mature, most organizations that perform threat modeling today are predominately using in-house, patchwork methodologies, along with outside security consultants, due to a lack of automated tools and widely accepted industry standards.
Enterprise Scale Threat Modeling
Because most application threat modeling methodologies and frameworks lack automation, they are unable to scale across large enterprises. This limitation has resulted in organizations continuing to rely heavily on security consultants to deliver customized services, in order to implement an application threat modeling process. However, this approach is largely a manual effort that is not only costly, but is also unable to effectively keep pace with ongoing software and architectural changes – let alone the ever-changing threat landscape.
Another obstacle to adoption is the inability to involve key stakeholders in the threat modeling process through real-time collaboration. Too often, the primary focus of threat modeling is to address risk exposure from an engineering and technical perspective, while losing sight of the actual costs and negative impact to a business should a breach occur. Until organizations are able to consistently align application security risk and risk-mitigation with business priorities to manage potential costs and brand damage, threat modeling will continue to be viewed as a largely theoretical exercise.
Future of Application Threat Modeling
Looking forward, application threat modeling should be capable of: Automatically and accurately pinpoint where threats exist; provide a clear actionable output, such as recommending the appropriate security controls; present test cases; and effectively display attack trees, etc., to ensure threats are mitigated in the most effective way possible.
In addition to identifying threats, threat modeling should also:
- Provide a way to calculate both the technical and business impact to an organization if threats are carried out
- Correlate threats to real-time threat intelligence to more effectively manage risk based on actual threat data.
Ideally, CDLC teams should correlate application threat modeling with an organization’s security policy and risk management, in a way that business executives can easily understand application risk, regardless of their level of application security experts. This will allow senior management, security specialists, and software developers to work collaboratively to more effectively prioritize and mitigate threats.
Threat Scoring Can Measure Key Threat Factors
Contextual, risk-based threat scoring should become an integral component of an effective application threat modeling practice as well. Automatically applying key threat factors such as:
- Exploitability
- Discoverability
- Automation
- Ability to predict the business and technical impact if a threat is carried out will significantly help prioritize mitigation efforts.
This can be accomplished through integration with current industry-standard threat scoring systems such as CWSS, CVSS, etc., and/or with custom-built threat scoring classifications, and will be an essential component of an efficient threat modeling process.
Furthermore, application threat modeling should also allow organizations to accurately calculate costs associated with mitigation, not only to help prioritize mitigation efforts but to provide an objective process for aligning security budgets with risk.
In summary, an effective application threat modeling program should be able to automatically identify threats, specify the appropriate mitigating controls, provide risk classification metrics to prioritize mitigation, present easy to understand security requirements that can be integrated into the SDLC, keep threat data current, automatically generate reports that are customizable to meet the needs of various stakeholders, and enable a consistent, repeatable, scalable, process that can be implemented enterprise-wide.
Learn more: Three Pillars of a Scalable Threat Modeling Practice
Continual Application Threat Modeling for CDLC
With the maturation of application security over the past decade, along with advances in threat modeling methodologies and tools to automate processes, application threat modeling is rapidly gaining momentum throughout the marketplace. The days of manual, tedious, time-consuming processes that lacked consistency and repeatability, produced unwieldy paper trails, and required subject matter experts, is being replaced by more straightforward and automated approaches that include contextual, concrete output that provides the necessary details to show how to mitigate risk, even if a user knows little or nothing about security.
Threat modeling is in the process of transitioning from an art to a science through automation and the development of industry-standard best practices, with integrations to CDLC platforms such as AWS. Compliance with security and regulatory laws, coupled with the substantial, tangible cost benefits associated with developing secure applications from the ground up, make it clear that threat modeling will become a widely adopted standard going forward. Above all, building security into applications during the design phase is the optimal way for organizations to mitigate risk.
ThreatModeler Uses the V.A.S.T Approach
The CEO of ThreatModeler conceived of the Visual, Agile, Simple Threat modeling approach, which satisfies more threat modeling requirements for agile CDLC than any other methodology. ThreatModeler’s V.A.S.T. ingrains the idea that threat modeler is useful only to the extent that it encircles the entire CDLC. ThreatModeler’s innovative solution lends itself to agile CDLC through automation, integration with project management tools, and security and compliance libraries (e.g., CIS, OWASP) and its collaborative features.
ThreatModeler has integrated with leading cloud service providers such as AWS to help organizations achieve and maintain compliance and security. Secure CDLC can be achieved with less cost and effort devoted to threat modeling through ThreatModeler’s automated platform.
To learn more about how ThreatModeler™ can help your organization build a scalable threat modeling process, book a demo to speak to a ThreatModeler expert today.