A l’heure où les utilisateurs ont adopté ce produit en masse, cela pose aujourd’hui plusieurs questions fondamentales de cybersécurité.  

Les entreprises doivent-elles laisser leurs employés – spécifiquement les équipes de développement – continuer à utiliser cet outil sans aucune restriction ? Doivent-elles suspendre son usage le temps que les équipes de sécurité se saisissent de la question ? Ou alors faut-il simplement le bannir ? 

Entre autres, certaines entreprises comme J.P. Morgan ou Verizon ont fait le choix d’en interdire l’usage. La société Apple avait initialement décidé d’autoriser l’outil pour ses employés avant de revenir sur sa décision et l’interdire. Amazon et Microsoft ont simplement demandé à leurs employés de faire attention aux informations partagées avec OpenAI. 

L’approche la plus restrictive qui consiste à bloquer la plateforme permet d’éviter toutes questions de cybersécurité mais posent d’autres interrogations, notamment sur la performance et la productivité des équipes, et plus largement de la compétitivité des entreprises sur des marchés changeant rapidement. 

Aujourd’hui, la question du blocage IT de l’intelligence artificielle reste d’actualité. Nous proposons de donner quelques éléments de réponses à cette question pour une catégorie de population particulièrement concernée par la question : les équipes de développement. 

ChatGPT, collecte d’informations personnelles et RGPD 

Le produit d’OpenAI est libre d’accès et d’utilisation sous condition de créer un compte utilisateur. C’est une tendance connue : si un outil en ligne est gratuit, c’est que la source de revenu n’est pas issue de l’accès à l’outil. Pour le cas particulier de ChatGPT, les informations provenant de l’historique des millions d’utilisateurs permettent d’améliorer la plateforme et la qualité du modèle de langage. ChatGPT est un service en preview : toute données entrée par l’utilisateur est susceptible d’être lue par un humain de façon à améliorer les services. 

Actuellement ChatGPT ne semble pas conforme au RGPD et à la loi informatique et liberté mais aucune décision de justice n’a été rendue. Les conditions générales ne font actuellement pas mention du droit à la limitation du traitement, droit à la portabilité des données ou encore du droit d’opposition. La société OpenAI basée aux Etats-Unis ne fait pas mention du RGPD mais rappelle que ChatGPT est conforme aux « CALIFORNIA PRIVACY RIGHTS ». En revanche, cette régulation ne s’applique que pour les résidents Californiens et ne s’applique donc pas au-delà des Etats-Unis d’Amérique. OpenAI ne propose pas non plus de solution pour permettre aux individus de vérifier si l’éditeur stocke leurs données personnelles, ni d’en réclamer leur suppression. 

Enfin, lorsque nous nous attardons sur les mentions légales de ChatGPT, nous pouvons comprendre que :  

1. OpenAI collecte les adresses IP de l’utilisateur, son type de navigateur Web, ainsi que les données et ses interactions avec le site web. Par exemple, cela inclut le type de contenu généré avec l’IA, les cas d’usages et les fonctions utilisées. 
2. OpenAI collecte aussi des informations sur l’activité de navigation des utilisateurs sur le web. Elle se réserve d’ailleurs le droit de partager ces informations personnelles avec des tiers, mais sans préciser lesquelles.  

Tout ceci étant fait dans le but entre autres d’améliorer les services existants ou de développer de nouvelles fonctionnalités.  

Pour revenir aux populations de développeurs, on observe aujourd’hui que la majorité du code s’écrit de manière collaborative en utilisant des outils Git. Ainsi, il n’est pas rare pour un développeur de devoir comprendre un morceau de code qu’il n’a pas écrit lui-même. Plutôt que de demander au rédacteur en question ce qui peut prendre plusieurs minutes (au mieux), un développeur peut être tenté de se tourner vers ChatGPT afin d’obtenir une réponse de manière instantanée. La réponse peut parfois même être plus détaillée que celle que l’auteur du code pourrait fournir. 

Les attaques classiques sur l’IA restent valables 

Plus de la moitié des entreprises se disent aujourd’hui prêtes et décidées à investir et à s’équiper d’outils fonctionnant grâce à l’intelligence artificielle. Par conséquent, il va être de plus en plus intéressant pour les attaquants d’exploiter ce type de technologie. D’autant que la notion cybersécurité est trop souvent ignorée lorsqu’on parle d’intelligence artificielle. 

L’IA d’OpenAI n’est pas immunisée contre les attaques par empoisonnement. Même si l’IA est entraînée sur une base de connaissance conséquente, il est peu probable que l’ensemble de cette connaissance ait fait l’objet d’une revue manuelle. Si nous revenons au sujet de la génération de code, il est probable que selon certains entrants spécifiques l’IA propose du code contenant une porte dérobée (backdoor). Même si ce cas de figure n’a pas été constaté, il n’est pas possible de prouver que celui-ci ne se produira pas selon un entrant particulier de l’utilisateur. 

Nous pouvons également supposer que l’outil n’a été entrainé qu’à partir de sources web relativement sûres. Le LLM (Large Language Model) sur lequel repose ChatGPT : GPT3 pourrait être susceptible à « l’auto-empoisonnement ». En effet, à mesure que GPT3 est utilisée par des millions d’utilisateurs, il est très probable que du texte généré par GPT3 se retrouve au sein de contenus internet de confiance. L’entraînement de GPT4 pourrait donc théoriquement contenir du texte généré par GPT3. Ainsi, l’IA pourrait réaliser son apprentissage à partir de connaissances qui aurait été générées par des versions antérieures du même modèle LLM. Il sera intéressant de voir comment OpenAI contourne le problème d’empoisonnement à mesure que les évolutions sont apportées au modèle. 

L’empoisonnement est une des techniques permettant d’ajouter des backdoors dans le code généré par l’IA, mais ceci n’est pas l’unique vecteur d’attaque. Il est également possible qu’une compromission des systèmes OpenAI permettant de modifier la configuration de ChatGPT afin de suggérer du code contenant des portes dérobées sous certaines conditions. Un attaquant sournois pourrait aller jusqu’à filtrer sur l’identité du compte utilisateur de ChatGPT (par exemple un compte finissant par @grandclientduCAC40.com) pour décider ou non de générer du code contenant des backdoors et autres vulnérabilités. Il est donc nécessaire de rester vigilant du niveau de sécurité d’OpenAI de façon à éviter toute compromission par rebond. 

Chat GPT et la génération de code 

