Lean IT : Cybersecurity Always

Pris dans nos sujets de flux et de delivery, je n’avais jamais envisagé appliquer le Lean sur des processus aussi complexes que ceux de la cybersécurité. Et pour dire la vérité, j’avais hâtivement identifié ce sujet comme étant un peu loin d’une valeur client sonnante et trébuchante.

A bien y réfléchir, un vieux dicton du Lean est Quality First, Security Always et, durant les premières années de ma pratique du Lean je voyais davantage ce levier Sécurité comme celui de la sécurité psychologique des collaborateurs. Aujourd’hui, l’évidence me saute aux yeux, en partie grâce à un dynamique RSSI (Responsable Sécurité des Systèmes d’Information) avec qui j’ai la chance de travailler depuis plusieurs années chez un client. Ce dicton pourrait ainsi se traduire dans le Lean IT par Quality First, Cybersecurity Always.

Au cours des 10 dernières années, les attaques de cybersécurité ont explosé et sont devenues une véritable industrie criminelle. Le coût estimé des attaques cyber sur les entreprises françaises est ainsi passé de 5 à 100 milliards d’euros entre 2016 et 2024 tandis qu’entre 50 et 60% des PME ayant subi une attaque cyber mettent la clé sous la porte dans les 18 mois.

Les RSSI n’ont pas toujours eu une bonne presse. Si lors de l'avènement du numérique et du focus sur la vitesse, ils ont parfois pu être jugés comme un obstacle à la rapidité des expérimentations (je n’étais pas le dernier à adopter cette posture), aujourd’hui ils sont des acteurs incontournables d’un SI sain et inspirant confiance. Cette évolution de perspective sur les RSSI est d’ailleurs au cœur de l’ouvrage clé de DevOps (The Phoenix Project) dans lequel le RSSI initialement perçu comme un obstacle devient graduellement un acteur clé de l’approche DevSecOps.

Maintenant que nous disposons, parmi nos belles histoires, de sujets liés à cette discipline, nous souhaitons vous en partager quelques-unes afin de montrer comment le Lean permet là encore d’obtenir des résultats significatifs sur des processus que, à ma connaissance, l’agile ou le Lean IT n’ont pas trop loisir d’explorer. Une autre vertu du Scaling Kaizen : la multiplicité des sujets traités chaque saison permet de démultiplier les apprentissages. Nous vous en proposons deux ci-dessous.

1. Accélérer la sécurisation des sites industriels

Nous sommes chez un acteur majeur des Energies & Utilities hexagonal. Cet acteur dispose de nombreux sites industriels (usines) qui doivent monter d’un niveau en termes de sécurisation des systèmes d’information.

Un projet a été lancé pour mener ces sécurisations mais les premières étapes se sont avérées laborieuses et rapidement ensevelies sous la complexité du sujet :

1. complexité organisationnelle : la gestion de projet classique qui pilote des dates plutôt que ce qui est terminé ;
2. volume et typologie des sites : plusieurs centaines, sur l’ensemble du territoire français, de typologie différentes ;
3. complexité des sites industriels : plusieurs usines impliquées, parfois difficilement accessibles pour le renouvellement de la connexion réseau ;
4. acteurs et parties prenantes : non seulement l’IT et les métiers sont impliqués mais aussi les acteurs régionaux, les opérateurs TelCo, les personnels des usines (pour qui cela ne fait pas partie de l’opérationnel quotidien) etc …

Aussi, le pilotage projet standard n’a pas su avancer sur le sujet au rythme attendu par la direction (sujet en visibilité ComEx).

Plusieurs centaines de sites sont concernés et au moment où démarre ce projet Lean (mois de mai), un seul site industriel a été passé au bon niveau de sécurité depuis le début du programme (en janvier de la même année). L’objectif donné par la direction est d’avoir sécurisé 50 sites à la fin de l’année.

Comprendre le processus

Dans un premier atelier, nous travaillons sur le processus. L’objectif est d’avoir une vision partagée avec les acteurs de l’IT (équipe cyber, équipe réseaux, équipe informatique industrielle) pour comprendre les différentes étapes de sécurisation d’un site et essayer de comprendre où sont les difficultés et quels sont les délais à chaque étape.

