This document discusses using "evil user stories" to improve application security. Evil user stories describe how attackers might compromise systems or abuse features from a malicious perspective. They can help security teams think like attackers and identify threats early. The document provides examples of evil user stories and corresponding mitigations that could be used to refine security testing and prevent vulnerabilities.

1. Evil User Stories –
Improve Your Application Security
@Anne_Oikarinen
Agile Testing Days 5.11.2019

2. • → Interested in computers, astronomy, physics
• → studied infosec & telecommunications
• → software testing
• → network security testing / test management /
• training instructor / network design / software development
• → incident response & security awareness
• → white hat hacker / guiding dev teams how to build security in
Whoami
Anne Oikarinen
Senior Security Consultant @ Nixu Corporation, Finland
M.Sc. (Tech), CISSP, GMOB
Twitter: @Anne_Oikarinen

3. Hire penetration testers, blame developers,
fix, release patches, … repeat
What if we could find bugs earlier?
https://dilbert.com/strip/2017-12-05

4. Thinking
like a
hacker

5. https://www.visualcapitalist.com/hackers-hack-motives-behind-cyberattacks/

6. Organized crime
•Money!
Angry persons
•Customer
dissatisfaction
•Unsatisfied former
employee
•Revenge
Hacktivists
•Destruction
•Racism
•Disruption
•Political influence
Cyber attack motives
Script kiddies
•Testing skills
•Excitement & Fun
•Training &
experimenting
•“Show-off”
Competitors
•Competitive
advantage
Nation State
•Destruction
•Spread
disinformation
•Political influence
•Espionage

7. • Motivation
• Wants to help
• Avoid conflict, fear of authority
• Will plug that suspicious USB and
tell sensitive information
Non-malicious harm-doers
Security problems can happen by accident
• Motivation
• Contribute to open source for CV
• Get the job done
• Copy paste coding, introduces
vulnerabilities by accident
Social Engineering Victim “Taylor” Incompetent Developer “Derk”
• A person with a
“can do” attitude,
always ready to
help others
• A web designer /
developer
without software
engineering
training

8. Evil user stories or “abuser stories”
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 the content of requests, so I
can access data and functions
for which I'm not authorized.
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
https://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories
https://www.pivotaltracker.com/blog/embracing-evil-user-stories

9. Identify assets to protectStep 1
• Important data and resources you want to protect
• Customer database, server resources, source code, AWS account, reputation, …
“An attacker should not be able to…”Step 2
• Think what bad should not happen to the important assets
• Complete the sentence “An attacker should not be able to….”
Refine the threat scenariosStep 3
• You have a list of threat scenarios
• Refine the scenarios: how could they happen?
• How can you prevent these from happening?
Reversing your thinking

10. 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 accidentally shut down the server
Evil user stories
An attacker should not be able to…

11. Put evil user stories to backlog
Mitigations as acceptance criteria
Evil user
story
• A user should
not be able
to send
spam on the
contact form
Investigate
mitigations
• Captcha
• Rate limiting
• Input
validation
Backlog
item
• Acceptance
criteria:
• Rate
limiting
• Input
validation
• Security
testing

12. Evil user story
•An attacker
should not be
able to send a
messages
pretending to
be someone
else
How could this
happen?
•Modifying
parameters in
requests
•Guess
password
Mitigations
• Minimize user
submitted
input
•Multi-factor
authentication
Examples of evil user stories and mitigations
Messaging

13. Evil user story
•A user should
not be able
reserve all
items in stock
in their basket
so that other
users cannot
buy them
How could this
happen?
•Clicking
tirelessly
•Bypassing logic
by tampering
Mitigations
• Release basket
items after a
delay
• Server-side
limitation on
the number of
items
Examples of evil user stories and mitigations
Online shopping application

14. Evil user story
• A user should
not be able to
browse through
personal data
unrelated to
their task
without being
detected
How could this
happen?
• Abusing
permissions
Mitigations
• User needs to
describe reason
• Logs
• Report
correlation
between views
vs. handled
cases
Examples of evil user stories and mitigations
Viewing health records or customer data

15. Evil user story
•A user should
not be able to
use premium
features
without paying
How could this
happen?
•Tampering
•Vulnerabilities
•Guess or brute-
force password
Mitigations
• Input validation
• Encourage
strong
passwords
• Lock account
after 3-5 wrong
attempts
Examples of evil user stories and mitigations
Online services that require payment

16. scoping
security
testing
automating
security
testing
exploratory
testing
performance
testing
Using evil user stories for test planning

17. Shifting left even more
Scoping security testing
Performance testing
Exploratory testing
Automated security testing
Getting involved in design
Threat modeling

18. • Find security threats and potential
weaknesses early by identifying
• Motivation
• Important data and resources
• Plan testing
• Get involved in threat modeling
• Get involved in design
Improve security with
evil user stories