This presentation, entitled “Security in Agile Development: Breaking the Waterfall Mindset of the Security Industry” was by Dave Wichers, member of the OWASP board and cofounder and COO of Aspect Security.

Manifesto for Agile Software Development

Individuals and interactions over processes and tools.  Working software over comprehensive documentation.  Customer collaboration over contract negotiation.  Responding to change over following a plan.

Agile Traits

  • Agile practices test driven development, pair programming, and doing the simplest thing.
  • Planning Sprint (Sprint 0) – define user stories
  • Develop in sprints and focus on what the customer wants first in short iterative development cycles

Assurance is the Goal

  • “Assurance is the level of confidence that software functions as intended and is free of vulnerabilities, either intentionally or unintentionally designed or inserted as part of the software” – DOD
  • Can agile software development methods generate assurance?
  • “test-driven development places (functional) assurance squarely at the heart of development” – Johan Peters

Waterfall Security is “Breadth First”

  • Build assurance layer-by-layer
  • Challenges are problem space is very large, difficult to prioritize, …

Agile vs Security

  • Where to insert security activities?

Security in Agile (nice chart here)

  • Add Threat Modeling and Stakeholder Security Stories at the beginning between the Story FInding/Initial Estimation
  • Do periodic security sprints (if needed) between writing the story and scenario and implementing functionality and acceptance tests
  • Do some independent expert testing and security architecture review support in the quality assurance phase
  • Add Application Security Assurance Review between system testing and release phases

Key Agile Security Enablers

  • Standard Security Controls: See the OWASP Enterprise Security API (ESAPI) Project
  • Secure Coding Standards: How to properly use your standard security controls.  How to avoid common security flaws.  Automated code analysis.
  • Developer Security Training: How to use your standard controls and avoid common flaws
  • Support from Security Expers: 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).

Planning Sprint (Sprint 0)

  • Identify StakeholdersL Ask them what thier most important security concerns are.  Work with them on the basic security controls required based on system purpose, environment, existence of such mechanisms, etc
  • 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?

Planning Sprint: Capture Risks in Stakeholder Security StoriesAssurance is the level of confidence

  • As a User…I want to be the only one who can access my account so that I can keep my information private.
  • As a User…I want my personal information encrypted in storage and transit so that it doesn’t get stolen by attackers.
  • As a Manager…I want to be the only one who can edit Employee salaries so that I can prevent fraud.
  • As a Business Owner…I want all security critical actions logged, so that attacks can be noticed and diagnosed.

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, and run the tests

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 information reviews)

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.
  • Results in significant increase in assurance

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.

Periodic Security Sprints

  • As necessary, build/integrate related security controls.  Implemente 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

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.

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 aroudn who can do what.  Configure your policy for what is most important first.  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.

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
  • In traditional security, assurance comes primarily from expert security reviews at successive stages of development.  In agile security, assurance comes from managing the key risks to the security stakeholders.