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.