Presentation is loading. Please wait.

Presentation is loading. Please wait.

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.

Similar presentations


Presentation on theme: "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."— Presentation transcript:

1 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 OWASP Threat analysis as methodology for deriving risk-based security tests of web application software Marco Morana OWASP IMI 2009 Security Summit

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

3 OWASP Security Testing 101 (In 10 Steps) 33

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

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

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

7 OWASP Derivation Of Security Requirements To Validate Compliance With Security Standards 7  [PCI-DSS] 6 Develop and Maintain Secure Systems and Applications  All vulnerabilities must be corrected.  The application must be re-evaluated after the corrections.  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] External application layer penetration test.  For web applications, the tests should include, at a minimum, the following vulnerabilities: OWASP T10

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

9 OWASP 9 Step 3: Identify Security Testing Tollgates Requirements and use cases DesignTest plans Code Test results Field feedback Security requirements Threat and risk Modeling Risk-based security tests Static analysis (tools) Penetration testing Secure Design Review Iterative approach Code Review Risk = Threat x Vulnerability x Cost What do we need to test, And how Code review tools

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

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

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

13 OWASP 13 Step 7: Decide Which Security Testing Tools To Use  Vulnerability Scanning  ISS, Foundscan, Nessus, Nikto  Penetration Testing (Black Box Testing)  Webinspect, Appscan, Hailstorm, Paros, Peach  Binary Analysis/Reverse Engineering  IDA SmartRisk  Source Code Analysis  Fortify, Klockworks, Parasoft, Free Tools (e.g. FindBugs)  Threat Modeling  MS TAM, TRIKE, PTA Technologies  Rootkit BackDoor Analysis  ootkits.org and rootkit.nl

14 OWASP 14 Step 8: Document Security Testing Cases Using Testing Guides  Information Gathering  Business Logic Testing  Authentication Testing  Session Management Testing  Data Validation Testing  Denial of Service Testing  Web Services Testing  Ajax Testing  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

15 OWASP Step 9: Report The Findings 15

16 OWASP 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) 16

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

18 OWASP State of the Art Of Security Testing 18

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

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

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

22 OWASP 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, reputation- brand 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” (WhiteHat Security Inc.) 22

23 OWASP Risk Based Security Testing Methodology 23

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

25 OWASP 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. 25

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

27 OWASP Cybercrime Threat Intelligence and Analysis: 27 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 11.Test HSM not use commands with PIN in the clear

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

29 OWASP 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:  SQL injection attacks  HTML (IFRAME) injection attacks  Script injection (e.g. cross-site scripting) attacks  Command shell injection attacks  File injection attacks  Server pages injection attacks (e.g. ASP, PHP)  Cookie poisoning attacks  XML poisoning attacks 29

30 OWASP Attack Vectors For Testing Web Applications 30

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

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

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

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

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

36 OWASP Security Risk Driven Strategy 36

37 OWASP 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 same attack vectors to try to evade countermeasures/defense mechanisms  Test defense in depth against threats identified in the application threat model 37

38 OWASP 38 Q & Q U E S T I O N S A N S W E R S

39 OWASP References  OWASP Testing Guide  f_Contents f_Contents  Testing for Software Security Rethinking security bugs   Education Module Embed within SDLC  thin_SDLC&setlang=es thin_SDLC&setlang=es  OWASP CAL9000 Project   Security Flaws Identification and Technical Risk Analysis Through Threat Modeling   OWASP Application Threat Modeling  39


Download ppt "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."

Similar presentations


Ads by Google