Blog

Is Every Diagram a Threat Model?

  • 10 April 2023
  • 3 replies
  • 176 views

Userlevel 4

With Executive Order 14028 and the compendium NIST Internal Report 8397, organizations are required to diagram their software and along with that conduct threat modeling exercises. In this context, order 14028 supplies the mandate and IR 8397 provides guidance for how to comply.  Whereas practitioners can quickly interpret and implement given SAST guidance from IR 8397, threat modeling guidance demands interpretation. For instance, when discussing threat modeling technique, IR 8397 references an SEI paper that itself refers to twelve (12) methods of threat modeling.  

Shevchenko's "Features by Threat Modeling by Method" - See Original

 

In her SEI paper, Shevchenko provides a table (see right) describing the different features of various threat modeling methodologies. Before proceeding, note that there are different classes of “method” within this list. Some, like CVSS or OCTAVE focus on scoring risk. Others, like STRIDE, or SECURITY CARDS focus on evaluating a checklist to discover risk. Still others, like VAST or PASTA, reflect more complete methodologies, inclusive of adversary analysis, risk discovery, and then scoring and prioritization. Having so broad a field of choices elicits a glaring challenge. Its simple formulation: “What will regulators deem ‘good enough’ to suffice as threat modeling?” Presently, it’s unclear. Will simply doing thought exercises with security cards suffice? Probably not. While wrestling with these questions some organizations have already asked a natural follow-up: “Is any diagram a threat model?” The answer:

“No, not any diagram suffices as a threat model.”

 

Towards a Minimum Standard

If organizations desire a comprehensive methodology, there are common elements they should seek to represent in their diagrams. Specifically, in order to detect architectural flaws, and support secure software design, a diagram should have the following characteristics. It should: 

  • Depict key structural, behavioral, and data-based aspects of applications and infrastructure;
  • Identify attack surfaces depicted in user interfaces, APIs, social or business workflows, and data feeds;
  • Differentiate adversaries by capability, motivation, and access to attack surfaces; and
  • Highlight both privileged functionality and sensitive data assets. Finally, the diagram will 
  • Explicitly call out security controls referring to details of their function. 

While there are plenty of other optional complements to diagram properties list above, this reflects the “minimum standard” for diagramming. Prosaically, a diagram should depict the system and orient practitioners to both its attack surfaces and its valued assets, then place specific adversaries within that context for attack modeling and secure design.  

Depicting the Minimum Standard’s Key Aspects on a Single Page

There is no “one-size-fits-all” diagramming convention that works for threat modeling. In fact, the best advice that can be given to security practitioners is to start with existing engineering documents and diagrams then augment them to assure the above aspects are present. Starting with existing documentation not only saves time and effort, but it also helps assure that engineers can participate in, understand, and conduct secure design based on the produced threat model. 

Assure that every threat model is represented by a single “one pager” overview diagram depicting the total scope of analysis. If different aspects of that scope require a “zoom in”, or different depiction (because data flow or behavior requires emphasis), create a compendium diagram. In the ThreatModeler tool, this can often be accomplished in concert within the “one pager” using nested models.

Rather than conform to a single diagram template, select a diagramming style that emphasizes the key assets or privilege in the system under analysis. ETL pipelines may benefit from depiction of data flows with emphasis on encoding, transformative operations, persistence properties, and access control. Protocol’s or business workflows (shopping cart and purchase, credential reset, etc.) are principally behavioral, and may benefit from augmenting a sequence or state-transition diagram. 

Finally, ensure diagrams depict both software and infrastructure layers of the system, as each inform the other context and posture can’t be evaluated without both. Be sure to explicitly call out middleware, development frameworks, key services present between software and infrastructure.

Success Criteria

Summarizing, there must at least be a diagram. That diagram should likely include infrastructure, software, and process aspects of the system being considered. The diagram may refer to others necessary to depict key aspects of system structure, data flow, or behavior.

Identify Attack Surfaces

