Evil User Stories ? Comment concilier Agilité et réduction de risque

25 juin 2024 | 11 min de lecture

Les retards s’accumulent, l’échéance se rapproche, le budget s’épuise… mais ça y est, on passe en prod !

C’était sans compter les nombreuses failles de sécurité détectées en fin de cycle 😢. Ces vulnérabilités qui auraient pu être corrigées en amont provoquent des tensions. Le management prévoit déjà de remplacer ce développement interne par une solution du commerce coûteuse.

Pour réduire le risque qu’une telle situation (pas si caricaturale) se produise, les Evil User Stories (EUS) décrivent comment des utilisateurs malveillants peuvent exploiter des fonctionnalités d’applications. Elles sont donc un moyen efficace d’aborder les menaces de sécurité en amont du projet et d’anticiper des actions de correction en adoptant dès le départ des bons réflexes de sécurité.

Dans cet article nous parlerons de threat modeling, rappellerons plusieurs concepts liés à la méthodologie Agile, et donnerons une marche à suivre pour implémenter des Security Tasks dans un projet de développement applicatif.

Mais que signifie Agile ?

Pour apporter de la souplesse et de la performance à des projets, déployer des solutions répondant aux attentes des clients et utilisateurs et tenir des délais, la méthodologie Agile (mettant en avant la collaboration entre des équipes auto-organisées et pluridisciplinaires et leurs clients) n’a plus de preuves à fournir quant à son efficacité.

1 – Persona et Users Stories – la modélisation de l’expérience utilisateurs

Lorsque l’on conçoit une application ou un logiciel de façon agile, un bon moyen pour remplir son cahier des charges est de se mettre à la place de différents utilisateurs-type du produit final et ainsi trouver de nouvelles fonctionnalités pertinentes à implémenter pour leur usage.

Nous représentons les utilisateurs finaux d’un logiciel par des personas. Chaque persona est un profil d’utilisateur que nous caractérisons par son nom, son genre, sa situation professionnelle, ses passions et d’autres éléments spécifiques au projet.

Une histoire utilisateur (ou User Story (US)) représente le besoin d’un persona de l’application. Nous l’écrivons sous la forme d’une phrase courte et claire, qui inclut le persona, son besoin et son objectif. A cette US on rattache des fonctionnalités ainsi que les tâches pour les implémenter. On sanctionne alors l’implémentation des tâches liées à une US lorsque les critères d’acceptation énumérés en description de l’US sont validés. Par exemple :

