Better Security Outcomes with Abuser Stories for Scrum Teams

A User Story is a fundamental concept that is used by nearly every Agile or Scrum Team. A User story is a simple description of a feature, from the perspective of the person/user who would be using said feature.

For example, one of the user stories for an enterprise expense management application would be:

As a user, I would like to upload and enter details of my business expenses, so I can be reimbursed by my organization.

The common syntax for a user story is As <user/user role>, I would like to <do something> so <some result>

As you can see, this is a fairly broad user story, that Scrum/Agile Teams typically would break into specific sub-features or tasks that can be addressed by the team in their sprints. Teams can break this user story down by workflow steps or business-rules or many other ways (A great approach to breaking down User Stories is in this article here)

While this is all fine and dandy, it doesn’t really address the subject of this article, “Abuser Stories”, which brings us to the million dollar question….

“What on earth is an Abuser Story?”

An Abuser Story is the “evil” version of a user story. While a User Story describes a useful feature or functionality that will eventually be part of the amazing app that you are building. An Abuser story is all gloom-and-doom. Simply put, an Abuser Story is a simple description of how the User Story (Feature) can be abused by a malicious actor. It is an “abuse case” of what a malicious actor would do to compromise confidentiality, integrity or availability (security) parameters of the user story for a particular purpose. For example, as a abuser story for the high-level user story mentioned above, this would be:

As a malicious employee, I will upload malware-laden files/content into the system, so I can compromise the computer of the administrator who downloads these files for review and approval

An Abuser Story, as you would notice, has a similar syntax to the user story. This just makes it easier for Scrum/Agile Teams to create more consistent Abuser Stories as well. The structure would be:

As <malicious actor>, I <perform a malicious action> so <outcome of malicious action>

Now that we have gotten that out of the way, we still have to understand…

“What’s the point of an Abuser Story?”

If you have been on an Engineering team, you probably know this unequivocal truth.

Security is Hard!

Securing your product/app is a highly involved and continuous activity. Security is also critical because you don’t want your product or customer data to end up in the wrong hands and deal with expensive and sometimes fatal (just ask the folks over at Equifax).

Therefore, as a responsible product engineering team, you need to have security embedded in every part of your SDLC/Continuous Delivery Pipeline/etc.

Ideally, we would like to ensure that security flaws and vulnerabilities are caught and addressed as early in the lifecycle as possible. This is the proverbial “Shifting Left”. While there are several aspects of Security practices that we can discuss across the lifecycle. We are here to focus on Abuser Stories, and Abuser Stories, typically appear where User Stories appear, which is in the Requirements/Plan Stage of the SDLC. However, the effect of Abuser Stories is present across the lifecycle, just as a user story has its flow across the SDLC as well.

The idea is that we are able to define the possible security exceptions and abuses we will run into with every user story and we validate the security requirements (like acceptance criteria) at each stage of the SDLC. If done correctly, this can significantly reduce the number of security flaws being introduced into a feature in production. Consequently, the application is likely to be that much more resilient to compromises.

If you’ve come this far, you’re clearly interested in how Abuser Stories can help your team. So onto….

“Great, How can I use Abuser Stories in my Agile Team? Spare me no details….”

Alright, this section will be a little longer than the previous ones, so please bear with me.

Let me explain this with our example.

As a user, I would like to upload and enter details of my business expenses, so I can be reimbursed by my organization.

First, I am going to break down this story by workflow and business rules, and embed Abuser Stories into these specific user stories.

Breakdown by Workflow Steps

Here, I’ll break down this High-Level user story into smaller user stories that can be taken up in sprints. In this style, I will be breaking down this user story into the individual steps required to make this user story happen.

1. As a user, I can to login to the application with my official email address and password, so I can upload details of my business expenditure for reimbursement.
2. As a user, I can setup the instruments that I use for official expenses, like my credit card and setup accounts that I can get reimbursements into, like a bank accounts, so that I can submit details of business expenditure accurately and receive reimbursements.
3. As a user, I can track details of approval and view approved and “waiting to be approved” expenditure, so I can know the bills are approved and those that are pending for approval.

Breakdown by Business Rules

In this style, I will be breaking down the high-level user story, by business rules. These may be implicit or explicit business rules.

1. As a user, I can only upload expenditure that is within a pre-defined budget, so I cannot overspend on the company’s dime.
2. As a user I can receive reimbursements only for the bills my manager approves, so I can only be reimbursed for approved expenses

