Since 1999

 

4 minutes estimated reading time.

What is an Abuser Story (Software)

—

I publicly speaking about how development teams and those who employ them should go about using user stories with security constraints and abuser stories as a security documentation tool. At this time there is not an entry on Wikipedia about it, so I am going to take a stab at writing it up for you here.

What is an Abuser Story in Software Development?

In software development and product management, an abuser story is a user story from the point of view of a malicious adversary. Abuser stories are used with agile software development methodologies as the basis for defining the activities that should be actively blocked or mitigated by the software and proven by automated regression testing.

An abuser story consists of all of the components of a traditional User story, and are principally composed of three aspects:

  1. a written description of the story used for planning and as a reminder
  2. conversations about the story that serve to flesh out the details of the story
  3. tests that convey and document details and that can be used to determine when a story is complete.

(Cohn 2004).

Examples

URL Tweaker

As an Authenticated Customer, I see what looks like my account number in the URL, so I change it to another number to see what will happen.

This story exercises the presence of a Direct-Object Reference (owasp.org top 10) vulnerability and rejects the refrain that “no one would ever do this,” which is tempting for non-technical stakeholders to posit.

Curious Editor

As an Authenticated Customer, I paste HTML that includes JavaScript into every field possible to see what happens.

This story exercises a XSS vulnerability (owasp.org top 10) that stems from unsafe handling of user supplied inputs.

Infrastructure Takeover

As a Malicious Hacker, I want to gain access to this web application’s Cloud Hosting account so that I can lock out the legitimate owners and delete the servers and their backups, to destroy their entire business.

This story demonstrates the failure of operational security, including the use of Two-Factor Authentication on infrastructure accounts. And it really happened to Code Spaces in 2014 (arstechnica.com).

History

Abuse stories are an adaptation of the abuse cases that were introduced by Hope, McGraw, and Anton to address the fact that there is no convenient security pull-down menu that will let you select “security” and then sit back and watch the magic happen. Instead your requirement gathering process must go beyond considering the desired features. Every time a feature is described someone should spend some time thinking about how that feature might be unintentionally misused or intentionally abused (Hope 2004, McGraw 2004). One should also note special security concerns when writing happy path user stories so that the developer can be in the mindset of addresses these concerns when he or she picks up that story for implementations.

Abuser stories appear to have been re-invented by multiple authors based on this original idea with various names, including Evil User Stories, Abuse Stories, and Abuser Stories. Johan Peeters appears to have used the term as early as 2008 in a paper entitled Agile Security Requirements Engineering.

References

  • Cohn, Mike (2004-03-01). User Stories Applied: For Agile Software Development (Kindle Locations 400-403). Pearson Education. Kindle Edition.
  • Hope, Paco, McGraw, Anton. (2004) Misuse and Abuse Cases: Getting Past the Positive. IEEE Security & Privacy (Volume:2 , Issue: 3). Available: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=1306981
  • McGraw, Gary. (2004) Software Security: Building Security In, p 205. Addison-Wesley.

Further reading

These sources were not specifically cited for this writing, but are worthwhile to pursue for additional insight and examples.

{% render_partial _includes/callouts/_web_topics_issue.md %}