« En tant qu’étudiant visitant headmind.com, je souhaite pouvoir consulter les offres d’emploi de l’entreprise (https://join.headmind.com/offres-demploi/ 😉), afin d’enrichir ma candidature. »

Persona : étudiant

– Besoin : avoir accès aux offres d’emplois HMP sur le site de l’entreprise ;

– But : avoir de la matière pour sa future candidature ;

– Fonctionnalités rattachées : affichage des offres d’emploi dans un onglet dédié, création de filtres (compétences, localisation, formation, …), etc… ;

– Tâches : développement d’un nouvel onglet sur le site, identification des tags liés aux offres d’emploi, création d’un champ de recherche, de filtres, etc… ;

– Critères d’acceptation : les offres d’emploi sont accessibles en moins de 3 clics depuis la page d’accueil du site, la page des offres ressort dans les 5 premiers résultats lorsque l’on recherche « emploi consultant cyber à Paris », etc… ;

2 – Les sprints et la backlog

Nous regroupons toutes les User Stories dans une liste appelée « backlog ». En concertation avec les membres du projet, nous alimentons ce backlog tout au long du projet. Après une phase de planning, nous regroupons les User Stories et implémentons les tâches associées par itérations (sprints) d’une ou plusieurs semaines, selon leur importance et l’estimation de leur durée de mise en place.

Evil User Stories – Incarner l’utilisateur malveillant

Mais qu’en est-il des utilisateurs malveillants ? Si les User Stories nous renseignent sur la manière dont des utilisateurs types pourront tirer le meilleur parti de chaque fonctionnalité, elles ne disent rien de la place laissée aux utilisateurs mal intentionnés.

Les Evil User Stories (ou Abuser Stories) étendent le concept des US aux utilisateurs malveillants. Elles se construisent de manière similaire aux User Stories :

« En tant que [persona malveillante], je souhaite [activité malveillante], afin de [impact] »

Y.com est un réseau social sur lequel les utilisateurs peuvent partager des publications de type texte ou vidéo. Un utilisateur peut en « suivre » un autre afin de consulter son activité dans un « feed » personnalisé.

Comment un utilisateur malintentionné pourrait-il nuire au site ou à ses utilisateurs ? Nous considérons ici le cas d’un hacktiviste dont la motivation est de nuire à certaines personnalités ou partis politiques.

« En tant que hacktiviste politique, je souhaite me faire passer pour une personnalité publique et faire de fausses publications sur Y.com, afin de dégrader son image. »

Un peu d’Abuser Brainstorming peut permettre d’identifier quelques moyens d’y parvenir.

Un premier moyen serait de contourner le contrôle d’accès et de directement prendre possession du compte de la personnalité publique. Cependant, cette méthode semble difficile à réaliser pour notre pirate, le contrôle d’accès étant déjà particulièrement robuste sur Y.com.

Un second moyen, plus crédible, serait d’utiliser un compte ayant des éléments de profil (photo, nom, id, …) similaires au compte authentique. Par exemple en en créant un de toute pièce ou en renommant un compte ayant déjà acquis de la visibilité.

Nous pouvons alors enrichir l’Expérience Utilisateur Spécifique (EUS) avec une méthode crédible que l’utilisateur peut employer. Si nous identifions plusieurs méthodes appropriées, il convient de créer une EUS distincte pour chacune.

« En tant que hacktiviste politique, je souhaite exploiter une vulnérabilité de conception non sécurisée sur Y.com, afin de me faire passer pour une personnalité publique et de dégrader son image en publiant de faux contenus. »

Cette compréhension des types de compromissions possibles, de leurs impacts pour le produit et des objectifs des acteurs malveillants nous permet de mettre en place les mécanismes de défense nécessaires. Cela nous pousse à définir le concept des Security User Stories.

Pour chaque super-vilain, un super-héros : les Security User Stories

Une fois l’ensemble des moyens de compromission identifiés et la rédaction des EUS associées faite, l’étape suivante consistera à définir des mécanismes de défense nécessaires à parer une attaque malveillante et à rédiger ce qu’on appelle des Security User Stories (SUS).

Dans l’exemple précédent, l’Evil User Story suivante a été définie :

Quelles sont les mesures à mettre en place afin d’empêcher l’attaque décrite dans la EUS sur le site Y.com ?

Une première méthode serait d’implémenter une vérification de l’identité des utilisateurs lors de la création de compte (pièce d’identité, vérification biométrique, etc.).

Une seconde méthode serait d’ajouter des contrôles, notamment d’intégrité sur les informations publiées sur le site.

Nous pouvons alors créer 2 SUS à partir de l’Evil User Story initiale faisant apparaître les méthodes de défense (note : si plusieurs méthodes sont identifiées, il convient de créer plusieurs SUS).

SUS 1: « En tant que membre de l’équipe projet, je souhaite implémenter une vérification sur l’identité des utilisateurs lors de la création des comptes, afin de pallier aux problématiques d’usurpation d’identité. »

SUS 2 : « En tant que membre de l’équipe projet, je souhaite implémenter une fonctionnalité de contrôle communautaire des sources, afin de répondre cas d’usurpation d’identité et plus généralement d’intégrité des données. »

Par la suite, nous intégrerons les tâches de sécurité associées aux SUS définies dans la backlog du projet.

Retour à la méthode Agile : l’enrichissement de la backlog du projet

Grâce aux Security User Stories (SUS) écrites à l’étape précédente, nous allons enrichir le backlog avec les tâches de sécurité à réaliser lors des prochains sprints. De plus, nous rattachons des critères d’acceptation aux SUS pour valider la bonne implémentation des mesures de sécurité.

Toujours sur notre exemple du site Y.com, reprenons notre SUS 2 écrite précédemment :

« En tant que membre de l’équipe projet, je souhaite implémenter une fonctionnalité de contrôle communautaire des sources, afin de répondre cas d’usurpation d’identité et plus généralement d’intégrité des données. »

Dans notre backlog projet, nous allons ajouter les éléments de sécurité suivants :

Tâches : 1 – Implémentation d’une fonctionnalité de contrôle communautaire des sources, avec un bouton spécifique lié à chaque post sur Y.com, permettant à un utilisateur de remplir un formulaire alertant quant à la fiabilité d’un post. 2 – Etudier la faisabilité de la création d’un algorithme de vérification des sources et de pondération de ces dernières pour établir un score de fiabilité sur les publication clivantes. 3 – …
Critères d’acceptation : 1 – Un score de fiabilité est affiché en dessous de chaque publication à partir de 10 alertes provenant d’utilisateurs différents. 2 – Lors des tests, un faux compte est détecté à partir de 500 impression de publications. 3 – …

Conclusion

En conclusion, l’intégration des Evil User Stories et des Security User Stories au sein de la méthodologie Agile représente une avancée significative dans la gestion proactive des risques de sécurité. Grâce à l’adoption de ces pratiques, les équipes de développement renforcent leur capacité à anticiper, détecter et atténuer les vulnérabilités, contribuant ainsi à la création de logiciels plus sûrs et résilients.

En plaçant la sécurité au cœur du processus de développement (approche dite « shift left » ou « DevSecOps » dans le cas des projets agile), les organisations peuvent non seulement répondre aux attentes des utilisateurs finaux en terme de fonctionnalités, mais aussi garantir une expérience utilisateur fiable et sécurisée, tout en préservant la réputation de leurs produits dans un paysage numérique de plus en plus complexe et exposé aux menaces.

Co-écrit par Alice Pigneux, Matthias Lotta et Joseph Couillaud