/nov 13, 2013

Agile Security: User Stories Vs Acceptance Criteria

By Mark Curphey

I seem to keep coming across advice recomending Agile development teams create “Security stories”. It seems much of this stems from SAFECodes Practical Security Stories and Tasks for Agile development environments and the OWASP Don’t Forget Evil Stories.

I think this is the wrong approach. As a security guy put yourself in the shoes of the scrum master and imagine your reaction when you find someone arguing that a story like the one below should be included in the next sprint.

As a blind user,
I want to be able to read the data table with a screen reader,
So I can understand the state of the economy.

Like the security story no one (at least not me) will argue with the good intent from the usability guy, but adding stories to represent stakeholders objectives is not the right way to integrate security into a development process. Stories are user stories (emphasis on the word user). Should we add stories for performance, security, usability, maintainability etc. etc. ...... No, it’s not the agile way and it simply doesn’t scale.

A better way is to embrace the Scrum way and use acceptance requirements or DoD ( the “Definition of Done”). Having security acceptance criteria for each story in the backlog means nothing ships without security as it’s not releasable by the definition of Scrum and security simply becomes part of the software quality definition. No one can describe the security needed in a few lines for the array of technologies a user feature may be built on (front-end presentation, services, DAL, crypto etc.) and so along with Agile philosophy placing trust in the team and placing value in “working software over comprehensive documentation” define "working" as "working" in a hostile environment.

The done thinking grid is helpful to reference.

developer workflows

Security people often question why developers push back on their advice, while developers question some of their advice. You can either integrate with existing (and accepted) developer workflows or you can try and disrupt them. Good luck if the later is your chosen path.

Related Posts

By Mark Curphey

Mark Curphey, Vice President, Strategy
Mark Curphey is the Vice President of Strategy at Veracode. Mark is the founder and CEO of SourceClear, a software composition analysis solution designed for DevSecOps, which was acquired by CA Technologies in 2018. In 2001, he founded the Open Web Application Security Project (OWASP), a non-profit organization known for its Top 10 list of Most Critical Web Application Security Risks.
Mark moved to the U.S. in 2000 to join Internet Security Systems (acquired by IBM), and later held roles including director of information security at Charles Schwab, vice president of professional services at Foundstone (acquired by McAfee), and principal group program manager, developer division, at Microsoft.
Born in the UK, Mark received his B.Eng, Mechanical Engineering from the University of Brighton, and his Masters in Information Security from Royal Holloway, University of London. In his spare time, he enjoys traveling, and cycling.