Attack surfaces hide everywhere, often in plain sight. Most importantly, they exist in multiple dimensions, from logical, to physical, to social. Within the diagram, annotate surfaces by depicting one or more classes of adversary that access each

Start by depicting the surfaces present for each user story from a UI/UX perspective, then add both underlying and free-standing APIs as well. APIs are important to depict, even when underlying UI/UX because they:

  • Represent a broader scope of functionality than the UI itself;
  • Offer opportunity to circumvent browser-based or intermediary service functionality (encoding) as well as controls (access control, namespace scoping, validation, escaping); and
  •  Are often publicly accessible and sometimes documented, if not advertised.

Continue by adding surfaces supporting alternative flows to the depiction. Supporting user flows can entail customer-success, administrative, or other operations functionality.

Depict both data feeds consumed and produced by the system. ETL pipelines, message bus/queues, and certain well-connected data stores are good candidates for depiction.  

Remember, 3rd party SaaS systems often are called and respond to internal APIs. Some reach out of their own accord as “users” to invoke these APIs. As such, the system endpoints that interact with 3rd party SaaS in either a producer, consumer, or bi-directional manner are attack surfaces. These are in scope.  

Success Criteria

A threat model should denote its attack surfaces. Attack surfaces should include the UI as well as underlying and adjacent APIs accessible to in-scope user (potential victims) and adversaries. Enumerated attack surfaces should include not just ‘front-end’ ‘happy-path’ interfaces, but those supporting alternative flows, as well as any surfaces that result from back-end processes or 3rd party interactions.    

Differentiating Adversaries

Adversaries are an important complement to attack surfaces. Within the diagram, each adversary is an avatar that holds capabilities, motivations, and access at an attack surface. These attributes direct attack modeling activities from an attack surface to assets. Adversary descriptions encode the aspects of how each attack chain ‘wants to develop’ (motivation) and whether it ‘is able to reach’ (capability and access) its goal assets

When defining adversaries at first, it may help to do so by category. Organizations sometimes consider an increasingly scale of three categories at first:

  1. Casual security researcher (e.g. bug bounty participant);
  2. Organized crime or competitor; and 
  3. Nation state security agency.

Enumerating adversaries can then proceed by considering the system’s users through the lens of:

       a) victimizing each user; and

       b) projecting malicious intent onto those users.

The above list (1-3) defines a set of three capability classes for adversaries, whereas the lens (a-b) of victimization and malice aids in brainstorming motivation.

Having considered the intersection of those two lists creates a great start for potential adversaries. Explicitly consider and park (exclude) adversaries that are out of scope for a threat model. Exclusion is as worthwhile an exercise as detailing the capabilities for in-scope adversaries. Many a threat model has been driven off the rails by characterizing and attempting to design a mitigation to risk only exploitable by a threat agent the organization wasn’t interested in countering. 

Continue by adding the users from alternative flows into the adversarial analysis. Again, candidate alternative flows and users may include customer service, system operation, or engineering. 

Success Criteria

A threat model should define the adversaries whose activity is deemed in scope for design to thwart. Defined adversaries should at least include adversarial analysis conducted on the user population. The definition of those adversaries should be scoped by the motivation, capability, and access of each. 

Highlight Privileged Functionality and Sensitive Assets

Adversaries need goals and threat models should explicitly enumerate them. Conceptually, an attacker’s goal may be anything an adversary can monetize as valuable. Many threat modeling methods fixate on data as the principal means by which an adversary gets value. However, functionality can be as or more lucrative to exploit, particularly when privileged. What constitutes privileged functionality may be a direct analog in the digital domain, such an electronic funds transfer, discount, or reward. Other goal functionality may reflect internal business processes, such as order refund or underwriting. Organizations should evaluate their systems thoroughly for privileged functionality including:

  • User lifecycle steps such as sign-up, credential reset, and others;
  • Customer service functions such as user impersonation or maintenance; and
  • Corrected customer transactions (reimbursement, replacement, etc.).

