Nous vous en parlions dans un précédent article, les équipes SSI doivent adapter leur organisation, leur processus et leur outillage pour assurer une prise en compte des enjeux de sécurité continue.
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 ?
