Agile Threat Modeling

Threat Modeling Scope & Contents

In an agile threat modeling approach I will start with a kickoff workshop (remote or on-site) with members of your architecture and development team and discuss lots of security topics related to your architecture. My detailed question list, based on my development, pentesting, and threat modeling experience, addresses important security aspects of your software.

This approach checks for many aspects including:

  • Vulnerabilities in software architecture
  • Vulnerabilities in critical business functions, like payment etc.
  • Vulnerabilities in authentication & authorization (including tenant isolation)
  • Vulnerabilities in exposed and consumed communication interfaces
  • Vulnerabilities in consumed data formats
  • Vulnerabilities in containerization and their orchestration
  • Vulnerabilities in cloud connections
  • Vulnerabilities in authentication and authorization
  • Vulnerabilities in encryption and digital trust handling
  • Vulnerabilities in transfer and storage of sensitive data

Next, during the main part of the agile threat modeling approach, I create the initial version of the Threagile model input data (the YAML file) to further work with the open-source Threagile toolkit for agile threat modeling.

Threagile enables teams to execute Agile Threat Modeling as seamless as possible, even highly-integrated into DevSecOps environments.

Threagile was released as the open-source toolkit for agile threat modeling at Black Hat Arsenal 2020 and DEF CON AppSec Village 2020 conferences. With this toolkit, which comes as a command-line interface (CLI) as well as a REST-server, a YAML model input file describing the architecture is processed in order to derive risks (using risk rules) and auto-generate a detailed data-flow diagram and various report formats (PDF, Excel, JSON).

For more details about Threagile see threagile.io, GitHub Repo, and DockerHub Repo.

Identification of Custom Risks

Of course the semi-automated agile threat modeling approach includes manually identified custom risks, which will be individually added to the Threagile model input data (the YAML file). That way all individually identified risks in the archietcture are presented and processed along with the other risk-rule based risks to avoid media breaks.

This is where my experience in threat modeling and security architecture comes in: Identification of individual risks, which are not identified by risk-rules and automation. Hence that way the threat model report includes also untypical and highly individual risks, based upon the initial threat modeling workshop mentioned above.

If you like to automate your usage of Threagile with individual risks in your corporation’s software architectures, custom risk-rules can be created in Threagile easily. As the developer of the open-source Threagile toolkit I can help you with that for your first custom risk-rule.

Risk Tracking

The risk tracking is also performed inside the Threagile model input data (the YAML file), so that during a debriefing workshop we can collectively assign states like accepted, in-progress, *mitigated”, or other to each risk (or categories of risks). This risk tracking will then be reflected inside another execution of the open-source Threagile toolkit, effectively reducing the number of remaining risks.

Detailed Reporting

The resulting report of the found risks includes detailed descriptions of the findings (along with all evidence collected) and mitigation advice to remediate each issue and tips to further harden your application. To better distribute the individual findings towards the relevant parties, I categorize all findings by function (development, operation, architecture, business) to which the finding applies.

After sending the report an on-site or remote debriefing meeting will be arranged to further discuss the report and any potential questions along with the team members assigned to remediate the findings.

As the report includes all Threagile model input data (the YAML file), you can independently adjust the model input as your architecture evolves and execute a fresh Threagile run with the open-source Threagile toolkit. This effectively keeps your model continuously up-tp-date.

Example Threat Model Report

In order to get some idea of how the agile threat modeling approach with the open-source Threagile toolkit is able to generate a risk view and data-flow diagram (DFD), here is the auto-generated DFD of a fictitious example application (click to enlarge the image):

Data Flow Diagram (auto-generated)

In order to get some idea of how such a report looks like, here are some results of a fictitious example application (click to enlarge the images):

Management Summary
Mitigation Tracking & Remaining Risks
Function Assignment & STRIDE Mapping
Data Loss Probabilities
Risks & Mitigation Recommendations
JSON Export (for further DevSecOps processing)

Prerequisites

Agile threat modeling mainly consists two of separate workshop days (remote or on-site) with your architecture and development team. It helps if some information about the architecture is given upfront, so that the first workshop can start well-prepared.

In between these two workshops I work (usually remote) on the collected answers and feedback to create an initial threat model. During that period it is helpful to have some team member as person of contact for detail questions during the model creation.