In this episode, Judy Neher shows us how to use an approach that she calls Abuser Stories to address potential security gaps in your system.
President/CEO of Celerity Technical Services, Inc.
Judy Neher is an agile trainer and coach, passionately transforming government software teams from traditional development practices to agile practices for the last 12 years.
Judy has over 27 years of experience with the Intelligence Community as a mathematician, computer scientist, traditional software manager, and ultimately, as an agile coach, trainer and leader.
After listening to this episode, you'll understand:
- How to apply Abuser Stories to address security features
- How and when to include security related non-functional features in your definition of done, User Stories, and Abuser Stories
- What tool you can use to identify security features for your software
- How to prioritize security features
Abuser stories take the concept of user stories and flips it on its side so we start thinking from a hacker’s perspective. Instead of looking at who are our users, we look at who are our adversaries. Who wants access to our data, who wants access to our systems, and what is their motivation?
Abuser stories allow us to put the bad guy hat on to help us identify potential security gaps and other risks. It allows us to look at our systems from an attacker’s perspective.
An example of a typical user story might be: “As a Facebook user I want to be able to log into Facebook so that I can get access to my profile.” That story inherently has a lot of places were a hacker would want to gain access.
We can take this user story and look at it from an attacker’s point of view. An abuser story might be “As an attacker I want to be able to get a user password so that I can access their personal data.” This approach allows us to understand where we might introduce vulnerabilities into our system by implementing a simple login story. It allows us to identify potential threats and understand how to address those threats.
Abuser stories also help us understand the threat and how to prioritize features to address those threats based on the potential risk.
Abuser stories will go on the product backlog along with your other user stories. As were defining our features, we’re looking at the security around those features and were able to prioritize the security around those features based on the threat. If the threat is likely to happen and will have a high impact, the abuser stories will be prioritized higher.
With user stories we have acceptance criteria to confirm that the story is done and acceptable. With abuser stories, the details are defined by reputation criteria. How can we define that the attack is not possible? The reputation criteria allows us to prove that the threat has been mitigated.
We can include security needs in a variety of ways. Security concerns can be addressed as part of user story, as part of your definition of done, or as part of the acceptance criteria in a user story.
Judy advises including security professionals in your story refinement sessions to help you identify specific security needs and perhaps brainstorm some of the abuser stories. Story demos are also a great place to include security professionals to provide feedback on potential threats and risks.
Due to the lack of availability of security professionals, everyone on the team needs be responsible for system security. Security cannot be an afterthought. That’s where abuser stories can help you to think differently about potential threats.
Abuser stories in practice
Whereas user stories can be prioritized based on business value, abuser stories carry negative business value. Consider the amount of damage it would cause if an attacker gain access to your data. The goal in each sprint is to optimize the net business value. If there is a low likelihood of an attack taking place and only a small amount of potential damage, the negative business value would be low.
The use of personas for potential internal and external attackers can also help you discover and address threats.
- Think about both internal and external threats to your software and create personas to represent individuals who may intend to exploit your system.
- Identify features and user stories with potential risk in your backlog and create abuser stories to address security gaps.
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.