La génération de code via ChatGPT est une des fonctionnalités qui peuvent faire gagner le plus de temps à un développeur au quotidien. Un développeur peut par exemple demander de rédiger un squelette de code pour une fonction puis compléter / corriger les erreurs de l’IA au besoin. Le risque principal induit par cette pratique est ici l’insertion de code malveillant au sein d’une application. 

Cependant, le risque existait bien avant ChatGPT. Un développeur malveillant pourrait très bien obfusquer son code et insérer une backdoor au sein d’une application de manière volontaire. En revanche l’introduction de l’IA apporte une nouvelle dimension au risque dès lors qu’un utilisateur bien intentionné pourrait introduire une backdoor malgré lui. Ceci est à mettre en perspective de la maturité de l’entreprise vis-à-vis de sa chaine CI/CD. La réalisation de scans SAST, DAST et d’audits divers avant la mise en production permet entre-autres de réduire le risque.  

Nous avons constaté que la génération de code via ChatGPT ne suit pas par défaut les meilleures pratiques de sécurité. L’outil peut générer du code utilisant des fonctions non sécurisées comme scanf en langage C. Nous avons proposé à l’outil la requête suivante : « Est-ce que tu peux écrire une fonction en langage C qui permet de créer une liste de nombres entiers grâce à des inputs d’un utilisateur ? ». 

Code généré par ChatGPT suite à l’entrée utilisateur décrite ci-dessus

En analysant le code généré par ChatGPT on remarque – entre autres – trois vulnérabilités importantes :  

(1) Pour débuter, l’utilisation de la fonction scanf permet à l’utilisateur de rentrer n’importe quelle longueur d’input (int overflow…). Il n’y a pas de validation de l’input de l’utilisateur, ce qui reste aujourd’hui un type de vulnérabilité phare remonté par l’OWASP TOP10.  

(2) Additionnellement, la fonction est sensible au buffer overflow : au-delà du 100ème input, la liste list ne contient plus de place pour stocker des données additionnelles ce qui peut soit terminer l’exécution par une erreur ou alors permettre à un utilisateur malveillant d’écrire des données dans une zone de la mémoire qui ne serait pas autorisée afin de prendre le contrôle de l’exécution du programme.  

(3) Pour finir, ChatGPT alloue de la mémoire à la liste via la fonction malloc mais oublie de libérer la mémoire une fois que la liste n’est plus utilisée ce qui pourrait entrainer des soucis de fuite de mémoire (memory leak). 

Chat GPT ne génère donc pas de code de manière sécurisée par défaut contrairement à un développeur expérimenté. L’outil propose du code contenant des vulnérabilités critiques. Si l’utilisateur se révèle assez sensibilisé à la cybersécurité, il est possible de demander à ChatGPT d’identifier les vulnérabilités contenues dans son propre code :  

ChatGPT est capable de détecter les vulnérabilités sur le code ayant été généré par ses soins.

Pour résumer, la génération de code via ChatGPT n’introduit pas de nouveaux risques mais accentue la probabilité qu’une vulnérabilité se retrouve en production. Les recommandations peuvent varier en fonction de la maturité et de la confiance qu’a l’entreprise dans la sécurisation du code livré en production. Une chaine CI/CD et des processus robustes avec des scans de sécurité automatiques (SAST, DAST, FOSS…) a de grande chance de détecter les vulnérabilités les plus critiques.  

Ainsi, ChatGPT n’est pas la seule ressource accessible en ligne par les utilisateurs pouvant permettre l’exfiltration de données (Google Drive, WeTransfer…). Le risque de fuite de données plane déjà sur toute organisation n’ayant pas implémenté une allow-list sur le proxy internet de ses utilisateurs. Le facteur différenciant dans le cas de ChatGPT est que l’utilisateur ne se rend pas nécessairement compte du caractère public des données postées sur la plateforme. Les bénéfices et le gain de temps apportés par l’outil sont bien souvent trop tentant pour l’utilisateur lui faisant oublier les bonnes pratiques. En ce sens ChatGPT n’apporte pas de nouveaux risques mais accentue les probabilités de fuite de données. 

Une organisation dispose donc de deux options afin d’empêcher la fuite de donnée via ChatGPT : (1) former et sensibiliser ses utilisateurs puis leur faire confiance, ou (2) bloquer l’outil.  

Pour les population de développeurs, ici encore la génération de code via ChatGPT n’introduit pas de nouveaux risques mais accentue la probabilité qu’une vulnérabilité se retrouve en production. Il revient à l’entreprise d’évaluer les capacités de sa chaine CI/CD et ses processus de mise en production afin d’évaluer les risques résiduels notamment concernant les faux-négatifs des outils de sécurité intégrés (SAST, DAST…).   

Afin de prendre une décision éclairée, une analyse de risques reste un bon outil pour prendre une décision quant au blocage éventuel de l’accès à ChatGPT. Les aspects suivants doivent être considérés : niveau de sensibilisation des utilisateurs, sensibilité de la donnée manipulée, paradigme de filtrage internet, maturité de la chaine CI/CD… Ces analyses sont bien sûr à mettre en perspective avec les potentiels gains en productivité des équipes. 

Cet article ChatGPT & DevSecOps – Quels sont les nouveaux risques cybersécurité induits par l’utilisation de l’IA par les développeurs ?  est apparu en premier sur RiskInsight.

Dans les articles précédents, nous avions beaucoup parlé de la façon dont la sécurité devait s’organiser pour accompagner des projets agiles : le changement de paradigme sécurité pour assurer le Security by design, comment organiser les équipes SSI face à ces changements, les méthodologies possibles pour tout de même continuer à analyser les risques ou les homologations de sécurité (et un rappel global de ce à quoi ressemble la sécurité dans l’agile).

Ces articles évoquaient surtout les changements de paradigme organisationnel et méthodologique que vivaient les équipes SSI, afin de pouvoir accompagner au mieux les projets, qui délivrent du code beaucoup plus rapidement.

Les liens entre Agilité et DevOps

En décalant un peu le regard vers les équipes de développement, et avec des retours d’expérience terrain, il s’agit aujourd’hui de traiter plus en profondeur les solutions logicielles et les processus permettant à la sécurité de venir s’intégrer directement dans les chaines de développement et dans le quotidien des développeurs, là où méthodologies Agile et DevOps, bien qu’elles visent les mêmes objectifs d’apport de valeur aux clients, vont s’exprimer différemment.

