Threat analysis as methodology for deriving risk-based security

Threat analysis as methodology for deriving risk-based security tests of web application software Marco Morana OWASP marco. m. morana@gmail. com OWASP IMI 2009 Security Summit Copyright 2009 © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation http: //www. owasp. org

Presentation Agenda < Security Testing 101 (In 10 steps) 4 Security 4 Security requirements derivation testing in the SDLC testing workflows, techniques and tools testing guides test reporting and metrics < State of The Art Of Security Testing 4 Effective testing, compliance driven testing, tool centric testing < Risk Based Security Testing Methodology 4 Deriving test cases from cyber-intelligence, attack tree analysis, attack vectors analysis, ATM/secure architecture analysis < Security Risk Testing Strategy < Q&A OWASP 2

Security Testing 101 (In 10 Steps) OWASP 3

Why Security Testing? <How Security Testing Is Different From Traditional Quality Testing? 4 Test that security controls function as designed with “positive” tests 4 Test that security controls cannot be abused by exercising un-intended/abused functionality with “negative” tests 4 Test to find vulnerabilities in applications with an application scan/pen test 4 Test to find vulnerabilities in the source code with a source code analysis/secure code review 4 Test to find security flaws in design with application threat modeling/secure architecture review OWASP 4

Testing For Software Security: Quality Assurance vs. Software Assurance Quality faults: test as Designed for what we want to do http: //www. ddj. com/184405196 Security faults: test as built for anything unexpected OWASP 5

The authentication control should lock a user Step 1: Derive Security Requirements after 3 failed attempts <Functional requirements 4 Validate security controls work as designed to function The application need to implement input filtering and (e. g. encoding to mitigate XSS attacks outputauthentication, authorization, encryption etc) <Non functional requirements 4 Validate there are no vulnerabilities and security flaws < Security compliance requirements 4 not store CC authentication data protect CCH data Do. Validate compliance with FFIEC, GLBA, PCI-DSS, SB in 1386, Info. Sec, CCN on display storage and mask. App. Sec standards <Threat mitigation requirements 4 Validate mitigation against threats : Spoofing user identity, Tampering client and server to prevent Mutually authenticatewith the data, Repudiation, Information Disclosure, as Man In the Middle (Mi. TM) repudiation attacks such Denial of service, Elevation of privileges attacks OWASP 6

Derivation Of Security Requirements To Validate Compliance With Security Standards < [PCI-DSS] 6 Develop and Maintain Secure Systems and Applications 4 All vulnerabilities must be corrected. 4 The application must be re-evaluated after the corrections. 4 The application firewall must detect and prevent web based attacks such as cross site scripting and SQL injection. < [PCI-DSS] 11 Regularly Test Security Systems and Processes < [PCI-DSS] 11. 3. 2 External application layer penetration test. 4 For web applications, the tests should include, at a minimum, the following vulnerabilities: OWASP T 10 OWASP 7

Step 2: Use Security Requirement Engineering Techniques such as Use And Misuse Cases OWASP 8

Step 3: Identify Security Testing Tollgates ity x abil Risk reat = Th t Cos d to e nee lner x Vu do w What w o And h Threat and risk Modeling Design w tools revie Code Secure Design Review Security requirements Requirements and use cases test, Risk-based security tests Test plans Code Review Static analysis (tools) Code Iterative approach Penetration testing Test results Field feedback OWASP 9

Step 4: Integrate Security Testing In Developer’s Workflows <Developers Security Tests 4 Test security of functions, methods and classes 4 Security unit/component tests 4 Secure code reviews/security bugs testing 4 Dynamic analysis (e. g. application scans) <Main developer’s workflow test check-points 4 Secure code reviews : validate compliance with secure coding standards during coding interactions 4 Defect management: clean security bugs before check-in code in application builds OWASP 10