Une fois ce processus mis à plat, on peut mieux identifier quelles sont les actions que l’on peut mener en parallèle en raison des différentes attentes. Nous parvenons ainsi à passer (sur le papier, avec cette nouvelle vision processus) à une durée de 12 semaines.

Nous identifions aussi rapidement une question Lean : comment pouvons nous mettre les BU régionales en situation de valider que la sécurisation est bien terminée. Nous construisons dans ce même atelier une check-list à destination des régions. Exemple de point de la check-list : les rendre autonomes dans la recette des nouveaux liens internet de la migration réseau avec leur capacité à identifier qu’il n’y a pas de non conformité remontée par la fiche de recette réseau.

Piloter le Build

Lors de l’atelier nous construisons aussi notre Obeya projet. Cette Obeya comporte la vision des sponsors (CIO et Directrice métier), la voix des clients (les BU régionales qui possèdent ces sites industriels) et les différents éléments liés à nos produits (pour aider à cette montée de niveau), nos indicateurs de performance (le nombre de sites migrés), et notre flux de production que nous décrivons dans la prochaine section.

Dans une première étape, nous identifions l’ensemble des actions de « Build » à mettre en œuvre pour pouvoir répondre aux enjeux de notre nouveau processus. Cela implique les trois équipes suscitées : cyber, réseau et informatique industrielle.

Nous nous donnons 6 semaines pour finir sur ces sujets qui vont ensuite faciliter la sécurisation des sites. Chaque semaine, nous nous retrouvons autour de notre Obeya virtuelle pour avancer sur nos deux thématiques : le build et la sécurisation de site. La partie build consiste à valider les solutions réseaux à installer dans ces sites, en les validant au plus tôt dans des sites pilotes.

En deux mois ces hypothèses d’architecture sont validées et il reste alors à nous concentrer sur l’activité principale : piloter la sécurisation des sites.

Piloter la production du programme

La grande difficulté de cette mission est que la sécurisation des sites n’est pas menée par l’équipe centrale mais par les équipes terrain. Le rôle de l’équipe centrale est donc principalement d’accompagner ces dernières pour rendre le travail terrain le plus clair et simple possible : voilà en partie la raison des efforts sur la partie Build.

Et, dans un second temps, l’objectif est d’accompagner les différentes BU afin de se donner des objectifs et les piloter. Avant cet accompagnement, le pilotage consistait à suivre l’avancement des sujets des différents sites en cours. Nous étions donc sur un flux poussé. Nous pilotons cette production sur deux tableaux.

Pilotage de la production

Un premier tableau liste les sites à migrer par semaine (colonne) et par BU (ligne).

Ce tableau donne aussi la vision de ce qu’on avait prévu et ce que nous sommes parvenus à sécuriser. Le nombre de personnes disponibles en support réseau est ajouté car il est structurant pour l’organisation de cette sécurisation, en particulier dans les premières semaines durant lesquelles nous éprouvons et standardisons notre processus en fonction des difficultés rencontrées : le rôle des experts réseau est alors essentiel en termes de support.

L’objectif d’avoir 50 sites sécurisés, à la fin de la première année de ce programme, tend à intimider l’ensemble des BUs.

Il nous reste une quinzaine de semaines avant la fin de l’année. Avec la vision flux tiré, le rythme moyen est d’avoir un peu plus de 3 sites migrés par semaine. Avec 9 BU cela signifie que chaque BU migre un site toutes les 3 semaines.

D’un seul coup, ramené à une vision concrète et hebdomadaire, l’objectif de 50 sites sécurisés dans l’année pour l’entreprise semble moins intimidant pour l’équipe centrale et les BUs.

Pilotage du flux

Un deuxième tableau nous aide à piloter l’avancement des sites suivant les étapes nécessaires à la sécurisation. Il nous permet de prendre des décisions informées quant aux choix des sites pour chaque semaine par BU. En outre, chaque ticket représente le nombre de sites concernés sous l’intitulé d’un site. En effet un site peut être unique ou composé de plusieurs unités, ce qui rend la sécurisation de cet ensemble plus complexe. Cette vision simple (site unique) ou complexe (sites multiples) nous aide aussi à construire notre « mix produit » en équilibrant la charge hebdomadaire avec des sites simples et complexes.