Le mouvement DevOps étant plus tardif que les méthodes Agile, les équipes de développement se sont organisées plus tôt que les opérations dans un mode itératif et rapide pour la livraison d’applications et de service. Les principes DevOps viennent pallier cet écart, en rapprochant les équipes Opérations et Développement, et en proposant encore des solutions d’accélération des livraisons, par l’automatisation forte du cycle de vie du développement logiciel, via les pipelines CI/CD. Au final, les deux approches viennent s’alimenter et se compléter, pour livrer plus vite et avec une meilleure qualité, grâce à l’automatisation d’un grand nombre de tâches, évitant ainsi des erreurs humaines.

Et la sécurité ?

Pour revenir à notre marotte, il s’agit désormais d’automatiser la sécurité le plus possible. Au même titre que les méthodes Agile et DevOps, la Sécurité dans l’Agile et le DevSecOps sont également très liés. L’idée est en effet de rapprocher toujours plus la sécurité des équipes de développement, mais aussi de la rendre aussi rapide. Un profil clé des principes de sécurité dans l’agile est tout à fait adapté au DevSecOps : celui du Security Champion. Tel que décrit dans l’article « Comment structurer les équipes SSI pour assurer la prise en compte de la sécurité dans l’Agile à l’échelle ? », c’est l’ambassadeur sécurité au sein des équipes de développement. Il fait partie intégrante de l’équipe produit et est présent à chaque sprint. Son rôle est de s’assurer que la sécurité est bien prise en compte à chaque sprint dans le développement des User Stories (en intégrant des Evil ou Security User Stories déjà écrites, ou en aidant à les rédiger). Le Security Champion peut être issu du monde des développements, et monter en compétence sur les sujets sécurité, avec l’aide de la Guilde Sécurité.

Pour aller un cran plus loin, le Security Champion peut aussi aider son équipe à comprendre les solutions automatisées de sécurité, avec l’aide bien sûr d’un spécialiste de l’équipe SSI, qui l’aidera à monter en compétences sur la sécurité applicative.

Cela étant dit, est-ce parce que Sécurité Agile et DevSecOps sont liés qu’il faut automatiquement se lancer dans un programme de transformation vers le DevSecOps ?

Quelques questions préparatoires pour se lancer dans le DevSecOps.

Dans la droite lignée de tout projet de transformation important, il convient de s’interroger sur les raisons de le faire, s’assurer d’avoir un plan et le bon sponsorship. Le DevSecOps n’échappe pas à la règle, même si les questions à se poser restent spécifiques.

Définition des périmètres et objectifs

Tout d’abord, et avant de se lancer, il faut identifier ses leviers de motivation. Est-ce pour livrer plus vite ? mieux ? de façon plus sécurisée ? Les problématiques rencontrées par les équipes Dev, Sec et Ops seront-elles résolues en rapprochant les compétences ? Ceci afin de de prioriser les efforts et s’assurer de pouvoir « vendre » le projet aux sponsors. Ensuite, le périmètre doit être identifié, en essayant de le délimiter entre périmètre transitoire (à court et moyen termes) et périmètre cible (à long terme). On peut commencer le travail sur un portfolio applicatif, une factory pour tester, puis créer la roadmap pour déployer le modèle au périmètre total.

La maturité actuelle de l’organisation en termes d’outillage et d’automatisation dans le cycle de développement des produits doit être évaluée. Une bonne connaissance des outils utilisés dans les chaines est un prérequis. Si trop de zones d’ombre persistent, il faut au préalable démarrer un inventaire des outils existants et un état des lieux des pratiques et processus en place.

Présence des briques essentielles de la chaine CICD

Avant de pouvoir intégrer la sécurité dans les chaines de développement de façon automatisée, il faut d’abord s’assurer d’avoir une bonne vision de ce à quoi peut ressembler une chaine à l’état de l’art. Il est possible de se lancer dans un programme de DevSecOps sans chaines opérationnelles déjà installées, mais avoir une idée claire de la cible est clé. Voici quelques exemples de solutions :

Figure 1 – les briques essentielles d’une chaine CICD (DevOps)

L’entreprise doit être capable également de quantifier les développements réalisés en interne ou en externe, avec des agences de développements. En effet, une chaine complète sera utile pour des entreprises développant principalement en interne : elle est un outil indispensable pour développer vite, avec les bons outils de sécurité intégrés à la chaine. Dans le cas de développements externes, le principe est différent et la sécurité moins « facile » à contrôler : les agences ne donneront pas forcément accès à leurs chaines ou à leur code source. Elles pourront se contenter de livrer des exécutables ou des images, via des dépôts distants par exemple. Intégrer la sécurité se fait donc par des moyens détournés et plus traditionnels : via des Plans d’Assurance Sécurité (PAS) par exemple, ou alors en obligeant contractuellement les agences à former leurs développeur.euse.s en sécurité applicative, via des solutions logicielles de formation (par exemple CodeWarrior, qui délivre des « ceintures » en fonction des niveaux de formation atteints).

Ensuite, une des idées les plus importantes est que la chaine se construit par étapes. Dans la lignée du « test and learn » cher aux méthodes Agile, une version « pilote » de la chaine peut être déployée pour une équipe produit volontaire pour la tester sur quelques semaines/mois. Le déploiement se fait ensuite progressivement, selon une feuille de route préétablie. Dans la plupart des cas rencontrés, les entreprises mettent d’abord en place une chaine DevOps, avec quelques outils d’analyse de code (le plus souvent orientés qualité), puis, une fois que la chaine est considérée comme fonctionnelle, les outils de sécurité y sont rajoutés.

Cependant, il pourrait être intéressant de considérer les outils de sécurité comme partie intégrante de la chaine CICD. Ils pourraient ainsi y être intégrés au fur et à mesure, selon une feuille de route priorisée, comme proposé ci-après.

Voici quelques exemples d’outils constituant la brique sécurité :

Figure 2 – Exemples de solutions de sécurité à intégrer à la chaine CICD (DevSecOps)

D’après nos retours d’expérience terrain, certains outils sont plus « simples » à mettre en œuvre et donc implémentés en priorité.

Outils SAST (Static Application Security Testing)

