Being an Agile Security Officer: user stories

This is the fourth part of my ‘Being an Agile Security Officer series’. In this blog post I will go deeper into the details of how user stories are created and what role security stakeholders should play in that.

The Epic

Within Agile, work is usually defined in user stories. These are minimal and defined amounts of work that can typically be finished in 1 sprint. However, user stories don’t magically appear from thin air. It all begins with so called epics. An epic is generally a high level wish that mostly describes the desired outcome. An example would be:

‘I want my customers to be able to order products online and have them delivered’.

This epic already gives an idea about what you want to achieve, but leaves a lot of options open on the features and solution. A common technique used to get from an epic to user stories is story mapping. Story mapping is all about identifying the wishes and requirements linked to the epic. Story mapping is most effective when done in small groups (3-5 people is often used as a guideline) and as a security officer it is important to be part of this phase as it is the first spot to identify possible risks and specify requirements. The only way to ‘earn’ that place is by being a ‘promoter stakeholder’ (see my previous blog). During the mapping phase the group identifies the major functionalities of the epic and define the specific user stories.

Mapping the Story

To use the previous example more detailed specifications have to be created on webshop functionality (e.g. how do you want users to be able to search), the payment options, what information you need to complete the ordering, and how you want to handle the delivery. The end result should be a complete map of everything that could be done with unlimited time and resources. A first mapping would therefor look something like this:

Adding Security Requirements

As a security stakeholder you should specify relevant security requirements. These requirements can be on a generic level (e.g. all communication should use TLS), a functional level, or on a very detailed level and linked to a specific part (or group) of the story map. E.g. if user profiling is enabled on the webshop, this should be reflected in the privacy policy and should have an opt-in or opt-out mechanism.
Once the story map is complete it will enter the phase of prioritizing. In the Agile way of working the minimal viable product or walking skeleton is the first goal. This is the minimal set of user stories that provide value to the business. Most of the user stories will in fact not be part of this first delivery.

Agile Risk Management

From a security perspective this might introduce a lot of uncertainties and risks, but if the user stories have been applied with the right security requirements this should not be a problem. Some examples;

• One of the requirements could be that all communication should be protected by TLS. The security stakeholder should have added that requirement to the whole group of webshop user stories. Regardless of what stories are actually selected for the webshop in the walking skeleton, TLS should be part of it.
• Another requirement could be that if credit cards are accepted as payment method, the system should be compliant with the PCI-DSS standard. As long as this user story is not part of a sprint, the security requirement is not relevant. By specifying this already early in the process a product owner can even decide that accepting credit card payments is not worth the effort and opt for another payment method or use a third party solution.
• There could also be a requirement that certain data is not allowed to be collected in the online analytics. As long as the team doesn’t implement and enable the tracking, this requirement is also not relevant for earlier sprints.

Being involved as a security stakeholder in the creation of the user stories allows security and privacy items to be identified early in process and makes sure that these get implemented at the right time. By connecting security requirements to the story map teams are also sure security will not cause a scope creep.

All parts in this blog series

Part 1: Being an Agile Security Officer
Part 2: The Security Stakeholder Mindset
Part 3: Pwn the Process
Part 4: User Stories
Part 5: Spread your knowledge
Pictures: Website www.scrumalliance.org