Threat Modeling - Locking the Door to Vulnerabilities
Download as PPTX, PDF2 likes1,167 views
This document details the significance of threat modeling in software security, emphasizing its role in identifying and managing vulnerabilities throughout the software development lifecycle. It advocates for a proactive approach to threat assessment, encouraging collaboration among stakeholders to create a shared understanding of potential risks and defensive measures. By implementing threat modeling, organizations can prioritize security efforts effectively and enhance overall risk management strategies.
Threat Modeling - Locking the Door to Vulnerabilities
- 1. Threat Modeling Locking the Door to Vulnerabilities #getsecure
- 2. Ed Adams • CEO by day; engineer by trade (and heart) • Mechanical Engineer, Software Engineer • Ponemon Institute Fellow • Privacy by Design Ambassador, Canada • In younger days, built non-lethal weapons systems for Federal Government
- 3. About Security Innovation • Authority in Software Security • 15+ years research on software vulnerabilities • Platform Centers of Excellence for specialization • Authors of 18 books, 11 with Microsoft • Named to the Gartner Magic Quadrant 4 years in a row • BIG Innovation and Cyber Security Excellence Award winner • Helping organizations minimize risk, regardless of problem complexity
- 4. Agenda Threat Modeling 101 • A World With and Without Threat Modeling • How Threat Modeling helps EVERY Security Stakeholder I’m not here to show you how to become a Threat Modeling guru – but to demonstrate it’s universal power in mitigating software risk
- 5. Polling Questions • Does your company conduct threat modeling? • If so, in what areas?
- 6. Threat Modeling vs. Other Security Analysis Techniques Activity Impact Phase Architecture & Design review Finds system level flaws Design Code review Finds code-level weaknesses Implementation Penetration test Finds dynamic vulnerabilities in the application and demonstrate their exploitability Verification/Deployment Attack surface review Finds/reduces number of avenues of attack Typically design Threat Model Finds issues related to most critical threats Typically design, but useful at every phase Two powerful risk management techniques “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
- 7. Threat Modeling Simplified Identify and quantify your weaknesses; devise appropriate defenses • Sound familiar? • Most people threat model every day but don’t realize it • If I asked you to threat model my house, you could; even if you have never been Courtesy: Sean Gallagher
- 8. Threat Mitigation Vulnerability Attacker ApplicationThreat Modeling Vulnerabilities are unmitigated threats Here’s our opportunity! • Secure applications start with understanding the threats • Threats are not vulnerabilities; they live forever and are attack vectors • If done right, provides more leverage than any other security activity
- 9. Why Threat Model? • Creates a shared understanding of problems that could happen • Reduces knee jerk reactions to events, tests, compliance, etc • Team effort to reduce threats • Abuse case creation for product owners and architects • Road map for developers to code defensively • Starting point to create security-minded test plans • Reliable way to: • Weigh security designs against functionality • Prioritize security efforts according to real risk • Find business-process and system-level security issues “To know your enemy, you must become your Enemy.” -Sun Tzu
- 10. What Threat Models Aren’t • A representation of how an attacker approaches a system • They represent total system security, not an attacker model • A test plan • A test plan is driven by a threat model, but threat models offer a lot more than just test planning • A formal proof of system security • This would be dangerous • A design review • Threat models are the foundation of it, but a design review needs to cover more implementation details and considerations beyond security
- 11. Why I Love Threat Modeling Professionally: how else could I possibly manage corporate risk effectively? Psychologically: tried and true risk management technique since the dawn of time provides confidence Cognitively: the engineer in me prefers a disciplined approach to problems versus “gut feel” Personally: my marriage depends on reducing bad decisions; e.g. spending hours fixing video doorbell when alarm system is broken
- 12. Agenda • Threat Modeling 101 A World With and Without Threat Modeling • How Threat Modeling helps EVERY Security Stakeholder
- 13. Threat Profiles are Never the Same @thegrugq
- 14. What Could Possibly Go Wrong? … and What do I do About It? Analyze Application Determin e Threats Rank Threat s • Identify possible threats based on motive, resources, and capabilities • Focus on most likely threats assets and not unicorns • e.g. most of us are not enemies of the state • What assets are you trying to protect? • What threats are the assets under? • What is the likelihood of that threat being realized? • What measures can mitigate or decrease the impact?
- 15. Threat Modeling vs. Threat Intelligence • Threat intelligence helps identify actions attackers are taking today • Alert overload without learning and improvement • Threat modeling helps reduce your attack surface and focus your investments in a proactive way • Unlikely to provide the quick hit that threat intelligence can, but drives a more strategic program Threat Modeling Threat Intelligence Timeframe Proactive Reactive Breadth Find issues Find attackers Vendor Support Consulting & Training Feeds & Tools
- 16. If Done Correctly, You’ll Get to This 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
- 17. Tabletop Exercise Threat Modeling In a Relatable Way • Setup: • I own a house on the ocean with an attached art and jewelry gallery • Components: • House, Ocean, Gallery • Assets: • Artwork, Jewels, Personal Property, Cat • I need to threat model to mitigate risk of theft, damage, disaster, etc.
- 18. OWASP Threat Physical World Software World Sensitive Data Exposure Items can be stolen in route to the gallery because the selected route is not secure Credentials can sniffed/stolen because it is passed in clear text on the network, e.g., login page HTTP Broken Authentication Items can be stolen from the gallery by an unauthorized “employee” because of a flawed identification mechanism at the gallery (counterfeit ID) Replay attacks stream legitimate messages from a valid user once stolen Security Misconfiguration Items can be stolen from the house because they were not stored in a safe Password stored as clear text in the database, e.g., not using password hashing Using Components with Known Vulnerabilities Items can be stolen from the house because the safe was using metal that was known to melt with high temperatures Has known hardware + software vulnerabilities Insufficient Logging and Monitoring Items can be stolen without possibility of tracing attacker, e.g., burglar can pick lock because video doorbell isn’t installed Security related actions like delete database, drop tables, etc. are not logged Broken Access Control Items can be stolen by an insider because there is no proper access management in the location where the artwork and jewelries are stored Direct object reference attacks attacker calls resource directly, e.g., knows URL or can brute force it Tabletop Exercise OWASP Overlay
- 19. Leverage to Code Defensively • Drives threat analysis into secure code reviews • Flaws in implementation methodologies and lack of development standards can be identified by looking to specific threats • Threats and misuse cases can drive unit test cases during implementation • Developers implement specifications, referring back to the threat model to understand operational context • Build countermeasures based on threats: encrypt data and traffic where and when? • Implement defensive coding measures to protect against attacks • e.g. customer feedback feature of application input sanitation • Take advantage of framework features, e.g., AntiXSS library in .NET 19
- 20. A World Without Threat Modeling • Inefficient use of resources • Reactiveness and randomization of efforts • Implementing counter-measures for low risk areas but leaving critical threats wide open • Looking for a dull needle in a haystack during testing
- 21. Vulnerable to Heartbleed? Threat #12 Compromise App Password 1.1 Access “in-use” password 1.2 Guess password 1.3 Access Password in DB 1.1.1 Sniff network 1.1.2 Phishing attack 1.2.1 Password is weak 1.2.2 Brute force attack 1.3.1 Password is in cleartext 1.3.2 Compromise database 1.3.2.1 SQL injection attack 1.3.2.2 Access database directly 1.3.2.2.1 Port open 1.3.2.2.2 Weak db account password(s) Use TLS to encrypt OpenSSL 1.0.1f Require strong Password 8+ char, upper, lower, number, special char Use Prepared Statements .NET parameterized queries OleDbCommand() with bind variables Restrict Port Access Firewall configuration
- 22. ThreatsVary and Evolve • Web, cloud, mobile attacked in different ways • Each technology has different security features and vulnerabilities • Threats change over time • Researchers will discover new ways to break into systems • Proprietary code will reveal itself to contain vulnerabilities • Deployed systems that have resisted attacks may eventually succumb • Things you do today may not work tomorrow so update/improve iteratively • When your security objectives and design changes • During implementation, testing and deployment • Threat models don't offer perfection, but help avoid a full-blown disaster
- 23. Example: Threat Modeling a Banking Application • Common elements in attack surface • Online banking uses TLS for all communications • Authentication: usernames, passwords, security questions, Touch ID, pins, SMS verification codes • Users select a security image that is displayed during authentication • Cookie-based session tokens for both the web and mobile application • No administrative roles or privileged users in the system • TAPI server handles all requests for the web and mobile applications • Top threats: an attacker can… • Read credentials and/or the the session ID • View or transfer account funds • Read or update bank account info and/or PII • Update account settings • Read, update, or delete messages or logs Many threats are likely applicable to your organization; however, it’s important to uncover unique threats and identify specific countermeasures
- 24. Agenda • Threat Modeling 101 • A World with and Without Threat Modeling How Threat Modeling helps EVERY Security Stakeholder
- 25. Leverage Threat Model to Gather Security Requirements • Requirement level threat models are constructed during definition phase • Business processes are security-checked and requirements documented • Need single-sign-on? Why? What’s the security benefit/risk? • Multi-factor authentication for the application? • Identification of negative scenarios and a preliminary threat analysis during requirement definition • Data classification can drive the identification of potential threats to the data assets 25 Leverage Threat Model to Gather Security Requirements • Requirement level threat models are constructed during definition phase • Business processes are security-checked and requirements documented • Need single-sign-on? Why? What’s the security benefit/risk? • Multi-factor authentication for the application? • Identification of negative scenarios and a preliminary threat analysis during requirement definition • Data classification can drive the identification of potential threats to the data assets 4
- 26. Leverage Threat Model at Design 26 • >50% defects introduce during design, when they’re cheapest to fix • Allows system architects to validate and explore whether the design meets the level of acceptable risks • Security requirements drive architecture choices • What type of multi-factor authentication for the application? • Which database will best meet functional and security requirements? • Which development language/framework is most appropriate? • Use of external components, libraries, and code • Increase/decrease attack surface? • Inherited vulnerabilities? • Additional security needed for component XYZ? • Etc.
- 27. Leverage for Precision Testing • Testers confirm that the specifications are implemented correctly • Each attack and sub-attack can become a test case in your test plan • Security testing validates controls are in place and working appropriately • Ascertain how the application holds up against the types of attacks envisioned during the threat modeling exercise – try them! • Drive test plans to ensure attacks focus on high threat areas 27 Threat model can be used by outside security teams to audit the code, freeing them from performing up-front analysis work.
- 28. Leverage for Acceptance Testing Plan Design Develop Test Deploy • Typical Plan and Design phases specifications, features, use cases • Threat modeling • Identify risks associated with outsourced development, e.g. backdoors • Supercharge SLAs with acceptance criteria, e.g. pass OWASP Top 10 scan • Develop robust test plans to look for specific threats defined pre-dev • Even forces a risk-based approach in planning and design
- 29. Leverage for Better Risk Management • Conduct a deployment review against threat model to ensure server configurations are appropriate • Threat model a portfolio of applicaitons for relative risk rating • Threat model during system operations to assess potential security risks and make informed decisions before change management events • Metrics and measurements can be gathered to plan the next releases • Lessons learned can be used to develop best practices and standards • Informed decision making around resource allocation and procurement
- 30. An Effective Threat Modeling Program… Agile, actionable, collaborative and focuses on business impact Has tangible outputs • Rolling list of top 10 threats replete with mitigating controls • Abuse cases • Security requirements Routine identification of new threats and mitigation validation Integrates with real-time intelligence around industry specific threats and statistical analysis of real-world attacks Track threats across organization Enforce consistency with re-usable components, e.g., authentication library
- 31. Summary • Threat models are an underutilized but powerful risk management technique • Threat Models are most effective when leveraged throughout development, deployment and operation • Bottom line: gets stakeholders speaking the same language and on the same page in terms of priorities and risk areas
- 32. Questions?
Editor's Notes
- #9: Secure software applications starts by thinking about threats
- #10: Threat Modeling helps you: Understand application risk Shape your application design to meet your security objectives Identify where more resources are required to reduce risks Weigh security decisions against other design goals Improve the security of your application by implementing effective countermeasures Understand attack vectors for penetration testing Understand the conditions under which an attack may be successful
- #17: One of the key goals of the threat model is to produce design-level mitigations for key threats. When faced with a significant threat you can choose to re-design your system in a way that eliminates the threat, you could use a mitigating technique to reduce or eliminate the threat or you can choose to accept the threat. In this example we have a threat in which an attacker can impersonate a user who authorized to use your system. There is probably not a way to redesign your system in a way that eliminates this threat as it would require a major modification to usage scenarios. In order to mitigate the threat you can apply mitigations to each branch of the attack tree. For instance you can ensure good server-side input and data validation to keep an attacker from bypassing security checks on the client. You can encrypt credentials on the network and in memory to keep an attacker from stealing these credentials and reusing them.