Step 5: Integrate Security Testing in Tester’s Workflows <Testers Security Tests 4 Test security in integrated application builds 4 Validate application security requirements 4 Assess and exploit vulnerabilities 4 Test for secure configuration in operational environment 4 Fuzz testing, reverse engineering <Tester Workflow Check Points 4 Validate application security requirements before release to QA or production: security assurance 4 Remediate all HIGH RISK vulnerabilities before release to production according to compliance requirements OWASP 11

Step 6: Adopt Manual and Automated Security Testing Techniques Find Vulnerabilities Using Combining All Four Find Vulnerabilities Using the Running Application Techniques is Most Effective the Source Code Manual Penetration Testing Automated Vulnerability Scanning Manual Code Review Automated Static Code Analysis OWASP 12

Step 7: Decide Which Security Testing Tools To Use <Vulnerability Scanning 4 ISS, Foundscan, Nessus, Nikto <Penetration Testing (Black Box Testing) 4 Webinspect, Appscan, Hailstorm, Paros, Peach <Binary Analysis/Reverse Engineering 4 IDA Pro, @stake Smart. Risk <Source Code Analysis 4 Fortify, Klockworks, Parasoft, Free Tools (e. g. Find. Bugs) <Threat Modeling 4 MS TAM, TRIKE, PTA Technologies <Rootkit Back. Door Analysis 4 ootkits. org and rootkit. nl OWASP 13

Step 8: Document Security Testing Cases Using Testing Guides <The OWASP Testing Guide <Testing Principles <Testing Process <Custom Web Applications <Black Box Testing <Grey Box Testing <Risk and Reporting <Appendix: Testing Tools <Appendix: Fuzz Vectors <Information Gathering <Business Logic Testing <Authentication Testing <Session Management Testing <Data Validation Testing <Denial of Service Testing <Web Services Testing <Ajax Testing OWASP 14

Step 9: Report The Findings http: //www. owasp. org/index. php/How_to_write_the_report_of_the_testing_Ao. C OWASP 15

What I Should Put in The Testing Report? <The security threat that can potentially exploit the vulnerability/defect <The root cause of security issues (e. g. , security bugs, security flaw) <The testing technique being used (e. g. source code analysis, pen test, threat modeling, security test case) <The remediation of the vulnerability/defect (requirement, design, code configuration change) <The risk rating of the vulnerability (Critical, High, Medium, Low) OWASP 16

Step 10: Collect Security Testing Metrics <Measurement Goals: 4 Measure vulnerabilities found with pen-tests to validate that are closed before production release 4 Measure vulnerabilities found with source code analysis and correlate with the ones found in pen tests 4 Measure time it takes to fix vulnerabilities during coding and during validation tests <Security Metrics: 4 No. of High, Mediums for each application 4 No. of vulnerabilities found in source code vs. the application 4 Time (man/hours) required to close security issues OWASP 17

State of the Art Of Security Testing OWASP 18

Risk Based Security Testing <The main objective is to assert threat mitigation: 4 Mitigate attacks targeting different exposure factors : internet, extranet, intranet 4 Mitigate attacks targeting different threats: fraud, confidential PII, credit card data, denial of service 4 Mitigate attacks that might exploit known vulnerabilities (e. g. OWASP T 10) 4 Mitigate attacks that might abuse functionality to cause damage/business impact (e. g. design flaw that allow to reset password insecurely) OWASP 19

Security Testing From Compliance Perspective < Good reasons for compliance security testing: 4 Avoid fines : $500, 000 - 800, 000 x breach 4 Doing business with third party (e. g. Walmart) 4 Minimal security assurance: CYA According to a recent survey (*) “ 71 percent of 4 Not convinced. DO NOT treatlead to better security companies checklists will PCI as a strategic < Butinitiative rely on compliance security tests since not just and 79 percent have experienced a data breaches occur even to PCI compliant DATA BREACH” (*) http: //www. imperva. com/docs/AR_Ponemon_2009_PCI_DSS_Compliance_Survey. pdf companies: 4 Heartland Payment Systems, 130 million credit cards 4 Hannaford Bros, 4. 2 million credit card < How aware you about software security assurance ? Beware of bad examples… OWASP 20

