Embed within SDLC OWASP Module (to be combined) Education Project

Embed within SDLC
Module (to be combined)
OWASP
Education Project
Copyright 2007 © 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
Introduction
OWASP
2
People / Processes / Technology
Training
Awareness
Guidelines
Automated
Testing
Secure
Development
Application
Firewalls
Secure Code
Review
Secure
Configuration
Security Testing
OWASP
3
A Few Facts and figures
Interesting Statistics – Employing code review
IBM Reduces 82% of Defects Before Testing Starts
HP Found 80% of Defects Found Were Not Likely To
Be Caught in Testing
100 Times More Expensive to Fix Security Bug at
Production Than Design”
– IBM Systems Sciences Institute
Promoting People Looking at Code
Improvement Earlier in SDLC
Fix at Right Place; the Source
Takes 20% extra time – payoff is order of magnitude
more.
Ref: http://ganssle.com/Inspections.pdf
OWASP
4
People Awareness and Education
OWASP
5
Get Buy In!
Management support crucial
Talk Business:
Create Value
Controll Risk
Create CxO elevator pitches
OWASP
6
Web Application Security SDLC Elevator Pitch
Between 70% and 90% of web applications
have serious vulnerabilities because
…the average developer is still not trained well
enough.
… of the way they came to be.
Embedding application security controls into
development and deployment will
Allow for higher uptime, less TCO
Put YOU into risk control
OWASP
7
Developer and administrator training
Give a man a fish and you feed him for a day;
Teach a man to fish and you feed him for a lifetime.
Chinese proverb
Organize Developer Workshops
Not only preach, but provide guidelines tuned to
the environment and tools to empower the
developers and administrators
OWASP
8
Security Requirements and Abuse Cases
OWASP
9
Security Requirements
 Security aspects must be part of the requirements
 The ‘business’ should be informed of certain risks
 Solid base for next application security controls
 Define Security Requirements Standards
 Which controls are necessary
 When are they necessary (applicability)
 Why are they necessary (e.g. SEC, SOX, etc.)
 Easy to use reference for requirements teams
 Standard method to implement each control
 Provide reference on how to implement
OWASP
10
Application Security Requirements Tailoring
Get the security requirements and policy right
Generic set of security requirements
Must include all security mechanisms
Must address all common vulnerabilities
Can be use (or misuse) cases
Address all driving requirements (regulation,
standards, best practices, etc.)
Tailoring examples…
Specify how authentication will work
Detail the access control matrix (roles, assets,
functions, permissions)
Define the input validation rules
Choose error handling logging approach
OWASP
11
Abuse Cases
Source: Templates for Misuse Case Description, Sindre & Opdahl
OWASP
12
Negative Scenarios are Not New
Montignac Caves, Dordogne, France
'Suppose it turns and charges
us before it falls into the pit'
OWASP
13
Misuse Cases
threatens
Drive the Car
Steal the Car
Car Thief
 Guttorm Sindre and Andreas Opdahl, 2000
 Actor is a Hostile Agent
 Bubble is drawn in inverted colours
 Goal is a Threat to 'Our System‘
 Input for Threat Modelling
OWASP
14
Threat Modeling
OWASP
15
Why
Understand the operating environment your
application is heading into
Identify, analyze and document (and thus
hopefully mitigate) threats
OWASP
16
Overview
assets
input/output
exposure (internal,
external, distributed,
centralized..)
threat types (patterns)
impact (who, how,
why)
OWASP
17
Identifying threats – data flow diagrams
dfd, level0
contains the major processes, system
boundaries
.. interactions with external entities
OWASP
18
Categorizing and Quantifying Threats
Most known: Microsoft stride, dread
spoofing, tampering, repudiation, information
disclosure, denial of service, escalation of privileges
damage potential, reproducibility, exploitability,
affected users, discoverability
Most important thing is that used models assist
in understanding and communicating
OWASP
19
Threat Modeling
Select mitigation strategy and techniques based
on identified, documented and rated threats.
Benefits:
Prevent security design flaws
Identify & address greatest risks
Increased risk awareness and understanding
Mechanism for reaching consensus
Cost justification and support for needed controls
Means for communicating results
OWASP
20
Success Factors
Obtain management support
Involve Business and Technical experts
Designate focal points
Define procedures
Document and maintain result
OWASP
21
Resources
http://www.octotrike.org
Threat modeling book - swiderski, snyder
http://blogs.msdn.com/threatmodeling/
OWASP
22
Secure Design Guidelines
OWASP
23
Secure Design
 Principles (*)










Secure the weakest link
Practice defence in depth
Fail securely
Follow the principle of least privilege
Compartmentalize
Keep it simple
Promote privacy
Remember that hiding secrets is hard
Be reluctant to trust
Use your community resources
 Future proof security design!
