Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Security Training: #3 Threat Modelling - Practices and Tools


Published on

Published in: Technology
  • Login to see the comments

Security Training: #3 Threat Modelling - Practices and Tools

  1. 1. Threat Modeling Practices and Tools Overview November 2008 Yulian Slobodyan, Oleh Basarab
  2. 2. Presentation Plan  Introduction  Threat Modeling  Threat Modeling Tools  Threat Modeling DEMO 2
  3. 3. Introduction
  4. 4. Introduction  Application Security Problems  Basic Terminology 4
  5. 5. Application Security Problems  Customer does not know what security he needs  Different groups think of security in different terms  Blind security controls applying  The area of security changes in time  Most decisions are made ad-hoc What we have to understand? Information Value Attackers Interest Events and causes 5
  6. 6. Basic Terminology  Assets  Threat  Vulnerability  Attack (Exploit)  Countermeasure 6
  7. 7. Threat Modeling
  8. 8. Threat Modeling Content  Threat Modeling Basics  Threat Modeling Process  Threat Modeling Summary Vision 8
  9. 9. Threat Modeling Basics
  10. 10. Overview What is Threat Modeling?  Threat modeling is a repeatable process that helps you find and mitigate all of the threats to your product. Why Threat Modeling?  Security design flaws are prevalent  Fixing design flaws is costly  Find problems when there is time to fix them  Threat modeling is one of the most effective security assessments  Know your enemies and their tactic 10
  11. 11. Benefits of Threat Modeling  Contributes to the risk management process because threats to software and infrastructure are risks to the user and environment deploying the software.  Uncovers threats to the system before the system is committed to code.  Revalidates the architecture and design by having the development team go over the design again.  Forces development staff to look at the design from a different viewpoint that of security and privacy. To understand the most at-risk components, development staff focuses on components with a high attack probability.  Helps clarify the selection of appropriate countermeasures for the application and environment.  Helps guide the code review process.  Guides the penetration testing process. 11
  12. 12. Threat Modeling Principles  Occurs early in the project lifecycle  Iterative process  Should be updated for evolving threats about every six months  Process output – documented Threat Model 12
  13. 13. Top 5 Reasons Why Threat Modeling Is Avoided  Time  Over Confidence  Cost  Underestimation  Procrastination 13
  14. 14. Approaches To Threat Modeling  Attacker-centric  Assets-centric  Software-centric 14
  15. 15. Threat Modeling Process
  16. 16. Architecture Diagram and Definitions Vision Identified Threats and Threats Attributes Threat Modeling Cycle Threat #1 Threat #2 Threat #n 16
  17. 17. Vision
  18. 18. Define Use Scenarios  Determine which key threat scenarios are within scope  Consider the insider-threat scenario should  Other common, but not securityrelated scenarios 18
  19. 19. Gather a List of External Dependencies  Application is not self-sufficient  Consider the default system-hardening configuration 19
  20. 20. Security Assumption and External Security Notes  Security assumptions about the environment in which the application resides  External Security Notes - for Users and other application designers 20
  21. 21. Model
  22. 22. What Is DFDs?  A Data Flow Diagram (DFD) is a graphical representation of how data enters, leaves, and traverses your component  It is not a Class Diagram or Flow Chart!  Shows all data sources and destinations  Shows all relevant processes that data goes through  Good DFDs are critical to the process  This point can’t be emphasised enough!  Building DFDs == understanding the system  Analysing DFDs == understanding the threats 22
  23. 23. Data Flow Diagram Symbols External Entity Data Store Complex-Process Dataflow Process Privilege Boundary 23
  24. 24. Privilege Boundaries  Boundary between DFD elements with different privilege levels  Machine boundary (data from the other machine could be anonymous)  Integrity boundary (Low  Medium trust)  Process boundary (e.g.; User process  SYSTEM process)  Kernel  User mode 24
  25. 25. DFD Levels  Context Diagram - very high-level; entire component / product / system  Level 0 Diagram - high level; single feature / scenario  Level 1 Diagram - low level; detailed sub-components of features  Level n Diagram - when is enough? 25
  26. 26. Context Diagram View files and Logging Data Response Web Shop (3.0) Users (1.0) Request Admin (3.0) Apply Settings 26
  27. 27. Level 0 Diagram 1 1 Web Config (3.1) Web Pages (3.2) Read Data Read Data Request Customers (1.0) Response Admin (3.0) 1 Create, Read, Update, Delete Insert, Update Web Server (3.3) Create, Update Read Order Processing (3.4) Read Membership Service (3.5) Insert, Update Read Membership Data (3.6) 1 27
  28. 28. Identify Threats
  29. 29. STRIDE Categories Asset Processes S T R I D E       Data Stores     External Entities   Data Flows    29
  30. 30. Threat Trees  A graphical representation of security-relevant pre-conditions in a system  Based on hardware fault trees  There are many “threat tree patterns” 30
  31. 31. Threat Tree Pattern Example Spoofing An Interactor or Process Obtain legitimate credentials Leverage insufficient authentication Falsify Credentials No Authentication System Week change management Equivalence Predictable Credentials Non-secure Channel Week transit Guessed Downgrade Authentication Secure Channel Week storage Null Credentials Server Client KDC Tampering Threats against Auth Process Information Disclosure against data flows Tampering against data flows 31
  32. 32. Risk Calculation Approaches  Microsoft’s Bug Bur (see Appendix A)  Risk = Probability × Damage Potential  DREAD model 32
  33. 33. Threat Rating According to DREAD Rating Damage potential Reproducibility Exploitability Affected users Discoverability High(3) The attacker can: subvert the security system; get full trust authorization; run as administrator; upload content. The attack can be reproduced every time and does not require a timing window. A novice programmer could make the attack in a short time. All users, default configuration, key customers The vulnerability is found in the most commonly used feature and is very noticeable. Medium(2) Low(1) Leaking sensitive information Leaking trivial information The attack can be reproduced, but only with a timing window and a particular race situation. The attack is very difficult to reproduce, even with knowledge of the security hole. A skilled programmer could make the attack, then repeat the steps. The attack requires an extremely skilled person and in-depth knowledge every time to exploit. Some users, non-default configuration Very small percentage of users, obscure feature; affects anonymous users The vulnerability is in a seldom-used part of the product, and only a few users should come across it. It would take some thinking to see malicious use. The bug is obscure, and it is unlikely that users will work out damage potential. 33
  34. 34. Mitigate
  35. 35. Plan Mitigation  Do Nothing  Remove the Feature (ASR)  Turn Off the Feature (ASR)  Warn the User  Counter the Threat with Technology 35
  36. 36. Mitigation Technique Based on STRIDE Threat Spoofing Property Authentication Definition Impersonating something or someone else. Example Pretending to be any of Billg , or ntdll.dll Tampering Integrity Modifying data or code Modifying a DLL on disk or DVD, or a packet as it traverses the LAN. Repudiation Non-repudiation Claiming to have not performed an action. “I didn’t send that email,” “I didn’t modify that file,” “I certainly didn’t visit that web site, dear!” web site. Deny or degrade Crashing Windows or a web site, sending a service to users Availability Allowing someone to read the Windows source code; publishing a list of customers to a authorized to see it Denial of Service Confidentiality Exposing information to someone not Information Disclosure packet and absorbing seconds of CPU time, or routing packets into a black hole. Elevation of Privilege Authorization Gain capabilities without proper authorization Allowing a remote internet user to run commands is the classic example, but going from a limited user to admin is also EoP . 36
  37. 37. Standard Mitigations Spoofing Authentication Tampering Integrity Repudiation Non Repudiation Information Disclosure Confidentiality Denial of Service Availability Elevation of privilege Authorization To authenticate principals: Basic authentication Digest authentication Cookie authentication Windows authentication (NTLM) Kerberos authentication PKI systems such as SSL/TLS and certificates IPSec Digitally signed packets To authenticate code or data: Digital signatures Message authentication codes Hashes Windows Vista Mandatory Integrity Controls ACLs Digital signatures Message Authentication Codes Strong Authentication Secure logging and auditing Digital Signatures Secure time stamps Trusted third parties Encryption ACLS ACLs Filtering Quotas Authorization High availability designs ACLs Group or role membership Privilege ownership Permissions Input validation 37
  38. 38. Validating
  39. 39. Validating Threat Model  Validate whole Threat Model  Has QA reviewed the model?  Is each Threat mitigated? 39
  40. 40. Summary  Structured approach to security  Address the top threats  Treat threat modeling as an iterative process  Dynamic item that changes over time  Help manage and communicate security risks across your team  Using a Threat Model to Aid Code Review  Using a Threat Model to Aid Testing 40
  41. 41. Threat Modeling Tools
  42. 42. TAM Security Artifacts  Data access control matrix  Component access control matrix  Subject-object matrix  Data Flow  Call Flow  Trust Flow  Attack Surface  Focused reports 42
  43. 43. SDL Threat Modeling Tool Beta  Structured analysis  Automated guidance and feedback in drawing threat diagrams  Guided analysis of threats and mitigations based on the STRIDE taxonomy  Integration with bug-and issue-tracking systems like Visual Studio Team Foundation Server  Reporting capabilities: Security activities and testing in the verification phase  Is a core element of the SDL 43
  44. 44. Threat Modeling DEMO
  45. 45. Appendix A Core Elements of Bug Bar Document
  46. 46. Rank Your Threats by Risk  Address the highest-risk items first  Risk level 1 or 2 threats must always be remedied during the development phase  Risk level 3 threats should be fixed before the product becomes a release candidate  Risk level 3 threats should be fixed before the product becomes a release candidate  Risk level 4 threats should be fixed if time permits 46
  47. 47. Spoofing Spoofing Server Pose as specific principals when using security protocol Risk Level 2 Pose as random principals when using security protocol Risk Level 3 Client Present bogus relied-upon trust decision UI used in common scenarios Risk Level 2 Present bogus trust decision UI used in common scenarios Risk Level 3 Present bogus UI to aids other attacks Risk Level 4 47
  48. 48. Tampering Tampering Server Permanent Modification Client Temporary Modification Common or Default Scenario Risk Level 2 Temporary Modification Risk Level 4 Common or Default Scenario Risk Level 3 Specific Scenario Risk Level 3 Permanent Modification Risk Level 2 Specific Scenario Risk Level 4 48
  49. 49. Information Disclosure Information Disclosure Server Targeted Client Untargeted Risk Level 4 Targeted Read any data Risk Level 2 Phone Home With no opt-in Risk Level 2 Read from known Locations Risk Level 3 Private data Risk Level 2 Private data Risk Level 2 Untargeted Risk Level 4 Read from OS Risk Level 2 49
  50. 50. Denial of Service Denial of Service Server Anonymous Client Authenticated Local Risk Level 2 Remote Permanent DoS Risk Level 2 Temporary DoS with amplification Risk Level 2 No user Interaction Risk Level 1 Temporary DoS Risk Level 3 Authenticated Risk Level 2 Iser Interaction Risk Level 2 50
  51. 51. Elevation of Privileges Elevation of Privilege Server Local Authenticated Risk Level 2 Client Remote Local Risk Level 2 Remote Anonymous Risk Level 1 No user Interaction Risk Level 1 Authenticated Risk Level 2 Iser Interaction Risk Level 2 51
  52. 52. References  Basic Terminology  Security Developer Center: Threat Modeling  Classification of Security Attacks  Approaches to Threat Modeling  Threat Modeling  Uncover Security Design Flaws Using The STRIDE Approach  Security Threats  Server and Domain Isolation Using IPsec and Group Policy  Security Briefs  Security Developer Center: Threat Modeling — Video Tutorials  us/security/aa570414.aspx  OWASP — Threat Risk Modeling  patterns & practices — Threat Modeling Web Applications  Peter Torr's blog: High-Level Threat Modeling Process  The STRIDE Threat Model  Microsoft Application Threat Modeling Blog 52
  53. 53. References  Template Sample: Web Application Threat Model  Application Threat Modeling  Threat Modeling Terms and How To Use Them Threat_M odeling_Lab_01 .90.docx SimpleModel.atmx 53
  54. 54. Questions 54