Security Testing From Security Tools Perspective < MITRE found that all application Beware of the silver bullet security tool vendors’ claims put security mentality 45% of the known together cover only and false sense of security (over 600 in CWE) vulnerability types given by tools ! < They found very little overlap between tools, so to get 45% you need them all (assuming their claims are true) OWASP 21

Security Testing From The Application Business Logic Perspective <“ 76% of financial sites still have at least one critical design flaw that can be exploited to cause financial fraud, identify theft, reputationbrand damage, denial of service to customers” (University Of Michigan study) <“Information leakage, insufficient authentication and authorization, and abuse of the website’s functionality are prime money-makers” (White. Hat Security Inc. ) OWASP 22

Risk Based Security Testing Methodology OWASP 23

Starting With Risk Based Security Testing < Basic Security Tests Are Prerequisite: 4 Functional and non functional security requirements are tested in compliance with standards and policies 4 Known vulnerabilities are assessed and mitigated < Expand Security Testing to: 4 Real attack scenarios (e. g. cybercrime) 4 Same methods, tools attack vectors and vulnerability exploits used by the attackers 4 Potential abuse/misuse of business logic 4 All entry points and access levels 4 Probing secure design/architecture OWASP 24

Risk Based Security Testing Methodology 1. Threat Intelligence: gather information about real attacks to simulate the same attack scenarios 2. Threat tree analysis: learn attacker goals and methods to derive test cases 3. Use and misuse cases to validate countermeasures for potential abuse of functionality 4. Attack vector analysis for testing attacks against defense evasion techniques (e. g. data encoding, automation) 5. Secure architecture analysis for proving countermeasures at different layers: external entity, trust boundary, data flow, process and asset. OWASP 25

Cyber-Attacks Intelligence Driven Security Tests <Gather information from cybercrime intelligence: 4 Learn from public cyber-crime reports: IC 3, Symantec, Mc. Afee AVERT Labs, Finjan software 4 Analyze the attacks: industry, geographic, local market, overall business, branch 4 Become your enemy: derive the attack scenarios, analyze the attack vectors and vulnerabilities exploited by cybercriminals. < Probe your defenses: 4 Try to exploit vulnerabilities using attack vectors 4 Use same botnet Trojans and PERL script tools to test application resilience against automation attacks OWASP 26

Cybercrime Threat Intelligence and Analysis: ATTACK: Attack “xp_cmdshell on MSQL server to upload sniffers to capture CC transactions and ATM PINs from DB, HSM TEST CASES AGAINST THIS THREAT: 1. Test xp_cmdshell is disabled 2. Test extended URLs are denied 3. Test escape for special characters “”, comma 4. Test store procedures run with minimum privileges 5. Test SQL Server and IIS run under non-privilege 6. Test appserver not use “sa” hardcoded 7. Test account locking on mainframes against brute force 8. Test access to DB server is internally restricted by IP 9. Test a proxy server is used for internet access 10. Test firewall rules are updated OWASP 11. Test HSM not use commands with PIN in the clear 27

Threat Tree Analysis of Credit Card Compromise Attacks #1 Test web application assuming browser compromise and/or automation attacks #2 Test for SQL injection and code injection (Frames) vulnerabilities #3 Test encryption of sensitive CC data in storage and transit #4 Test for session fixation and hijacking OWASP 28

Security Testing With Attack Libraries <Derive a list of attack vectors that can be used for testing countermeasures such as filtering of encoded cross-site scripting and SQL injection commands. <Start with code injection attacks library: 4 SQL injection attacks 4 HTML (IFRAME) injection attacks 4 Script injection (e. g. cross-site scripting) attacks 4 Command shell injection attacks 4 File injection attacks 4 Server pages injection attacks (e. g. ASP, PHP) 4 Cookie poisoning attacks 4 XML poisoning attacks OWASP 29

