sachin rawat crypsis [email protected] sdl threat modeling

22
Sachin Rawat Crypsis [email protected] SDL Threat Modeling

Upload: maya-hutchison

Post on 26-Mar-2015

239 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

Sachin [email protected]

SDL Threat Modeling

Page 2: Sachin Rawat Crypsis sachin@crypsis.net 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.

Page 3: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

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

Page 4: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

Building Blocks

STRIDEData Flow Diagrams

+ Trust Boundary

STRIDE-per-element

Page 5: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

Properties of Secure Software

Authentication Integrity Non-repudiationConfidentiality Availability Authorization

Page 6: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

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

Page 7: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

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

Page 8: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

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.

Page 9: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

STRIDE-per-Element

Element S T R I D EExternal Entity √ √

Process √ √ √ √ √ √Data Store √ √* √ √

Data Flow √ √ √

Page 10: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

SDL Threat Modeling Process

Page 11: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

Vision

ScenariosUse Cases / StoriesAdd security to scenarios and use casesDetermine security assurances for the product

Page 12: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

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

Page 13: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

Identify Threats

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

Page 14: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

Mitigate

Analyze each threatFour possible responses

RedesignUse standard mitigationsUse custom mitigationsAccept risk

Page 15: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

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

Page 16: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

Validate other information captured

DependenciesAssumptionsExternal Security Notes

Page 17: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

Threat Modeling Approach Summary

Page 18: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

SDL Threat Modeling Tool (v3)

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

Page 19: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

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/

Page 20: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

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!

Page 21: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

Contact

Email [email protected]

Web Addresswww.crypsis.net

Page 22: Sachin Rawat Crypsis sachin@crypsis.net SDL Threat Modeling

© 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.