Web Applications are the greatest risk to organizations Web application vulnerabilities represented the largest category in vulnerability disclosures In 2009, 49% of all vulnerabilities were Web application vulnerabilities SQL injection and Cross-Site Scripting are neck and neck in a race for the top spot IBM Internet Security Systems 2009 X-Force® Year End Trend & Risk Report3
What is the Root Cause? 1. Developers not trained in security Most computer science curricula have no security courses Focus is on developing features Security vulnerability = BUG 2. Under investment from security teams Lack of tools, policies, process, Lack of resources 3. Growth in complex, mission critical online applications Online banking, commerce, Web 2.0, etc Result: Application security incidents are on the rise
Security Testing Within the Software Lifecycle SDLC Coding Build QA Security Production% of Issue Found by Stage of SDLC Most Issues are found by security auditors prior to going live.
Security Testing Within the Software Lifecycle SDLC Coding Build QA Security Production% of Issue Found by Stage of SDLC Desired Profile
IBM Rational AppScan Suite – Comprehensive Application Vulnerability Management SECURITYREQUIREMENTS CODE BUILD QA PRE-PROD PRODUCTION AppScan Enterprise AppScan onDemand AppScan Reporting Console Security AppScan Source Requirements AppScan AppScan AppScan AppScan Definition Build Tester Standard Standard Security Security / compliance Security & Outsourced testing requirements Automate Security Build security / Compliance testing incorporated Compliance for security audits & defined before testing into the into testing & Testing, oversight, production site design & testing in the IDE Build Process remediation control, policy, monitoring implementation workflows audits Application Security Best Practices – Secure Engineering Framework7
Black White Box Box “Hacker in a box” “Automated code review”Requires running site Requires source-code/bytecodeCrawl, Test, Validate Source-to-Sink Analysis AppScan AppScan Standard Ed. Source Ed.
Black-Box vs. White-Box – Paradigm Cleverly “guesses” behaviors that may demonstrate vulnerabilities Black Box Examines infinite number of behaviors White in a finite approach (approximation) Box
Black-Box vs. White-Box - Perspective - Works as an attacker - HTTP awareness only Black - Works on “the big picture” Box - Resembles code auditing - Inspects the small details SQL Injection Found White - Hard to “connect the dots” Box
Black-Box vs. White-Box – Prerequisite - Any deployed application - Mainly used during testing stage Black Box - Application code White - Mainly used in development stage Box
Black-Box vs. White-Box – Compatibility - Oblivious to languages, platforms - Different communication protocols require attention Black Box - Different languages require support - Some frameworks too White Box - Oblivious to communication protocols
Black-Box vs. White-Box – Scope Exercises the entire system - Servers (Application, HTTP, DB, etc.) - External interfaces Black Box - Network, firewalls Identifies issues regardless of configuration White Box
Black-Box vs. White-Box – Time/Accuracy Tradeoffs - Crawling takes time - Testing mutations takes Black (infinite) time Box - Refined model consumes space - And time… White - Analyzing only “important” code Box - Approximating the rest >> Summary
Black-Box vs. White-Box – Accuracy Challenges Challenge: - Cover all attack vectors Black Box Challenge: - Eliminate non-exploitable issues White Box