Animation du suivi hebdomadaire

Chaque semaine l’ensemble de l’équipe centrale se retrouve afin de piloter cette production de sites sécurisés.

Dans un premier temps, nous regardons le nombre de sites qui a été sécurisé la semaine précédente. Sommes-nous à l’objectif ? Si nous n’y sommes pas, pour quelle(s) raison(s) ? A quelle étape du processus ? Est-ce un problème traité par notre standard ? S’il l’est, alors que s’est-il passé qui a conduit à ne plus suivre notre mode standard ? S’il ne l’est pas comment doit-on modifier notre standard pour qu’il soit capable de gérer cette typologie de nouveau cas ?

Ensuite, nous faisons une passe sur les sécurisations prévue la semaine suivante et on s’assure que tout va bien se passer en validant l’ensemble des pré-requis.

Enfin, nous passons sur le second tableau pour le positionnement des sites en fonction des macro-étapes de sécurisation. On part de la droite (sécurisation planifiée) et on parcourt l’ensemble des colonnes de l’aval vers l’amont pour voir les actions à mener pour faire passer trois sites chaque semaine à la colonne (et donc l’étape) suivante. L’objectif étant chaque semaine d’avoir trois sites en « finalisation planifiée » (avant dernière étape).

Pilotage des BU

En marge de ce point d’animation central, Antoine le chef de projet, anime sur un même rythme hebdomadaire un point de coordination avec les correspondants des BU. Il utilise pour cela les deux mêmes tableaux. Son objectif est de faire remonter les sujets qui ne sont pas à la main des BU pour pouvoir les discuter lors de notre point de pilotage central, et ou à la hiérarchie de la DSI pour arbitrage et support.

Résultats

Si, lors des premières semaines, l’équipe a bien évidemment du mal à livrer des sécurisations de site, les standards se renforcent et le processus devient plus fluide. L’équipe parvient même à accélérer pour finir sur un rythme très soutenu qui permet de rattraper le retard accumulé en début d’année et aboutir à 39 sites sécurisés à fin novembre.

Avec le Lean nous sommes passés de 4 sites livrés sur les 6 premiers mois, à 45 sites sur les 5 mois suivants : nous avons donc multiplié par onze la production du projet.

Enseignements

Avec cette mise en œuvre du Lean (et de l’Obeya) pour piloter ce projet, le chef de projet a appris à mieux accompagner les représentants des BU pour les engager à terminer les sécurisations de leurs sites. Cela nécessite de s’appuyer sur un travail de standardisation pour rassurer ces équipes qui ne souhaitent pas voir d’impact opérationnel au niveau de leurs usines.

Celui-ci nous confiera au terme de l’accompagnement que “On est parvenu à simplifier le pilotage et rendre les choses beaucoup plus simples avec l’Obeya”

La sponsor de la mission, de son côté, ajoute “L’approche a apporté une dynamique remarquable avec cette vision du nombre de sites à sécuriser chaque semaine. Cela a apporté de la cadence et surtout beaucoup de visibilité à l’ensemble de l’entreprise sur ce projet à visibilité ComEx.” * *

2. Améliorer le processus de traitement des vulnérabilités critiques

Contexte

Le sujet des vulnérabilités critiques est un des sujets phares de la cybersécurité. Celles-ci font l’objet d’un traitement spécifique de l’équipe de trois personnes impliquées dans ce Kaizen, l’objectif étant de les résoudre rapidement (moins de 72 heures). Ces vulnérabilités peuvent prendre la forme de : failles de sécurité dans des librairies open-source ; vulnérabilités d’injection SQL/XSS ; exposition de nouvelles URL, etc …

L’impact des vulnérabilités critiques est significatif, que ce soit pour les clients des solutions de l’entreprise (confidentialité et intégrité des données) ; pour les équipes de développement de solutions qui doivent interrompre leurs travaux en cours pour intervenir sur ces sujets ; et enfin pour l’entreprise pour lesquelles ces failles peuvent avoir un impact sur l’intégrité de ses données, sa réputation et son image. Cette réduction des vulnérabilités critiques est, en outre, un des OKR de la DSI.