(*) Building Secure Software, Viega-McGraw
OWASP
24
Security Principles
Minimize attack surface area
Establish secure defaults
Principle of Least privilege
Principle of Defense in depth
Fail securely
Don't trust services
Separation of duties
Avoid security by obscurity
Keep security simple
Fix security issues correctly
OWASP
25
Design Reviews
Better to find flaws early
Security design reviews
Check to ensure design meets requirements
Also check to make sure you didn’t miss a requirement
Assemble a team
Experts in the technology
Security-minded team members
Do a high-level penetration test against the design
Be sure to do root cause analysis on any flaws
identified
OWASP
26
Secure Coding Guidelines and Security Code Review
OWASP
27
Secure Coding Guideline
Formalize best practices into secure coding
guidelines
well documented and enforceable coding
standards
Tune towards environment
OWASP Secure Coding Guide can be reference
can be used as a metric to evaluate source code
OWASP
28
Code Review
 Security bugs subset of implementation bugs!
 Static / dynamic analysis tools
 Requires manual inspection
 Threat-based
 Check list driven
 Benefits:
 Improves code quality
 Prevents security bugs
 Increased developer awareness and understanding
OWASP
29
Testing for web application security
OWASP
30
Software Vulnerability Analysis
Find flaws in the code early
Many different techniques
Static (against source or compiled code)
 Security focused static analysis tools
 Peer review process
 Formal security code review
Dynamic (against running code)
 Scanning
 Penetration testing
Goal
Ensure completeness (across all vulnerability areas)
Ensure accuracy (minimize false alarms)
OWASP
31
Application Security Testing
Identify security flaws during testing
Develop security test cases
Based on requirements
Be sure to include “negative” tests
Test all security mechanisms and common
vulnerabilities
Flaws feed into defect tracking and root cause
analysis
OWASP
32
The OWASP Testing Guide
Part of an appsec body of knowledge…
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
33
Secure administration and
Security within Change Management
OWASP
34
Deployment Process
Ensure the application configuration is secure
Security is increasingly “data-driven”
XML files, property files, scripts, databases, directories
How do you control and audit this data?
Design configuration data for audit
Put all configuration data in CM
Audit configuration data regularly
Don’t allow configuration changes in the field
Gap Development - Deployment
OWASP
35
Application Security Defect Tracking and
Metrics
“Every security flaw is a process problem”
Tracking security defects
Find the source of the problem
 Bad or missed requirement, design flaw, poor implementation, etc…
ISSUE: can you track security defects the same way as
other defects
Metrics
What lifecycle stage are most flaws originating in?
What security mechanisms are we having trouble
implementing?
What security vulnerabilities are we having trouble
avoiding?
OWASP
36
Deployment WebAppSec Controls
OWASP
37
Software security tollgates in the SDLC
Iterative approach
Security
requirements
Design
Review
Risk
analysis
Requirements
and use cases
Design
Risk-based
security tests
Test plans
Code
Review
Static
analysis
(tools)
Code
Penetration
testing
Test
results
Field
feedback
OWASP
38
WebAppSec Tools
OWASP
39
Tools
•Test sites / testing grounds
•HTTP proxying / editing
•XSS cheat sheet tools
•webapp fuzzing
•Encoding tools
•HTTP general testing HTTP
fingerprinting
•Browser-based HTTP tampering / editing
/ replaying
•Cookie editing / poisoning
•Ajax and XHR scanning
•RSS extensions and caching
•SQL injection scanning
•Threat modeling
•FireFox Add-Ons
•Bookmarklets
•SSL certificate checking / scanning
•Honeyclients, Web Application, and Web
Proxy honeypots
•Footprinting
•Web application security malware,
backdoors, and evil code
•Web application assessment services
•Browser-based security fuzzing / checking
•PHP static analysis and file inclusion
scanning
•Web Application Firewall (WAF) and
Intrusion Detection (APIDS) rules and
resources
•Web services enumeration / scanning /
fuzzing
•Web application non-specific static sourcecode analysis
•Static analysis for C/C++ (CGI, ISAPI, etc) in
web applications
•Java static analysis, security frameworks,
and web application security tools
•Microsoft .NET static analysis and security
framework tools,
•Database security assessment
•Browser Defenses
•Browser Privacy
40
OWASP
•Application and protocol fuzzing
Tools
http://www.owasp.org/index.php/Phoenix/Tools
Best known OWASP Tools
WebGoat
WebScarab
Remember:
A Fool with a Tool is still a Fool
OWASP
41
Tools – At Best 45%
 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)
