How-to Perform Threat Modeling
Threat modeling is the process of analyzing various business and technical requirements of a system identifying the potential threats, the mitigations of these threats, and documenting the vulnerabilities these threats have on the system.
Note: Threat modeling isn't a one-time activity. It needs to be repeated in increments and iterations and checked at specific milestones during product development.
The purpose of this guide is to explain how to create and maintain a threat model in an agile way, and how to ensure that the threat model is ready at release.
It walks through the activities to be executed in each increment. For more information on how to compose the threat model, see 3BSE070612 Threat Modeling Guideline.
Intended for
Architects, cyber security engineers, software developers, test engineers, and product owners.
Activities
Plan threat modeling activities
Threat modeling is a part of the agile development process, and it shall be planned and performed in each increment. During planning for the next increment, development and architecture teams shall check if planned design changes may affect the existing threat model or if input from other sources indicates an update is needed. If this is the case, plan for the threat model revisions accordingly.
The threat model updates are transparently planned in Azure DevOps (ADO) as features (enablers) and added to the stream backlogs. Ideally, each increment should have its own features defined to ensure that the threat model is independently checked, whether any changes are required or not.
The architects identify the threat model requests based on changes in the architecture, and the cyber security engineers identify requests based on design changes.
Update threat model
In general, involved people shall create and maintain the threat model using the recommended threat modeling tools (Microsoft Threat Modeling tool is highly suggested). Publish the threat model on the ADO wiki to make it visible and accessible to the teams.
Note: Each development stream shall have its own architecture documentation in ADO wiki (preferred) or GitHub. The threat modeling section on the wiki must be up-to-date with the latest available threat modeling diagram.
Document the components that make up your system. A clearly documented model of your entire application simplifies the analysis. Note down use cases, data flows, data schemas, and deployment diagrams.
There are two types of visualizations you can build:
- Data flow diagram (mandatory): It depicts how data is designed to move through your system. It shows the operational level and displays where data enters and exits each component, data stores, processes, interactions, and trust boundaries.
- Process flow diagram (optional): At an application level, it depicts how users interact and move through various use cases.
While data flow diagrams focus on how your system works internally, process flow diagrams concentrate on user and third-party interactions with your system.
Identify the most important actors and assets in the threat model diagrams.
Review threat model
Review the threat model on the ADO wiki. Check the validity and correctness of the updated threat model, and align the model with the architecture documentation and related software components.
Use pull requests to capture any review comments or further updates.
The cyber security engineer moderates the review and makes the final approval of the updates.
Evaluate threats
Based on the threat model, identify which one of the assets can be compromised by potential attackers.
For example, use a STRIDE checklist (spoofing identity, tampering with data, repudiation threats, information disclosure, denial of service, and elevation of privilege) for the dataflows that cross a trust boundary.
Keep the list of the identified threats and vulnerabilities together with the threat model.
If changes in the threat model highlight new findings (not known from the previous cycle), these need to be investigated.
Once the threats are identified, you have a master list or library of threats associated with each asset, its operations, and a list of possible attacker profiles. Analyze which of these threats are applicable to your modeled component/product) and identify proper mitigations in order to reduce the likelihood of the threat (from "High" to "Medium" or "Low").
Make an initial ranking of which threats that need to be mitigated or not.
Resolve threats (or identify mitigations)
When threats are evaluated, mitigations need to be identified to reduce the likelihood of the threat. The evaluation of the effectiveness of the mitigation requires to identify and accept a certain level of risk, in case the threat occurs, based on the impact on the product.
From National Institute of Standards and Technology (NIST): “The risk is a measure of the extent to which an entity is threatened by a potential circumstance or event and is typically a function of the adverse impacts that would arise if the circumstance or event occurs and the likelihood of occurrence”.
The risk assessment addresses the potential adverse impacts to ABB systems and assets, see 3BSE070612 Threat Modeling Guideline).
Based on the risk analysis of the threats, you can deal with the vulnerabilities in the following ways:
- Don't do anything (risk accepted).
- Remove the feature associated with it.
- Turn the feature off or reduce the functionality.
- Make code, infrastructure, architecture, or design fixes.
Enter the vulnerabilities that need to be addressed in ADO (to be included in increments or iterations). Tag them as "security" bugs and track them to closure.
Note: In case the risk is ‘not acceptable’ and no solutions can be applied, the head of cyber security or the cyber security product manager shall be involved for final approval.
Validate threats (or validate mitigations)
Mitigations shall be individually validated, by proper test cases defined for them, and the result approved by cyber security engineer.
Validate (for example in tests) the threats and vulnerabilities that are addressed. Make sure the threat modeling is completed (that features/enablers are closed), the prioritized threats are analyzed, and the vulnerabilities (bugs) are addressed.
You need to decide the steps for any remaining threats and if they should be included in upcoming updates of the threat model.
Details
About threats and vulnerabilities
A threat exploits a vulnerability and can damage or destroy an asset. A vulnerability refers to a weakness in your hardware, software, or procedures.
According to NIST, a threat is any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service.