Put simply, threat modeling is a process to identify all the ways a malicious actor can compromise your systems and gain unauthorized access to your assets. Once identified, the potential threats are then categorized under a risk classification scheme. Decision makers can then strategically allocate security resources based on the prioritized threats.
The idea of looking at one’s fortifications and resources from the perspective of an attacker is not new. Military strategists have used it since antiquity. However, only since the 1970s have system engineers and InfoSec professionals considered how to apply it to IT security.
Reactive cybersecurity allows attackers to find and exploit vulnerabilities. Security then deploys a patch to address the discovered vulnerabilities – and then waits for the next wave of attacks. Threat modeling takes an entirely different approach. It allows organizations to proactively identify and address the potential risks inherent in today’s cyber-ecosystem which are relevant to the organization’s application portfolio.
Threat Modeling consists of three essential components. A malicious actor (aka attacker), the assets (which the organization is working to protect), and a means for the attacker to get to those assets (which are the threats to be identified). The process of enumerating those threats is outlined in the methodology.
Why Threat Modeling is Important
Today’s organizations exist in a highly interconnected cyber-ecosystem. That interconnectivity includes hundreds or even thousands of applications which may interact with one another in unpredictable ways. It includes isolated, grouped, and shared infrastructure components. It includes third party applications and infrastructure elements. And for most organizations, their interconnectedness reaches well beyond the organization’s applications and infrastructure through a vast and growing network of other systems, platforms, and infrastructures. Without a doubt, organizations derive tremendous value from being part of such a networked ecosystem.
However, the increasing interconnectivity also produces greater challenges for today’s security professionals. The potential threats relative to isolated applications and infrastructure components still need to be identified. Increasingly, however, new threats are generated relative to that same interconnectivity. These threats cannot be discovered through isolated vulnerability scans or penetration tests. There are only two ways to find them: passively by allowing individuals to seek out exploitable vulnerabilities (either by white hat or black hat hackers), or proactively through threat modeling.
Threat modeling is highly effective for identifying otherwise difficult to detect potential threats. But that is not the limit of its potential. There are at least four broad reasons organizations to adopt this process:
- Allows DevOps teams to significantly reduce the cost of post-production remediation of vulnerabilities.
- Empowers security teams to enforce consistent standards thereby driving security policies enterprise-wide.
- Security teams make efficient use of real-world, real-time threat intelligence so that stakeholders can prioritize their risk mitigation efforts.
- Enables senior executives to minimize organizational risk exposure and establish data-driven policy.
Producing Actionable Output
Threat modeling can provide significant, quantifiable, valuable, and actionable output to stakeholders across the organization. Developers and architects equally benefit by integrating it into their development process. DevOps teams gain a rapid enumeration of relevant mitigating security controls to support their Agile development methodology. Security teams gain the ability to analyze and track the threats to measure organization’s risk. This includes real-time attack surface analysis that can be drilled down to specific threats and their origins within an application or the operating system. Furthermore, senior executives gain trackable, reportable financial and performance metrics to assess the organization’s existing risk posture.
An effective threat modeling process should – at a minimum – concretely and consistently produce actionable output that includes:
- A list of top 10 threats based on real-time data. This enables key stakeholders to quickly identify the most critical threats and contextually prioritize their mitigation strategy accordingly;
- Articulated abuse cases and the relevant mitigating security requirements. This provides developers and OpSec teams a secure coding roadmap and infrastructure hardening guidelines;
- The identification of high-value targets and potential data exposures which may require more robust controls;
- Seamless integration into the existing Agile methodology workflow, and toolchain of DevOps teams;
- An organizational threat portfolio which is automatically updated whenever a new relevant threat is identified.
Choose the Right Methodology
For a threat modeling process to be effective and result oriented, it is imperative to choose the right methodology and tools. Choosing the proper methodology for your organization depends on the scope of the initiative, the outputs required, and the resources available for investment. When considering how you should do threat modeling today, you need to consider where you want your process to be in the future.
Other methodologies yield security-driven processes. The Visual, Agile, and Simple Threat modeling methodology (VAST), on the other hand, is the first one designed to be driven by the DevOps teams. The underlying principle provides organizations with the ability to scale their process across hundreds or even thousands of threat models while seamlessly integrating with existing Agile methodology workflows and toolchains.
The VAST methodology develops concrete, consistent, actionable outputs for DevOps teams, security personnel, and senior executives by starting with the understanding that the needs of developers are unique from the needs of the infrastructure team. Read more on the VAST methodology.
Who are the Stakeholders
Traditionally threat modeling has been done by security professionals with a high level of subject matter expertise. That was acceptable in the past, but now that threat modeling has become mainstream, the required scope has drastically increased. Organizations are looking to build 500 or more threat models. Also, each threat model must be kept current. Doing this with a traditional DFD-based process would require an army of security experts.
If organizations want a scalable, repeatable process that fully integrates into their existing DevOps workflow and toolchain, it cannot be driven by the security team alone. All stakeholder groups must have an integral part in an enterprise-level process.
The DevOps team should drive the process – that is, those who are intimately familiar with the application design and system deployment will be most effective in building the threat models and providing the contextual details that will allow identification of all relevant threats.
While this may look like it is asking security to take a back seat, the opposite is true. The capacity of an automated process to identify and enumerate relevant threats based on real-world intelligence is dependent on the security team. Their expertise is efficiently utilized throughout the secure SDLC initiative as they create and update a centralized threat library with the necessary associated security controls. Their expertise is also needed to review threat models to ensure the required security controls are in place and to monitor the organization’s attack surface and threat portfolio.
And, of course, senior executives also need to be part of an enterprise-level threat modeling initiative. They drive the security policy organization-wide, establish the context by which threats are prioritized, and set the risk mitigations and other policies.
Contact us for a free consultation to discuss how a scalable, enterprise-level threat modeling process can benefit your organization.