When organizations write user stories for development it should include the acceptance criteria. The acceptance criteria being 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 SecDevOps and rugged software development. 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 and rugged 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 by the organization. Start by defining what’s considered restricted. Data might fall into categories such as PII, PHI, IP, customer data or other. 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 is the heart of any access control system. AAA is the intelligence behind controlling access to resources, policy enforcement and auditing of said 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 rugged software is a key component of SecDevOps. Ensuring stories include security acceptance criteria goes a long way in moving security to the left in the development pipeline.
