Overview |  | Roles |  | Work Items |  | Views |  | CMMI |  | Index |  | Glossary |

Project Portal
| See Also Threat Model for Web Applications Template |
| ### Patterns & Practices Threat Modeling Threat Modeling Web Applications |
| Develop Threat Model ( 3 : TS : 2 : 2.1 ) Solution Architect
Activity: Develop Threat Model
Solution Architect
Developer
|  |  |  | Planning |  |
|  | Participating Roles Responsible: Solution Architect Developer Accountable: Solution Architect Consult: Business Analyst
### Overview A threat model documents the known security threats and describes how to address them. Threat modeling is part of a structured approach to identifying and rating threats most likely to affect the system. With a solid threat model, threats are addressed in order of greatest risk with appropriate countermeasures. Build a threat model early and then update it as the application and architecture evolve. Review the threats with the business analyst to create security requirements. # Entry Criteria Application Diagram Must be approved for current iteration. System Diagram Must be approved for current iteration. Logical Datacenter Diagram Must be approved for current iteration. When: After architecture has been selected for current iteration. # Sub-Activities
1 | Create an Application Overview | Identify the scenarios that relate to the security objective. Examine each scenario for possibilities where the business rules could be misused. Look at the scenarios that relate to the security objective to look for potential areas between the scenarios that may lead to vulnerability. Identify specific technologies used in the solution. Identifying these technologies will help you focus on technology-specific threats. It also helps you determine the correct and most appropriate mitigation techniques. Identify any key points that you know about authentication, authorization, input validation, configuration management, sensitive data, session management, cryptography, parameter manipulation, exception management, auditing, and logging. Determine which areas of the product authentication and authorization are tied to these key points.
2 | Partition Your Application | Identify the trust boundaries of your application. Add new zones to the logical datacenter diagram to reflect these boundaries. For each subsystem, consider whether the upstream data flows or user input is trusted. If the input is not trusted, consider how the data flows can be authenticated and authorized. Trace your application’s data inputs through the system from entry to exit. Identify data flows between individual subsystems and components. Start at the top and partition the application by analyzing the data flow between individual subsystems. Use the system diagram to understand the component structure. The entry points of your solution also serve as entry points for attacks. Examine the logical datacenter, system, and application diagrams for the interfaces between components crossing trust boundaries. Consider the security levels of exposed entry points. Identify the points within your application where it outputs data to the client. Prioritize the exit points around where you write out data that includes client input or includes data from mistrusted sources such as shared databases.
3 | Identify Threats | For each asset, identify the scenarios that have been implemented so far that relate to that asset. Utilize these scenarios to bound the discussion of how the system will or will not be used. For each entry point, determine how an adversary might try to affect an asset. Utilize the threat template to document these threats. Utilize the STRIDE classification system to predict what the adversary would do and what his goals would be. The STRIDE model classifies threats in Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. A threat can belong to multiple categories. Analyze the threats to determine which ones are mitigated. Unmitigated threats will become vulnerabilities or secure type quality of service requirements. Capture the assets, threats, and methods to mitigate the threats in a threat model document and upload the document to the project portal. The threat mitigation generates a security requirement.
4 | Review Threats | Ensure that all parts of the system have been reviewed and that all currently known threat categories have been considered. Review new, changed, or reactivated threats with the appropriate business analyst. Discuss each threat in the context of the scenarios. Describe possible mitigation strategies. Threats evolve over time. Ensure the threat model is updated during each iteration.
# Exit Criteria
| Threats to the features under development are identified, documented, and rated in the threat model document.
| Security requirements are generated from threat mitigations.
© 2005 Microsoft Corporation. All rights reserved. MSF for CMMI Process Improvement: 1.00.0000.00 |