Download - Sachin Rawat Crypsis sachin@crypsis
Sachin [email protected]
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 betterUsually starts during the design phaseUsed 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 codeSaves cost and timeEnsures the resulting application has a better security posture
Building Blocks
STRIDEData Flow Diagrams
+ Trust Boundary
STRIDE-per-element
Properties of Secure Software
Authentication Integrity Non-repudiationConfidentiality Availability Authorization
STRIDE
Spoofing : Impersonating something or someone elseTampering : Modifying data or code Repudiation : Claiming to have not performed an action Information Disclosure : Exposing information to someone not authorized to see itDenial of Service : Deny or degrade service to usersElevation of Privilege : Gain capabilities without proper authorization
Mapping Threats to Security Properties
Threat Security PropertySpoofing Authentication Tampering Integrity Repudiation Non-repudiation Information disclosure Confidentiality Denial of service Availability Elevation of privilege Authorization
Data Flow Diagrams (DFD) for TMElement Shape Description
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
Element S T R I D EExternal Entity √ √
Process √ √ √ √ √ √Data Store √ √* √ √
Data Flow √ √ √
SDL Threat Modeling Process
Vision
ScenariosUse Cases / StoriesAdd security to scenarios and use casesDetermine security assurances for the product
Model
Create a DFD diagram of your applicationEnsure all key components are represented Represent data flow between componentsIdentify and draw trust boundaries between components where applicableStart 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 threatFour possible responses
RedesignUse standard mitigationsUse custom mitigationsAccept risk
Validate
Ensure the diagram is up-to-date and represents the actual systemEnsure all trust boundaries are representedAll threats are enumerated
Minimum STRIDE-per-element that touches a trust boundary
Ensure all threats are analyzed and appropriate actions are takenEnsure all threats are mitigated and the mitigations are done right
Validate other information captured
DependenciesAssumptionsExternal 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
ReferencesThe Microsoft Security Development Lifecycle (SDL)
http://msdn.microsoft.com/en-us/security/cc448177.aspx
The Microsoft SDL Threat Modeling Toolhttp://msdn.microsoft.com/en-us/security/dd206731.aspx
SDL bloghttp://blogs.msdn.com/sdl/
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)http://blogs.msdn.com/threatmodeling/
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!
© 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.