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

Project Portal
| ### Next Steps Implement a Development Task Write Security Tests |
| ### Patterns & Practices Threat Modeling |
| Activity: Develop Threat Model
Architect
|  |  |  | Create Solution Architecture |  |
|  | Participating Roles Responsible: Architect
### 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 system and solution architectures evolve. Review the threats with the business analyst to create security requirements. # Entry Criteria When: New security objectives or scenarios related to existing security objectives have been scheduled to be implemented in the upcoming iteration. Dependencies: The logical datacenter diagram is current. # 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.
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 untrusted sources such as shared databases.
3 | Identify Threats | For each asset or objective, identify the scenarios that have been implemented so far that relate to that asset. Utilize these scenarios to drive 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 quality of service requirements for security.
4 | Identify Vulnerabilities | 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 solution under development are identified, documented, and rated.
| Architects, developers, and testers can use the model to design, implement, and test effective and relevant countermeasures.
(C) 2005 Microsoft Corporation. All rights reserved. Build 97 |