This article “What to Threat Model -- 3rd Party Software” is part of the What to Threat Model series. This article targets Software Acquirers and the Security Champions/Architects working within that group.
Author: John Steven
Soon after modeling some of an organization’s internal applications -- or even because of such modeling -- an inevitable question arises: “How should threat modeling contend with 3rd party components and services?” Increasingly, this question becomes more important to security posture, as engineering evolves from principally a development activity to one focused on integration.
Yes, absolutely, 3rd party components and services are not only likely to require threat modeling, but they may also turn out to be a focal point of threat models. How do you determine what 3rd party material to model? How does modeling 3rd party material differ from what which your organization owns and delivers?
Before we continue, a distinction: this article addresses incorporating 3rd party software within an existing threat model, rather than hunting threats within that 3rd party as a security researcher might. A separate article will tackle the threat hunting use case.
Is This an SBOM Thing?
Historically, Security Initiatives looked at 3rd party code through the lens of Software Composition Analysis (or SCA). Now EO-14028 has them wrestling with the demand they publish Secure Bill-Of-Materials (SBOM). However, these tools and activities are no more a substitute for threat modeling than are Static or Dynamic Application Security Testing (SAST and DAST respectively). So, as with other techniques, leave SBOM and SCA to inform and be informed-by Threat Modeling; never as an implementation replacing it.
SCA or SBOM may provide useful input to threat modeling activities: practitioners sometimes rely on these tools to help discover and diagram a model’s structure. Threat modeling may also help disposition and prioritize these tools’ output.
Perhaps the most effective use of SBOM in Threat modeling is using its results to flesh out the “How” column of the Threat Traceability Matrix described by the What to Threat Model article. Conceptually, practitioners might consider vulnerabilities reported by an SBOM for inclusion in exploit graphs. Each reported vulnerability represents a potentially exploitable exploit in an attack chain.
Not All 3rd Party Material is Created Equally
Thankfully, the 00’s debate of “Which is more secure: proprietary or OSS software?” is over. Still, 3rd party software comes in a considerably different forms and ranges in maturity-of-process and quality. Rather than choose one type over another, organizations model and ingest each differently.
Regardless of what kind of 3rd party software being considered, start as with any threat model, with our two key tools: 1) a diagram and 2) a traceability matrix. 3rd party software typically provides reasonable design diagrams you can replicate in your tool of choice -- in ThreatModeler as a nested diagram for instance. The focus is filling out a traceability matrix and then placing its results back into the tool’s threat framework as component content:
- Identify attack surfaces presented by the 3rd party;
- Enumerate users (code and human) that can access those surfaces;
- Identify provided security controls, gaps; and
- Collate available data on vulnerability and potential weaknesses;
3rd party software contributes to the pile of Lego pieces out of which a larger system is built -- so in keeping with the analogy -- threat modeling conducts the same activities on the ‘brick’ as the ‘build’. Unless the 3rd party software is a platform on which you’re building, it’s often helpful to think about surfaces, usage, controls, and potential weakness at the system level before digging into the 3rd party software. Once set, the organization can ask, “What does the 3rd party component add or subtract from the present posture. This helps set context and prevent wasting time on impossible or out-of-scope aspects of the 3rd party threat model.
Modeling Platforms
A lot of key 3rd party software is commercially licensed proprietary SaaS. Prime examples include Salesforce or Hubspot, or ServiceNow. The SaaS need not be purely web-based, they exist in every space. Examples include Apple’s IOS, Powerapps, Appian, Wix, and countless others. The principal difference between a ‘platform’ and more typical service is that organization not only call key enabling services provided by the vendor, but also build their own custom code on this platform, often on specific programming languages with platform-specific runtime libraries and execution environment specific to that platform. Because of these factors, platforms are one type of 3rd party software to consider before the larger model context: they set the stage and security posture for an organization’s own efforts.
Attack Surfaces:
Platforms naturally present an attack surface between themselves and the application being developed on them. Think of the platform like a Virtual Machine or Kernel: it provides and exposes privileged operations, access to valuable or sensitive resources, and defines/defends system security assumptions (identity, authorization, segments or compartments, etc.). Any exposure application logic creates to its attack surface allows attackers to pivot and attack the platform underneath the application, either controlling or circumventing it. Platforms have many large attack surfaces. For a database, a good start is its dynamic query as well as stored procedures, administrative APIs, and file load interfaces. For a language (Java, .NET, JavaScript, Python): their runtime APIs, code linking/loading libraries, and interpreter API/CLI provide sprawling surfaces. Many of us have familiarity with these types of platforms. Use this familiarity to discover and map surfaces on less-familiar platform you’re modeling.
Generally, expect platform surfaces to be multi-faceted, and look for:
- Facilites to include, load, and dynamically update code
- The runtime API
- Invocation CLI/API
- Inversion-of-Control: Any query or means a user has to cause the platform to execute data input
- Marshalling: any means application logic has to serialize, then import/export code from the platform
- Escape: Shell, exec, etc. Any means the application has to execute code ‘below’ the platform.
For platforms, attack surfaces not only flesh out the ‘where’ within a traceability matrix, they serve as a trust boundary at which modelers must consider “What security assumptions change at this interface?” “What controls are applied by the platform -- or does the platform insist developers apply prior (i.e. authentication, input validation, encoding, or escaping) or subsequent (output encoding, masking/redaction, etc.) to calling?”
Controls:
Modern platforms provide a wide range of (typically) high-quality security controls. Platform documentation typically advertises these controls, leaving deep analysis unnecessary for their discovery. Apply a checklist approach, mapping security controls (e.g. authentication, authorization, encryption, logging and monitoring, etc.) to each platform.
Also document how the platform affects the security control. Candidate mechanisms include:
- Asked of the application developer, when using the platform; (e.g. entity access control, authorization)
- At the discretion of the app developer to properly configure/call within the platform; (e.g. encryption)
- On and secure-by-default, provided w/in the platform; (e.g. secure password storage)
- Intrinsic to the platform, and unable to avoid/disable (e.g. Java/.NET memory management)
These dispositions are important to your model, even when controls are intrinsic to a platform. These will stand either as the controls that “cross out a row” in your traceability matrix (invaliding an attack chain) or stand as security requirements to levy on developers when they interface with a platform component (bullets 1-2 above).
Vulnerability:
As vulnerability data arrives from threat intelligence, SBOM, and other sources, associate that with the appropriate surfaces within the platform component.
Modeling Services
Commercial SaaS providers are an exceedingly common 3rd party software type. From the perspective of the over-arching threat model, consider a) what privileged functions a service provides and b) what sensitive data is sent to, store and/or processed by, and emitted from these services. Doing so will help determine the priority and role of the service in the threat model.
Attack Surfaces:
Unless exceptional, services don’t have the wide variety of attack surfaces that platforms possess. For some cases, their principal and only attack surface will be the API they provide customers itself. One area worth looking at is how hosting and compartmentalization works for the service. At the highest level, consider:
- The deployment models the service supports:
- Public or private cloud hosted,
- Proprietary datacenter, or
- Customer hosted are common options.
- If applicable, consider the compartmentalization model:
- Multi-tenant,
- Single customer tenant.
- Consider IAM:
- Scope(s) of identity,
- Methods of authentication, and
- Any subsequent 3rd party systems (OKTA, etc.) involved.
- Finally, look at how the data encryption model works:
- Site-wide encryption (protects SaaS from some underlying infra attacks)
- Customer-specific encryption, or
- Customer-managed keys, with customer-specific encryption.
Take care to understand the difference between the portion of the API the broader system leverages as well as those endpoints which may be discoverable and accessible to the system and its users.
Controls:
When considering a service’s provided controls, use the scheme outlined above for platforms. Pay particular attention to the first two bullets -- which outline engineers’ responsibilities for applying controls prior to calling and after receiving a response from the service. As with “defensive programming” scenarios, some threat models apply a “second layer” of control around one provided by a service to assure their specific policy is met. Examples might include input filtering or output encoding, or field-level encryption.
Vulnerability:
Historically, adopters could not rely on a timely and accurate SBOM from service providers. That may change in the coming years. In the meantime, practitioners can evaluate -- from a process perspective -- whether the service provider has security practices in place for absorbing external security research (be it functioning vulnerability submission channels, bug bounty, or other means), as well as a functioning and responsive vulnerability disclosure program. If the answer to these questions is “No.”, the organization may have to include this service in their own on-going security research to feed threat modeling. If the answer is “Yes.” threat modeling efforts should consider this information in the traceability matrix.
Modeling Components and OSS
Consider components within the context of the overarching threat model, given the nature of the functions each provide, and the data they consume, emit, and store/operate on. Evaluate the attack surface and controls similarly.
Components and OSS may be less likely to provide SBOM or vulnerability reporting, depending on the stature and maturity of that component. Where the importance of the component warrants, some mature organizations have augmented their threat model’s attack vectors to include SAST and SCA output for important components without solid maintenance and vulnerability disclosure regimes.
What to Do About Risk
We threat model for a singular purpose: creating a reasoned perspective that helps improve security posture. The most common activities owing to this perspective are a) secure design, b) diligence for [3rd party] software acquisition, and c) assessment, testing (existing system posture analysis). Once a 3rd party software has been modeled, the next steps are no different:
- During a lifecycle’s design phase, high priority threats into the backlog of security design spikes. Assure that risk is mitigated through design or that compensating controls are in place.
- During technology selection activities, or in support of software acquisition, incorporate the threat model’s discovered risks in the decision-making process, and -- during approval -- conduct secure design sufficient to meet risk tolerance.
- During a lifecycle’s implementation phase, use the threat model as an information source to a) verify control presence and b) validate resistance to documented potential attacks.
The challenge with 3rd party software, of course, is that alleviating risk from within the system is challenging. Organizations are caught between “maintaining a more secure fork” (where possible with OSS) or “engaging the vendor to improve security posture”. While this may be necessary, instead try to think in terms of compensating controls that can be used in concert with the 3rd party software. Having done the attack surface, control, and vulnerability enumeration described above will facilitate this.
The list of “control mechanisms” described by the Platform Modeling section should raise focus up out of the 3rd party software and assure practitioners include “using the software effectively and securely” as well.
Secure Design with Insecure 3rd Party Components
Remember that it’s not absolute essential to conduct threat modeling proactively, before a system is built (read more Here). Take the output of the activity described above and feed it into other threat modeling activities. Loosely:
- Consider the attack surfaces presented by 3rd party components -- incorporate them into the diagram and traceability matrix:
- Define trust boundaries for the internal surfaces and evaluate control effectiveness at that interface;
- Add adversaries (“who”) and potential misuse (“what”), as well as the surface itself (“where”) to the traceability matrix for external surfaces;
- Consider the controls offered by the 3rd party software, do they:
- Mitigate any existing documented attack paths within the traceability matrix?
- Add these controls to components within the ThreatModeler product.
- Consider the vulnerabilities as:
- Additional attack vectors in the traceability matrix (“how”)
- Add exposure (“threats”) to components within the ThreatModeler product.
It is possible to build a secure system out of untrusted components -- we’re doing this all the time. So, threat modeling 3rd party software is more about iterating secure design to compensate, than it is about selecting or rejecting components.
