Face aux transformations digitales agiles imposant la fourniture rapide et fiable de services IT à travers de nouvelles chaînes de production applicative, les équipes SSI doivent adapter leur organisation, leur processus et leur outillage pour assurer une prise en compte des enjeux de sécurité continue. Pragmatisme et adaptabilité seront les maîtres mots pour faire de l’agilité le catalyseur d’une évolution positive dans la prise en compte des enjeux de la cybersécurité.
A travers cette série d’articles, nous présenterons nos convictions pour permettre aux équipes SSI de mener cette transformation en profondeur.
La transformation numérique implique l’usage d’une nouvelle méthode de delivery IT
A l’heure des transformations numériques, les organisations doivent faire face à 3 principaux défis :
- Innover plus rapidement pour faire face à la compétition.
- S’adapter rapidement au changement avec plus de flexibilité afin de mieux gérer l’incertitude et la complexité.
- Mieux combiner les compétences IT et métier pour maximiser la valeur produit.
Dans ce contexte, les méthodes agiles représentent par leur approche de développement itératif, incrémental et adaptatif, la promesse d’une organisation plus fluide en permettant de :
- Réduire les délais entre l’expression de besoin métier et l’ouverture du service idoine (« Time to Value ») : les fonctionnalités développées à chaque étape (sprint) sont opérationnelles et potentiellement utilisables.
- Maitriser les risques et le niveau de qualité: l’approche itérative et incrémentale de l’agile permet de récolter un maximum d’apprentissage (« test and learn ») en un minimum d’effort.
- Augmenter la productivité et la collaboration entre les différentes équipes en donnant du sens à leur travail : en cassant les silos organisationnels, les interactions entre l’IT et les métiers s’intensifient et améliorent l’engagement autour du projet et les boucles d’amélioration continue.
- S’adapter rapidement aux changements: avec la possibilité de changer à tout moment en cas d’évolution des besoins ou de mauvais feedbacks.
Parce que les méthodes agiles bouleversent les façons de prendre des décisions et l’organisation, de nouvelles questions se posent autour de l’articulation de la sécurité dans des organisations agiles :
- Comment réinventer l’intégration de la sécurité dans les projets pour s’adapter à une livraison itérative ?
- Comment soutenir le passage à l’échelle ? Comment structurer les équipes de sécurité pour assurer la sécurité dans l’agile à l’échelle ?
- Au-delà du support sur les projets, comment l’organisation et les processus majeurs SSI évoluent-ils pour fonctionner dans le nouveau modèle opérationnel agile de l’entreprise ?
L’adoption des méthodes agiles impose une refonte du processus d’intégration de la sécurité dans les projets
L’adoption des méthodes agiles représente une véritable rupture dans l’organisation du travail. Le cycle itératif de développement et la fréquence de livraison exigent que toutes les équipes qui gravitent autour du produit soient alignées et impose donc au RSSI de trouver l’articulation idéale entre agilité et sécurité.
Dans les méthodes de gestion de projets traditionnelles, la sécurité est implémentée de manière monolithique à travers 3 piliers :
- Evaluation des risques : évaluation des besoins sécurité et du niveau d’accompagnement SSI consenti pour gérer les risques identifiés.
- Accompagnement : accompagnement des équipes de développement et d’infrastructure dans la conception et l’implémentation des mesures de sécurité.
- Contrôle : réalisation de recette sécurité pour valider la résorption des risques de sécurité et valider la mise en production.
L’intégration de la sécurité dans les processus agiles doit pouvoir s’appuyer sur ces 3 piliers mais il est nécessaire que les équipes SSI revoient leur approche pour s’adapter aux nouvelles méthodes de delivery.
Vous trouverez dans cet article, 4 facteurs clés de succès pour réussir à transposer le processus d’ISP dans une démarche agile.
1. Evaluer le niveau d’accompagnement SSI tout au long du cycle de développement agile
L’appréciation de la sensibilité d’un projet est une première étape incontournable pour prioriser et optimiser les efforts des équipes SSI. Dans une démarche agile, cette évaluation ne doit plus uniquement être réalisée en amont du projet, mais bien tout au long du cycle de développement. Chaque produit doit donc posséder un passeport sécurité, qui sera mis à jour sur une base régulière (ex : tous les 3-6 mois) et lors de développement de fonctionnalités induisant de nouveaux besoins en sécurité.
Le niveau d’accompagnement des équipes SSI sera déterminé en tenant compte de la sensibilité SSI des fonctionnalités développées lors des prochains sprints et du niveau de maturité de la Squad en matière de cybersécurité.
2. Adopter une approche Security by Design
Pour faciliter l’approche Security by Design, les exigences SSI devront être intégrées le plus tôt possible dans la conception du produit.
Pour y parvenir, les équipes SSI vont devoir traduire les mesures de sécurité (référencées dans des politiques et des standards SSI souvent méconnus des équipes de développement) en « security baseline », c’est à dire en un socle de bonnes pratiques applicables de façon systématique et conférant un niveau de protection minimum.
Cela se traduit par une liste de « security user stories », facilement manipulable par les développeurs, qui sera intégrée dans tous les backlogs produit.
3. Traduire les scénarios de risques en Evil User Stories
De la même façon que le Product Owner rédige des User Stories pour décrire de façon conversationnelle une attente exprimée par un utilisateur, les équipes sécurité vont devoir s’adapter aux méthodes agiles en exprimant les risques de façon conversationnelle à travers des Evil User Stories (EUS).
Les Evil User Stories permettent à la sécurité d’exprimer les intentions d’un utilisateur malveillant.
Une Evil User Story décrit la réalisation d’un scénario de risque à travers l’identification d’une source de risque (attaquant externe / collaborateur malveillant), exploitant une vulnérabilité, occasionnant un impact sur la valeur métier.
Pour chaque EUS, des mesures de sécurité (Security User Stories) permettant de mitiger les risques sont identifiées et intégrées au backlog.
Les Security User Stories peuvent être définies à plusieurs étapes du cycle :
- Lors de l’évaluation initiale des risques au lancement du produit.
- Au fil des itérations : dès lors qu’une user story métier induisant des risques SSI est identifiée.
- Lors des phases de contrôle : dès qu’une vulnérabilité est détectée.
Par rapport à une analyse des risques en cycle en V, les Evil User Stories apportent des avantages clés en termes de sécurité :
- Les risques sont facilement compréhensibles, car ils sont énoncés de manière conversationnelle : aujourd’hui lorsqu’on réalise une analyse de risques, les risques que l’on formalise ne vont pas forcément parler à un métier ou à un développeur. De cette façon, les risques sont compréhensibles par tous les acteurs du projet et sont intégrés dans leur quotidien.
- Les risques sont régulièrement mis à jour chaque fois que le produit évolue : la prise en compte des enjeux sécurité doit être à la fois continue et pragmatique et permettre ainsi une démarche de réduction incrémentale du risque. Les Security User Stories sont priorisées en fonction du risque réel et le risque résiduel reste acceptable tant que le produit est exposé à une poignée d’utilisateurs.
- Le processus de remédiation est facilement contrôlable en examinant le backlog : la liste des Security User Stories est embarquée dans le backlog et tracée dans un outil (ex : Jira). C’est un vrai gain par rapport aux méthodes traditionnelles qui ne permettaient pas toujours de suivre la bonne application des mesures de sécurité.
4. Intégrer la sécurité dans les critères d’acceptation des User Stories
Dans un monde idéal, où la sécurité serait systématiquement embarquée, les équipes sécurité n’auraient pas forcément besoin d’intégrer des Security User Stories au backlog produit.
En effet, dans les méthodes agiles, des critères d’acceptation accompagnent chaque user story. Ils représentent un ensemble de conditions (utilisabilité, performance, etc…) que la story doit satisfaire pour être considérée comme complète et terminée. Ils sont rédigés par le Product Owner, en collaboration avec l’équipe de développement.
Ainsi l’équipe sécurité pourrait profiter de ces conditions de satisfaction pour ajouter la liste des mesures de sécurité à intégrer pour assurer la sécurité de chaque fonctionnalité développée.
Dans la réalité, ce n’est jamais réalisé de cette façon (trop contraignant pour la Squad), d’où la nécessité de rédiger et intégrer des Security User Story au backlog produit.
5. Fournir des outils ludiques pour favoriser la prise en compte des enjeux SSI
Parce que les membres au sein des Squad qui vont devoir identifier les Evil User Stories, n’ont pas forcément toutes les compétences pour le faire, nous avons développé un jeu de cartes qui permet de rendre l’exercice d’analyse de risques plus concret et ludique.
Le jeu est composé de cartes, chacune ayant 2 faces :
- Recto : les Evil User Stories 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 User Stories décrivent les mesures de sécurité à implémenter pour s’assurer que l’Evil User Story ne se produise pas (ex : utilisation d’un algorithme de chiffrement robuste AES 256/512, …).
Comment jouer :
- Il faut rassembler à minima les membres de la Squad ayant une connaissance fonctionnelle de la solution (Product Owner) et une connaissance technique et des risques (référents sécurité, développeurs, architectes).
- Les architectes dessinent l’architecture applicative sur une grande affiche A3 sur une table en faisant apparaitre les flux de données et la classification des données et le Product Owner liste les prochaines User Stories qui devront être développées.
- Le référent sécurité (Security Champion) et les développeurs répartissent les vulnérabilités exploitables sur le schéma d’architecture.
- Le Product Owner et le Security Champion qualifient l’impact que peut avoir chaque vulnérabilité.
- Le Security Champion et les développeurs vérifient si les mesures de sécurité permettant de contrer les vulnérabilités identifiées sont déjà implémentées.
- Si des mesures de sécurité ne sont pas encore en production : Le Security Champion priorise les mesures techniques à implémenter permettant de couvrir les risques induits (risque pour l’entreprise, pas seulement au niveau business).
- Le Product Owner priorise les autres mesures de sécurité au regard des risques business / et des moyens de l’équipe.
Ce type de jeu permet de mobiliser l’ensemble des parties prenantes dans l’analyse des risques et d’identifier les mesures de sécurité à injecter dans le backlog.
A travers cet article, nous avons identifié 4 premiers leviers pour intégrer la cybersécurité dans une démarche agile :
- Le Passeport Sécurité pour évaluer le niveau d’accompagnement SSI tout au long du cycle de développement agile
- La traduction opérationnelle de la Security Baseline pour assurer un niveau de protection minimum
- Les Evil User Stories pour exprimer de façon simple et compréhensible les scénarios de risques
- Des outils ludiques pour favoriser la prise en compte des enjeux SSI
Dans les prochains articles, nous répondrons aux questions suivantes :
- Comment soutenir le passage à l’échelle ? Comment réorganiser l’équipe SSI ?
- Comment assurer un bon niveau de contrôle sécurité ?
- Au-delà du support sur les projets, comment l’organisation et les processus majeurs SSI doivent-ils évoluer pour fonctionner dans le nouveau modèle opérationnel agile de l’entreprise ?
