Empowering Application Security Protection in the World of DevOps
Ibm עמרי וייסמן
1. Dec 14, 2010
Static and Dynamic
Technologies
for Securing
Web Applications
Omri Weisman
Manager, Static Analysis Group
IBM Rational Software, Israel
weisman@il.ibm.com
3. 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 Report
3
4. 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
5. 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.
6. Security Testing Within the Software Lifecycle
SDLC
Coding Build QA Security Production
% of Issue Found by Stage of SDLC
Desired Profile
7. IBM Rational AppScan Suite –
Comprehensive Application Vulnerability Management
SECURITY
REQUIREMENTS 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 Framework
7
8. Black White
Box Box
“Hacker in a box” “Automated code review”
Requires running site Requires source-code/bytecode
Crawl, Test, Validate Source-to-Sink Analysis
AppScan AppScan
Standard Ed. Source Ed.
10. 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
11. 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
12. 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
13. 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
14. 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
15. 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
16. Black-Box vs. White-Box – Accuracy Challenges
Challenge:
- Cover all attack vectors
Black
Box
Challenge:
- Eliminate non-exploitable issues
White
Box