Threat Modeling: Improving the Application Life cycle

1. Threat Modeling: Improving the Application Life cycle Dan Sellers .Net Developer Specialist Microsoft Canada http://blogs.msdn.com/dansellers

2. Agenda • Important notes and definitions • Why model threats? • The modeling process • DFD, Threat Types, Risk, Mitigations • Exercise

3. Developer Security Data Points • “75 percent of hacks happen at the application” - Gartner “Security at the Application Level” • “Over 70 percent of security vulnerabilities exist at the application layer, not the network layer” - Gartner • "The conclusion is unavoidable: any notion that security is a matter of simply protecting the network perimeter is hopelessly out of date” - IDC and Symantec, 2004 • “11 of CERT’s 13 major security advisories for 2003 are bugs arising from programming errors in applications [not the OS]” - Carnegie Mellon University • “If only 50 percent of software vulnerabilities were removed prior to production … costs would be reduced by 75 percent” - Gartner “Security at the Application Level” • “The battle between hackers and security professionals has moved from the network layer to the Web applications themselves" - Network World • “64 percent of developers are not confident in their ability to write secure applications” - Microsoft Developer Research • “The Economic Impacts of Inadequate Infrastructure for Software Testing 2002” put the cost of fixing a bug in the field at $30,000 vs. $5,000 during coding- NIST

4. Some Important Notes: Security is a Process and NOT a Product • Two types of Security for Software • Application Security • Secure Software • QA confused with Software Security Testing • Improve the process (start early, and often) • Fault Injection

5. Actualsoftwarefunctionality Traditionalfaults BO in authn Weak authn Unintended,undocumentedor unknown functionality Intendedfunctionality Security Testing PoorDefenses Extra‘functionality’BOs, XSS, etc

6. Intended behavior!

7. Test for the Unintended behavior!

8. 87 Some Important Definitions • Threat Agent • Someone who could do harm to a system (also adversary) • Threat • An adversary’s goal • Threat Tree • A graphical representation of security-relevant pre-conditions in a system • Vulnerability • A flaw in the system that could help a threat agent realize a threat • Asset • Something of value to valid users and adversaries alike • Attack • When a motivated and sufficiently skilled threat agent takes advantage of a vulnerability

9. We must put appropriate defenses in our products Because attackers Your application Want to attack Why Threat Modeling? Source: Common Criteria for Information Technology Security Evaluation v2.1

10. What is Threat Modeling? • Threat Modeling: • Is the security-based analysis of an application to help find “anti-scenarios” • Is a critical part of the design process • Reduces the cost of securing an application Source: Code Complete 2nd Ed

11. Delivering secure applications has to become a mandatory requirement … the cost of fixing defects after deployment is almost fifteen times greater than detecting and eliminating them during development. Why Software Development Must Change 100X Application In the Field 15X System/Acceptance Testing Integration Testing 6.5X 1 X Static Analysis Design Development Testing Deployment Source IDC and IBM Systems Sciences Institute

12. Where Threat Modeling Fits in the SDL Security Deployment Lifecycle Task and Processes Use SecurityDevelopment Tools & Security Best Dev & Test Practices Create SecurityDocsand ToolsFor Product PrepareSecurityResponsePlan Security Push FinalSecurity Review Security Servicing &ResponseExecution Security Training Security Arch & Attack SurfaceReview Security Kickoff& Register withSWI Security DesignBest Practices Pen Testing ThreatModeling Traditional Microsoft Software Product Development Lifecycle Tasks and Processes Testing and Verification Feature ListsQuality GuidelinesArch DocsSchedules Code Signing A CheckpointExpress Signoff RTM Product SupportService Packs/QFEs SecurityUpdates DesignSpecifications Development of New Code FunctionalSpecifications Bug Fixes Requirements Design Implementation Verification Release Support&Servicing

13. The Goals of Threat Modeling and Secure Design • Identify where an application is most vulnerable • Determine which threats require mitigation • Reduce risk to an acceptable level through mitigation

14. Define Scenarios Build Threat Trees Create DFD Optional DetermineThreatTypes DetermineRisk Plan Mitigations The Updated Threat Modeling Process Manual Rote

15. 68 Define Scenarios • Define the most common and realistic use scenarios for the application • Example from Microsoft Windows Server 2003 and Microsoft Internet Explorer • “Think about an admin browsing the Internet from a Domain Controller” • Bounds the scope of what you need to model 

16. 87 75 Model the Application with DFDs • Most “whiteboard architectures” are DFD-like ExternalEntity Process Multi-Process Data Store Dataflow Privilege Boundary 

