Cyber attack motives, part 2: Evil user stories

How do hackers think? What do evil users do? What does it feel like join the dark side? If you have ever wondered what happens in the mind of a cyber criminal, read on. Maybe you'll improve your application security at the same time.

In the first part of this blog series, Cyber attack motives, part 1: Why hackers hack? Who are they?, we examined typical cyber attacker and harm-doer profiles. Now we are going to focus on finding out what kind of harm these baddies could do.

Evil user stories or ”abuser stories” explore unwanted scenarios

In agile software development, user stories are used for describing features from the perspective of a user in a simplified form: what would they want to do in the system and why. For example, one user story in online shopping could be: "As a user, I want to add items to a basket and then pay them all at once." The simplest way to create evil user stories is to use the regular user story format from an evil point of view: "As a hacker, I want to...".  Because these stories typically misuse the system somehow, evil user stories are sometimes referred to as abuser stories.

The Open Web Application Security Project (OWASP) describes evil user stories as a way to "hack the product backlog". OWASP's evil user story examples are quite technical and on the other hand, pretty generic:

• "As a hacker, I can send bad data in URLs, so I can access data and functions for which I'm not authorized."
• "As a hacker, I can send bad data in HTTP headers, so I can access data and functions for which I'm not authorized."

"Data and functions" needs to be defined better to put this into the backlog and implement any security controls to prevent this.

A Pivotal Tracker blog post by Jeremy Jarrell has approachable examples:

• "As a hacker, I want to steal the credit card numbers of the site’s users, so I can sell those numbers on the black market."
• "As a disgruntled employee, I want to delete all of the store’s inventory, so that the store will appear to be out of stock of all items and will be unable to generate revenue."

What's good in this approach is that it captures other harm-doers than bad hackers attempting cyber crime. As already mentioned in the first part of this blog series, insiders and annoyed users may cause cybersecurity problems as well as mistakes. However, what if you run out of ideas on what the hacker would want to do?

An attacker should not be able to...

There is another way. You can reverse your thinking and start brainstorming, what do you want to protect, with these steps:

1. Identify the assets you want to protect. Assets mean data and resources, such as your customer database, your source code, credentials, signing keys and certificates, and so on. Also, reputation and compliance can be assets.
2. Think about what bad should not happen to important assets. You can do this by completing the sentence, “An attacker should not be able to… what?” For example, “An attacker should not be able to download our source code.”
3. Refine these threat scenarios: How the scenarios could happen, and how could we prevent it? How would the attacker be able to download our source code? Maybe by guessing credentials to Github? Or by stealing a developer laptop? And how can we prevent this? In this case, by having multi-factor authentication to Github and encrypting laptop disks.

Examples of evil user stories:

• An attacker should not be able to purchase items without paying.

• An attacker should not be able to hack the site using known vulnerabilities.

• A user should not be able to see another user’s personal information.

• A user should not be able to send spam on the contact form.

• Many simultaneous users should not be able to crash the website.

• The admin should not be able to shut down the server accidentally.

• A user should not be able to add so many items to a shopping basket that the items are marked as reserved, and other users cannot buy them.

• A user should not be able to use premium features without paying.

• A help desk person should not be able to browse through the information of celebrities or neighbors if they are not related to their task at hand without being detected.

Shifting left with evil user stories

Evil user stories help you to shift left your security. Before you start implementing a new feature, you can have a brainstorming session to create evil user stories related to that feature.

Put evil user stories to your backlog

To make sure you implement mitigating security controls for your evil user stories, you should put user stories into your backlog with mitigations and acceptance criteria.

Let’s have an example with an evil user story “A user should not be able to send spam on the contact form”. A malicious user could do it by using a script and automating it. Possible mitigations include

1. putting a CAPTCHA on the form to prevent automated attacks, using rate-limiting to prevent users from sending the requests at a high-speed rate, and 
2. input validation on the web form to drop out possible random garbage and malicious content attempting to find and exploit web application vulnerabilities.

On the backlog item, we can describe the following acceptance criteria to consider the user story finished.

• Rate limiting implemented

• Input validation implemented

• Security testing done

Of course, you can adapt this to your way of working with the backlog. The main point is that you tie these security items to the actual features and implement them together.

Use evil user stories to plan and prioritize testing

Evil user stories are also useful for test planning. First of all, you can scope security testing based on the threats you discovered: decide which features need testing and what should be prioritized. You may want to automate those evil user stories that are very likely to happen. Security testing can be automated to some extent, but humans are usually needed to analyze the results. Then you can use exploratory testing to experiment, how could the threat scenarios of evil user stories actually happen. A large amount of security testing requires humans to tinker and fiddle with the application. Some of your evil user stories will probably be related to users crashing or slowing down the system. Performance testing is the way to verify these.

Evil user stories are a threat modeling method

Secure applications have one thing in common: security has been considered already in the design phase. A useful way of addressing security early is threat modeling. In short, the idea of threat modeling is to think, what bad could happen, and what can we do about it. Evil user stories can be used as a threat modeling method to complemented architecture-focused approaches.

For some reason, testers are not always invited to design meetings or threat modeling workshops. They should because in my experience, testers are usually really good in threat modeling because they usually have the best knowledge on how the system works. Security testers have the mindset of out-of-the-box thinking or even evil thinking that is essential in identifying security problems.

Build security in with evil user stories

Security should not be an afterthought. You can improve your application security and build security in with evil user stories when you

• identify what the important data and resources you want to protect are,

• think who would be motivated to attack,

• think who could cause harm by accident, and

• put your evil user stories into a backlog.

Evil user stories help you in implementing security together with the functionality, not as an afterthought.

Want to keep track of what's happening in cybersecurity? Sign up for Nixu Newsletter.