Just by examining this list, those of you in security (or who can think in 😈 terms) will realize how Abuser Stories fits in. A Malicious Actor can potentially abuse all of these user stories in some way or the other. Oftentimes, in more ways than one. So here are some example Abuser Stories for these User Stories:

As a user, I can only upload expenditure that is within a pre-defined budget, so I cannot overspend on the company’s dime.

Example Abuser Story: As a malicious employee, I can elevate privileges and increase the budget allocated to me/specific employee, so I can get payments for bogus expenses beyond the previously pre-defined budget.

Or let’s take another story:

As a user I can receive reimbursements only for the bills my manager approves, so I can only be reimbursed for approved expenses

Example Abuser Story: As a malicious employee, I am able to gain access to my manager’s account so I can approve expenditure on behalf of my manager.

While, in this case, I have identified a single Abuser Story for only some of these user stories, you could have multiple abuser stories identified for each of these user stories. The important point is that these Abuser Stories need to fit in with the specific user story and have some kind of security impact (confidentiality, integrity, availability).

Which brings us to a really important point….

“Alright, now I have Abuser Stories…What next??”

There are multiple segues from each Abuser Story. These segues are the ones that you would be using to design security features, develop and validate security features, test and subsequently monitor these security features in your application.

The typical segues that you can derive from the Abuser Stories are (but not limited to):

• Possible Attack Scenarios
• Security Feature Design
• Development Checks
• Testing Strategies
• Deployment Checks

Let’s go back to our example. Let’s start with the User Story and Abuser Story

As a user I can receive reimbursements only for the bills my manager approves, so I can only be reimbursed for approved expenses- As a malicious employee, I am able to gain access to my manager’s account so I can approve expenditure on behalf of my manager.

Based on the above Abuser Story, here are some of the possible segues. Please note that I am not including all possible scenarios and combinations. This is just an example for you to understand the uses of Abuser Stories:

Possible Attack Scenarios

Possible Attack Scenarios are used to identify specific attack vectors used to make the Abuser Story happen:

• SQL Injection to gain access to steal manager’s password and gain access to his/her account
• Sniff Session Tokens over the network to gain access to manager’s session token and subsequently gain access to his/her account
• Bruteforce weak password used by Manager to gain access to his/her account
• Use Social Engineering to trigger potential CSRF attack against manager to approve the expense
• Embed malware laden file in file upload and compromise manager’s browser/computer and takeover manager’s account

The interesting aspect of the Attack Scenarios is that these can be morphed into Security Test Cases that can be used by your Security Testing team to perform more specific validations against the application.

Security Feature Design

This segue specifically refers to features that can be designed in as part of the application as defenses against this and other abuser stories. These may be separate user stories as well.

• Log Invalid Access Attempts and setup security alerts to detect bruteforce attacks in progress.
• Allow only specific types of files for upload (like image files, etc). Scan files for malware before accepting.
• Enforce Password Complexity Requirements, with High-Entropy passwords being enforced on all users in the system

Development Checks

This segue could be a “checklist” (although I hate that word) for developers to use when creating the application’s features:

• Use Parameterized Queries in every Database query
• Use and validate Anti-CSRF tokens for each request to the application.
• Sanitize HTML Output to protect against XSS Attacks
• Implement HTTPS with TLS 1.1 and 1.2 support and strong cipher suites. Implement HSTS

In Conclusion…

Abuser Stories are a very useful way to integrate security into your Scrum/Agile Team. In find it especially useful, since you can integrate it directly into the User Stories. Ideally, you should have a cross-functional team creating Abuser Stories, with members from Security, Product Management, Dev and Business involved in creating the stories, that way Business risks would also be considered as part of pure security risks.

About the Author:

Abhay Bhargav is the CTO of we45, a focused Application Security company and the Chief Architect of Orchestron, an Application Vulnerability Correlation and Orchestration Platform. Abhay is the author of two international publications. “Secure Java for Web Application Development” and “PCI Compliance: A Definitive Guide”. Abhay is a builder and breaker of applications. He is a passionate Pythonista and loves the idea of automation in security. This passion prompted him to author the world’s first hands-on Security in DevOps workshop that has been delivered at OWASP AppSecUSA, OWASP AppSecEU and DEFCON. He regularly speaks at major security and industry events including OWASP, JavaOne.

Follow him on Twitter: Abhay Bhargav

LinkedIN: https://www.linkedin.com/in/abhaybhargav