if ( !emtpy($headline_subheadline ) ) : ?>
L’achat d’une nouvelle plate-forme brillante n’est pas une consolidation tant que vous n’avez pas désactivé les anciens outils, ce qui signifie demander aux personnes qui les utilisent ce qu’elles font réellement.
endif; ?>
Il existe un vieux fantasme de leadership qui ressemble à ceci : le RSSI examine un parc technologique tentaculaire, découvre 11 outils faisant le travail de quatre, calcule les économies de licences, sélectionne une nouvelle plate-forme stratégique brillante et déclare que la consolidation a commencé. Six mois plus tard, les 11 outils fonctionnent toujours. La nouvelle plateforme porte désormais le numéro 12.
J’en ai vu des variations tout au long de ma carrière, des services financiers aux médias en passant par les entreprises technologiques. Au sein du Groupe CME, j’ai fini par me donner un titre officieux : chef du démantèlement. Le travail était considérablement moins glamour que ne le suggérait l’acronyme. J’ai dû trouver une technologie qui avait dépassé sa durée de vie, identifier ceux qui pensaient qu’elle la possédait toujours, déterminer qui en dépendait réellement et, occasionnellement, lui mettre une balle dans la tête.
Acheter de la technologie est facile. Il est difficile de tuer la technologie. La prolifération des outils est rarement un simple problème technologique mais plutôt un problème de psychologie organisationnelle. La solution du secteur a traditionnellement été la consolidation. Achetez une plateforme. Standardisez la pile. Réduisez le nombre de fournisseurs et centralisez les achats. Bien que toutes les idées soient sensées, les efforts de consolidation stagnent régulièrement quelque part entre la diapositive PowerPoint et la production.
Pourquoi? Parce que changer d’ensemble d’outils est facile. Alors que changer les mentalités est bien plus difficile.
Vous ne pouvez pas tromper une équipe d’ingénieurs par l’esprit des Jedi
Les dirigeants aiment ce qu’on appelle le « message du sommet ». Le PDG affirme que la sécurité est importante. Le CIO dit que tout le monde va normaliser. Le RSSI annonce la plateforme stratégique. Les achats renégocient les contrats. Pendant ce temps, Gartner produit un quadrant qui rassure tout le monde sur le fait que le fournisseur choisi habite la bonne région géométrique. Tout va bien dans le monde du népotisme des terrains de golf.
Puis la réalité arrive. Un développeur affirme que le nouveau scanner prend 12 minutes de plus. Un responsable marketing dispose d’une API héritée génératrice de revenus dont il dépend. Des demandes d’exception sont déposées depuis plusieurs années pour permettre à cet outil de continuer à exister malgré que les packages le supportant soient en fin de vie et ne recevant aucune mise à jour de sécurité. C’est là que le « message du milieu » est important.
La transformation ne se produit pas exclusivement dans les salles de réunion et les équipes de fusion. Cela se produit au niveau des responsables de l’ingénierie, des architectes, des propriétaires de produits, des ingénieurs de sécurité et des responsables des opérations qui déterminent si la politique annoncée à l’étage devient le comportement pratiqué en bas. Chaque couche de l’organigramme essaie ostensiblement de faire la bonne chose et d’améliorer les choses. Mais les politiques descendantes et les initiatives ascendantes trouvent rarement un terrain d’entente.
Ignorez la couche intermédiaire de l’organigramme et votre projet de consolidation devient un exercice de mise en étagère plutôt coûteux. C’est quelque chose que j’ai appris en travaillant dans des organisations européennes, où la recherche d’un consensus a plus de poids organisationnel que les instincts de commandement et de contrôle courants dans les entreprises américaines (la philosophie de gestion inspirée de Nike « Just Do It ! »). Vous devrez peut-être prendre une décision sans posséder le contexte organisationnel (ou « le caoutchouc rencontre la route ») nécessaire pour la faire tenir ou mériter d’être mise en œuvre.
Les bons officiers de déclassement ont besoin d’un mélange de compétences Jedi et machiavéliques. Nous avons besoin de persuasion, de constitution de coalitions, d’incitations, de pressions sélectives et parfois de capacité à convaincre les gens que l’idée que vous avez désespérément besoin qu’ils soutiennent était leur idée depuis le début. Ce sont en fait les droïdes que vous recherchez.
Chaque outil a une identité
La métaphore de Star Wars devient plus utile lorsque l’on cesse de considérer les produits de sécurité comme des logiciels. Les outils de sécurité modernes ont une volonté et une intention. Ils ont:
- Clés API
- Comptes de service
- Octroi d’OAuth
- Autorisations cloud
- Jetons d’accès GitHub
- Intégrations CI/CD
- Bots Slack
- Webhooks
- Informations d’identification de la base de données
- Rôles Kubernetes
- Identités des machines et,
De plus en plus, les agents d’IA agissent avec une autorité humaine déléguée omniprésente et persistante.
Chaque fois que nous introduisons des produits de sécurité, nous créons un autre compte hautement privilégié. L’industrie parle sans cesse d’identité humaine. Qui est cette personne et à quoi est-elle autorisée à accéder ? Nous sommes décidément beaucoup moins disciplinés en matière de délégation d’identité. Qu’est-ce que cette application est autorisée à faire au nom de Mike ? Qu’est-ce que ce scanner est autorisé à lire depuis GitHub ? Quels référentiels cette intégration peut-elle modifier ? Quelles références avons-nous données à l’ancien fournisseur il y a trois ans ? Et la question de plus en plus importante : lorsqu’un agent autonome agit, quelle autorité exerce-t-il réellement ? Cela change l’économie de la prolifération des outils. Le coût du douzième outil de sécurité ne se résume pas à un simple abonnement annuel supplémentaire. Il s’agit d’une autre relation de confiance (potentiellement mal engendrée).
C’est pourquoi je préconise le déclassement comme discipline fondamentale en matière de sécurité. Les organisations technologiques souffrent d’un biais d’immortalité. J’ai donné une « session la mieux notée » sur ce sujet au RSAC au printemps. Nous disposons de processus sophistiqués pour créer des choses et de processus étonnamment primitifs pour les faire disparaître. Le cycle de vie du développement logiciel est généralement illustré par la planification, la conception, le développement, les tests et le déploiement. Le diagramme s’arrête souvent là, comme si chaque application déployée par la suite vivait heureuse pour toujours. Ce n’est pas le cas.
La consolidation sans déclassement est une multiplication
Je suis sceptique lorsque les fournisseurs promettent que la « plateforme » résoudra à elle seule la prolifération des outils. Une stratégie de plateforme peut tout à fait avoir du sens. Moins de fournisseurs peuvent signifier des coûts de licence inférieurs, moins d’intégrations et des données cohérentes avec moins de complexité opérationnelle. Mais l’achat d’une plateforme ne consolide rien en soi. La suppression des anciens systèmes le fait. Cela semble évident, mais de nombreuses organisations mesurent le succès d’une consolidation par les contrats signés plutôt que par l’élimination des systèmes.
Imaginez remplacer trois outils par une seule plate-forme, mais laisser les trois produits techniquement opérationnels « temporairement ». Les comptes de service restent. Quelqu’un s’y connecte toujours. Félicitations! Vous n’avez pas consolidé quatre outils en un seul, mais plutôt trois outils en quatre. Cette distinction devient importante à mesure que les produits de sécurité acquièrent des capacités autonomes. Le tableau de bord oublié d’hier devient l’agent oublié de demain avec la permission d’agir. Une application zombie est déjà assez mauvaise, mais une application zombie avec agence est pire.
Demandez aux personnes qui utilisent réellement les droïdes
L’antidote n’est pas un contrôle central plus fort mais plutôt une appropriation explicite. Beaucoup de matrice RACI ? Avant de remplacer un outil, recherchez les personnes qui l’utilisent et posez une question simple et embarrassante : « À quoi sert-il réellement ? » Ne demandez pas ce que dit le contrat. Ne faites pas confiance à ce que le diagramme d’architecture pourrait montrer (*vérifiez* la date de la dernière modification, cependant).
Prenez ce que croit le représentant de la réussite client du fournisseur avec un grain de sel et plus qu’un minimum de scepticisme. Qu’est-ce que les gens en font réellement le mardi matin ? Les responsables de la sécurité sont généralement surpris par la réponse. Peut-être que la principale valeur du scanner de vulnérabilités n’est pas l’analyse des vulnérabilités. Peut-être qu’une équipe d’ingénierie dépend d’une fonction d’exportation obscure pour ses mesures hebdomadaires. Peut-être que l’ancien SIEM a une règle de corrélation liée à une exigence réglementaire qui n’a pas été migrée. Vous trouverez ces choses si vous regardez.
C’est là que le milieu de l’organisation devient votre véritable réseau de renseignement. Les personnes les plus proches des systèmes savent où se trouvent les dépendances non documentées. Traités comme des obstacles et ils défendront leurs outils. Mais permettez-leur de participer et ils aideront à les démanteler. Une bonne perspective lorsque l’on envisage de tuer le bébé de quelqu’un est de l’aider à comprendre qu’il est tombé amoureux du contrôle que l’outil lui a donné sur le chaos qui régnait avant sa mise en œuvre. Et qu’un nouvel outil peut être tout aussi confortable et plus facile à prendre en charge que le fardeau des soins et de l’alimentation qu’exigent la plupart des applications et solutions « patrimoniales » (je préfère ce terme à « héritage »).
La propriété devrait inclure le pouvoir de recommander la retraite. L’un des indicateurs les plus sains qu’une organisation puisse créer : le nombre d’outils et d’intégrations qu’elle a réussi à éliminer cette année. Nous célébrons le déploiement. Pourquoi ne célébrons-nous pas la suppression ?
Le RSSI en tant que responsable du démantèlement
Chaque RSSI doit passer du temps en tant que CDO. Pas de directeur des données. Responsable du déclassement. Ce rôle nécessite de poser des questions inconfortables, car presque toutes les incitations technologiques encouragent l’addition. Personne ne reçoit de communiqué de presse ou de promotion pour avoir désactivé quelque chose. Mais la résilience est en partie soustractive.
Chaque fournisseur redondant supprimé représente une entreprise de moins détenant vos données et une console d’administration de moins qu’un attaquant peut cibler et pirater. Notre industrie dépense des milliards en se demandant : « Que devrions-nous déployer d’autre ? » Les organisations matures se demandent également : « Que pouvons-nous éliminer en toute sécurité ? Cette deuxième question devient beaucoup plus importante avec l’IA agentique.
Nous remplissons rapidement les entreprises de droïdes numériques agissant au nom des humains. Quelle que soit la fonction, presque tous nécessitent des informations d’identification et une autorité déléguée. Les organisations qui gèrent cette transition avec succès ne sauront pas seulement comment autoriser ces identités ; ils les feront pivoter et les révoqueront automatiquement. Le leadership a donc besoin à la fois d’un message venant d’en haut et d’un message venant du milieu. Le sommet établit la direction et le milieu fournit la réalité.
Faites participer les personnes qui font le travail à la décision. Assurez-vous que votre équipe de fusion chargée de consolider 77 tableaux de bord est composée de anciens dirigeants de la garde ainsi que de jeunes recrues. Efforcez-vous de comprendre les dépendances, les exigences fonctionnelles (aussi archaïques soient-elles) et les exigences non fonctionnelles telles que la disponibilité, l’intégrité et la confidentialité. Définissez à quoi ressemble une retraite réussie avant d’acheter le remplaçant.
Ne « bougez pas »
La prochaine fois que quelqu’un arrive avec une nouvelle plateforme miraculeuse promettant d’éliminer la moitié de votre stack, résistez à l’envie d’agiter la main et de dire : « Ce ne sont pas les droïdes que nous recherchons ». Il se pourrait bien qu’ils le soient. Mais avant d’acheter d’autres droïdes, découvrez à qui appartiennent ceux qui errent déjà autour de votre Étoile de la Mort. Trouvez-les. Nommez-les. Comprenez quelle autorité vous leur avez donnée. Et lorsque leur mission est terminée, osez les éteindre. Créez un cimetière technologique sur votre site wiki, Confluence ou SharePoint et célébrez l’ajout d’outils et de technologies mis hors service avec encore plus de ferveur que ceux qui ont récemment vu le jour.
