A couple of years ago Mike Cohn introduced me to a cute concept. The “Abuser Story”. A User Story to prevent abuse.

I got the idea from Mike Cohn but Johan Peeters seems to be the main advocate, at least according to Google. He has been talking about them since at least 2005. Johan says:

Abuser stories identify how attackers may abuse the system and jeopardize stakeholders’ assets. Thus they state systems’ security requirements. Similar to user stories, they do so briefly and informally.

The Mike Cohn example of an Abuser Story is: “As a Malicious Hacker I want to steal credit card information so that I can make fraudulent charges”

Security as Abuser Story

Notice that the Abuser Story is not something we actually want to enable. It is something we want to prevent. An anti-feature.

What I like about the Abuser Story format is it makes the threat more real. Somebody, our “Malicious Hacker” user, is trying to cause mischief. It creates a sense of risk, a bit of tension.

In contrast a non-functional requirements (NFR) about “Security” is too abstract to cause much excitement.

Security as NFR

I don’t know about you but I look at that and go: “Yawn, yeah, sure, security. Real important <snooze>”. That reaction means the NFR might not appear as a card on a Lean-Agile board at all. It looks both huge and a bit abstract. Even if the NFR did make it to the product backlog it almost certainly would not be prioritised against value adding user stories i.e. user stories that add functionality.

The more gritty Abuser Stories have a chance to challenge that. But only a chance. I’m really not sure whether this tension, the hint of reality of an Abuser Story, would really make a difference to relative prioritisation. It has a better chance than a plain NFR but functionality is still likely to win out.

I also can’t help thinking that the example, whether phrased as a non-functional requirement or Abuser story, is an Epic and will have to be broken down into much smaller elements. You’d have to remember to retain the Abuser format at lower levels as well to retain the touch of tension that the format gives.

None-the-less there is sufficient promise in the idea of an Abuser Story that I’ll try it.

References

Peeters, J. (2005). Tracking agile security requirements. XP Days Benelux 2005.

Peeters, J. (2008). Agile Security Requirements Engineering. Secure Application Development.