Nous vous en parlions dans un précédent article, la transformation numérique agile est en marche et ce nouveau modèle impose de totalement revoir sa manière d’intégrer la sécurité dans les projets. Nous allons découvrir dans cet article comment conduire un atelier Cybersécurité agile, permettant de définir les Evil User Stories (EUS) et Security Stories. Trouvez ci-dessous un bref rappel des notions fondamentales pour comprendre la suite.
L’atelier EUS & Security Stories : Qui, quand, où ?
Tout d’abord, nous ne pouvons que vous conseiller d’impliquer dans cet atelier les habituels acteurs des cérémonies agiles :
- Le Product Owner (PO) en sa qualité de représentant des besoins métiers
- Le Coach Agile en sa qualité de garant du respect de la méthode
- Les référents techniques du projet (architecte, développeurs, testeurs…)
Pour apporter un œil cybersécurité, il est important de compter sur la présence du Security Champion de l’équipe projet. Si aucun n’est disponible, un membre de l’équipe du RSSI peut le remplacer et aura « l’état d’esprit » Cybersécurité pour vous aiguiller et mener l’atelier à bien.
Ensuite, on se demande souvent à quel moment ces ateliers doivent être conduits… Pour tout vous avouer, il n’y a pas de règle à ce sujet, car cela dépendra des exigences sécurité de chaque release ! Toutefois, notre premier conseil à ce sujet est de synchroniser leur fréquence avec celle de revue du backlog produit. Ainsi, il vous suffit de prolonger les ateliers où vous travaillez sur les User Stories d’environ 50% pour vous consacrer à cette étude sécurité avec déjà tous les bons acteurs présents et mobilisés.
Enfin, où réaliser l’atelier ? Idéalement dans la continuité de votre atelier précédent, dans une salle avec un tableau ou un projecteur permettant de partager un écran et la possibilité d’annoter les schémas assez facilement (post-its, feutres pour tableau blanc…). Néanmoins, il est également tout à fait envisageable de le faire en ligne ! Chez Wavestone, nous utilisons régulièrement des solutions comme Mural ou Stormboard à cet usage. Faites-vous la main sur une solution de ce genre et vous verrez si c’est jouable !
Déroulement de l’atelier
Tout d’abord, il est souvent nécessaire que le Security Champion mène la barque dans les premiers ateliers. Mais l’idée est de se coordonner avec le Coach Agile et travailler de concert pour que les référents techniques puissent petit à petit prendre en main la méthodologie et se l’approprier.
Quand nous formons nos clients sur le sujet, nous prenons souvent un cas d’usage, fictif mais concret et réaliste ! WaveCare est une application médicale avec de nombreuses fonctionnalités innovantes telles que :
- Consultation des disponibilités de praticiens près de chez vous
- Transmission en temps réel de vos données de santé grâce à votre montre connectée
- Réalisation de consultations à distance en Visio (conférence Skype)
- Réception de l’ordonnance après le RDV en format dématérialisé
Pour cette démonstration, intéressons-nous à deux composants en particulier : le schéma descriptif de la fonctionnalité permettant à un patient de rechercher et réserver un créneau dans l’agenda de son médecin et le schéma d’architecture générale.
–
Etape 1 : Construire les scénarios de risque
Les premières questions à se poser sont « Où-suis-je vulnérable ? », « Comment et par où peut-on m’attaquer ? ». Le référent sécurité (Security Champion) et les développeurs vont devoir essayer de répondre à ces questions ! Ici, c’est donc un mélange de connaissances en sécurité applicative et en développement qui va permettre d’identifier les vulnérabilités exploitables. Nous pouvons déjà noter un aspect intéressant de l’approche : elle fonctionne aussi bien sur l’aspect infrastructure qu’applicatif !
Un conseil que nous pouvons déjà vous donner : encouragez les développeurs à s’approprier l’approche et à être force de proposition, c’est un excellent levier pour les sensibiliser à la sécurité ! Pour le référent sécurité, son rôle doit majoritairement être de modérer l’échange et challenger les propositions des développeurs. Cette posture peut en plus vous permettre d’identifier des potentiels Security Champions, ne lésinez pas à la conserver !
Appliquons donc ce que nous venons de nous dire à notre exemple, dans les figures ci-dessous.
–
Et voilà, on peut finalement identifier assez rapidement quelques points d’attention ! Si nous voulons détailler le scénario « Injection de code » du schéma d’architecture globale, nous pouvons par exemple le reformuler comme cela : « En tant qu’attaquant, je veux injecter du code malveillant dans les champs de saisie non sécurisés de l’application ». Vous voyez, cette terminaison est très proche de celle d’une User Story classique, mais l’angle est bien celui de l’attaquant !
Etape 2 : Evaluer les impacts métiers des scénarios
La seconde phase va être clef pour s’assurer d’utiliser l’énergie de l’équipe au bon endroit. C’est à ce moment que le Product Owner entre en jeu ! Avec le Security Champion, il va mener les débats pour qualifier l’impact que peut avoir chaque vulnérabilité.
Pourquoi le PO est-il décisif sur cette étape ? Toute simplement car c’est lui qui connaît le mieux à la fois la réalité métier du projet et l’importance de chaque fonctionnalité. Il s’agira de bien l’orienter, avec des questions comme « Est-ce grave si les données envoyées à ce moment par le patient sont volées ? », « Quelle est la gravité du vol du compte de l’utilisateur ? », etc.
Ensuite, il vous faudra donner une note pour prioriser chaque scénario. Deux choix s’offrent alors à vous. Le premier est d’utiliser une vue risque cyber classique, avec un niveau de probabilité et d’impact. Personnellement, je vous recommande plutôt d’utiliser un système de point ou la suite de Fibonacci, comme pour une US classique, c’est franchement plus simple et instinctif !
Etape 3 : Définir et prioriser les Security Stories
La prochaine étape consistera à construire des Security Stories basées sur chacun des scénarios.
Au tour du Security Champion et des développeurs de remonter sur scène ! Pour continuer sur l’exemple précédent, voici une Security Story que nous pouvons rédiger : « En tant que développeur, je veux m’assurer que les attaques par injection de code sont évitées ». Concrètement, elle nous fera ajouter au backlog du produit des actions comme l’échappement des caractères spéciaux, le filtrage des entrées utilisateurs ou encore l’usage de l’attribut HttpOnly pour éviter le vol des cookies de session.
Evidemment, pour chacune des Security Stories, il peut s’avérer que les mesures de sécurité à mettre en œuvre le sont déjà. Dans le cas contraire, le Security Champion se charge de prioriser les mesures de sécurité techniques, au regard de la couverture des risques induits, à l’échelle de l’entreprise et pas uniquement du métier. Pour les mesures de sécurité n’étant pas uniquement techniques, c’est au Product Owner de les prioriser, au regard des risques business et des moyens de l’équipe.
Et voilà, vous pouvez maintenant démarrer votre sprint plus sereinement !
Et pour vous aider, préparez et adaptez le matériel à votre contexte !
Pour rendre les ateliers plus simples et ludiques, nous avons conçus un jeu de cartes génériques, constitué de cartes ayant chacune deux faces :
- Recto : les Evil User Stories, elles décrivent de façon très pédagogique ce qui peut mal se passer, en utilisant quelles vulnérabilités (ex : élévation de privilèges sur un serveur Web, attaque par force brute, XSS, …)
- Verso : les Security Stories décrivent les mesures de sécurité à implémenter pour s’assurer que l’Evil User Story ne se produit pas (ex : utilisation d’un algorithme de chiffrement robuste AES 256/512, …).
Ces cartes sont vraiment utiles pour vous lancer ! Pour de meilleurs résultats, vous pouvez même choisir de les adapter à votre contexte d’entreprise. Utilisez vos politiques de sécurité et intégrez vos exigences sur le chiffrement, la complexité des mots de passe, etc. Suivant les besoins de sécurité du projet, vous pouvez aussi calquer de exigences liées à des certifications (HDS) ou des directives (LPM, NIS).
Retrouvez le jeu de carte disponible gratuitement ici (et en anglais ici)et n’hésitez pas nous faire vos retours pour que nous continuions à l’améliorer !
Également, un atelier qui se déroule avec fluidité est toujours plus productif ! N’oubliez pas de préparer les supports en amont : schémas d’architecture du projet (flux et classification des données), listing et détail des prochaines User Stories à développer…
