More Related Content
What's hot (20)
Viewers also liked (20)
Similar to Appsec2013 assurance tagging-robert martin (20)
More from drewz lin (17)
Recently uploaded (20)
Appsec2013 assurance tagging-robert martin
- 1. Tagging Your Code with a Useful Assurance Label Engineering Your Software For Attack Robert A. Martin Senior Principal Engineer Cyber Security Center Center for National Security The MITRE Corporation
- 2. About Me • About Me Identified Hosted by OWASP & the NYC Chapter
- 3. What We’ve Learned Making systems secure by just reducing attack surface really hard – maybe impossible Software Systems & Networks too large and complex Zero vulnerabilities for all assets on network? – Assumes you know all assets – Assumes you can know all vulnerabilities Cyber Attack Lifecycle Recon Deliver Weaponize Control Exploit Maintain Execute
- 4. Characteristics of the Advanced Persistent Threat 1. We won’t always see the initial attack 2. We can’t keep the adversary out 3. Advanced Persistent Threat is not a “hacker”
- 5. Cyber Threat Intelligence Sharing Building Blocks – Phases of a Cyber Attack Lifecycle Recon Deliver Weaponize Proactive Detection Mitigation Recon Weaponize Control Exploit Maintain Execute Incident Response & Mission Assurance • Obtain information to conduct the attack • Place payload into delivery vehicle Deliver • Send the attack to the potential victim Exploit • The point of no return Control • Direct the victim system to take actions Execute • Fulfill mission requirements Maintain • Insure future access
- 8. Elements of an Attacker Aware Cyber Threat Intelligence Sharing-Based Approach 1. Understanding of the Attackers Building Blocks 2. Effective Cyber Threat Intelligence Sharing Model 3. Agile defensive posture aligned with threat from the attackers and attack techniques 4. Development team working side-by-side with operators (DevOps)
- 9. Extending the Threat-Driven Perspective Beyond Operational Defense Risk-Based, Attack-Aware, and Threat-Driven Operational Strategic
- 10. From Just a Mitigation Approach A traditional information assurance approach based solely on regulation, which resulted in an approach based on mitigation and compliance around static defenses To a threat/attacker based cyber defense that understands attacks and balances Mitigation with Detection and Response M • Defenders become demanding consumers of intelligence, informed by understanding of the attacks their software systems face D • Producers of intelligence R
- 11. What is “Cyber Threat Intelligence?” Consider these questions: What activity/attacks are we seeing? What attacks should I look for on my networks and systems and why? Where has this attack been seen? What does it do? What weaknesses does this attack exploit? Why does attacker do this? Who is responsible for this attack? What can I do about it?
- 21. A1 Threat Agents Risk Application Specific Application Security Risks What Are Application Security Risks? Attackers can potentially use many different paths through your application to do harm to your business or organization. Each of these paths represents a risk that may, or may not, be serious enough to warrant attention. Threat Agents Attack Vectors Security Weaknesses Security Controls Weakness Control Attack Technical Impacts Business Impacts Impact Asset Attack Weakness Attack Impact Weakness Control Function Impact Asset Weakness What’s My Risk? References The OWASP Top 10 focuses on identifying the most serious risks for a broad array of organizations. For each of these risks, we provide generic information about likelihood and technical impact using the following simple ratings scheme, which is based on the OWASP Risk Rating Methodology. OWASP Weakness Prevalence Weakness Detectability Technical Impacts Easy Widespread Easy Severe Average Common Average Moderate Difficult App Specific Attack Vectors Uncommon Difficult Minor Attack Vectors Business Impacts App / Business Specific Only you know the specifics of your environment and your business. For any given application, there may not be a threat agent that can perform the relevant attack, or the technical impact may not make any difference to your business. Therefore, you should evaluate each risk for yourself, focusing on the threat agents, security controls, and business impacts in your enterprise. We list Threat Agents as Application Specific, and Business Impacts as Application / Business Specific to indicate these are clearly dependent on the details about your application in your enterprise. The names of the risks in the Top 10 stem from the type of attack, the type of weakness, or the type of impact they cause. We chose names that accurately reflect the risks and, where possible, align with common terminology most likely to raise awareness. • OWASP Risk Rating Methodology • Article on Threat/Risk Modeling External • FAIR Information Risk Framework • Microsoft Threat Modeling (STRIDE and DREAD) Security Weakness Exploitability EASY Attacker sends simple text-based attacks that exploit the syntax of the targeted interpreter. Almost any source of data can be an injection vector, including internal sources. Control Sometimes, these paths are trivial to find and exploit and sometimes they are extremely difficult. Similarly, the harm that is caused may be of no consequence, or it may put you out of business. To determine the risk to your organization, you can evaluate the likelihood associated with each threat agent, attack vector, and security weakness and combine it with an estimate of the technical and business impact to your organization. Together, these factors determine the overall risk. Threat Agents Consider anyone who can send untrusted data to the system, including external users, internal users, and administrators. Injection Prevalence COMMON Detectability AVERAGE Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code. They are often found in SQL, LDAP, Xpath, or NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc. Injection flaws are easy to discover when examining code, but frequently hard to discover via testing. Scanners and fuzzers can help attackers find injection flaws. Technical Impacts Business Impacts Impact SEVERE Application / Business Specific Injection can result in data loss or corruption, lack of accountability, or denial of access. Injection can sometimes lead to complete host takeover. Consider the business value of the affected data and the platform running the interpreter. All data could be stolen, modified, or deleted. Could your reputation be harmed? Am I Vulnerable To Injection? How Do I Prevent Injection? The best way to find out if an application is vulnerable to injection is to verify that all use of interpreters clearly separates untrusted data from the command or query. For SQL calls, this means using bind variables in all prepared statements and stored procedures, and avoiding dynamic queries. Automated dynamic scanning which exercises the application may provide insight into whether some exploitable injection flaws exist. Scanners cannot always reach interpreters and have difficulty detecting whether an attack was successful. Poor error handling makes injection flaws easier to discover. Preventing injection requires keeping untrusted data separate from commands and queries. 1. The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful with APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood. 2. If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter. OWASP’s ESAPI provides many of these escaping routines. 3. Positive or “white list” input validation is also recommended, but is not a complete defense as many applications require special characters in their input. If special characters are required, only approaches 1. and 2. above will make their use safe. OWASP’s ESAPI has an extensible library of white list input validation routines. Example Attack Scenarios References Scenario #1: The application uses untrusted data in the construction of the following vulnerable SQL call: OWASP Checking the code is a fast and accurate way to see if the application uses interpreters safely. Code analysis tools can help a security analyst find the use of interpreters and trace the data flow through the application. Penetration testers can validate these issues by crafting exploits that confirm the vulnerability. String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; Scenario #2: Similarly, an application’s blind trust in frameworks may result in queries that are still vulnerable, (e.g., Hibernate Query Language (HQL)): Query HQLQuery = session.createQuery(“FROM accounts WHERE custID='“ + request.getParameter("id") + "'"); • OWASP SQL Injection Prevention Cheat Sheet • OWASP Query Parameterization Cheat Sheet • OWASP Command Injection Article • OWASP XML eXternal Entity (XXE) Reference Article • ASVS: Output Encoding/Escaping Requirements (V6) • OWASP Testing Guide: Chapter on SQL Injection Testing In both cases, the attacker modifies the ‘id’ parameter value in her browser to send: ' or '1'='1. For example: External http://example.com/app/accountView?id=' or '1'='1 • CWE Entry 89 on SQL Injection This changes the meaning of both queries to return all the records from the accounts table. More dangerous attacks could modify data or even invoke stored procedures. • CWE Entry 564 on Hibernate Injection • CWE Entry 77 on Command Injection
- 24. Software Assurance Methods Countermeasure Selection Development Process Apply assurance activities to the procedures and structure imposed on software development Operational System Implement countermeasures to the design and acquisition of end-item software products and their interfaces Development Environment Apply assurance activities to the environment and tools for developing, testing, and integrating software code and interfaces Additional Guidance in PPP Outline and Guidance
- 25. Public Law 113-239 Section 933 - Software Assurance DoD Software-based System Software Assurance.—The term ‘‘software assurance’’ means the level of confidence that software functions as intended and is free of vulnerabilities, either intentionally or unintentionally designed or inserted as part of the software, throughout the life cycle. Sect933 confidence functions as intended Program Office Milestone Reviews with OSD on SwA Program Protection Plan’s “Application of Software Assurance Countermeasures” Development Process • Static Analysis • Design Inspection • Code Inspections • CVE • CAPEC • CWE • Pen Test • Test Coverage Operational System • Failover Multiple Supplier Redundancy • Fault Isolation • Least Privilege • System Element Isolation • Input checking/validation • SW load key Development Environment • Source • Release Testing • Generated code inspection free of vulnerabilities
- 27. SQL Injection Attack Execution Flow User 1. Web Form with ‘ in all fields MS SQL Database 2. One SQL error message SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='$user_input' 3. Web Form with ‘ in ITEM_CATEGORY field ORDER BY message PRICE 4. SQL error 5. Web Form with: ' exec master..xp_cmdshell 'dir' -6. a listing of all directories
- 28. Simple test case for SQL Injection Test Case 1: Single quote SQL injection of registration page web form fields Test Case Goal: Ensure SQL syntax single quote character entered in registration page web form fields does not cause abnormal SQL behavior Context: • This test case is part of a broader SQL injection syntax exploration suite of tests to probe various potential injection points for susceptibility to SQL injection. If this test case fails, it should be followed-up with test cases from the SQL injection experimentation test suite. Preconditions: • Access to system registration page exists • Registration page web form field content are used by system in SQL queries of the system database upon page submission • User has the ability to enter free-form text into registration page web form fields Test Data: • ASCII single quote character Action Steps: • Enter single quote character into each web form field on the registration page • Submit the contents of the registration page Postconditions: • Test case fails if SQL error is thrown • Test case passes if page submission succeeds without any SQL errors
- 29. Security Feature Cross-site Scripting (XSS) Attack (CAPEC-86) Improper Neutralization of Input During Web Page Generation (CWE-79) SQL Injection Attack (CAPEC-66) Improper Neutralization of Special Elements used in an SQL Command (CWE-89) 29
- 30. Software, Network Traffic, Physical, Social Engineering, and Supply Chain Attack Patterns
- 33. Engineering For Attack – ISO/IEC TR 20004: Refining Software Vulnerability Analysis Under ISO/IEC 15049 and ISO/IEC 18045 Known Threat Actors Attack Patterns (CAPECs) Attack Weaknesses (CWEs) Weakness Controls* System & System Security Engineering Trades Technical Impacts Operational Impacts Impact Item Asset Attack Weakness Impact Item Function Attack Impact Weakness Asset Weakness Item * Controls include architecture choices, design choices, added security functions, activities & processes, physical decomposition choices, code assessments, design reviews, dynamic testing, and pen testing
- 34. Technical Impacts – Common Consequences
- 35. Scoring Weaknesses Based on Context Archetypes: • Web Browser User Interface • Web Servers • Application Servers • Database Systems • Desktop Systems • SSL Vignettes: 1. Web-based Retail Provider 2. Intranet resident health records management system of hospital Web Browser Web Browser Web Browser 2 1 Web Browser Web Browser Web Browser Web Browser
- 36. Vignettes – Technology Groups & Business/Mission Domains Common Weakness Risk Assessment Framework uses Vignettes with Archetypes to identify top CWEs in respective Domain/Technology Groups
- 37. Business Value Context (BVC) • Identifies critical assets and security concerns • Links Technical Impacts (derived from CWE weaknesses) with business implications • More fine-grained model than the CIA Triad • • (Medical billing): Privacy is very important, claimed by one source to be the largest obstacle for sharing medical records; yet life-and-death situations in (critical care) may have different criteria than in a clinical setting. Electronic medical breaches could lead to discrimination, not just personal embarrassment or discomfort. Availability is less important - could cause delays in billing but do not directly affect health of the patient. (Implanted medical device): Power consumption and privacy a concern. Key management important. Must balance ease-of-access during emergency care with patient privacy and day-to-day security. Integrity and availability are essential improper execution or failure of the device could lead to illness or death.
- 38. Technical Impact Scorecard • Links business value with the technical impact of weakness exploitation • Stays away from technical details of individual weaknesses • Operates within the context of a vignette
- 40. Scoring Weaknesses Discovered in Code using CWSS
- 41. Utilizing Coverage Claims Code Review CWE’s a capability claims to cover Static Analysis Tool A Static Analysis Tool B Pen Testing Services Most Important Weaknesses (CWE’s) Which static analysis tools and Pen Testing services find the CWE’s I care about?
- 42. Leveraging and Managing to take Advantage of the Multiple Perspectives of Analysis • • • • • Null Pointer Dereference Threading Issues Issues in Dead Code Insecure Crypto Functions … Total Potential Security Weaknesses Static Analysis Application Logic Issues • • • • • • Environment Configuration Issues Issues in integrations of modules Runtime Privileges Issues Protocol Parser/Serializer Issues Issues in 3rd party components … Dynamic Analysis • • • • • • SQL Injection Cross Site Scripting HTTP Response Splitting OS Commanding LDAP Injection …
- 43. Leveraging and Managing to take Advantage of the Multiple Perspectives of Analysis Different perspectives are effective at finding different types of weaknesses Some are good at finding the cause and some at finding the effect Static Code Analysis Penetration Test Data Security Analysis Code Review Cross-Site Scripting (XSS) X X X SQL Injection X X Architecture Risk Analysis X Insufficient Authorization Controls X X X X Broken Authentication and Session Management X X X X Information Leakage X X Improper Error Handling X X Insecure Use of Cryptography X X Cross Site Request Forgery (CSRF) X X Denial of Service X Poor Coding Practices X X X X X X
- 44. SwA and Systems Development (example) Abuse Case Development Cyber Threat/ Attack Analysis Application Security Code Review (developed and purchased), Penetration Testing & Abuse Case Driven Testing Gather All of the Evidence for the Assurance Case and Get It Approved and Systems Design Attack Analysis against Supply Chain & Application Architecture Security Review Attack-based Application Design Security Review * Ideally Insert SwA before RFP release in Analysis of Alternatives Application Security Code Review, Penetration Testing & Abuse Case Driven Testing of Maintenance Updates
- 45. (Page 1 of 3) Want Discernibility Suggestions Started with Mitigation Suggestions
- 46. (3) DoS: unreliable execution (4) DoS: resource consumption (5) Execute unauthorized code or commands (6) Gain privileges / assume identity (7) Bypass protection mechanism (8) Hide activities Binary Static Analysis Automated Dynamic Analysis 81 CWEs 91 CWEs 56 CWEs 31 CWEs 69 CWEs 60 CWEs 74 CWEs 26 CWEs Penetration Testing Review of Live System (2) Read Data Source Code Static Analysis Review of Code (1) Modify data Design Review Review of Architecture and Design Architecture Analysis Red Team Assessment
- 47. “An Assurance Tag for Binaries” Architecture Analysis (1) Modify data Design Review Source Code Static Analysis Binary Static Analysis Automated Dynamic Analysis Penetration Testing CWE-23 CWE-23 Relative Path Traversal CWE-131 CWE-131 Incorrect Calculation of Buffer Size CWE-311 (2) Read Data CWE-14 CWE-14 Compiler Removal of Buffer Clearing CWE-129 CWE-129 Improper Validation of Array Index CWE-209 CWE-209 CWE-209 Information Exposure Through an Error Messages (3) DoS: unreliable execution CWE-36 CWE-476 CWE-476 Null Pointer Dereference CWE-406 (4) DoS: resource consumption CWE-395 CWE-395 Use of NullPointerException CWE-190 CWE-412 (5) Execute unauthorized code or commands CWE-88 CWE-120 (6) Gain privileges / assume identity CWE-96 (7) Bypass protection mechanism (8) Hide activities CWE-89 CWE-36 Absolute Path Traversal CWE-88 Argument Injection CWE-96 Static Code Injection CWE-89 SQL Injection CWE-78 CWE-78 OS Command Injection CWE-190 Integer Overflow CWE-120 CWE-489 Leftover Debug Code CWE-311 Missing Encryption of Sensitive Data CWE-406 CWE-406 Network Amplification CWE-412 CWE-412 Unrestricted Externally Accessible Lock CWE-120 Buffer Overflow CWE-489 CWE-311 Red Team Assessment CWE-79 CWE-79 Cross-site Scripting CWE-309 CWE-309 CWE-309 Use of Password System for Primary Authentication CWE-357 CWE-357 Insufficient UI Warning of Dangerous CWE-665 CWE-168 CWE-168 Improper Handling of Inconsistent CWE-444 CWE-665 CWE-665 Improper Initialization CWE-444 CWE-444 HTTP Request Smuggling
- 48. © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use
- 49. Planning to Leverage “State of the Art Resource” (SOAR): Software Table of “Verification Methods”
- 50. Going Forward • Put table of CWEs, by the 8 Technical Impact Types, on the “SwA On-Ramp” • Fill in missing remediation recommendations for the rest of CWE • Validate the CWEtechnical impact type in CWE • Fill in “Discernibility” information for each CWE leveraging the IDA SOAR – those discernable in arch/design review; – those discernable (findable) in the code; and – those discernable on the live system. • Other Ideas? • Volunteers?
- 51. Big finish? Sharing knowledge of our opponents and watching the plays develop, we can make the saves that protect our networks and the software running on them. 51
- 52. Optional: FFRDC name here Optional Image Here Optional Image Here Optional Image Here Optional Image Here Optional Image Here Optional Image Here
Editor's Notes
- #2: With so many ways for software to be vulnerable, businesses needs a way to focus their assurance efforts on those potential vulnerabilities that are most dangerous to them and their software. This talk will offer a new way to focus and organize your software vulnerability assessment and assurance efforts across the entire life-cycle of a project so that you target the most impactful weaknesses when they are most visible. The approach can be done consistently across your enterprise and will have you looking for specific weaknesses at the point where you can gain the most assurance that you have dealt with them successfully. Matched to the activities of your development effort, this approach will have your team looking for those security weaknesses (CWEs) that are most discernable/findable in each of the different stages of a software development effort. For example, when you have a live exemplar system available you should look for the weaknesses in design, configuration, code, or architecture that are findable through dynamic analysis, pen testing, or red teaming of that living system. Similarly, in the coding phase you want the emphasis to be looking for weaknesses that are findable by static analysis tools. The follow-on step to this approach is to use what you found and what you did to create “An Assurance Tag for Binaries", basically an assurance "food label" for the code of that project. This talk will conclude with a discussion of what such a tag could look like, what it could capture, how the information could be obtained, whom would/could create them, and how they could be represented for humans and machines to use.
- #9: Development team working side-by-side with operators (DevOps)