Writing security acceptance criteria into an Agile story

When development groups write Agile user stories for development it should include security in the acceptance criteria or the definition of done.

DevSecOps is the evolution of the DevOps philosophy. It is a concept that injects security into the software development lifecycle. Many people refer to this approach as “moving security left”. To that end, when creating Agile software development stories, any potential security requirements should be documented as “acceptance criteria” or “definition of done”.

In Agile development, the acceptance criteria is a detailed description of the expected features and functionality the story should deliver.

Far too often developers and product managers fail to include information security requirements as part of the acceptance criteria. Including security criteria in every story is a requirement of our Lean Security practice, which is our overarching framework on top of DevSecOps.

I often get asked about what kind of security criteria should be included in a user story. While not every user story needs to include a litany of security criteria there are a few basic rules one should follow that will go a long way in building a more secure application. Here are a few example categories of stories to consider requiring security acceptance criteria.

Input Validation

Most developers understand the importance of validating any kind of data input. Failure to properly sanitize and validate data has been the root of more kinds of attacks than any other method. Buffer overflows, cross site scripting and SQL injection are just a few of the more well known attack methods due to input validation failure. The bottom line when dealing with any kind of input data, especially that coming from an end-user, is simply never trust it – ever. Any user story that deals with input data needs to include acceptance criteria stating that the data needs to at least be sanitized and validated against the expected.

Storage or Transfer of Private Information

Before an organization can put controls around restricted information, they first have to define what is considered private or restricted information. Data might fall into categories such as PII ( Personally identifiable information), PHI (Patient Health Information), IP (Intellectual Property) or any customer information. Any story that touches these classes of data needs to have information security acceptance criteria. Depending on how the company has chosen to protect, store or transmit this data will drive the story development and acceptance criteria.

Any use of Cryptography

There are a few basic, but important rules when it comes to cryptography. The first and most important rule is don’t invent your own cryptography. The second rule is to use a trusted and reputable cryptography library provider. The third rule is to only use cryptographic functions approved according to your company security policies. The fourth and hardest rule is to ensure you are using cryptography for its intended purpose. Keep these four rules in mind when authoring a story that has anything at all to do with cryptography and how they can be used to develop acceptance criteria.

Authentication, Authorization, Accounting

Authentication, Authorization and Accounting or often simply referred to as AAA. AAA is the intelligence behind controlling access to resources, policy enforcement and auditing of events. It might be better said that everything in AAA is information security related. When developing a story that deals with AAA, one should ensure the testing criteria include both the permit and the deny cases for the desire access matrix. For example, simply testing that a user can login with the right password doesn’t assume that a wrong password attempt will deny access. The other general point to consider is that AAA actions generally should include a log event for audit purposes.

Committing to develop secure software is a key component of today’s modern day software development lifecycle. Ensuring stories include security acceptance criteria goes a long way in moving security to the left in the development pipeline.