Attack Vectors For Testing Web Applications OWASP 30

Security Testing Using Application Threat Modeling Analysis <DFD-secure architecture analysis provide testers information about the application scope for risk based testing such as: 4 The location of the application entry points that need to be tested 4 The access levels that are required to access the entry points 4 The vulnerabilities that can be exploited at each layer of the architecture that need to be tested 4 The countermeasures that need to be tested for mitigation of identified threats. OWASP 31

Application Threat Modeling Access Level Internal I. Spoofing II. Repudiation Auth. N, Encryption Digital, signatures, HMAC, TS Access Level External Access Level Restricted I. Auth. N, Encryption II. Digital signatures, HMAC, TS, Auth. Z Audit III. Encryption, Auth. Z IV. Filtering, Auth. N I. Tampering II. Repudiation III. Info Disclosure IV. Denial OF service OWASP 32

Threat Modeling Driven Security Test Cases < Spoofing Identity 4 Test attempts to impersonate a user by sniffing user credentials on the wire or in persistent storage 4 Test that security tokens (e. g. cookie) issued before authentication cannot be replayed to bypass authentication < Tampering with the data 4 Test with a web proxy that is not possible to tamper and replay the data 4 Test strength of hashes against replay attacks (e. g. use of salted hashes) < Repudiation 4 Test mutual authentication and/or digital signatures to trust connection between client and server 4 Test all security events are audited and logged OWASP 33

Threat Driven Security Test Cases (Con’t) < Information Disclosure 4 Test that the access of non-public data requires authentication 4 Test that error messages and exceptions do not disclose useful information to an attacker 4 Test that processes do not cache or log passwords, session information or PII < Denial of Service (Dos) 4 Test you cannot flood a process with so much data it stops responding to valid requests. 4 Test that malformed data cannot crash the process < Elevation of Privilege 4 Test user cannot tamper client parameters or forceful browsing to his elevate privileges 4 Test that a process cannot be forced to load a command shell, which in turn will execute with elevated privileges OWASP 34

Threat Driven Security Testing Activities Throughout the SDLC Identify security requirements to be tested Identify data flows to be tested Identify attack scenarios, goals and methods to test Identify security flaws and countermeasures to be tested Secure Coding Requirements drive testing during coding Identify security bugs with secure code analysis Derive security test cases for integrated system tests Test secure configuration before production release Identify vulnerabilities with pen tests during UAT cycles OWASP 35

Security Risk Driven Strategy OWASP 36

The Security Risk Testing Strategy <Identify which attacks can be most likely used against your web application and your customers <Use attack methods where difficulty of attack is the least and the impact is the highest <Use misuse cases to test abuse of functionality/business logic <Use the same attack vectors to try to evade countermeasures/defense mechanisms <Test defense in depth against threats identified in the application threat model OWASP 37

Q & QUESTIONS ANSWERS OWASP 38

References < OWASP Testing Guide 4 http: //www. owasp. org/index. php/OWASP_Testing_Guide_v 3_Table_o f_Contents < Testing for Software Security Rethinking security bugs 4 http: //www. ddj. com/184405196 < Education Module Embed within SDLC 4 http: //www. owasp. org/index. php? title=Education_Module_Embed_wi thin_SDLC&setlang=es < OWASP CAL 9000 Project 4 http: //www. owasp. org/index. php/Category: OWASP_CAL 9000_Project < Security Flaws Identification and Technical Risk Analysis Through Threat Modeling 4 http: //www. net-security. org/dl/insecure/INSECURE-Mag-17. pdf < OWASP Application Threat Modeling 4 http: //www. owasp. org/index. php/Application_Threat_Modeling OWASP 39