Comme évoqué précédemment, ces outils sont presque toujours déjà présents dans la chaine initiale, dans leur format de test de la qualité du code. Il s’agit ici de les configurer pour aller un cran plus loin et faire de l’analyse sécurité du code statique. Ce type d’outil peut être intégré à plusieurs endroits de la chaine, dans une logique de « shift-left », c’est-à-dire d’intégration de la sécurité au plus tôt dans la chaine. Il peut être positionné directement sur les IDE (integrated development environment) des développeurs, afin de leur faire des retours « en temps réels » sur les erreurs pouvant introduire des vulnérabilités. Il peut également être utilisé au moment de la compilation du code.

Un inconvénient de ce type d’outils est le nombre assez élevé de faux positifs en résultat. La configuration est évolutive et s’améliore avec le temps. Cependant, la gouvernance et les processus autour de l’outil doivent être pensé en amont : une équipe de triage des vulnérabilités peut être une solution ; la formation des Security Champions à repérer les faux positifs également, avec l’aide d’expert en sécurité applicative (un Application Security Engineer par exemple).

Outils SCA (Software Composition Analysis)

Ces outils devraient logiquement être installés en priorité, les développeurs faisant une grande consommation de bibliothèques open source pour développer leurs produits. Le SCA va vérifier les composants de la bibliothèque, tels que les licences, les dépendances, les vulnérabilités et potentiels exploits. Plusieurs attaques trouvent en effet leur origine dans une utilisation non contrôlée des librairies open source pouvant contenir des vulnérabilités critiques (comme le Log4Shell exploit).

Cet outil peut être utilisé comme le SAST, sur les IDE ou avant la compilation du code.

Outils DAST

Les outils DAST analysent les builds applicatifs en cours d’exécution à la recherche de vulnérabilités de sécurité. Ils permettent la simulation du comportement d’un attaquant malveillant à travers des pentests automatisés et détectent des vulnérabilités de sécurité usuelles telles que les OWASP 10. Ces outils peuvent être moins facile d’utilisation en mode authentifié (l’authentification est difficile en mode automatique, elle doit être effectuée manuellement avant de lancer un test). Les tests prennent aussi plus de temps qu’un scan statique, et des plages doivent être dédiées pour ne pas perturber le travail des développeurs ou la production.

Ils peuvent être utilisés au moment des tests, mais aussi en production.

Il faut penser très tôt à la gouvernance et aux processus à mettre en place autour de ces outils, en s’assurant notamment que les développeurs ne puissent pas passer outre les vulnérabilités détectées (en les passant en « faux positif » par exemple) et d’assurer une centralisation des vulnérabilités dans un outils unique (outil de vulnerability management par exemple), pour plus d’efficacité.

Vérification de la présence des prérequis techniques facilitateurs

L’intérêt de travailler en DevSecOps peut être limité sur des applications de type progiciels non configurables et non instanciables.

Côté infrastructure, l’Infrastructure as Code (gestion et provisionning de l’infrastructure via le code plutôt que via des processus manuels), l’utilisation de containers ou de VM provisionnées permet d’utiliser les chaines CICD de façon plus efficace.

Sans oublier toute la couche de gouvernance et de conduite du changement autour du projet

Il faut s’assurer de construire, ou d’avoir déjà, un modèle opérationnel répondant aux besoins (security champions, enabler teams, outillage, processus). Travailler en mode « agile à l’échelle » n’est pas obligatoire sur les premières itérations (en fonction du périmètre choisi).

Utiliser une méthode de « test and learn » cadrée pour expérimenter est un bon moyen d’impliquer les équipes très tôt, et d’avoir des retours terrains complets et pertinents, avant de commencer le déploiement à l’échelle. Des expérimentations de cybersécurité ont été menées chez des clients, pour savoir quels types de pratiques ou d’outils mettre en œuvre. Quelques exemples :

• Purple teaming, permettant aux développeurs de voir les résultats des outils de tests d’une autre équipe et de tenter de les exploiter (permettant aux développeurs de se rendre compte de la réalité d’une attaque et de la potentielle facilité à la mener à bien),
• Mise en œuvre de solutions comme Cloudbees, pour l’automatisation des processus de la chaine CICD,
• Formation de Security Champions à l’interprétation des résultats des outils de sécurité.

Ces expérimentations font également office de conduite du changement, puisque la plupart des parties prenantes peuvent être impliquées très tôt dans le programme de transformation.

En conclusion

Les chaines CICD sont une véritable opportunité pour la sécurité de s’automatiser. En intégrant les bons outils dans la chaine, les développeurs sont encadrés dans leur pratique, lancé sur des véritables « guardrails » de sécurité, facilitant la production d’un produit sécurisé.

Au-delà de sécuriser les produits, il s’agit aussi de sécuriser la chaine elle-même, au même titre que tout composant ayant de larges accès sur le système d’information : il s’agit de contrôler les accès sur les différents outils qui la composent, s’assurer de la bonne gestion des secrets, du durcissement des serveurs sous-jacents, etc.

Dans un prochain article, nous détaillerons nos convictions sur les piliers du DevSecOps, ou comment réussir une transformation durable et efficace (à base de shift-left, de guardrails et de responsabilisation des équipes sur la sécurité !).

Des commentaires, des corrections ? N’hésitez pas à nous contacter !

Cet article Sécurité dans l’agilité et DevSecOps : des destins liés ? est apparu en premier sur RiskInsight.

Historiquement l’approche Agile est un ensemble de pratiques utilisées pour des projets de développement informatique.  

Le Manifeste publié en 2001 propose 4 grandes valeurs pour révolutionner la performance des entreprises : 

Ce point d’honneur mis aux interactions humaines entre équipe de développement et acteurs métiers vise à réduire le time to market des produits ainsi développés, par opposition à des projets menés en cycle en V qui une fois livrés, et pour caricaturer, ne correspondaient plus aux attentes du métier qui avaient eu le temps d’évoluer.  

Aujourd’hui cette pratique est appliquée dans la majorité des entreprises à tous les niveaux. Dans le dernier State of Agile Report, sur plus de 4000 entreprises interrogées dans le monde, 95% déclarent utiliser l’agile et 65% d’entre elles le pratiquent depuis au moins 3 ans.  Par ailleurs au-delà des domaines IT, la méthodologie est aussi utilisée dans les directions marketing, ressources humaines, ventes ou encore finances. 52% des entreprises sondées déclarent qu’au moins la moitié des directions de leur entreprise travaillent en agile. C’est un réel passage à l’échelle qu’il ne faut pas louper.  

