In this article, we’ll explore how threat modeling can help with vulnerability management. We’ll also add an example with a diagram.

I also wrote an article about threat modeling versus vulnerability management. It outlines the similarities & differences between the two.

This is roughly how vulnerability management works in large enterprise companies (with some over-simplification & exaggeration):

• Build a (software and infrastructure) project to meet IT or business needs. The project will include lots of software, code, perhaps some middleware, and supporting infrastructure. I’ll include some detailed examples of items that may be included:
  • Open source software, including lots of underlying frameworks, libraries, imports, etc.
  • Importing a framework, which in turn has many dependencies, some of which have yet more dependencies. It turns out that lots of code is used as part of the final solution.
  • A vendor solution is bought to solve one piece of the overall puzzle. That piece of vendor solution requires Java Runtime Environment (JRE).
  • Multiple Virtual Machines with Linux or Windows are required to host part of the solution.
  • A (PostgreSQL or MS SQL) database is required for local data storage.
  • An API solution is required to open external access, which in turn requires changes to the underlying software, and more imports & dependencies.
• Deploy the project to production and start running it. The team notices that there are some problems with deployment and re-work is needed requiring yet more middleware tweaks.
• Fast forward 6 or 12 months, and now there are all kinds of vulnerabilities throughout the tech stack. Everyone is surprised how many vulnerabilities have accumulated in such a short time. The team is unsure how to apply the vulnerabilities. Vendors are needed to help explain how some vulnerabilities can be remediated, but this adds to the remediation time.
• The vulnerabilities start to build up. Now there’s a backlog of vulnerabilities.
• Teams have difficulty understanding the impact of specific vulnerabilities. This is crucial information when prioritizing vulnerability remediation.

Multiply this by 100 or 1000 to cover all the various projects that have been carried out within the large enterprise company over the last few years!

How Threat Modeling can Help

Threat modeling can’t solve all vulnerability management problems. But it can help with the following:

• Identifying potential sources of vulnerabilities early on in a project, and thus allowing teams to prepare for such vulnerabilities, including having plans in place to remediate vulnerabilities.
• Determining the overall impact of vulnerabilities in a project. This provides valuable information for prioritization.

Identifying Potential Sources of Vulnerabilities Early on in a Project

How it works:

• In an architecture diagram or an overview of components, identify whether components are susceptible to vulnerabilities. There are two potential sources of vulnerabilities:
  • Code-related vulnerabilities (i.e., a code base can contain vulnerabilities or import them via a framework, library, etc.).
  • Infra-related vulnerabilities (i.e., contains infrastructure or middleware components that can have vulnerabilities).
• Once components have been identified, determine a (preparedness) plan to remediate (future) vulnerabilities. The details can vary based on the expected types of vulnerabilities.
• Ensure that all types of software and infrastructure are included in the threat model. This will help to assess whether new vulnerabilities affect the overall solution. One of the challenges in vulnerability management is assessing whether a vulnerability affecting a type of software is relevant to a project. Think of it as a basic Software Bill of Materials (SBOM).
• Highlight software that has a history of (new) vulnerabilities being identified. For example, Java (nothing against Java by the way).

Determining the overall impact of vulnerabilities in a project

How it works:

• A project will have details like the following: the overall goal of the project, the type of data included within the project, the type of personal data included within the project, the criticality of the project within the wider business, etc. These details will help a team to understand how the project and the company will be affected by vulnerabilities (at a high level). Typically, companies will also have CIA ratings or similar to determine criticality. At the very least, the threat model should indicate:
  • Overall criticality of the project (for the company).
  • Internal and external exposure (indicates the likelihood of vulnerability exposure).
  • Affected components (by the vulnerability).

An Example Diagram

The above diagram shows how vulnerability insights can be added to a threat modeling diagram:

• It includes an overview of components that are susceptible to vulnerabilities.
• It includes an indicator regarding the potential vulnerabilities per component (i.e., what types of vulnerabilities).
• It includes types of code and libraries used (limiting to examples only: for a real-world threat model, we would fill in the specific code and libraries used).

The above information may seem simple to some. However, many teams that manage projects and solutions with various IT assets struggle to understand which components are susceptible to vulnerabilities, what those vulnerabilities are, and how to solve them.

Note that such a diagram, with vulnerability insights, should be updated periodically once more experience is gained in managing the components and their vulnerabilities.