Lorsque nous démarrons le Kaizen, l’équipe chargée de ce sujet au sein du domaine Cybersécurité nous explique que le plus gros obstacle dans le traitement de ces failles est qu’elles ne sont pas directement actionnables par cette équipe. En effet, ils doivent les remonter pour correction à différents interlocuteurs : les développeurs d’application de la DSI ; les intégrateurs ou éditeurs partenaires ; les filiales ou entreprises appartenant au groupe (filiales dont la DSI et donc l’équipe Cyber sont responsables de la sécurité).

Problème

Lorsque nous démarrons ce Kaizen, il reste 63 vulnérabilités critiques ouvertes avec un âge moyen de 70 jours. La durée moyenne de traitement des vulnérabilités critiques traitées sur les 6 derniers mois est de 29 jours et 54% de ces vulnérabilités ont été traitées en moins de 72 heures.

L’équipe se donne deux objectifs cibles : réduire de 50% le nombre de vulnérabilités ouvertes et avoir un SLA de 72 heures sur les nouvelles vulnérabilités critiques exposées.

Causes

Nous faisons une passe exhaustive sur les vulnérabilités ouvertes pour en identifier la typologie et comprendre les types de causes. Cette analyse permet d’identifier plusieurs cas :

1. Les interlocuteurs des applications ne sont pas identifiés ou connus. La DSI gère plusieurs centaines d’applications et certaines sont dans une zone grise pour ce qui est de la responsabilité. Il en va de même pour l’identification au niveau de la supervision de certains sites de l’administrateur du logiciel de sécurisation des accès applicatifs ;
2. Certaines applications sont en RUN et n’ont plus de développeur pour apporter les modifications nécessaires (typiquement une montée de version sur une librairie) ;
3. Des intégrateurs avec qui il n’y a aucune dimension contractuelle pour ce qui est du SLA des corrections de vulnérabilités critiques ;
4. Une API développée dans une démarche Proof of Concept, qui a été mise en production avec ce processus particulier, sans passer par une validation de l’équipe cybersécurité ;
5. Absence de suivi avec les différents domaines des sujets cybersécurité : les demandes de corrections/prise en charge sont envoyées par mail et, étrangement, ne sont pas traitées dans les temps (sourire) ;
6. Des vulnérabilités ont été résolues en environnement de développement et production mais n’ont pas été propagées sur les autres environnements (e.g. recette, pré-production).

Contre-mesures

Marjorie et Olivier, de l’équipe cyber, portent ce sujet et décident de lancer un certain nombre de contre-mesures :

• La première consiste à procéder à une classification Simple (moins d’un jour de résolution) / Complexe (2 jours ou plus de résolution) pour ce qui est de la correction nécessaire. Avec cette information, nous souhaitons encourager les interlocuteurs de l’équipe à une résolution rapide (simple) ou planifiée à l’avance (complexe) ;
• La seconde consiste à organiser un point hebdomadaire de 30 minutes sur le sujet de gestion de ces vulnérabilités avec les représentants cybersécurité des autres domaines et des intégrateurs. L’idée est de les engager pour la résolution des vulnérabilités dans le stock, mais aussi pour le bon niveau de réactivité sur les nouvelles vulnérabilités ouvertes. Bien évidemment, ce point est en complément des messages de notifications sur les vulnérabilités ouvertes sur un chat interne, car avec un pilotage hebdomadaire il est difficile de tenir le SLA de 72 heures. En outre l’équipe cyber demande un engagement de date aux représentants sur les différents problèmes ouverts ;
• Ce sujet étant en visibilité du CoDir de la DSI, le RSSI remonte chaque semaine en 15 minutes le statut et sollicite ses pairs directrices et directeurs de domaines afin d’obtenir des arbitrages lorsque nécessaire, et obtenir les contacts des personnes que l’équipe n’a pas su trouver ;
• Le document en ligne présentant la stratégie de gestion des vulnérabilités est mis à jour et diffusé à nouveau ;
• Les développeurs et tech lead suivent un webinaire d’information sur ce sujet : des échanges rapides ont montré qu’ils n’avaient pas connaissance du SLA de 72 heures ;
• Le chef de projet qui n’a plus de développeur sur son application (une petite application utilisée par une faible population dans l’entreprise) est accompagné par une experte technique cybersécurité pour monter de version d’une librairie gérant le protocole de sécurisation des données transmises sur son application, la builder et la réinstaller (un atelier d’une heure) ;
• L’intégration d’une nouvelle clause contractuelle pour la résolution des vulnérabilités critiques avec les intégrateurs et éditeurs concernés.