Au-delà d’une méthode de management de projet c’est une nouvelle philosophie avec des éléments gamifiés. On ne parle plus de réunion mais de cérémonie et de rituel, et de nouveaux rôles apparaissent (product owner et scrum master par exemple). Le souhait est réellement de créer une ambiance de co-construction et d’utiliser au maximum l’intelligence collective pour améliorer les performances de l’entreprise. 

Concernant la sécurité, bien que sous-jacente à la pensée des auteurs du manifeste, ils ne donnent pas plus d’indications que cela pour l’intégrer aux produits. L’intégration de la sécurité dans les projets (ISP) à la mode « cycle en V » n’aurait pas de sens dans un produit Agile ; l’ISP (le « P » pour « produits » cette fois) doit donc se réinventer.  

Quels sont les défis et tendances du domaine ?  

Un de nos défis est d’apporter à nos clients une vision globale de la problématique. Réussir à passer d’une approche traditionnelle à une approche agile nécessite plusieurs niveaux de réflexion pour la sécurité (et d’autres équipes support, telle la qualité, peuvent également être amenées à évoluer en ce sens). Il faut penser organisation certes mais aussi outillage.  

En termes d’organisation, la SSI doit se repositionner comme un service au métier, pour retrouver une image de fonction support, et non plus de « gendarme ». Le rôle de Security Champion est créé : c’est un membre de la feature team (souvent un développeur) qui devient le point de contact privilégié des équipes SSI. Cela permet de recréer du lien avec chaque feature team tout en augmentant l’autonomie sur l’intégration de la sécurité. Cela ne se fait pas en un jour, et un certain nombre de formations doivent être créées et dispensées, pour repartager les enjeux de cybersécurité et de la connaissance (bases de la SSI, développement sécurisé, notamment). Au-delà des formations, cela passe aussi par l’instauration d’une Guilde Sécurité, regroupant experts SSI, Security Champion et toutes personnes intéressées à la sécurité, et permettant d’échanger de l’information sur les dernières actualités sécurité, les bonnes pratiques, mais aussi de partager les retours d’expérience terrain. Cette Guilde doit être outillée pour communiquer le plus simplement possible et pour capitaliser les informations (sur un wiki interne par exemple). 

En tant que référent sécurité, c’est à lui que les développeurs peuvent s’adresser en cas de questions, une fois que l’équipe SSI l’aura formé. Il a donc une casquette assez technique. Les experts SSI gardent leur rôle mais adapté à l’agile ; on va passer d’une relation de contrôle et d’audit à une relation de soutien au fil de l’eau, de facilitateur. Des audits peuvent toujours être réalisés (tests d’intrusion, sur demande de la feature team ou à l’initiative des experts sécurité). De l’outillage méthodologique doit aussi être disponible pour aider les Champions dans leurs tâches et cela passe notamment par la réécriture des risques au format conversationnel. Pour s’adapter à l’utilisation de User Story par les feature teams, l’équipe SSI pourra s’essayer à la rédaction d’Evil User Story, qui correspond à une action réalisée du point de vue d’un attaquant. Par exemple : 

En face de ces risques, des User Story Sécurité, proposant des solutions de remédiation face aux EUS, avec des critères d’acceptance prêts à l’emploi. Tout cela peut être intégré dans une baseline sécurité (également au format backlog, dans un outil de product management, comme JIRA par exemple), proposant un socle minimum de sécurité à intégrer dans les produits. 

Au soutien organisationnel aux équipes doit s’ajouter le soutien technique via l’optimisation de la chaine d’intégration et de déploiement continu (CI/CD) avec des outils visant à automatiser au maximum la sécurité, ce que l’on pourra appeler la Stack Sécurité ou Security pipeline : revue de code, scans de vulnérabilité, détection de secrets, sécurité de l’Infrastructure as Code, etc.).  Une attention particulière doit être porté à sa propre sécurisation, pour ne pas produire l’effet inverse… Dans une optique de shift left security, la sécurité est intégrée par défaut dans le produit, et ce dès le début. Elle adapte donc sa vélocité à celle de l’agile et permet de passer d’une logique de DevOps à celle de DevSecOps.  

Un autre rôle peut être créé, celui d’AppSec Manager. Il fait partie cette fois de l’équipe SSI et est un expert en sécurité logicielle doublé d’un expert de la Stack Sécurité. Il aide les développeurs à prioriser et remédier aux vulnérabilités remontées par la Stack. Il travaille en binôme avec le Risk Manager/Expert SSI, qui lui apporte la connaissance des risques associés au produit, ce qui permet une analyse plus fine des vulnérabilités à traiter en priorité. Tout cela participe à créer une culture de security by design. 

Les défis en mission ensuite sont de s’adapter au maximum aux spécificités client : côté secteur public les attentes et défis sont un peu différents. En effet les ministères sont en train de passer à l’agile mais se pose à eux la problématique des homologations de sécurité de l’ANSSI en neuf étapes. Ce processus s’intègre mal à la méthodologie agile et il faut donc trouver des biais d’adaptation. Une possibilité pourrait être de détailler une checklist de Release permettant à la feature team d’être autonome dans ses mises en production, en sachant quels éléments sont autorisés à passer en production, et lesquels doivent faire l’objet d’une vérification plus approfondie (via un go/no go du RSSI par exemple, ou des contrôles spécifiques).  

Quelles sont les attentes de la part des clients ? 

Les clients RSSI attendent d’être rassurées sur le fait que la sécurité en mode agile ne va pas leur faire « perdre le contrôle » sur la bonne mise en œuvre de la sécurité. Et le modèle que nous proposons responsabilise les feature teams, les outille, mais la sécurité garde le contrôle en centralisant les indicateurs de performance, en ayant la capacité de réaliser des contrôles aléatoires/en fonction de critères prédéfinis, via du bugbounty par exemple ou une enveloppe de jours de pentesters, à répartir sur les différents produits. 

Ensuite, en tant que cabinet de conseil, je pense que les clients attendent de nous le partage de convictions et d’exemples très concrets de ce que nous avons pu réaliser chez d’autres clients. Pour répondre à cette demande, la practice cybersécurité et confiance numérique de Wavestone a créé un certain nombre d’accélérateurs méthodologiques grâce à des retours terrains, prêts à être partagés pour être déconstruits et adaptés. Pouvoir mener nous-aussi la mission en mode Agile fait également partie des attentes, en favorisant la co-construction plutôt que d’apporter des livrables figés et quasi finalisés dès le premier jet. Dans cette optique de gamification chère à l’agile, nous proposons des ateliers de co-construction originaux basés sur l’intelligence collective, grâce à notre asset Creadesk, qui forme les consultantes et consultants et met à disposition des outils de travail collectif à distance. 

