OWASP New York Conference 2008
Security in Agile Development:
Breaking the Waterfall Mindset
of the Security Industry
OWASP
Dave Wichers
Cofounder and COO Aspect Security
Volunteer Member of OWASP Board
and OWASP Conferences Chair
dave.wichers@aspectsecurity.com
443-745-6268
Copyright © 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
Agile Manifesto
OWASP
2
Agile Traits
Agile Practices
Test driven development
Pair programming
The simplest thing
Planning Sprint (Sprint 0) – Define User Stories
Develop in Sprints
Focus on what customer wants first
Short iterative development cycles
OWASP
3
Assurance Is the Goal
 Can Agile software development methods generate
assurance?
 “test-driven development places (functional) assurance
squarely at the heart of development” – Johan Peters
OWASP
4
Waterfall Security Is “Breadth First”
Build assurance layer-by-layer
Security
Requirements
Validation Spec
Challenges
Problem space is very large
Difficult to prioritize issues
Loss of traceability from
threat agents to source code
Problems always seem “theoretical”
until it’s too late
Security Architecture
Review
Code Review
Application
Vulnerability Test
External Application
Security Assessments
OWASP
5
Agile vs. Security
Where to insert security activities?
OWASP
6
Security in Agile
Application Security
Assurance Review
{
Threat Model
Stakeholder Security
Stories
Periodic
Periodic
Security
Security
Sprints (if
Sprints
needed)
Some Independent
Expert Testing and
Security Architecture
Review Support
OWASP
7
Key Agile Security Enablers
Standard Security Controls
• See the OWASP Enterprise Security API (ESAPI) Project
• http://www.owasp.org/index.php/ESAPI
Secure Coding Standards
• How to properly use your standard security controls
• How to avoid common security flaws (e.g., SQL Injection)
• Automated code analysis (to enforce ‘your’ standards) – QA/security tool
Developer Security Training
• How to use your standard controls and avoid common flaws
Support from Security Experts
• Even with training and standard controls, security is hard
• Access to security experts and independent testing/analysis is key
• Ideally, a security expert would be on the team (but usually not possible)
OWASP
Planning Sprint (Sprint 0):
Stakeholder Identifies Priorities
 Identify Stakeholders (User, Roles, Data Owners, …)
 Ask them what their most important security concerns are
 Work with them on the basic security controls required based on system
purpose, environment, existence of such mechanisms, etc.
 You are the expert, not them
 Confidentiality
 Who is allowed to access what data and how?
 How important is protecting this data?
 Regulatory requirements?
 Integrity
 What data must be protected and to what degree?
 Availability
 How important is system availability? Can we define an SLA?
OWASP
9
Planning Sprint:
Identify Key Risks to the Business
Threat Agent
Attack
Vulnerability
Control
Technical Impact
Business Impact
Attack
Attack
Attack
Business
Impact
Vulnerability
Vulnerability
Attack
Vulnerability
Attack
Vulnerability
Control
Missing
Control
Business
Impact
Asset
Business
Impact
Asset
Control
Function
Asset
 Security architecture review process is helpful here
 See OWASP Risk Rating Methodology
 http://www.owasp.org/index.php/How_to_value_the_real_risk
OWASP
10
Planning Sprint:
Capture Risks in Stakeholder Security Stories
•I want to be the only one
who can access my
account, so that I can keep
my information private
•I want my personal
information encrypted in
storage and transit so that
it doesn’t get stolen by
attackers
•Risk level: HIGH
•Controls: Authentication and
Data Layer Access Control
•Risk Level: HIGH
•Controls: SSL and Encryption
As a User…
As a User …
•…I want to be the only
one who can edit
Employee salaries so that I
can prevent fraud
•I want all security critical
actions logged, so that
attacks can be noticed and
diagnosed
•Risk Level: HIGH
•Controls: Function Layer
Access Control
•Risk Level: MEDIUM
•Controls: Logging and
Intrusion Detection
As a
Manager…
As a Business
Owner…
Some come from Stakeholder and some come from you as the expert
OWASP
11
Building Assurance “Depth First”
 Identify most important security concerns
 and their required security mechanisms
 Within sprints, or in periodic security sprints
Perform Application
Security Assurance
Review
Development Sprints
Implement and Review
Next Priority Security
Concerns …
Development Sprints
Implement Security
Mechanisms and Review
Priority Security Concerns
Development Sprints
ID Most Important
Security Concerns
 Develop test methods for them and their use
 Configure/implement/analyze these security mechanisms
 Run the tests
OWASP
12
Implement Stakeholder Security Stories
 Security stories are implemented just like other stories
 Test-Driven Development
 Unit test cases come before the code
 Continuous reviews and inspection
 Pair programming / Constant informal reviews
 Continuous integration
 Avoid common vulnerabilities. i.e., security controls
aren’t
Misused
Ignored
Missing
Broken
OWASP
13
Test Cases for Security Controls
 Security ‘requirements’ are defined by developing test
cases
 Unit tests can test both positive (functional) and negative (not
broken) aspects of security mechanisms
 Tests are repeatable, providing full regression testing
 But not true penetration testing or analysis
 Real experience with test driven development
 The OWASP Enterprise Security API
 600+ test cases, rerun every time a change is made
 Results in significant increase in assurance
OWASP
14
Test Cases for Security Stories
 Functional test cases
 Typical unit testing by developers
 Verify presence and proper function of security control
 May include simple tests with a browser
 Security test cases
 Check for best practices
 Test for common pitfalls
 Hopefully, most come with your standard security controls
 Test cases provide strong assurance evidence
 Independent Security Testing
 Verifies that functional and security tests were performed
 Provides additional specialized security testing expertise
OWASP
15
Periodic Security Sprints
 As necessary, build/integrate related security controls
 Implement highest priority related security controls first
 Leveraging your standard security components is key
 Building significant new security controls is hard
 Security sprints may even be completely avoided if sufficient
standard components are available
 Examples
 Authentication, Sessions, Authorization
 Validation, Canonicalization, Encoding
 Error Handling, Logging, Intrusion Detection
OWASP
16
Perform Agile Security Reviews
 Security Reviews: Verify all are in place and complete
 Threat model
 Security stories
 Security controls
 Test cases
 Test results
Notice: Most are standard agile artifacts, not just add-on security deliverables
 Application code review and penetration testing
 Added for critical applications to increase assurance
 Manual (tool supported), automated, or both
 Within security sprints and/or predeployment testing
OWASP
17
Example: Agile Access Control
With standard access control components
Just make sure “isAuthorized()” is called where needed
 Both in presentation layer and business logic
Stay focused on implementing the functionality
Define user stories around who can do what
Configure your policy for what is most important first
E.g., define and restrict what normal users can do
Policy can be both declarative and programmatic
How do you test proper implementation?
Develop policy specific test cases to make sure policy is
enforced properly
OWASP
18
Security in Agile Summary
 Agile can generate assurance well, possibly better
 Approach is depth-first, not breadth-first
 Getting the right stakeholder security stories is key
OWASP
19
References
 Beyond Functional Requirements On Agile
Projects - Strategies for addressing nonfunctional
requirements
 Scott W. Ambler - September 16, 2008
http://www.ddj.com/security/210601918
Agile Security Requirements Engineering
 Johan Peters
 http://secappdev.org/media/2008/pdf/abuser stories.pdf
OWASP