Merging security requirements into your agile framework
There are many models for capturing functional requirements and many less for non-functional requirements. We need to adapt those that exist for non-functional requirements into our agile frameworks. The misuse case is a great model for capturing the attackers intent — but how does that fit in Agile, or how can we make an equivalent fit in Agile.
Those in software are well aware of the use case, a tool specifying required behavior and features in product development effort. A use case is useful in specifying a set of actors (systems or objects) and actions (or interactions) between those actors. In the below example (from: https://en.wikipedia.org/wiki/Use_case) we can see the various actors interact in a restaurant system.
Actors
- Waiter
- Chef
- Client
- Cashier
Interactions
Misuse or abuse cases are often used in the same manner to capture an attackers mindset by focusing on ways the system can be compromised. This results in non-functional (security focused) requirements. But these artifacts generally do not have homes in the traditional modern agile framework; for us to capture these non-functional requirements we should leverage the same technique we use to capture the functional requirements. Say it another way, “What happens to use cases in Agile”?
Moving into the Agile mindset we transition from Use Cases to User Stories. The often misunderstood (and subtle) difference is that the user story is focused on a specific users needs. It is a specific micro value proposition. To balance use cases — lets look at a simple user story:
As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved.
The accompanying acceptance criteria may include:
- User cannot indicate a folder to exclude without being prompted to verify
- Failure to save changes results in no changes to the backup configuration
- User cannot deselect a folder to backup if that folder is owned by another user
Now lets focus on the non-functional requirements.actor!
The misuse cases introduces a bad actor, the Crook. In this model the crook is more than willing to steal a bunch of things (depending on their motivation). Perhaps there should be multiple bad actors a thief, a competitor, a belligerent customer. However the point is much the same, name the actors and the interaction…
As mentioned above Agile focuses on user stories, micro value propositions that describe what a user might do in your software and why they might want to perform that function. Enter the folks at OWASP and the concept of “Evil User Stories”. While their entry isn’t prevalent on the web and is light on verbiage, it conveys the point concisely. So lets look at an example:
As a hacker, I can send bad data in the content of requests, so I can access data and functions for which I’m not authorized.
That story is a pretty generic. I would suggest making the evil story more specific to your organization, are you building a banking system, how about this:
As a thief, I want to steal piggy back HTTP requests on an authenticated session, so that I can transfer money out of your account into mine.
Those of you building web applications should immediately recognize this as a Cross Site Request Forgery, and be able to reference the litany of material on defending that attack vector. Perhaps those can “acceptance criteria”, but perhaps since we are formalizing the story from the thief’s perspective we should call them “denial criteria”.
I welcome thoughts on capturing non-functional and security related requirements into Agile frameworks.
Originally published at https://www.linkedin.com.
