Security Training: #3 Threat Modelling - Practices and Tools
•
38 likes•14,117 views
This document provides an overview of threat modeling practices and tools. It begins with an introduction that defines threat modeling and outlines its benefits. It then covers threat modeling basics like principles, approaches and reasons it is avoided. The main threat modeling process is described, including creating diagrams, identifying threats and planning mitigations. Popular threat modeling tools and a demo are discussed. Standard mitigation techniques and a sample threat model appendix are also included.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Security Training: #3 Threat Modelling - Practices and Tools
Similar to Security Training: #3 Threat Modelling - Practices and Tools (20)
More from Yulian Slobodyan
More from Yulian Slobodyan (11)
Recently uploaded
Recently uploaded (20)
Security Training: #3 Threat Modelling - Practices and Tools
- 1. Threat Modeling Practices and Tools Overview November 2008 Yulian Slobodyan, Oleh Basarab
- 2. Presentation Plan Introduction Threat Modeling Threat Modeling Tools Threat Modeling DEMO 2
- 3. Introduction
- 4. Introduction Application Security Problems Basic Terminology 4
- 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
- 8. Threat Modeling Content Threat Modeling Basics Threat Modeling Process Threat Modeling Summary Vision 8
- 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. 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. 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. Top 5 Reasons Why Threat Modeling Is Avoided Time Over Confidence Cost Underestimation Procrastination 13
- 14. Approaches To Threat Modeling Attacker-centric Assets-centric Software-centric 14
- 16. Architecture Diagram and Definitions Vision Identified Threats and Threats Attributes Threat Modeling Cycle Threat #1 Threat #2 Threat #n 16
- 17. Vision
- 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. Gather a List of External Dependencies Application is not self-sufficient Consider the default system-hardening configuration 19
- 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. Model
- 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. Data Flow Diagram Symbols External Entity Data Store Complex-Process Dataflow Process Privilege Boundary 23
- 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. 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. Context Diagram View files and Logging Data Response Web Shop (3.0) Users (1.0) Request Admin (3.0) Apply Settings 26
- 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. Identify Threats
- 29. STRIDE Categories Asset Processes S T R I D E Data Stores External Entities Data Flows 29
- 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. 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. Risk Calculation Approaches Microsoft’s Bug Bur (see Appendix A) Risk = Probability × Damage Potential DREAD model 32
- 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. Mitigate
- 35. Plan Mitigation Do Nothing Remove the Feature (ASR) Turn Off the Feature (ASR) Warn the User Counter the Threat with Technology 35
- 36. Mitigation Technique Based on STRIDE Threat Spoofing Property Authentication Definition Impersonating something or someone else. Example Pretending to be any of Billg , microsoft.com 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. 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. Validating
- 39. Validating Threat Model Validate whole Threat Model Has QA reviewed the model? Is each Threat mitigated? 39
- 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
- 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. 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
- 45. Appendix A Core Elements of Bug Bar Document
- 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. 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. 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. 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. 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. 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. References Basic Terminology http://msdn.microsoft.com/en-us/library/aa302419.aspx#c03618429_005 Security Developer Center: Threat Modeling http://msdn2.microsoft.com/en-us/security/aa570411.aspx Classification of Security Attacks http://homepages.uel.ac.uk/u0305518/classification_of%20security_attacks.htm Approaches to Threat Modeling http://en.wikipedia.org/wiki/Threat_model Threat Modeling http://msdn.microsoft.com/en-us/library/aa302419.aspx Uncover Security Design Flaws Using The STRIDE Approach http://msdn.microsoft.com/enus/magazine/cc163519.aspx Security Threats http://technet.microsoft.com/en-us/library/cc723507.aspx Server and Domain Isolation Using IPsec and Group Policy http://www.microsoft.com/technet/security/guidance/architectureanddesign/ipsec/ipsecapd.mspx Security Briefs http://msdn.microsoft.com/en-us/magazine/dd148644.aspx Security Developer Center: Threat Modeling — Video Tutorials http://msdn2.microsoft.com/en us/security/aa570414.aspx OWASP — Threat Risk Modeling http://www.owasp.org/index.php/Threat_Risk_Modeling patterns & practices — Threat Modeling Web Applications http://msdn2.microsoft.com/enus/library/ms978516.aspx Peter Torr's blog: High-Level Threat Modeling Process http://weblogs.asp.net/ptorr/archive/2005/02/08/368881.aspx The STRIDE Threat Model http://msdn2.microsoft.com/en-us/library/ms954176.aspx Microsoft Application Threat Modeling Blog http://blogs.msdn.com/threatmodeling/ 52
- 53. References Template Sample: Web Application Threat Model http://msdn.microsoft.com/en-us/library/ms978534.aspx Application Threat Modeling http://www.owasp.org/index.php/Application_Threat_Modeling Threat Modeling Terms and How To Use Them http://blogs.msdn.com/jmeier/archive/2005/10/10/threat-modelingterms-and-how-to-use-them.aspx Threat_M odeling_Lab_01 .90.docx SimpleModel.atmx 53
- 54. Questions 54
Editor's Notes
- 2. One of the problems in designing secure software is that different groups think of security in different terms. Software developers think of security primarily in terms of code quality while network administrators think of firewalls, incident response, and system management. Of course, all of these things are important in building secure systems. But maybe the single biggest problem is a lack of security success criteria. If we want to avoid security failures, it means we have to have some idea of what security success looks like. 3.To secure an application or a system without spending excessive time and effort we are tempted to blindly apply security controls that have already been extensively used in practice. However, without understanding security requirements common security controls can not provide adequate protection within the specific context.4. A development process must also change5.We have to understand:- the real value of information resources that we need to protect- if an attacker has an interest to compromise our system what are the events and causes that will have an unwelcome consequence upon our system
- Once the application has been decomposed into its components, threats identified, and mitigations applied, the final step is to validate.The validation task includes the following:Check whether the Data Flow Diagrams match the final code. If the design has been modified since creating the DFDs, they need to be updated accordingly.Verify whether STRIDE threat types have been identified for each component of the DFD, especially those that touch a trust boundary.Check whether proper mitigations have been applied to the threats identified.Check that all the above tasks have been accomplished before shipping.
- Since threat modeling is an iterative process, it is possible to keep repeating the various tasks and updating the threat model until the product is finally shipped.For this reason, it’s extremely important to know when the threat modeling process can be considered complete. Validating the following helps you determine when to stop:DFDs match frozen code.Threats have been identified and mitigations applied to each component in the DFD.The mitigations are validated by QA by testing whether the application is still vulnerable to the threats for which the mitigations are in place.When the threat model has been reviewed and approved by an external security expertSummary: Threat modeling allows you to apply a structured approach to security and to address the top threats that have the greatest potential impact to your application first. This chapter helps you to decompose your Web application to identify and rate the threats that are most likely to impact your system. The chapter presents a six-step threat modeling process.While you can mitigate the risk of an attack, you do not mitigate or eliminate the actual threat. Threats still exist regardless of the security actions you take and the countermeasures you apply. The reality in the security world is that you acknowledge the presence of threats and you manage your risks. Threat modeling can help you manage and communicate security risks across your team.Treat threat modeling as an iterative process. Your threat model should be a dynamic item that changes over time to cater to new types of threats and attacks as they are discovered. It should also be capable of adapting to follow the natural evolution of your application as it is enhanced and modified to accommodate changing business requirements.Threat modeling is critically important to helping build secure software because it is the cornerstone to understanding how your product could be attacked and how to defend it. The process is also a great way to determine the overall security health of a software development team because security-savvy teams are more in tune with the threats to their code and, therefore, tend to build better threat models.By following the updated threat-modeling process, you can systematically uncover threats to the application, rank the risk of each threat, and determine appropriate mitigations. Threat modeling can also help you perform code reviews and build penetration tests.Using a Threat Model to Aid Code ReviewOne of the deliverables from the threat-modeling process is a list of entry points to the system. This is really what the context diagram shows. If you look at the context diagram main entry points to the system. When it comes to reviewing the code for security bugs, it's imperative that you review all code that is remotely and anonymously accessible before reviewing other code. Simply look at the data flow diagram to determine which elements are accessible in this manner.Using a Threat Model to Aid TestingAs we have mentioned, specific threat types (spoofing and tampering, for example) have specific mitigation techniques. These techniques can also be attacked. Determine how best to build attacks or perform penetration testing by looking at the relevant threats' tree patterns, and considering the leaf nodes of each tree. These leaf nodes can give you not only design insight but also attack insight.There's a couple of interesting points here:Assets tend to be very much a point of confusion. It's tough to put boundaries here. For example, show me which pages or components you don't want to protect. Do you really have a page or component you don't care about? Is it an asset or not? This is why we moved to identifying security objectives in our threat modeling approach. This was a lot more tangible. Using security objectives also allowed us to incorporate assets without pinning your threat modeling success to you being able to identify your assets. However, assets do have their place. I think they're best use is to identify priorities and values. Do you care more about your shed or your garage? Your garage or your house. OK, let's start w/your house and prioritize there ... Attacks tend to be the domain of subject matter experts. We don't expect typical practitioners to know the realm of attack possibilities. That's why we try to provide a picklist where possible. Vulnerabilities are your most valuable fallout of your threat modeling exercise. While threats help you see what's within the realm of possibility and to prioritize, vulnerabilities are a clear cut action item. You can use a list of vulnerabilities to drive action. Given enough relevant info, a developer can analyze and address a vulnerability from their code's perspective. Testers can scope their work testing that the developer addressed the vulnerability. Countermeasures could also be called mitigations. You mitigate a risk, not a threat though. You can counter an attack. At the end of the day, we went with countermeasures because enough customers liked the idea of being empowered to defend their code against evil doers as well as non-malicous threats. Put it another way, countermeasures resonated with practitioners. Threats are particularly interesting. You can slide and dice them many ways. You can also choose classes of threats. For example you may view threats strictly as those with business impact. I think it helps to broaden, yet scope this to negative impact against the confidentiality, integrity, or availability (CIA) of your information system
- TAM Overview – Asset centric toolMicrosoft Threat Analysis & Modeling tool allows non-security subject matter experts to enter already known information including business requirements and application architecture which is then used to produce a feature-rich threat model. Along with automatically identifying threats, the tool can produce valuable security artifacts such as:- Data access control matrix- Component access control matrix- Subject-object matrix- Data Flow- Call Flow- Trust Flow- Attack Surface- Focused reports
- SDL Threat Modeling Tool Beta – Software centric tool The Microsoft SDL Threat Modeling Tool Beta allows for structured analysis, proactive mitigation and tracking of potential security and privacy issues in new and existing applications. Microsoft developed the tool and we use it internally on many of our products. This tool offers a threat modeling methodology that any software architect can lead effectively — in contrast with other processes, which are more expert-dependent. A few quick notes about the features: · 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 ServerThe Microsoft SDL Threat Modeling Tool is a core element of the SDL. The tool is part of the design phase of the SDL and allows software architects to identify and mitigate potential security issues early, when they are relatively easy and cost-effective to resolve.The Microsoft SDL Threat Modeling Tool enables software architects to do the following:Communicate about the security design of their systemsAnalyze those designs for potential security issues using a proven methodologySuggest and manage mitigations for security issuesCapabilities and InnovationsInnovative features in the Microsoft SDL Threat Modeling Tool 3.0 include: Automation: Guidance and feedback in drawing threat diagramsSTRIDE Framework: Guided analysis of threats and mitigationsIntegration: Issue-tracking systemsReporting capabilities: Security activities and testing in the verification phaseA Unique MethodologyThe Microsoft SDL Threat Modeling Tool differs from other tools and approaches in two key areas:Centered on softwareMany threat modeling approaches center on assets or attackers. In contrast, the Microsoft Security Development Lifecycle’s (SDL) approach to threat modeling is centered on the software. This new tool builds on activities that all software developers and architects are familiar with – such as drawing pictures for their software architecture.Focused on design analysisThe term “threat modeling” can refer to either requirements elicitation techniques or design analysis. Sometimes, it refers to a complex blend of the two. The Microsoft SDL approach to threat modeling is a focused design analysis technique.As threat modeling matures as a discipline, there's no single 'right' way to do it. Both the TAM tool and the SDL tool address specific needs. The SDL tool is intended to be software centric, while TAM is asset centric. It's great to be in a situation where we can really distinguish between these and make tools which are focused on the needs of the different customer groups.
- Note that there are no risk rankings for repudiation threats. The threats remain unranked for various reasonsmost notably because Microsoft has issued no security bulletins relating to repudiation. In general, the feeling is that any such errors follow the tampering risk rankings. By the end of the risk-identification stage, you should have ranked your threats by risk, from high to low. Obviously, you should 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, and risk level 4 threats should be fixed if time permits.