Mitigating Risks the Agile Way
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 is the open-source toolkit which allows to model an architecture with its assets in an agile declarative fashion as a YAML file directly inside the IDE or any YAML editor. Upon execution of the Threagile toolkit a set of risk-rules execute security checks against the architecture model and create a report with potential risks and mitigation advice. Nice-looking data-flow diagrams are automatically created, as well as other output formats (Excel and JSON).
The risk tracking can also happen inside the Threagile YAML model file, so that the current state of risk mitigation is reported as well. Threagile can either be run via the command-line (also a Docker container is available) or started as a REST-Server.
Threagile was released as the open-source toolkit for agile threat modeling at Black Hat Arsenal 2020 and DEF CON 2020 AppSec Village conferences.
For more details about Threagile see threagile.io, GitHub Repo, and DockerHub Repo.
Video and slides of my talk at DEF CON 2020 AppSec Village about Threagile as well an introduction video with demos:
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 (business, architecture, development, operations) 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):
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):
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.