Un dernier conseil pour les lecteurs ?  

Mettre en place une véritable démarche en mode test & learn est capital. Co-construire des outils est une chose, mais les tester et les vérifier sur le terrain en est une autre. Anticiper les problèmes est possible jusqu’à un certain point, mais les confronter directement (et les résoudre !) au fur et à mesure représente une valeur ajoutée énorme en mission. Cela permet d’être au contact des métiers et des feature teams directement, de leur montrer que des actions concrètes sont mises en œuvre. La démarche est agile, souple et évolutive. Les accélérateurs, les méthodologies et les outillages proposés évoluent au cours des pilotes et n’en deviennent que plus pertinents pour la deuxième vague de pilotes, jusqu’à ce que toutes les feature teams soient intégrées. 

En parallèle, il faut retenir que la conduite du changement est primordiale. Il faut prévoir un vrai plan de communication, construire les communautés de pratique/les guildes dès les débuts des pilotes, identifier des early adopters qui seront des moteurs précieux du changement au sein même des équipes. L’agile a un impact réel et rapide dans la vie de tous les jours et à tous les niveaux d’équipe : accompagner ce changement est primordial.   

Cet article La sécurité dans l’agile, interview d’Emma Barféty est apparu en premier sur RiskInsight.

Cette méthode a bouleversé les façons de travailler des équipes produits et des équipes SSI, mais il ne va pas s’agir de « juste » adapter l’homologation RGS du cycle en V à l’Agile, mais bien de proposer une solution adéquate pour répondre à l’objectif de l’homologation : « trouver un équilibre entre le risque acceptable et les coûts de sécurisation, puis faire arbitrer cet équilibre, de manière formelle, par un responsable qui a autorité pour le faire[3] ».

Une solution : l’homologation provisoire et l’homologation ferme

Comme l’a déclaré un célèbre expert Sécurité Agile de Wavestone : « l’Agile et les homologations, c’est pas sorcier ». Sans nier les débats d’experts et les difficultés, l’approche reste assez simple à expliquer. Face à des équipes qui doivent livrer plus vite et mettre en production en continu, il faut que les niveaux de risques et donc l’homologation suivent le rythme.

Que doit prendre en compte l’homologation ?

Comme toute homologation traditionnelle, il s’agit de présenter le niveau de risque à une Autorité d’homologation, qui acte le fait que ce niveau est acceptable au regard des critères SSI de l’organisation (nombre d’EUS présentes sur le projet par exemple, pourcentage des règles de base de la PSSI ou règles d’hygiène appliqué pour un périmètre donné, etc.) et prend la responsabilité des éventuels risques résiduels.

Par exemple, un projet à ses débuts, qui souhaite mettre à disposition quelques fonctionnalités à peu d’utilisateur, présentera un niveau de risques moindre, dû à sa faible exposition, malgré un périmètre peut-être encore peu sécurisé. Une homologation provisoire (d’une durée de quelques mois par exemple) peut être prononcée pour permettre l’expérimentation, à renouveler lorsque certains critères de renouvellement (définis à l’avance) sont atteints.

Figure 1 – Exposition au risque résiduel d’un produit
Tiré du Guide ANSSI : Agilité et Sécurité Numériques, octobre 2018 (lien vers le guide)

Pour un projet en rythme de croisière, accessible à son public cible avec toutes les fonctionnalités attendues, une homologation ferme (3 ans par exemple) est prononcée. Les critères de renouvellement, menant à la prononciation d’une nouvelle homologation sont également définis à l’avance.

Quand renouveler une homologation ?

Bien que les critères de renouvellement soient très contextuels, voici des pistes de réflexion (en volume et degré d’exploitation du projet).

Pour l’homologation temporaire, elle est valide jusqu’à ce que des critères de renouvellement soient identifiés :

• De nouvelles fonctionnalités critiques sont ajoutées (à définir par le projet),
• Un nouveau palier de nombre d’utilisateurs est franchi (défini à l’avance, en fonction des risques associés),
• De nouvelles données à caractères personnel doivent être intégrées et traitées par le projet,
• De nouvelles fonctionnalités liées à des paiements doivent être implémentées,
• Un nouveau palier de volume de transaction est dépassé,
• Et bien sûr quand la date limite de l’homologation est atteinte.

Pour l’homologation ferme, la validité de l’homologation est plus longue, sur hypothèse que moins de changement seront apportés au projet. Cependant, et toujours dans une optique d’amélioration continue, la vérification des niveaux de sécurité sera réitérée à intervalles réguliers (tous les 3 ans par exemple).

Quels éléments de preuve doivent apporter les squads ?

Les squads doivent normalement être en mesure de présenter différents éléments de preuve à l’Autorité d’homologation/responsable de l’homologation. Les Evil User Stories (EUS) font office de risques, avec leur priorisation qui donne un élément de compréhension sur leur gravité. Nous avions détaillé dans un article précédent la manière de mener à bien ces ateliers d’analyse des risques en Agile. Un extrait du backlog peut apporter la preuve que les EUS principales ont bien été traitées et que les EUS résiduelles sont connues (et par extension, doivent être acceptées par l’Autorité d’homologation).

Le Passeport Sécurité (détaillé dans notre article sur la transformation Agile) est également un moyen pertinent de suivre les niveaux de sécurité d’un projet.

Les rapports des outils de revue de code et de scan de vulnérabilité peuvent également être utilisés (pour les squad ayant intégré le DevSecOps et possédant également les outils adéquats).

Si l’équipe X-team existe (voir notre article sur les nouveaux rôles SSI dans l’Agile et l’organisation associée) ou si une équipe d’audit externe a pu les réaliser, les rapports de test d’intrusion sont également présentés.

Tout autre document existant et nécessaire peut également être présenté (document d’architecture par exemple, réglementation applicable…).

Pour l’homologation temporaire, ces éléments de preuve ne doivent pas forcément faire l’objet d’un « dossier » hors-sol ; il faut surtout s’assurer qu’ils existent bien et sont accessibles aux acteurs de l’homologation (Autorité d’homologation ou son délégué, équipe SSI…).

Qui sont les acteurs du processus ?

