Judy Neher

A hacker is someone who uses a combination of high-tech cybertools and social engineering to gain illicit access to someone else’s data.

John McAfee

Historically, as software product development teams, we’ve tended to focus on functionality and getting features out the door. When did we think about security? Usually right before it went into production! Seems a bit late to start thinking about how to plug holes and protect precious data from adversaries.

But really...who are our adversaries? What do they want? What motivates them?

This is where “abuser stories” come in. Abuser stories allow us to put ourselves in the mindset of an adversary or attacker. They enable us to stand in their shoes, look at our products, and brainstorm their motivations for accessing our most precious resources: our data.

Before we dive into what an abuser story is, let’s take a look at its functional counterpart: the user story.

According to Mike Cohn, user stories are:

...short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

Typically, user stories are written in the following format:

AS A <who> I WANT TO <what> SO THAT <why>.

User stories are an Extreme Programming (XP) concept. They are, however, generally and widely used as a way to capture requirements for all types of Agile teams: Scrum Teams, XP teams, and Kanban teams. Agile teams tend to like writing user stories for the following reasons:

They keep us focused on the what versus the how.

Historically, as product development teams, we tended to write all requirements starting with, “The system shall...” We thought mostly from the perspective of what the system needed to do. User stories help us stay focused on the problems that we are trying to solve for users and customers.

They are easily understood between business and development.

Because they are written from the perspective of the user, user stories translate nicely between the business side of the house and those who are building the product and foster conversation between those groups. For Development Teams, good user stories provide the why of what they are building, which helps them have empathy for the users.

Abuser stories share a very similar structure to functional user stories. Abuser stories specifically help organizations see their products in the same way attackers do. Abuser stories help us view our products from the perspective of our adversaries, rather than our actual users. They help us understand what types of assets our adversaries would want to get at and what their motivations are.

A typical abuser story looks like this:

AS A <attacker> I WANT TO <intent> SO THAT <motivation>.

For every feature we add to our products, someone in the organization (whether a Development Team member or a security professional) should be looking at the feature from the perspective of an adversary: how could someone exploit this feature?