Agile Security: User Stories Vs Acceptance Criteria

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.

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.