17. 90 DFD Process • Create the context diagram • Create Level-0 DFD • Create Level-1 DFD (if needed) • Create Level-2 DFD (if needed) • Keep going until there are no more multi-processes • Generally Level-2 is “deep enough” 

18. Server 77 The Context Diagram One multi-process, and the different external entities Request Users AdminSettings Response Admin Logging Data 

19. 93 Privilege Boundaries • Specific DFD addition to TMs • Boundary between DFD elements with different privilege levels • Machine boundary (data from the other machine could be anonymous) • Process boundary (e.g., user process  SYSTEM process) 

20. 6 7 Request RequestedFile(s) Audit Read Audit Write 1 Audit Data Response 4 Authn Info 8 Audit Info Audit Requests Authn Request 2 SetUser Data 9 GetCreds 3 Verify User Data 5 Set/GetCreds 79 Next – The Level-0 DFD Data Files Audit Data User Service Audit Engine Authn Engine Admin MnmgtTool Credentials 

21. Function call • Network traffic • Shared memory • Etc. • Services • Web Services • Assemblies • DLLs • EXEs • COM object • Etc. • Database • File • Registry • Shared Memory • Queue/Stack • Etc. • Real People • News feeds • Data feeds • Events • Notifications • Etc. Implementation Examples 

22. Data Files Data Files Service Service 78 Common DFD “Bugs”(1) How does the data get into the data store? Data Entry Tool Data Entry Operator  

23. Data Files Data Files Common DFD “Bugs”(2) How does data move from one data store to another? Data Files Replication Engine   Data Files

24. Data Files Data Files Common DFD “Bugs”(3) How does data move from a user to a data store? User User Data Entry Tool  

25. Anti-I in CIA Anti-C in CIA Anti-A in CIA 104 84 DFD Element Threat Types • Each DFD element (Asset) is susceptible to certain kinds of threats • Spoofing • Tampering • Repudiation • Information Disclosure • Denial of Service • Elevation of Privilege 

26. 6 7 Request RequestedFile(s) Audit Read Audit Write 1 Audit Data Response 4 Authn Info 8 Audit Info Audit Requests Authn Request 2 SetUser Data 9 GetCreds 3 Verify User Data 5 Set/GetCreds Every Asset is Subject to Attack Data Files Audit Data User Service Audit Engine Authn Engine Admin MnmgtTool Credentials 

27. External Entity Data Store Dataflow Threat Types by Asset Type Asset S T R I D E         Process       

28. External Entities 1 & 9 Processes 2, 4, 5 & 8 Data Stores 3, 6 & 7 Data Flows 14, 41, 24, 42, 32, 64, 35, 53, 59, 95, 98, 89, 78, 87, 48 List all Assets from the DFD Every asset is subject to threats

29. Spoofing E: 1, 9 P: 2, 4, 5, 8 Tampering P: 2, 4, 5, 8 DS: 3, 6, 7 DF: 14 etc Repudiation E: 1, 9 P: 2, 4, 5, 8 Information Disclosure P: 2, 4, 5, 8 DS: 3, 6, 7 DF: 14 etc Denial of Service P: 2, 4, 5, 8 DS: 3, 6, 7 DF: 14 etc Elevation of Privilege P: 2, 4, 5, 8 A Complete List of Threats

30. Threat Reduction • Assets… • …within the same trust boundary • …using like technology • Can be treated as one unit • Saves time! • Great for data flows

31. 93 Calculating Risk with Numbers • DREAD, etc. • Very subjective • Often requires the analyst be a security expert • On a scale of 0.0 to 1.0, just how likely is it that an attacker could access a private key? • Where do you draw the line? • Do you fix everything above 0.4 risk and leave everything below as “Won’t Fix”?

32. Critical Run malicious code Most ‘E’ vulns Important Denial of service against a server Moderate Server DoS that stops once attack stops Low DoS against a client Security Risk Rankings (Examples)

33. 106 Mitigating Threats • Options: • Leave as-is • Remove from product • Remedy with technology countermeasure • Warn user

34. 107 Mitigation Techniques

35. Testing Mitigations • All threats and mitigations must be tested • The job of a good security tester is to find other conditions in the threat tree • Threats have mitigations • Mitigations can be attacked • Spoofing • Authentication • Password guessing, brute force, Authn downgrade

36. The Threat Modeling Process 1. Define key scenarios 2. Model the application using DFDs 3. Determine threat types for each DFD element 4. Calculate risk 5. Plan mitigations

37. © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.