We talked about it in a previous article, the agile digital transformation is on the way and this new model requires a total rethinking of the way security is integrated into projects. In this article, we will discover how to conduct an agile Cybersecurity workshop, allowing to define Evil User Stories (EUS) and Security Stories. Find below a brief reminder of the fundamental notions to understand the rest.
The EUS & Security Stories workshop: Who, when, where?
First of all, we can only advise you to involve in this workshop the usual actors of agile ceremonies:
- The Product Owner (PO) as a representative of business needs
- The Agile Coach in his capacity as guarantor of the respect of the method
- The technical referents of the project (architect, developers, testers…)
To bring a cyber security eye, it is important to count on the presence of the Security Champion from the project team. If none is available, a member of the CISO team can replace him or her and will have the Cyber Security “mindset” to guide you and complete the workshop.
Then, one often wonders when these workshops should be conducted… To tell you the truth, there is no rule about this, as it will depend on the security requirements of each release! However, our first piece of advice on this subject is to synchronize their frequency with that of the product backlog review. So, all you need to do is extend the workshops where you work on User Stories by about 50% to devote yourself to this security study with all the right players already present and mobilized.
Finally, where should the workshop be held? Ideally in the continuity of your previous workshop, in a room with a board or a projector allowing you to share a screen and the possibility to annotate the diagrams quite easily (post-its, whiteboard markers…). However, it is also possible to do it online! At Wavestone, we regularly use solutions such as Mural or Stormboard for this purpose. Get your hands on a solution like this and see if it’s playable!
Course of the workshop
First of all, it is often necessary for the Security Champion to lead the way in the first workshops. But the idea is to coordinate with the Agile Coach and work together so that the technical referents can gradually take charge of the methodology and make it their own.
When we train our clients on the subject, we often take a use case, fictitious but concrete and realistic! WaveCare is a medical application with many innovative features such as :
- Consulting the availability of practitioners near you
- Real-time transmission of your health data thanks to your connected watch
- Realization of remote consultations in Visio (Skype conference)
- Receipt of the order after the appointment in dematerialized format
For this demonstration, let’s focus on two components in particular: the descriptive schema of the functionality allowing a patient to search and reserve a slot in his doctor’s diary and the general architecture schema.
–
Step 1: Building risk scenarios
The first questions to ask yourself are “Where am I vulnerable? “How and where can I be attacked? ». The Security Champion and the developers will have to try to answer these questions! Here, a mix of application security and development knowledge will help identify exploitable vulnerabilities. We can already see an interesting aspect of the approach: it works on both the infrastructure and application aspects!
One piece of advice we can already give you: encourage developers to take ownership of the approach and to be proactive, it’s an excellent lever for raising security awareness! For the security referent, his or her role should mainly be to moderate the exchange and challenge the developers’ proposals. This position can also help you identify potential Security Champions, so don’t skimp on keeping it!
So let’s apply what we have just said to our example, in the figures below.
–
And here we are, we can finally identify quite quickly some points of attention! If we want to detail the “Code Injection” scenario of the global architecture schema, we can for example rephrase it like this: “As an attacker, I want to inject malicious code into the application’s insecure input fields“. You see, this ending is very close to that of a classic User Story, but the angle is indeed that of the attacker!
Step 2: Evaluate the business impacts of the scenarios
The second phase will be key to ensure that the team’s energy is used in the right place. This is where the Product Owner comes in! Together with the Security Champion, he will lead the debate to qualify the impact that each vulnerability can have.
Why is the PO decisive at this stage? Quite simply because he is the one who knows best both the business reality of the project and the importance of each feature. He will need to be well oriented, with questions such as “Is it serious if the data sent by the patient at this point is stolen? “What is the seriousness of the theft of the user’s account? etc.”, etc.
Next, you will need to give a score to prioritize each scenario. You then have two choices. The first is to use a classic cyber risk view, with a level of probability and impact. Personally, I recommend you rather use a point system or the Fibonacci suite, as for a classic US, it’s frankly simpler and instinctive!
Step 3: Define and prioritize Security Stories
The next step will be to build Security Stories based on each of the scenarios.
Now it’s the turn of the Security Champion and the developers to get back on stage! To continue on the previous example, here is a Security Story we can write: “As a developer, I want to make sure that code injection attacks are avoided“. Concretely, it will make us add to the product backlog actions such as escaping special characters, filtering user input or using the HttpOnly attribute to prevent the theft of session cookies.
Obviously, for each of the Security Stories, it may turn out that the security measures to be implemented are already in place. Otherwise, the Security Champion will prioritize the technical security measures, with regard to covering the risks involved, on a company-wide scale and not only on a business level. For security measures that are not purely technical, it is up to the Product Owner to prioritize them, with regard to business risks and the team’s resources.
And there you have it, you can now start your sprint more serenely!
And to help you, prepare and adapt the material to your context!
To make the workshops simpler and more fun, we have designed a generic deck of cards, consisting of cards with two sides each:
- Front side: the Evil User Stories, they describe in a very pedagogical way what can go wrong, using which vulnerabilities (ex: privilege escalation on a Web server, brute force attack, XSS, …).
- Verso: the Security Stories describe the security measures to be implemented to ensure that the Evil User Story does not occur (e.g. use of a robust AES 256/512 encryption algorithm, …).
These cards are really useful to get you started! For best results, you can even choose to adapt them to your business context. Use your security policies and integrate your requirements on encryption, password complexity, etc. Depending on the security needs of the project, you can also copy requirements related to certifications (HDS) or guidelines (LPM, NIS).
You can find the card game available for free here and don’t hesitate to give us your feedback so that we can continue to improve it!
Also, a workshop that runs smoothly is always more productive! Don’t forget to prepare the materials beforehand: architecture diagrams of the project (data flow and classification), listing and details of the next User Stories to be developed…
