Application Threat Modeling

Get Creative, Stay Informed, and Build Bonds with Threat Modeling

Charles A. Jacco

Charles A. Jacco

Principal, Cyber Security, KPMG US

+1 212-954-1949

Alexander Smith

Alexander Smith

Associate Advisory, Cyber Security Services, KPMG US

+1 480-284-3292

Bo Pratt

Bo Pratt

Associate Advisory, Cyber Security Services, KPMG US

+1 212-758-9700

Caleb Queern

Caleb Queern

Director, Cyber Security, KPMG US

+1 571-228-8011

Get Creative, Stay Informed, and Build Bonds with Threat Modeling

Finding and fixing security flaws in production is much more costly to an organization than finding them earlier in the software development life cycle (SDLC). In order for IT organizations to stay competitive, security must be a mindset that’s embraced from the beginning – starting with planning & design considerations.

While introducing security in the software planning and design stage, most security automation is not available yet, so consider other creative methods to reduce risk.  Threat modeling is an effective option that includes creativity and involves team building.

Why Use Threat Modeling?

When you threat model early, you not only satisfy security’s goal to keep information and devices secure by design, but you also satisfy the business need to keep costs and risk low by catching issues before they manifest themselves into more expensive problems in production.

How to Get Started

Threat modeling is a process that involves mapping out an application’s functionality, looking at the application through the eyes of an attacker, and finding ways to mitigate possible threats. Threat modeling in the early stages of design is a great way to build bonds between developers and information security from the get-go, as it involves a joint effort between teams with different perspectives.  At its core, threat modeling seeks to answer the questions:

  • How could a malicious actor intentionally abuse functionality of the application?
  • What can be done to prevent this?

Step 1: Decompose the application

Seek to gain an understanding of the application’s purpose, its audience, and its dependencies. Think about what type of information is processed, where it originates, and where it is stored.

Step 2: Mapping the flow of data

With your new understanding, create a Data Flow Diagram (DFD) to visualize how data moves across your application and how different users and systems interact with it. Look at how data is protected in transit and at rest. Use elements like “actors”, “processes”, and “data stores” to depict your environment. Whiteboard with your team and welcome opinions, ideas, and related discussion to the table.

Step 3: Taking the attackers perspective

Use your DFD to discover threats by looking for ways into and out of the system, opportunities for configurations to be set improperly, with special focus on functionality involving privileged access. Understand what the valuable assets are and how they can be modified, accessed, or abused. A framework like “STRIDE” can be used for categorizing and understanding threat tactics, techniques & procedures. STRIDE is an acronym that represents common threat categories:

  • Spoofing
  • Tampering
  • Repudiation
  •  Information Disclosure
  • Denial of Service
  • Elevation of Privilege

Step 4: Determine threat risk levels & mitigations

With your new level of understanding you can rank threats by their overall impact by using risk assessment models, like “DREAD”, that consider various threat characteristics:

  • Damage
  • Reproducibility
  • Exploitability
  • Affected Users
  • Discoverability

After you’ve ranked your threats, discuss ways to reduce the likelihood and impact of the threat. Recognize controls that are already in place, and document recommendations for improved risk mitigation.

Three final “pro tips”...

  1. Don’t treat threat modeling as a “one and done” exercise. Applications are meant to change over time, and any major update should trigger a refresh of the existing threat model.
  2. Not all risk is found “in production”. Consider including the continuous integration / continuous delivery (“CI/CD”) pipeline in a threat modeling exercise for a more comprehensive view of the risk to an application. Build pipeline security has taken on increased importance in the wake of the SolarWinds event of December 2020.
  3. Looking for “friendlies” on the application teams to engage for threat modeling exercises? Security champions programs are great ways to identify or create such allies.


Threat modeling introduces security from the onset of a new product, helps enforce a security related mindset with developers, and perhaps most importantly, fosters team building between devs and information security. Leaders should consider investing in threat modeling for their most business-critical applications at a minimum. Reach out if you would like help in getting started with your threat modeling journey.


  1. KPMG LLP (US), “Integrating security into your DevOps environment”, (June 11, 2019).
  2. KPMG LLP (US), “Don’t overlook configurations as you embrace DevOps”, (June 29, 2021).
  3. LLP (US), “Dynamically determining application risk for greater risk reduction”, (June 21, 2021).
  4. KPMG LLP (US), “Security monitoring for software build pipelines”, (March 19, 2021).
  5. KPMG LLP (US), “SolarWinds explainer”, (2021).
  6. KPMG LLP (US), “Why a 'security champions program' is a great investment”, (June 6, 2019).
  7. LLP (US), “Rebooting DevOps security by design”, (December 1, 2021).

Related content

This article represents the views of the author only, and the information contained herein is of a general nature and is not intended to address the circumstances of any particular individual or entity. No one should act on such information without appropriate professional advice after a thorough examination of the particular situation.

The KPMG name and logo are trademarks used under license by the independent member firms of the KPMG global organization.