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.

Threat Modeling to Reduce Software Security Risk

Learn about threat modeling from our CTO and co-creator of the DREAD threat modeling classification, Jason Taylor. Understand more about what threat modeling is, dive into real life examples, and use techniques you can leverage at every phase of the SDLC.

  • Be the first to comment

Threat Modeling to Reduce Software Security Risk

  1. 1. Threat Modeling to Reduce Software Security Security Risk
  2. 2. About Security Innovation • Authority in Software Security • 10+ years research on software vulnerabilities • Security testing methodology adopted by SAP, Symantec, Microsoft and McAfee • Authors of 18 books • Helping organizations minimize risk • Assessment: Show me the gaps • Education: Guide me to the right decisions • Standards: Set goals and make it easy and natural • Tech-enabled services for both breadth and depth • Gartner MQ Leader for security computer-based training
  3. 3. Agenda Threat Modeling 101 • Threat Modeling Activity Examples • STRIDE and DREAD threat classification techniques • Leveraging a Threat Model at every phase of the SDLC
  4. 4. Threat Mitigation Vulnerability Attacker Threat Modeling Overview Vulnerabilities are unmitigated threats Here’s our opportunity! • Threat modeling consists of Assets, Threats and Attacks • Assets are what you want to protect • Threats live forever; they are the attacker’s goal • Attacks are how an attacker can realize a threat • Vulnerabilities are design or implementation errors that allow an attack to succeed • Very hard to write secure solutions unless you understand your Assets, Threats and Attacks • If done right, provides more ROI than any other security activity
  5. 5. What is Threat Modeling? • A powerful way to identify potential threats, visualize risk and understand the security of the software system • Multi-disciplinary effort in which all team members think about and address threats • A way for architects to realize and mitigate design problems • A road map for developer to write secure code • A starting point to create robust security minded test plans • The most reliable way to: • Understand the security implications of system architecture • Find business-process and system-level security issues • Ensure you get the most impact for your security investment “Experience shows that nearly 50% of security flaws will be discovered from Threat Modeling because it finds different threats than those found through code review" -Michael Howard, author of "Writing Secure Code" and Security Program Manager, Microsoft
  6. 6. Why Threat Model? • Creates a common understanding amongst technical and management stakeholders • Ensures design and code is written to protect critical assets • Allows organizations to: • Make better decisions throughout development • Prioritize security efforts according to true risk • Understand your organization’s weaknesses • Weigh security designs against functional design goals • Step into the mind of an attacker and identify attack vectors “To know your enemy, you must become your Enemy.” -Sun Tzu
  7. 7. Threats Vary by Platform, Technology, Language • Web, embedded, mobile attacked in different ways • You cannot implement effective design and coding countermeasures without knowing these specific attacks • Adobe Flash vulnerabilities exploited numerous times • PHP is widely known as being insecure • Java frameworks littered with security flaws • Each Technology has different security features and vulnerabilities • .NET and J2EE protect against buffer overflows; objectiveC does not • Heartbleed, Shellshock, POODLE, GotoFail, Stuxnet • All software born exploits
  8. 8. A World Without Threat Modeling • Important assets are left unprotected • Many assets aren’t even identified • Team doesn’t understand key threats to the system • Developers code defensively but leave gaps • Mitigations are in place but they block the wrong attacks • Low risk areas are well protected, high risk areas left open • Testing is conducted with a one-size-fits-all solution • Reliance on scanning tools and vendors with canned test plans
  9. 9. What a Threat Model Isn’t • A representation of how an attacker approaches a system • Represents system security, not an attacker model • A test plan • Test plans should be based on a TM, but a TM offers more than just test planning • A formal proof of system security • This is not achievable on complex systems • A design review • Design review is the next level of action after the Threat Model is completed
  10. 10. Agenda • Threat Modeling 101 Threat Modeling Activity Examples • STRIDE and DREAD threat classification techniques • Leveraging a Threat Model at every phase of the SDLC
  11. 11. Threat Modeling in a Nutshell Analyze Application Determin e Threats Rank Threat s • Understand architecture and security requirements • Identify assets and roles • Build an activity matrix • Identify threats that put assets at risk • Define a set of attacks and/or negative scenarios that could be used to realize threats • Identify testable conditions each attack requires to be successful • Assess probability, harm, priority, and business impact of each threat • Devise mitigations
  12. 12. Identifying Entry Points, Assets & Roles • Entry points in an online store application example: • Front-end web server • Merchandise database • Interface with 3rd-party credit card processing system • Interface with inventory system • To find assets one needs to think about what the attacker will target • Customer data • Checkout cart • Product information • Inventory system • The Web application • Identify roles Web customer (Authenticated user) • Site Administrator • Anonymous user • 3rd-party payment processing system • Suppliers
  13. 13. Building the Activity Matrix • The activity matrix shows the interactions between each asset and role in the target system • The activity matrix is a set of explicit mappings between roles and asset • Each <role, asset> pair lists the access types granted to a role for the asset • The activity matrix is used in later steps to derive threats to the system based on improper asset access
  14. 14. Building the Activity Matrix: Example 14 Role Asset Action Anonymous Authenticated User Site Admin Customer Data Create Always Sometimes 1 Never Read Never Sometimes 1 Always Update Never Sometimes 1 Never Delete Never Sometimes 1 Always Product Items Create Never Never Always Read Always Always Always Update Never Never Always Delete Never Never Always Password Create Always Always Never Read Never Never Never Update Never Sometimes 2 Sometimes 3 Delete Never Never Never Sometimes 1 User can modify their own data, but not anybody else's Sometimes 2 Cannot change username or reset password more than once a day Sometimes 3 Admins should be able to set temporary password or trigger password reset
  15. 15. Building Threat Profile • Identifying Threats • CIA on assets • Attacker steals an asset • Attacker modifies an asset • Attacker denies an asset • Break rules in activity matrix • Attacker can act with higher privileges • Classifying Threats • Is it data tampering? DoS? Other? (more on STRIDE shortly) • Rating Threats • What is Impact? Likelihood? (more on DREAD shortly) • Building Threat Trees • Threat trees can provide comprehensive details about a threat, describing the conditions required to realize it
  16. 16. Tips for Building the Threat Model • Arrange a meeting to brainstorm on threats • Include at least one member from the different groups in the team • Developer • Architect • Tester • Business representative • Don’t think too much into solutions or mitigations • Identify each threat with a unique Threat ID
  17. 17. For Each Threat Decide How to Stop It • Redesign and eliminate • Use standard threat mitigations • Accept risk in accordance with your organization’s risk tolerance Client/UI Threat #4: Attacker Impersonates user Spoof authentication token/transaction ID Modify the audit trail so that it appears that a different user conducted the transaction Bypass the client application/UI to create transaction Attacker discovers another user’s credentials Attempt to intercept credentials during their transmission Attempt to discover credentials left in memory Threat Action Sub-Actions
  18. 18. Agenda • Threat Modeling 101 • Threat Modeling Activity Examples STRIDE and DREAD threat classification techniques • Leveraging a Threat Model at every phase of the SDLC
  19. 19. Vulnerability Classification and Prioritization • Not all vulnerabilities are equal, so it’s important to have defined criteria for vulnerability criticality • Here are the things you can use to get there • Data asset classification • DREAD • Criticality definitions (critical, high, medium, low) • Combined, it gives you a framework for how to respond to a vulnerability
  20. 20. STRIDE: Classifying Threats 20 Name Description Spoofing Is it something or someone that tricks us to be legitimate and valid? Tampering with Data Can attackers modify or tamper with legitimate information? Repudiation Is when a user denies performing a certain action which could be illegal and harmful? Information Disclosure Is information disclosed that should not be? Denial Of Service When a service is brought down intentionally or unintentionally, resulting in disruptions for legitimate users Escalation of privilege An unauthorized user gets higher privilege access from the one he was supposed to have, which might result in access to restricted information, or might apply dangerous tasks
  21. 21. DREAD: Rating Threats • For each vulnerability, assign a rating (0 to10) for each DREAD category • The final DREAD rating will be the sum of the ratings • The higher the DREAD rating, the more serious the vulnerability • Prioritize vulnerabilities according to their DREAD rating 21 Name Description Damage Potential How much damage can this threat do to our system? Reproducibility Is it easy to reproduce? Exploitability How much effort and experience does it require to be exploited? Affected Users In case the threat became an attack, how many users can be affected? Discoverability How easy is it to discover the vulnerability?
  22. 22. Threat Modeling Methodology – D.R.E.A.D.Rating High (3) Medium (2) Low (1) Damage potential Attacker can subvert security system, get full trust authorization, run as admin, upload content Leaking sensitive information Leaking trivial information Reproducibility Attack can be reproduced every time and does not require a timing window Attack can be reproduced but only with timing window and particular race situation Attack is difficult to reproduce, even with knowledge of the security hole Exploitability A novice programmer could make the attack in a short time A skilled programmer could make the attack, then repeat the steps. Attack requires extremely skilled person and in-depth knowledge every time to exploit Affected users All users, default configuration, key customers Some users, non-default configuration Small percentage of users, obscure feature; affects anonymous users Discoverability Published information explains the attack; Vulnerability is in most commonly used feature Vulnerability is in seldom-used part of product The bug is obscure; unlikely that users will work out damage potential DREAD: Example Ratings
  23. 23. Reporting Business Impact • DREAD can serve as an excellent template for providing insight into the business impact of a particular bug • For example - A SQL injection bug: • Damage potential: • High; A malicious user can directly access and modify the application database and run any Oracle commands that are available • Reproducibility: • Reproducible under default install • Exploitability: • Medium; Requires knowledge of Oracle SQL and the design of the application • Affected users: • All users of the application and others whose information is present in the database • Discoverability: • This is a standard attack vector for these types of applications 23
  24. 24. Prioritizing and Classifying Vulnerabilities Critical • Server or client side error allows remote code execution from anonymous user • Persistent XSS allows attacker to propagate a web-mail worm with minor victim interaction • Server crash or infinite loop allows attacker to generate a widespread DoS • Tampering vulnerability allows attacker to tamper with critical data Low • Server or client side error allows remote code execution from anonymous user • Denial of Service error caused by low resources in victim machine • Information disclosure of implementation details allows attacker to create/execute reverse engineering attacks Medium • Server or client side error allows remote code execution from anonymous user • Information disclosure allows attackers to gain access to fixed encryption data such as initialization vectors • Encryption or hashing using outdated methods SSL v2, MD4, etc High • Reflected cross-site scripting allows attacker to steal victims’ confidential data (such as cookies or session ID) • Server-side error such as excessive resource consumption allows attacker to generate a temporary widespread denial of service attack • Tampering vulnerability allows attacker to tamper with highly sensitive data • Local escalation of privileges allows a non-admin attacker to gain admin-level privileges
  25. 25. Defining Criticality • Every organization will report criticality differently • Consistency is important • Typical scales include several levels: • Critical • High • Medium • Low 25
  26. 26. Agenda • Threat Modeling 101 • Threat Modeling Activity Examples • STRIDE and DREAD threat classification techniques Leveraging a Threat Model at every phase of the SDLC
  27. 27. Leverage Threat Model to Gather Security Requirements • Threat modeling is generally a design-phase activity • However, its not a bad idea to start thinking in terms of threats when gathering security requirements • At a high level: • What should not be allowed to happen? • What are some critical assets that need to be protected? • For instance • Processing credit card data, so we can’t allow it to be stolen • Will need to generate some requirements around keeping the data safe when transmitting and we should not be storing it 27
  28. 28. Leverage Threat Model at Design • Shape your application design to meet security objectives • Build security architecture to protect critical assets • Decisions made before developing or during architectural or project revisions • Capture basic architectural and design assumptions that may raise security issues • List features that may increase the attack surface of your application • Help in defining mitigations to specific threats 28
  29. 29. Leveraging Threat Modeling to Code Defensively • Developers implement the security specifications, referring back to the threat model to understand the context they operate in. • Understand which assets need protection • Understand threats that can be used to compromise an asset • Understand what types of vulnerabilities could allow attacks through • Build countermeasures to reduce vulnerabilities in the code • Overall benefit is developer awareness and prioritization of effort to protect the most important assets against the most likely attacks 29
  30. 30. Leverage Threat Model for Precision Testing • Threat model contains attacks that should be attempted • Also contains vulnerabilities that, if present, would allow an attack to succeed • Tester can use this information to create a very targeted test plan • Built the test plan Security testing is the process of validating that security controls are in place and working appropriately • Ascertain how the application holds up against the types of attacks envisioned during the threat modeling exercise • Threat Model allows testers to focus testing on the most impactful threats and vulnerabilities 30 Threat model can be used by outside security teams to audit the code, freeing them from performing up-front analysis work.
  31. 31. Threat Model – Summarizing Software or Enterprise Risk • Threat Modeling allows you to get ahead of and plan for risk • If you understand threats and risks before deployment, you can reduce security impacts to development schedule and cost • Most solutions make trade offs between security and functionality • If low priority security concerns are mis-prioritized, you can negatively impact usefulness and user experience • If high priority security concerns are mis-prioritized, you can negatively impact your users and business • Threat modeling helps you plan and prioritize effectively 31
  32. 32. Summary • It all starts with Threats • What are the potential threats that could impact each asset? • Think about CIA on each asset: Confidentiality, Integrity, Availability • Under what conditions would each attack succeed? • Threat Models makes EVERY security engineering activity better • Threats change – update and improve iteratively • When your security objectives and design changes • During implementation, testing and deployment
  33. 33. How Security Innovation Can Help • Training • How to Conduct a Security Threat Model in addition to 100+ other courses • Computer based and Instructor-led for all major roles, technologies and platforms • Software and SDLC Assessments • Standards and Process Improvement • Application and IT Security Hackathons • Authentic environments to learn and hone attack and defense skills
  34. 34. Thank You! Related Resource • A CTO’s Perspective on Software Threat Classification • evolution-of-dread Additional Resources and Guides • Additional Webinar Replays •

    Be the first to comment

    Login to see the comments

  • sticks414

    Jan. 19, 2017
  • JesseGajinNa

    May. 31, 2018
  • cyberpower

    Jul. 11, 2018

Learn about threat modeling from our CTO and co-creator of the DREAD threat modeling classification, Jason Taylor. Understand more about what threat modeling is, dive into real life examples, and use techniques you can leverage at every phase of the SDLC.


Total views


On Slideshare


From embeds


Number of embeds