OWASP
42
Technology
Do not develop on islands, but look for
organisation wide:
Framework Architectures J2EE, .NET
Security Patterns
Leverage PKI, IAM initiatives
Vulnerability Scanners
Application level firewalls
OWASP
43
Starting and improving an SDLC
OWASP
44
Opportunities for Metrics - Secure
Development Life Cycle (SDL)
Were software assurance activities conducted at each lifecycle phase?
Secure questions
during interviews
Concept
Security push/audit
Threat
analysis
Learn &
Refine
External
review
Designs
Complete
Team member
training
Security
Review
Test plans
Complete
Data mutation
& Least Priv
Tests
Source: Microsoft
Code
Complete
Deploy
Review old defects
Check-ins checked
Secure coding guidelines
Use tools
Post
Deployment
= on-going
OWASP
45
How to Start?
No Big Bang approach
Trigger can be (bad) result of Web App Pen Test
Assure Management buy-in:
First business case!
Then Bootstrap!
OWASP
46
Business Case
For use throughout the lifecycle and the entire
software portfolio:
Contracting Phase
Development Phase
Deployment/Production Phase
Audit Phase
Benefits:
Cost savings
Risk measurement and reduction
Compliance reporting
OWASP
47
Cost Savings
Significantly reduce the costs associated with
new and deployed products :
A flaw that costs $1 to fix in the design and
development phase will cost $100 to correct once it is
deployed
Reduce development time and number of cycles
Patch management costs
Contractor and vendor costs
“Removing only 50 percent of software vulnerabilities before use will
reduce patch management and incident response costs by 75 percent.”
(John Pescatore, Gartner)
OWASP
48
Risk measurement and reduction
Eliminate vulnerabilities before they become
liabilities
Manage the risks of serious financial loss,
negative publicity, legal liability, loss of contracts,
erosion of market share, degraded performance
or other serious business impact as a result of a
failure in security
Set, enforce and report that software assurance
thresholds are maintained
Measurable reports prove progress internally
and for compliance
OWASP
49
Compliance Reporting
 Compliance reporting:
 Comply with legal and regulatory requirements
 Regularly assess risk, disclose vulnerabilities and weaknesses,
and prove progress both internally and for compliance
requirements
 Scope & application
 Risk assessments are mandatory for most regulations, including
application vulnerability detection
 Example internal control frameworks: CobiT, ISO 17799
 Example regulations: Basel II, FISMA (NIST 800-53), DoD
8500.2, Sarbanes-Oxley, FDA, HIPAA …
OWASP
50
BootStrap!
Identify current way of working!
Set goals and start with phased approach
Compare this with security strategy
(can already be set out in a secure development
policy)
Perform a gap analysis and proceed with
process improvement cycles:
Tailor to Company Culture!
Driven by Risk Management!
Introduce Metrics
OWASP
51
Examples of Application Security Metrics
Process Metrics
 Is a SDL Process used? Are
security gates enforced?
 Secure application
development standards and
testing criteria?
 Security status of a new
application at delivery (e.g., %
compliance with organizational
security standards and
application system
requirements).
 Existence of developer support
website (FAQ's, Code Fixes,
lessons learned, etc.)?
 % of developers trained, using
organizational security best
practice technology,
architecture and processes
Management Metrics
 % of applications rated
“business-critical” that have
been tested.
 % of applications which
business partners, clients,
regulators require be
“certified”.
 Average time to correct
vulnerabilities (trending).
 % of flaws by lifecycle phase.
 % of applications using
centralized security services.
 Business impact of critical
security incidents.
OWASP
52
Examples of Application Security Metrics
Vulnerability Metrics
 Number and criticality of vulnerabilities found.
 Most commonly found vulnerabilities.
 Reported defect rates based on security testing (per
developer/team, per application)
 Root cause of “Vulnerability Recidivism”.
 % of code that is re-used from other products/projects*
 % of code that is third party (e.g., libraries)*
 Results of source code analysis**:
 Vulnerability severity by project, by organization
 Vulnerabilities by category by project, by organization
 Vulnerability +/- over time by project
 % of flaws by lifecycle phase (based on when testing occurs)
Source: * WebMethods, ** Fortify Software
OWASP
53
Web Application Security Roles and Responsibilities
OWASP
54
Get involved
Security Analyst:
Get involved early in SDLC. Security is a function of
the asset we want to secure, what's it worth?
Understanding the information held in the application
and the types of users is half the battle.
Involve an analyst in the design phase and thereafter.
Developer:
Embrace secure application development. (Educate)
Quality is not just “Does it work” Security is a
measure of quality also.
OWASP
55
Get involved
QA:
 Security vulnerabilities are to be considered bugs,
the same way as a functional bug, and tracked in the
same manner.
Managers:
Factor some time into the project plan for security.
Consider security as added value in an application.
–
$1 spent up front saves $10 during development and $100 after release
OWASP
56
Roles
 Role of security architect (cross-development projects):
 ensure security goals are reached during all cycles of the
development process
 create awareness within development teams, business
 bridge function to "IT Security"
 mentor the security engineers and project leaders
 Role of security engineer (part of project team)
 SPOC within development team for all security related matters.
 Search for Champions!
OWASP
57
Round up
OWASP
58
Where to start?
Awareness and Training
2-hour course:
$100-200/seat
Seeing the look on the IT VPs’ faces when they get
SQL Injection: Priceless
Policies and Standards
Application Assessments and Reviews
Get some data
Strive to be consistent and uniform
Support Development Teams
OWASP
59