Privileged functionality can reflect a technical analog to tasks above, such as “obtaining or renewing a session token”. These serve as technical proxies for assets of value. It may also include IT tasks as well, such as:

  • Obtaining and/or using material that codes-for identity, such as a session or cryptographic key;
  • Obtaining and/or using material that codes-for an entity, such as a GUID;
  • Administrative functionality: service deployment, start, and stop; or even
  • Development, orchestration, deployment, and operational privilege available in production.

Success Criteria

An organization is probably done enumerating assets when it’s considered the following three perspectives; the:

  1. Business - The various ways the business makes money and generates value to its owners;
  2. Users - The privacy and value the customer expects from the organization; and
  3. Attacker - The various ways adversaries can monetize both assets and their metadata. 

A threat model should enumerate and value attacker goals from all of these three perspectives across the business and technical domains. 

Enumerate and Place Security Controls

In this context, controls are any means by which a security property is afford the organization’s systems, data, or processes. They may be safeguards that prevent or counteract vulnerability or risk impact. Controls take a variety of forms, complicating their representation for Threat Modelers. Some, of course, are:

  • Infrastructural -- like Firewalls, WAFs, hardware key vaults;
  • Software-based -- contextually-aware output encoding, encryption; 
  • Toolchain based -- Heap/stack organization, code signing;
  • SaaS -- Authentication, authorization proxies; as well as
  • Emergent -- controls and design that provide “least privilege” or “compartmentalization” in aggregate;
  • Biometric; and
  • Process-based: such as mailing account information. 

Depicting this myriad of different types of security controls challenges organizations. Some controls are best depicted as objects in their own right within a diagram. Others are better suited to be attributes, badging a depicted object. Biometric or process-based controls may not fit inside certain diagramming contexts comfortably unless you’ve chosen the process-flow diagramming format.  

Success Criteria

Regardless of how security controls are manifest in your organizations diagrams, they should be a) present, and b) visually associated with the risks they are intended to prevent or counteract. 

 

Summarizing 

Yes,  it’s unclear, at an industry level, as to what a sufficient and successful threat model and diagram entails. Though they have tactical uses, it is unlikely that a single diagramming modality (such as data flow diagrams) with only a small set of features (nodes, edges denoting flow, and trust boundaries) will suffice. Instead, organizations will likely need different diagram styles, each with its own set of characteristics, for different systems or situations. Again, such characteristics are likely to include:

  • Depicting key structural, behavioral, and data-based aspects of applications and infrastructure;
  • Identifying attack surfaces depicted in user interfaces, APIs, social or business workflows, and data feeds;
  • Differentiating adversaries by capability, motivation, and access to attack surfaces; and
  • Highlighting both privileged functionality and sensitive data assets. Finally, the diagram will 
  • Explicitly calling out security controls referring to details of their function. 

Holding threat modelers responsible for incorporating these characteristics in every diagram will help make effective and impactful diagrams.


3 replies

Userlevel 2
Badge +1

Tremendous article and insight, John! Most prospects lean on the STRIDE methodology for their “early-stage” threat modeling program. This is a good starting point, but has limitations and will prevent teams from a truly successful threat modeling program.

Userlevel 4

Tremendous article and insight, John! Most prospects lean on the STRIDE methodology for their “early-stage” threat modeling program. This is a good starting point, but has limitations and will prevent teams from a truly successful threat modeling program.

Thanks @Mitchell DeMazza. As you point out, STRIDE is a fine starting point for organizations with emerging threat modeling practices. However, the challenge of evolving from a such a checklist-based approach to this sort of minimum standard for diagramming will be greater than from approaches like VAST or PASTA, to which practitioners can incrementally add aspects such as I describe.

If an organization is committed to STRIDE as a fitness test for its table top or threat modeling exercises, I suggest they add diagrams with adversary analysis, attack surface, goals, and controls as a companion ‘workbench’ on which to conduct stride and incrementally build maturity.  

Userlevel 2
Badge +1

Thank you for the insightful article and for fully confirming that not *every* diagram can be a threat model.

Reply