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 OWASP OWASP New York Conference 2008 Security in Agile Development: Breaking the Waterfall Mindset of the Security Industry Dave Wichers Cofounder and COO Aspect Security Volunteer Member of OWASP Board and OWASP Conferences Chair

OWASP Agile Manifesto 2

OWASP 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 3

OWASP 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 4

OWASP Waterfall Security Is “Breadth First”  Build assurance layer-by-layer  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 Requirements Validation Spec Security Architecture Review Code Review Application Vulnerability Test External Application Security Assessments 5

OWASP Agile vs. Security  Where to insert security activities? 6

OWASP Periodic Security Sprints Security in Agile Threat Model Stakeholder Security Stories Application Security Assurance Review Periodic Security Sprints (if needed) { 7 Some Independent Expert Testing and Security Architecture Review Support

OWASP Key Agile Security Enablers See the OWASP Enterprise Security API (ESAPI) Project Standard Security Controls 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 Secure Coding Standards How to use your standard controls and avoid common flaws Developer Security Training 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) Support from Security Experts

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? 9

OWASP Planning Sprint: Identify Key Risks to the Business  Security architecture review process is helpful here  See OWASP Risk Rating Methodology  Attack Vulnerability Asset Technical ImpactBusiness ImpactVulnerabilityAttackThreat Agent Vulnerability Business Impact Business Impact Function Asset Business Impact Control Missing Control 10

OWASP 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 Risk level: HIGH Controls: Authentication and Data Layer Access Control As a User… I want my personal information encrypted in storage and transit so that it doesn’t get stolen by attackers Risk Level: HIGH Controls: SSL and Encryption As a User … …I want to be the only one who can edit Employee salaries so that I can prevent fraud Risk Level: HIGH Controls: Function Layer Access Control As a Manager… I want all security critical actions logged, so that attacks can be noticed and diagnosed Risk Level: MEDIUM Controls: Logging and Intrusion Detection As a Business Owner… 11 Some come from Stakeholder and some come from you as the expert

OWASP Building Assurance “Depth First”  Identify most important security concerns  and their required security mechanisms  Within sprints, or in periodic security sprints  Develop test methods for them and their use  Configure/implement/analyze these security mechanisms  Run the tests ID Most Important Security Concerns Development Sprints Implement Security Mechanisms and Review Priority Security Concerns Development Sprints Implement and Review Next Priority Security Concerns … Development Sprints Perform Application Security Assurance Review 12

OWASP 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 13

OWASP 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 14

OWASP 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 15

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

OWASP 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 17

OWASP 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 18

OWASP 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 19

OWASP References  Beyond Functional Requirements On Agile Projects - Strategies for addressing nonfunctional requirements  Scott W. Ambler - September 16,  Agile Security Requirements Engineering  Johan Peters  stories.pdf stories.pdf