The Need for Continuous and Dynamic Threat Modeling

The trend towards accelerated application development, and regular updates to an architecture through an agile methodology, reduces the efficacy and effectiveness of point-in-time threat modeling. This recognition led us to explore and strategize ways to continuously, and dynamically, threat model an application architecture during runtime.

Today, thanks to a robust DevOps environment, developers can deploy a complex architecture within a public cloud such as Amazon Web Services (AWS) or Google Cloud Platform without requiring support from a network or database administrator. A single developer can develop code, deploy an infrastructure through code into a public cloud, construct security groups through code, and deploy an application on the resulting environment all through a continuous integration/continuous delivery (CI/CD) pipeline. While this enables deployment velocity, it also eliminates multiple checks and balances. At Cisco, we recognized the risks introduced by such practices and decided to explore strategies to continuously evaluate how an architecture evolves in production runtime to guard against architecture drift.

Dynamic threat modeling must begin with a solid baseline threat model that is done in real-time. This can in turn be monitored for architecture drift. Our approach to obtain such a real-time view is to use dynamic techniques to allow security and ops teams to threat model live environments instead of diagraming on paper or whiteboards alone.

How Does Dynamic Threat Modeling Work?

Threat modeling is the practice of identifying data flows through systems and various constructs within an architecture that exhibit a security gap or vulnerabilities. A crucial element that enables the practice of threat modeling is generating the right kind of visual representation of a given architecture in an accurate manner. This approach can differ based on context and from one team to another.  At Cisco, we instead focused on elements and features that need to exist to allow a team to dynamically perform a threat modeling exercise. These elements include the ability:

◉ To transform an operational view of an architecture to a threat model

◉ To contextualize a requirement

◉ To monitor the architecture for drift based on a requirement

From Operational View to Threat Model

Numerous tools exist that can render an operational view of an architecture. However, an operational view of an architecture is not the same as a threat model. Instead, an operational view must undergo a transformation to create a threat model view of an architecture. For this to occur, the solution should at a minimum provide a way to filter and group queries within an architecture so that only relevant data is visually rendered.

As an example, consider a case where an AWS hosted public cloud offer consists of two types of S3 buckets (Figure 1). One type of S3 buckets is deployed for customers for them to access directly. Each customer gets their own unique S3 bucket to access. Other types of S3 buckets are deployed for organization-specific internal administrative purposes. Both types of S3 buckets are identified through their AWS tags (“Customer” and “Admin” respectively). A filter-based query applied to an architecture of this type can answer questions such as “Are there S3 buckets with Tag: ‘Customer’ or ‘Admin’ in this architecture?”

Figure 1. Operational Views with and Without Filtering or Grouping Applied

Even though grouping is like filtering, it differs because it allows an administrator to query an architecture with the question: “Are there S3 buckets with the Customer or Admin tag in this architecture? If so, group these assets by their tags and logically represent them by their tags” (Figure 2).

Figure 2. Operational View with Grouping Applied by Admin or Customer Tags

What Does it Mean to Contextualize a Requirement?

With dynamic threat modeling, contextualizing a requirement allows a team to prescribe a contextualized remediation plan for a specific area of the architecture so that it can be monitored for architecture drift. This event is the next step towards securing an architecture from specific threats at a more granular level once the appropriate base line security guardrails have been applied towards an environment.

To build on the example from above, industry standard best practices towards securing a S3 bucket prescribes configuring S3 buckets as non-public. As mentioned above, the first type of S3 bucket is offered to customers for them to access (for read or write). Furthermore, each customer gets their own unique S3 bucket. The second type of S3 bucket is used by the organization’s internal administrative purposes. Once the standard guardrails have been implemented towards the two types of S3 buckets, the next step is to determine the type of access authorization that should be applied towards the two types of S3 buckets based on the purposes they serve (Figure 3).

Figure 3:

Ability to Monitor the Architecture for Drift Based on Requirements

As previously mentioned, the goal of dynamic threat modeling is to monitor the architecture that has been threat modeled in real-time for architecture drift. This should not be confused with the ability to monitor a network for vulnerabilities. To monitor for vulnerabilities, there are already numerous tools within the industry to help a DevSecOps team determine areas of risks. To monitor for architecture drift, a solution must be able to tie together a sequence of events to determine if the appropriate context exists for the events to be considered as drift. To continue our example from Figure 3, Figure 4 below outlines the areas within the S3 architecture that should be monitored for architecture drift once the contextualized requirement has been applied.

Figure 4. Monitoring Applied to Customer and Admin Buckets Grouped Based on Requirements

Challenges and What the Future Holds

By enabling dynamic threat modeling, DevSecOps can continuously monitor an environment in real-time for any architecture drift. However, the following challenges must be addressed by DevSecOps:

◉ Apply better conversion techniques to transform an operational view to a threat model

◉ Develop better strategies to codify human-based contextual requirements into actual rules

◉ Drive a consistent baseline security strategy that can be evaluated based on various architectures

Security is a journey that requires influencing and enabling teams to adopt and employ best practices and controls for their architectures. By continuing to enhance this strategy and addressing the challenges mentioned above, we anticipate wide adoption and acceptance of continuous and dynamic threat modeling of live environments to monitor for any architecture drift and proactively mitigate the risks in the fast-paced world of DevSecOps.

Figure 5 illustrates what we’ve accomplished at Cisco as we strive to raise the bar on security and the trust of our customers.

Figure 5. Cisco Security Automation for DevSecOps Features

Source: cisco.com