The general tendency of the requirements document has predominantly focused on what the software should do. In project charters and scope control documents, sometimes we also write what features will be out of scope. The UML diagrams and use cases discuss how the classes should interface, and modules should interoperate, for instance. The agile paradigm discusses persona approaches drilling down DEEP property for describing backlog features and INVEST principle elaborating on the characteristics of a user story. Even test cases that focus on negative testing use a requirement traceability matrix to the requirements limitedly testing the functionality of what a system shouldn't do.
But, when a system is hacked or inappropriately accessed, the loopholes rests on the inefficiencies in how the system was designed to allow such loopholes to exist. So, how do you avoid these vulnerabilities so that the hacker doesn't exploit these "working as designed" gaps?
While volunteering at the Agile 2015 conference, I chose to attend a section on Abuser stories by Judy Neher from Celebrity Technical Services. It was a great session introducing the concept that a persona of a hacker or disgruntled employee could potentially have a malicious intent to deliberately break the system. The speaker suggested describing user stories that specifically could break the system or expose the system for malicious intent. The participants in an activity gave examples for a simple user authentication such as the stringent password recycle policy, the use of a double password and picture identification, the use of external devices such as phone, email, or mobile texting to use tokens for validation within a short timeframe before the account is locked, the creation alerts for maintenance for incorrect and frequent access to multiple accounts, the enforcement of HR exit policies on employment dates before the role based access can be authenticated, the validation of human versus robot logging by tracking the speed of password entry, etc. Imagine having such stories to bulletproof the system against malicious attacks on standard user stories and have automation capabilities to constantly check for these loopholes.
I am sure one would say that this would add more time to the scheduled release or limit the stories written per iteration/sprint. Of course, like non-functional stories that add some time, the abuser stories also will add time. The need to develop hunches on the type of regulations in the industry, the type of technical platforms used, the time to market considerations, etc. However, the question shouldn't be whether to do them or not but when to do them. If we fail to do them, we are increasing the technical debt. A couple of alternatives are to dedicate a sprint or a portion of every sprint to address these abuser stories.
I really think this is an important component of combined technical and product ownership to ensure we see the persona of other types of users and see the system from that view. As good project managers turn assumptions into risks and control quality, the technical and product owners should be accountable for products that preclude vulnerabilities by design. Abuser stories are a great start. Don't you think so? Share your thoughts.
References
Neher, J. (2015). Abuser Persona. Agile 2015 Conference.
