Why Treating Threat Modeling as a Net-New Security Activity Will Strain Your Enterprise

Threat modeling is increasing in both use and reference. Security champions are now being joined by a chorus of regulators and government officials who are singing the praises of threat modeling activities for improved software/ product security. However, implementing threat modeling as a simply another security initiative to layer on to an already burdened enterprise may be the wrong approach when looking to implement a process that could pay long-term dividends to product owners, development managers, and other key internal stakeholders. As with anything else, it’ll come down to execution.

Easy for Me, Hard for You.

Security groups are service departments. This concept may be new to many, but security groups are not profit centers and for the most part serve the needs of the enterprise. Many security teams looking to implement threat modeling are looking for quick wins to impress CISOs and others who are responding to driving forces for implementing some level of threat modeling across an organization. Easy threat categorization approaches or tools that don’t have to be aligned to an elaborate process can surely bring some easy wins for saying, “Look CISO, we got threat models!”, however, these efforts and results will appear to the internal customer as simply another security effort piled onto a dozen or so other security efforts that they don’t understand, or, even worse, value. These well-intended security leaders that introduce threat modeling as a net-new initiative will quickly witness a fatigued, internal customer base that is trying to make sense of the outcomes amongst threat modeling activities and the other 20 security activities that are calling their product “insecure”, “high risk”, “non-compliant”, etc.

As security process owners for DAST, SAST, pen testing, compliance audits, etc. get in line to speak to product owners on some aspect of risk, impact, or threat, adding a threat modeling SME to the end of the line will simply fatigue product owners that are overwhelmed with the litany of security efforts that claim to have unique findings. When all of these security efforts have “critical” or “high” risk issues, those terms begin to lose their meaning amidst a dizzying seesaw ride of security activities. The litany of security activities can often seem to contradict remediation priorities and even undermine remediation queues and timelines. When the above security straws illustrated present a montage of High, Mediums, and Low risk issues, how is the product owner expected to discern which High is the first high to address without the proper context. So, this begs the following questions:

• “Where is the context to all of these security issues?”
• “Why can’t a model of threats for an application actually contextualize software weaknesses, design flaws, insecure libraries, and vulnerable infrastructure as part of its process?”

Well, it actually can, but not with quick and dirty approaches that may check the box, but actually with a risk centric approach that bundles all of the security straws together and processes them within the threat model, for greater context and residual risk identification.

Integrated, Contextualized Threat Modeling Yields More

Risk centric threat models can contextualize a lot of the “security straws” from the diagram above and reduce the security load for the enterprise. In 2015, the Process for Attack Simulation and Threat Analysis was born as PASTA – a risk centric approach to threat modeling that is a step-by-step methodology. As a process consisting of seven stages, it has inputs and outputs across each stage. Many of the security activities that exist in enterprise security today actual “feed” a risk centric, PASTA threat model and, therefore, contextualizes security information into a model of threats for the application.

Common questions by application/ product owners are as follows:

1. “What are the things that I need to worry about?”
2. “Can you show me how this is a {critical | high | medium} risk?”

As many of the security activities depicted in the drawing overwhelm product owners, risk centric threat models provide a framework to which vuln data, exploit testing, threat sources, control scan results, and much more can help truly solve for a residual risk level that looks at more than just any security deliverable in isolation. Models of threats are just that – models. Models need information and credible sources at that. Security programs can introduce risk-based threat modeling as a process that embellishes much of the information produced by DAST, SAST, SCA, Pen Testing, and much more. Risk-based threat models provide an opportunity for the output of various security activities to substantiate a threat assertion, which truly pertains to question #2 above. A threat assertion may be “Data Theft” or “Persistence”. As these unique and tailored assertions are created through the use of threat intel research (already conducted by CTI groups), then a more tailored, credible threat library can be constructed and maintained with SecOps information that stems from assessments, scans, pen tests, threat intel feeds, etc.

Recently a joint initiative around secure design was published by CISA and various other global security agencies and, in the document, it references a growing need for “tailored” threat models. Below is an excerpt from that document with the key call to have tailored models highlighted (see below).

FACT – threats are unique to industry and their impacts are also unique. Threats to system availability may be a bad thing for a banking institution, but may be catastrophic for an energy player. Even within a given sector, companies will and should have unique threat models. Building tailored threat models with tailored threat libraries will leverage some of these other security activities within an enterprise and provide an opportunity to operationalize information from several sources, thereby elevating the credibility of the model itself.

In the risk centric, PASTA methodology for example, internal security controls and governance requirements for crypto use, logging, etc. can be factored into Stage 1 of the methodology. CASM and SSCM tools can enumerate components within an application attack surface which ties into Stage 2 of the approach. Threat intel feeds and correlated SIEM events can substantiate threat claims or assertions built in Stage 4 of the risk centric methodology. Vuln scans from SSCM, SCA, vulnerability scanners, DAST/ SAST tools can denote vulnerabilities that support the possibility that the threat could take place. Stage 6 provides pen testers with a blueprint of a threat objective > targeted component > associated vuln/ weakness to be presented to an adversarial engineer in order to test the viability of an abuse case or attack pattern. As such, the risk centric threat model with PASTA doesn’t introduce threat modeling as simply a net-new initiative, but an actual “wrapper” to contextualize all of this security information for the product/ application owner.

PASTA Threat Modeling Stage 2

“Risk Centric Threat Modeling” (Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis | Wiley), the book that introduced PASTA as a risk centric threat modeling approach, was supported by the now, late, top aid to President Obama, Howard Schmidt. Mr. Schmidt actually wrote the preface to the 1st edition of the threat modeling book. A few years later, several universities, global corporations have since adopted the process as their de-facto threat modeling methodology and have even made their own “PASTA” by leveraging the modularity of the methodology’s stages. GitLab wrote about their adoption and use journey, which can be found here. How we’re creating a threat model framework that works for GitLab.

Most data models need to be fed and threat models are no different. For tailored, contextualized models of threats that are substantiated by various security results, PASTA provides a true risk centric approach that alleviates those security straws from piling and instead focuses on contextualization and integration. Product owners appreciate that a model of threats now contextualizes all of the other security inputs and helps to streamline what needs to be worked on first in terms of remediation.

For more information on the steps, stages, and other artifacts around risk centric threat modeling with PASTA, take a look at the eBook found on Process for Attack Simulation and Threat Analysis – VerSprite.