Pendant tout le développement du produit, le Security Champion (cf. la définition dans cet article) est garant de la bonne mise en œuvre de l’évaluation des risques via les ateliers d’identification des Evil User Stories et des Security Stories associés. De manière assez naturelle, l’équipe SSI est actrice du processus d’homologation, via l’expertise apportée aux équipes, notamment lors de ces ateliers.

Le Product Owner est responsable de la bonne création et mise à jour des éléments de preuve nécessaire à l’homologation. Il s’assure également que l’équipe SSI est bien tenue informée du bon déroulement de l’homologation et qu’elle est sollicitée si besoin.

L’Autorité d’homologation est, comme toujours, un responsable métier (par exemple le Business Owner) capable d’accepter les risques résiduels et de valider les niveaux de sécurité des produits. Cependant, et toujours dans une optique d’amélioration des temps de traitement, la signature d’une homologation temporaire pourra être déléguée au Product Owner, en tant qu’émanation du métier, pour peu que les critères nécessaires à la validité de l’homologation soient bien respectés. Dans les cas où le projet ferait porter un risque à d’autres métiers ou à d’autres systèmes, la responsabilité de l’homologation devra être portée en transverse, par un N+1 commun. Si aucun compromis n’est trouvé, c’est le Directeur des Systèmes d’Information (DSI), dans son rôle de garant du maintien en conditions opérationnelles des SI, qui assumera la responsabilité.

Ainsi, l’homologation conserve toute son importance, et notamment dans le cadre de la méthodologie Agile qui fait évoluer la manière de travailler des équipes produit. Les équipes SSI doivent profiter de ces évolutions pour se (re)projeter dans ces équipes (à travers le Security Champion et à travers la formation des équipes à la sécurité) et ainsi œuvrer à la réduction incrémentale du risque.

Plus d’articles à venir sur la Sécurité dans l’Agile, restez à l’écoute !

[1] Guide ANSSI : Agilité et Sécurité Numériques, octobre 2018 (lien vers le guide)

[2] Pour les administrations : décret n°2010-112 du 2 février 2010, modalités du Référentiel général de sécurité (RGS). Pour tout produit traitant d’informations relevant du secret de la Défense nationale : l’Instruction générale interministérielle 1300. Pour les opérateurs d’importance vitale : volet cyber de la LPM (loi n° 2013-1168 du 18 décembre 2013 – article 22), pour le renforcement de la sécurité des sys­tèmes d’information critiques qu’ils exploitent, mené dans le cadre d’une démarche d’homologation.

[3] Guide ANSSI : L’homologation de sécurité en neuf étapes simples, août 2014 (lien vers le guide)

Cet article Homologation Sécurité et Agilité Numérique : c’est possible ! est apparu en premier sur RiskInsight.

Les méthodologies Agiles se généralisent au sein des organisations et les équipes de sécurité doivent désormais s’adapter pour s’intégrer au nouveau modèle opérationnel.   

Mais lors de la mise à l’échelle de la sécurité, passant de quelques projets Agile à accompagner à une centaine, la rareté de l’expertise en sécurité devient un frein majeur (il est estimé qu’il manquera 350 000 experts en cybersécurité d’ici 2022). La conséquence ? Les équipes sécurité, surchargées, et ne pouvant accompagner toutes les Feature Teams, doivent donc parfois se résoudre à mettre en production de nouvelles fonctionnalités en fin de sprint, sans revue de sécurité.  

Ainsi, pour accompagner cette transformation, les équipes du RSSI doivent revoir en profondeur leur modèle de fonctionnement pour être présentes et garantir un bon niveau de sécurité. Cela implique de revoir leur organisation, leur processus et leurs outils.  

Comment réaliser concrètement cette transition ?

Définir les nouveaux rôles SSI pour une transition vers un nouveau modèle opérationnel

Il faut d’abord comprendre les différents rôles que la sécurité doit jouer dans le nouveau modèle opérationnel, pour soutenir ce passage à l’échelle : 

• La Guilde sécurité : afin d’assurer la diffusion du savoir entre les équipes, il est important de construire une communauté de personnes qui ont une appétence sécurité pour les aider à partager les bonnes pratiques. Cette communauté de Security Champions, dont la description est au paragraphe suivant (et de toutes personnes intéressées par les sujets de sécurité), doit également permettre d’enrichir un cadre de référence commun sur les méthodologies (KM sécurité, Evil User Stories, Security Baseline, contrôle de niveau 1, explicités dans notre article précédent).

• Le Security Champion : c’est l’ambassadeur sécurité au sein des Feature Teams. Il fait partie intégrante de la Feature Team et est présent à chaque sprint planning. Son rôle est de s’assurer que la sécurité est bien prise en compte à chaque sprint dans le développement des User Stories. Le Security Champion peut être issu du monde des développements, et monter en compétence sur les sujet sécurité, avec l’aide de la Guilde et de l’Enabler Squad.

• L’Enabler Squad : dans le modèle de Spotify c’est le moteur des Guildes ; un groupe de personnes issus de l’équipe du RSSI qui va accompagner la Guilde Sécurité tout en bâtissant des méthodes, des processus, des produits, des services et des standards de développements qui vont permettre aux Security Champions de gagner en autonomie. Lors du démarrage de l’appropriation du modèle, ils peuvent incarner le rôle de Security Champion, avant de pouvoir les former. Ils fournissent aussi de l’expertise sécurité sur les périmètres les plus critiques et/ou les équipes les moins matures.

• La X-Team (« cross team ») : si le rôle de l’Enabler Squad est d’assister les Feature Teams dans l’intégration de la sécurité, le rôle de la X-Team est de contrôler le niveau de sécurité et de garantir la couverture des risques. Elle réalise des tests techniques (tests d’intrusion, revues de code, etc.) ciblés. Evidemment, réaliser un test d’intrusion dans chaque Feature Team et pour chaque sprint n’est pas possible pour des raisons de charge. Ainsi, les tests seront réalisés soit par échantillonnage et aléatoirement (jouant ainsi le rôle de « Chaos Monkey » dans l’organisation), soit en se concentrant dans un premier temps sur les périmètres les plus sensibles et/ou les moins matures. En effet, dès lors que suffisamment de KPI sécurité seront remontés depuis les Feature Teams, la X-Team pourra aller contrôler de manière plus renforcée les équipes dont le niveau de sécurité dérive de la cible.

