Writing Abuser Stories

Abuser stories have been around for a while, and while not a revolutionary idea, it is somewhat of an untapped one, an underappreciated one, one that I personally hadn’t been exposed to in my nearly 30 years working as a business analyst. That’s a huge problem, if you ask me.

Being the new kid on the block in a Development Agency with security as the number one value means learning a lot of new things. But when it came to writing requirements I didn’t think there was as much I needed to get my head around. I was wrong. When our founder, Frank Rietta introduced me to the concept of Abuser Stories, I learned that maybe I didn’t know quite as much as I thought I did.

For those who also haven’t been exposed them, the first thing to address is: what is an Abuser Story? Abuser Stories are told from the standpoint of a nefarious character, or maybe even a not so nefarious actor, but one who is curious enough to find their way into a situation that could compromise the security of your site, application or app. Abuser Stories follow the standard Agile User Story format of “As a {user type}, I want to {do something}, so that I can {have this outcome}”, but the action and/or the outcome are not necessarily what we would expect a standard user to do.

For example, a standard story for user login might look something like this:

As a registered user, I want to login to Widgets-R-Us with my UID/PW, so that I can buy widgets.

Now we turn this around to represent a nefarious or curious type:

As a bad actor, I want to try a series of passwords with a UID I know to be valid, so I can order Widgets using someone else’s account.

If we break this out into some acceptance criteria, for the first story it would be a pretty simple set of items:

• I am on Widgets-R-Us homescreen
• I choose the Login Option
• I receive the login form
• I enter my UID
• I enter my PW
• I confirm my entry
• I am logged in

Nothing in this series of statements is unusual, it’s pretty standard stuff, but it does nothing to address the potential for the second story. It doesn’t prevent someone from trying as many passwords as they want, trying a ton of different User ID’s, or using a script to do any of this automatically. That’s why this second story is so important, it forces us to look at the possibilities, the holes, or if you’re like me, how badly you need to clean your baseboards (oh wait, that’s a different blog post isn’t it?).

Let’s look at the acceptance criteria for the second user story:

• I am on Widgets-R-Us homescreen
• I choose the Login Option
• I initiate an automated script that fills in a known UID and tests a series of potential passwords
• After the first failed attempt I receive a Captcha challenge for subsequent tries.
• First subsequent try presents a click captcha “I am not a robot”
• Subsequent Captcha challenges are image challenges “Find all the cars” style.
• After five failed attempts account is locked.
• After five failed attempts an email is sent to the account holder requesting a password change.

This set of criteria addresses several different things. It addresses trying multiple UID/PW combinations that are not valid, it addresses someone trying to use automation to do so, and finally it addresses more than five failed attempts, and goes on to ensure that the account owner is notified and that they change their password.

Now most good business analysts would have added some of these secondary requirements to the first story, but we have a lot of young, up and coming BAs who are still learning. We have even more situations where the concept of Business Analyst has been discarded and developers, project managers and other roles end up being responsible for requirements as a secondary task, one which they are often less than passionate about.

With so so many high profile hackings in recent years, with the release of pretty much every human beings personal information in some form or fashion into the hands of hackers, I think it’s time that the development industry start making this a standard practice, rather than one that is an afterthought. Or no thought at all.

What do you think? Have you used Abuser Stories? Are you going to start using them now? Let us know by tweeting @riettainc.