Résultats

Avec la mise en œuvre de ces contre-mesures, l’équipe est passée à de 62 à 34 vulnérabilités ouvertes au bout de deux mois. Le temps moyen de résolution est passé de 29 à 15 jours mais l’équipe n’est pas parvenue à augmenter le pourcentage de vulnérabilités traitées en moins de 72 heures (ils sont passés de 54% à 40%). Cela peut s’expliquer par la résolution des sujets qui étaient ouverts depuis plusieurs semaines.

Si ces sujets ravissent le CoDir, Marjorie et Olivier ne s’en satisfont pas. Ils décident de renouveler l’exercice et de faire une nouvelle boucle d’améliorations.

• Un nouveau job est créé sur l’outil de suivi des vulnérabilités pour permettre aux développeurs de valider que leurs corrections sont bien effectives sur l’ensemble des différents environnements ;
• Les équipes cyber sont notifiées instantanément par mail lors de la découverte de nouvelles vulnérabilités par l’outil utilisé ;
• Une nouvelle politique d’enregistrement DNS est définie et partagée qu’il s’agisse d’un site d’information, d’un Proof of Concept ou d’une nouvelle application ;
• Une séquence cyber-sécurité est intégrée dans l’accueil des Tech Lead et Chefs de projet. Ceux, déjà en poste, sont sensibilisés lors d’une réunion pour les informer des nouvelles procédures. La présentation de leur A3 est particulièrement éclairante pour donner du sens à cette présentation et se prémunir d’une éventuelle impression de lourdeur administrative.

Un mois plus tard, les résultats sont spectaculaires. L’équipe a encore réduit le nombre de vulnérabilités ouvertes de 34 à 5 (réduction de 80%) et le temps moyen de résolution des nouvelles vulnérabilités est de 3 jours (au lieu de 15 jours). Si seulement 33% des nouvelles vulnérabilités ont été traitées en moins de 3 jours, les 2 tiers restant l’ont été en 4 jours.

Enseignements

Comme pour le cas de la sécurisation des sites industriels, l’équipe responsable des vulnérabilités critiques a appris à mobiliser les différents acteurs sur le sujet : par de la communication bien sûr mais surtout par un pilotage hebdomadaire de la résolution de ces vulnérabilités.

De son côté, l’équipe managériale (le CoDir de la DSI) a appris à soutenir cette démarche, portée par l’équipe cyber mais aussi les équipes des différents domaines. Il s’agit du volet Teamwork du Toyota Way : faciliter la collaboration d’équipes différentes, sur un même flux de valeur critique pour l’entreprise et pour les clients.

Cybersecurity Always et esprit Kaizen

Pour ce qui est des coachs, l’enseignement principal est que le Lean s’est avéré particulièrement adapté pour traiter ces sujets d’une grande complexité, nécessitant une collaboration transverse.

En ce qui me concerne, j’ai aussi été particulièrement marqué par la détermination de Marjorie et Olivier qui ne se sont pas contentés des premiers résultats et ont pris l’initiative pour refaire une seconde boucle sur le Kaizen pour explorer des sujets qu’ils n’avaient pas eu l’opportunité de traiter dans le premier cycle de 8 semaines.

Comme le rappelle Masaaki Imai dans ses 10 principes du Kaizen : les possibilités d’amélioration sont infinies. Ce principe n’est pas tombé dans l’oreille d’un sourd pour ce qui est de nos deux protagonistes. On se rend alors compte qu’au delà de l’exercice de 8 semaines mené avec eux, l’équipe a complètement intégré l’esprit Kaizen et ne s’abandonne pas à la complaisance : Cybersecurity Always ! Indeed.