• Concernant le RSSI : le rôle évolue pour permettre d’opposer un veto si le niveau de sécurité du delivery de la Feature Team est jugé insatisfaisant (selon la X-Team ou selon un niveau « score sécurité » au niveau applicatif ou de l’infrastructure développé par l’équipe SSI). Il ne peut bien entendu être présent durant toutes les cérémonies Agile, et doit se reposer sur la Guilde Sécurité pour lui remonter les sujets d’arbitrage, où une décision stratégique doit être prise. Il peut néanmoins participer aux PI Planning et cérémonies peu fréquentes pour disposer d’une vision d’ensemble et pressentir les sujets et besoins qui nécessiteront un accompagnement renforcé. Des comités dédiés peuvent également être mis en place, permettant aux projets de s’inscrire pour faire arbitrer les sujets, avec appel au RSSI en cas de besoin d’arbitrage final. 

Comme dans toute conduite du changement, l’efficacité de l’acculturation réside davantage dans la pratique que dans la théorie. Il faut commencer petit pour initier une prise en main progressive du nouveau modèle opérationnel par l’équipe SSI. Il sera ensuite plus simple d’étendre son périmètre à toute l’entreprise. 

Faire : mobiliser des experts sécurité pour amorcer la transition dans 2 ou 3 Feature Teams

La prise en compte de la sécurité se veut continue. L’objectif est que les Feature Teams soient suffisamment matures et compétentes en matière de cybersécurité pour être autonomes dans leur gestion des risques. Mais dans une période intermédiaire, la présence d’experts sécurité dans une posture de service et d’accompagnement est un facteur de réussite pour faciliter la prise en compte de la sécurité dans les projets, en attendant que des Security Champions émergent dans toutes les Feature Teams. Ces experts sécurité doivent donc se répartir les périmètres prioritaires (projets critiques, Feature Team en difficulté au niveau sécurité…) et ne pourront pas accompagner tous les projets.  

L’objectif est d’amorcer la transition, d’utiliser les experts en sécurité de l’équipe SSI pour “faire” avec les équipes, apprendre en pratiquant et utiliser leurs connaissances pour constituer les premières briques des méthodes sécurité requis par les équipes Agiles. 

C’est à ce moment-là que les premiers outils et méthodologies nécessaires doivent être construits, utilisés et améliorés :  

• Le passeport sécurité : il suit le projet tout au long de sa vie (et au-delà). Il est initié dès le début d’un projet (au moment du PI Planning) pour en identifier la criticité, mettre en place et suivre les mesures de sécurité appropriées.

• La Security Baseline : c’est l’ensemble des règles et standards de sécurité de base, traduits de façon conversationnelle pour être intégrés facilement aux backlogs des Feature Teams, afin d’être traitées lors des sprints. Elles se présentent sous forme de Security Stories : 

Pour atteindre un niveau minimum de sécurité, les projets (standards ou peu sensibles) doivent au moins respecter cette Security Baseline. 

• Les formations à destination des futurs Security Champion  
  • Présentation de la fiche de poste, les rôles et responsabilités,  
  • Formation sur les EUS, Security Stories, grâce à la gamification chère à l’Agile. C’est ici que les Security Champions peuvent se familiariser avec le jeu de carte produit par Wavestone (nous vous invitons à aller lire cet article pour retrouver toutes les informations sur le Jeu de Carte Agile de Wavestone), 
  • Formation à la bonne utilisation du KM (partager les informations, faire vivre la communauté, connaître les référents…).

• La sécurisation des productions des équipes 
  • Mise sous contrôle les développements : formation au développement sécurisé, sécurisation du pipeline CI/CD, mise en place de contrôle sur le code produit, etc. 
  • Définition des règles de séparation des rôles et responsabilités en DevOps : mise en production, édition des tests, changement en production, etc. 

Un article plus complet sera dédié à cette dernière partie. 

Et ensuite ? Comment passer à l’échelle ?

Cette période intermédiaire, où les experts SSI ont été projetés dans quelques Feature Teams est clé, pour la construction des rôles, des outils et des processus.  

Une fois le modèle bien maîtrisé par les équipes SSI, il s’agit d’étendre la méthodologie à tout le périmètre agilisé.  

Communiquer

La célébration des succès des 2 ou 3 Feature Teams pilotes peut favoriser l’adoption par le reste du périmètre.  

Une fois que les premiers projets auront démontré l’intérêt de la démarche et que les outils et les méthodes seront développés, il s’agira alors d’étendre ces bonnes pratiques à l’échelle de l’entreprise. 

Former

Les experts sécurité pourront servir de coachs pour diffuser les pratiques au sein des Feature Teams qui se formeront au fur et à mesure.  

Une bonne solution est d’utiliser la moitié des experts en sécurité pour partager les outils et former les équipes. Cette moitié constitue naturellement la Security Enabler Squad. 

L’autre moitié peut ainsi rester concentrée sur la réduction des risques au niveau des périmètres critiques ou moins avancé, en tendant vers une montée en maturité suffisante des Security Champions des autres Feature Teams. 

Il faut aussi toujours assurer la communication autour de la transformation et l’animation de la communauté sécurité pour favoriser le passage à l’échelle.  

Contrôler et piloter la maturité des Security Champion

Enfin, une fois les Feature Teams formées à utiliser les outils et méthodes sécurité, les experts sécurité de l’équipe SSI peuvent concentrer leurs efforts sur le contrôle des versions importantes et le pilotage de la Guilde Sécurité. Il s’agit de faire vivre cet espace d’échange, de capitalisation et de partage, pour continuer la montée en maturité de toute la Guilde, et donc des Feature Teams. 

Combien de temps pour parvenir à agiliser complètement la sécurité ?

Les premiers retours d’expérience font état d’une transition de 3 ans, pour passer du début de l’état intermédiaire où l’équipe sécurité se projette dans les Feature Teams, jusqu’à une complète autonomie des Security Champions. Cela peut sembler long, mais le passage à l’Agile est bien plus qu’un simple changement de méthodologie, c’est un véritable changement de paradigme qui nécessite une conduite du changement, à la fois révolutionnaire et faite pour durer dans le temps. 

Dans les prochains articles, nous répondrons aux questions suivantes : 

• Comment assurer les contrôles de sécurité en Agile ? 
• 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 ? 

Cet article Comment structurer les équipes SSI pour assurer la prise en compte de la sécurité dans l’Agile à l’échelle ?  est apparu en premier sur RiskInsight.

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…

Cet article Comment conduire un atelier Cybersécurité agile ? est apparu en premier sur RiskInsight.