Les noms de Petya, Locky ou Waledac ne vous sont pas totalement inconnus ? Votre ordinateur a peut-être été infecté ! En effet, ces virus informatiques de familles différentes (rançongiciel cryptant les données et fichiers systèmes, ou botnet spam) sont classés dans le top 10 des plus importants de l’histoire de la cybersécurité.
C’est dans ce contexte favorable aux menaces et risques en tout genre, que les méthodes agiles se sont imposées pour permettre aux entreprises de rester concurrentielles et innovantes. Toutefois, il est rare de trouver nativement des items de sécurité dans la backlog. Les contraintes de sécurité tombent souvent à la suite d’audits ou autres contrôles internes douloureux. Les conséquences peuvent s’avérer très coûteuses et pénibles pour les équipes projet et équipes de production.
Comment peut-on alors associer agilité et sécurité informatique dans la pratique ?
L’omniprésence des risques de sécurité rend indispensable la prise en compte des éléments de sécurité dans les projets agiles, et ce le plus tôt possible. Mais quels éléments prendre en compte et à quels moments clefs des cycles itératifs agiles agir pour être au rendez-vous du marché ?
Loin d’être incompatibles, agilité et sécurité doivent être des leviers d’opportunités pour des livraisons de qualité et de valeur. Je vous propose un tour d’horizon pour réconcilier votre vision de l’agilité et votre politique de sécurité informatique en pratique, à la fois du point de vue d’une équipe agile et de celui de collègues bienveillants de la cybersécurité.
Pourquoi déconstruire l’image du RSSI gendarme ?
L’agilité, avant de se décliner en cadre de travail ou en méthode à appliquer, est un état d’esprit reposant sur les principes énoncés dans le manifeste agile (agile manifesto). Un de ses principes fondateurs est de « satisfaire le client en priorité ». Votre client ne peut être satisfait si votre projet n’a pas été validé, ou a minima revu, par un représentant RSSI (Responsable de la Sécurité des Systèmes d’Informations ou assimilé Business Risks Manager ou encore IT Risk Manager).
De même, on entend par « client » aussi bien votre commanditaire ou sponsor, que les utilisateurs finaux qui vont utiliser le produit ou le service à livrer. Il est alors primordial que la relation de confiance que vous souhaitez construire avec votre client, pour qu’il adhère à votre produit, soit aussi forte et valable que la relation que vous devez établir avec votre responsable sécurité. Dans le meilleur des cas, votre interlocuteur sécurité vous préconisera tout un plan d’actions (conformité au RGPD, politique de gestion des mots de passe, exigences des niveaux d’encryptions, etc.) avec la marche à suivre.
Dans le cas inverse, vous serez face à des bloqueurs qui rallongeront vos délais et votre budget, voire mettront en péril votre projet. Ce dernier cas est bien trop souvent répandu et encense l’image négative du gendarme et de la patrouille de sécurité qui sévit. Ici, un autre principe agile s’impose à vous en tant qu’équipe agile : « accueillir favorablement les demandes de changement ».
En pratique, faites de votre RSSI un allié avec une aura de sécurité bienveillante. Le terme RSSI est trompeur car votre interlocuteur ne sera pas tenu pour responsable si une menace se concrétise (fuite ou perte de données, cyberattaques, etc.). En effet, son rôle pourrait se résumer à analyser, à préconiser et à rendre un rapport de sécurité. Charge à l’owner et au sponsor d’endosser ou de faire accepter les risques encourus quant à l’urgence business et au cadre réglementaire. Pour se mettre dans de bonnes conditions et solliciter la sécurité, voici une préconisation de démarche douce pour réconcilier agilité et sécurité informatique auprès de toute l’équipe agile (y compris le product owner, le Scrum master et l’équipe de développement en mode Scrum).
Cybersécurité : comment rendre le terrain favorable ?
La backlog est constitué, les rituels sont en place et vous avez déjà commencé vos sprints. La démo arrive et vous êtes confiant.es : vous êtes en mesure de livrer les premières user stories de la backlog. Cependant, la livraison comporte des failles ou plutôt des points faibles. Légitime en démarche agile direz-vous. Mais pouvez-vous concrètement passer en production alors que, d’un point de vue fonctionnel, les parcours ne sont pas totalement conformes au RGPD et que, techniquement, la rétention, la redondance et les processus de service management n’ont pas été défini ? La question se pose et la réponse dépend grandement de votre cadre d’application.
N’ignorez pas les faiblesses de sécurité
Vous avez peut-être réussi à passer entre les mailles du filet jusque maintenant mais vous sentez bien que la patrouille vous rattrapera. Pourquoi ? Parce que vous n’avez pas appliqué la checklist des exigences standards de sécurité à votre projet en production (si vous travaillez pour une entreprise sérieuse et que vous ne sentez pas l’aura de la sécurité, le choc sera sans doute violent). Pas étonnant lorsque l’on voit cette fameuse checklist (encore faut-il qu’elle soit accessible facilement) : sécurité = alerte rouge. Tentons de comprendre les différents aspects de cette analyse nécessaire de sécurité.
Le projet est drivé par les délais et les coûts incluant la mesure des risques, sans les ignorer pour autant. L’erreur la plus grave serait de camoufler les faiblesses de sécurité du service ou du produit que l’on veut livrer. En ce sens, l’approche empirique de Scrum repose sur trois piliers : transparence, inspection et adaptation.
Cybersécurité : proposition d’une démarche non violente
Les cycles itératifs organisés en sprints consécutifs renforcent le sentiment d’urgence pour la livraison. Il faut livrer rapidement et régulièrement. Et en même temps, l’agilité exige un rythme constant et soutenable indéfiniment. La veille constante des risques de sécurité relève du ressort de la cybersécurité.
L’équipe agile doit donc aussi puiser régulièrement dans la maestria produite par l’équipe de sécurité pour s’imprégner de ses préconisations. Au même titre que la qualité, la performance et le design, la sécurité doit émerger dans la backlog de manière native. Pour qu’elle émerge concrètement, la sécurité doit s’inscrire dans la définition du done des user stories.
Cette démarche doit s’inscrire dans vos processus d’amélioration continue. Une proposition d’approche en trois étapes pour concilier agilité et sécurité : se former, s’évaluer, s’éveiller !
Stage #1 – Se former à la sécurité
L’échange est d’autant plus riche et pertinent lorsque les termes et les concepts sont connus et précis. Commencez donc par vous (toujours la dev team) former pour vous approprier l’étendue des aspects de sécurité. Vous vous êtes formés à l’agilité ? Alors enrichissez vos compétences avec des bases solides en matière de sécurité informatique.
À cette fin, en plus des recommandations de votre RSSI, vous pouvez vous appuyer sur l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information). Ce service à compétence nationale est une administration chargée d’assurer, au-delà de la défense et de la sécurité nationale, une mission de conseil auprès des entreprises et des particuliers. Consultez-le guide des bonnes pratiques de l’ANSSI.
Stage #2 – S’évaluer en cybersécurité
Les artefacts de l’agilité doivent être simples et compréhensibles. Il en va de même pour les artefacts de la sécurité. C’est peut-être là que le bât blesse car le formalisme courant des équipes sécurité rebute. En pratique, tentons de nous poser les bonnes questions le plus tôt possible, puis de manière régulière et transparente pour que la sécurité devienne un positionnement concurrentiel aux coûts maîtrisés.
Au niveau des entreprises, des normes existent pour se situer et évaluer son niveau de maturité, la norme internationale de référence étant ISO27001. Par exemple, au niveau de l’équipe, effectuez des autodiagnostics rapides en amont et entre les sprints pour vous assurer que le projet est en ligne avec la politique de sécurité de l’entreprise. De même, vous pourrez catégoriser la sensibilité du projet et l’exposition aux menaces, et adapter vos actions. Des questionnaires sécurité adaptés devraient vous être proposés par vos interlocuteurs et interlocutrices sécurité en fonction de votre contexte projet (SaaS, Clouds, implémentation hybride).
Stage #3 – S’éveiller à l’agilité
Oui s’éveiller au sens agile, s’éveiller continuellement, être alerte. Une formation solide sur la sécurité a dû vous sensibiliser au vaste aspect des menaces : malware, phishing, botnet, spam, troll, etc. L’entreprise constitue donc des bastions et des lignes de défense. La vigilance de chaque collaborateur est une première ligne de défense.
Dans les cycles itératifs agiles, il serait intéressant de tester la méthode de dual track agile, relativement récente pour les aspects design, appliquée à la sécurité. Peut-on insuffler des idées de sécurité dans l’innovation ? Pour des équipes qui ne considèrent la sécurité que comme une contrainte et non comme une source d’opportunités peut-être pas. Mais pour les autres ?
En attendant, cet éveil à la sécurité fait évoluer des profils vers l’agile. La ‘‘team’’ étant au cœur de l’agilité, il devient de plus en plus crucial de composer une équipe pluridisciplinaire (Product Owner, Scrum Master, Business Analyst, Data Analyst, etc.) avec l’esprit “security and privacy by design and by default”, ou « sécurité et protection des données dès la conception ». Issus des directives européennes en matière de RGPD (Règlement Général sur la Protection des Données), les organisations et les projets inhérents « sont encouragés à mettre en œuvre des mesures techniques et organisationnelles dès les premières étapes de la conception des opérations de traitement ».
Autres profils qui se transforment dans le bon sens en faveur de ce concept : le RSSI / DPO (Data Privacy Officer) bienveillant impliqué en amont et, surtout, les nouveaux DevSecOps dans l’équipe agile. Le mode DevOps (abréviation de Développement et Opérations) est une approche qui repose sur les principes agiles pour livrer vite et accélérer la prise en compte des retours utilisateurs dans le sprint de développement suivant. Une collaboration le plus tôt possible des équipes sécurité et agile permet ainsi d’intégrer les items de sécurité en vue d’en planifier l’automatisation. La sécurité est une responsabilité partagée au sein de la dev team qui doit être suffisamment autonome et autoorganisée pour prendre en compte les éléments de sécurité dans ses choix de conception aussi bien au niveau architecture, infrastructure et application. Le cadre DevSecOps contribue donc fortement à réconcilier agilité et sécurité en pratique pour les projets.
En faisant de la sécurité un thème intégré aux cycles itératifs agiles, l’agilité se réconcilie avec la sécurité dans la pratique. La démarche « se former, s’évaluer, s’éveiller » pour toute l’équipe de développement favorise une culture propice au DevSecOps. Avec la déconstruction de l’image rigide de la sécurité, c’est là une des clefs d’une réussite agile.
Sources et références
- Manifeste agile agilemanifesto.org
- Définition de la cybersécurité de Kaspersky : “une entité dédiée à protéger vos systèmes informatiques”.
- Top dix des virus ayant marqué l’histoire de supinfo 2016
- Guide des bonnes pratiques de l’ANSSI
- Norme ISO 27001 Information Security management
- Qu’est-ce que le DevSecOps ? Redhat.com
Pas encore de commentaires