Sachin Rawat Crypsis SDL Threat Modeling

What is Threat Modeling ? SDL Threat Modeling is a repeatable process which involves a methodical analysis of system design or architecture to discover and mitigate threats to an application. It helps identify design level security problems.

Threat Modeling Basics When ? The earlier, the better Usually starts during the design phase Used throughout the Application Development Lifecycle Who ? Everyone! Development and Test Engineers, Program Managers and Security Experts Why ? Identify potential security issues even before writing any code Saves cost and time Ensures the resulting application has a better security posture

Building Blocks STRIDE Data Flow Diagrams + Trust Boundary STRIDE-per-element

Properties of Secure Software Authentication Integrity Non-repudiation Confidentiality Availability Authorization

STRIDE Spoofing : Impersonating something or someone else Tampering : Modifying data or code Repudiation : Claiming to have not performed an action Information Disclosure : Exposing information to someone not authorized to see it Denial of Service : Deny or degrade service to users Elevation of Privilege : Gain capabilities without proper authorization

Mapping Threats to Security Properties ThreatSecurity Property SpoofingAuthentication TamperingIntegrity RepudiationNon-repudiation Information disclosureConfidentiality Denial of serviceAvailability Elevation of privilegeAuthorization

Data Flow Diagrams (DFD) for TM ElementShapeDescription Process Any running code External Interactor A user or machine that interacts with the application and is external to it Data Store Any data at rest, such as a file, registry key or database Data Flow Data flow is any transfer of data from one element to another. Trust Boundary An entry point where un-trusted data may be presented, or where many principals have shared access.

STRIDE-per-Element ElementSTRIDE External Entity Process Data Store* Data Flow

SDL Threat Modeling Process

Vision Scenarios Use Cases / Stories Add security to scenarios and use cases Determine security assurances for the product

Model Create a DFD diagram of your application Ensure all key components are represented Represent data flow between components Identify and draw trust boundaries between components where applicable Start with an simple high level DFD that has just a couple of process, data stores and external entities. Break out into more details as required

Identify Threats Automatically done by the tool using STRIDE-per-element!

Mitigate Analyze each threat Four possible responses Redesign Use standard mitigations Use custom mitigations Accept risk

Validate Ensure the diagram is up-to-date and represents the actual system Ensure all trust boundaries are represented All threats are enumerated Minimum STRIDE-per-element that touches a trust boundary Ensure all threats are analyzed and appropriate actions are taken Ensure all threats are mitigated and the mitigations are done right

Validate other information captured Dependencies Assumptions External Security Notes

Threat Modeling Approach Summary

SDL Threat Modeling Tool (v3) Walkthrough the process of creating a Threat Model for a simple web application using the SDL TM v3 tool

References The Microsoft Security Development Lifecycle (SDL) The Microsoft SDL Threat Modeling Tool SDL blog Writing Secure Code (Howard, Michael and David LeBlanc, Microsoft Press) Articles and blogs by Adam Shostack, Michael Howard :) Threat Modeling for LOB Applications : ACE Approach (asset centric, based on CIA threat classification)

Feedback / QnA Your Feedback is Important! Please take a few moments to fill out our online feedback form Use the Question Manager on LiveMeeting to ask your questions now!

Contact Address Web Address

© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.