The folks over at the non-profit group, Software Assurance Forum for Excellence in Code (SAFECode) have published a great document called “Practical Security Stories and Security Tasks for Agile Development Environments”. Here is the direct link to the PDF file.
It’s a 34-page document that undoubtedly required a lot of work by a number of people. I applaud them for the effort and thank them for making the document freely available to all of us.
That said, I’d also like to offer an opinion and guideline about the security-focused stories in the report. Here are a couple of story examples from the document:
Story #1: As a(n) architect/developer, I want to ensure AND as QA, I want to verify allocation of resources within limits or throttling
Story #17: As a(n) architect/developer, I want to ensure AND as QA, I want to verify that cross-site scripting attacks are prevented
These are not “User Stories” in the manner intended for use by agile development teams. A user story should focus on a user (or entity) activity and system functionality. It should provide value to the business. Even though these security stories are formatted as user stories, they are not focused on end users and business value. They are focused on the system being built. They are not so much focused on system functions as they are on preventing certain types of (malicious) behaviors.
As such, these security-focused stories would better serve us as acceptance criteria to the typical user stories we define to capture business requirements. The security stories fall into the category of non-functional requirements. They are important to the system under development and to the business but they don’t represent functionality.
Every system we build should be robust, reliable and secure. Oftentimes, end users come to expect such system characteristics without explicitly putting them in writing. It’s our job as subject matter experts to expand upon the user stories provided by the Product Owner and others to include acceptance criteria that can be verified as non-functional requirements.
I encourage you to download and read the SAFEcode document. Use it as a guide when defining, implementing and testing user stories. Security has become a major challenge for all of us and it’s not getting any easier.