[Debrief Cyber] Descente chez le Fournisseur
Retour Terrain d'une visite chez le fournisseur ayant un faible niveau de cybersécurité
Le contexte
Une entreprise du nord de la France, spécialisée dans l’électronique embarquée. Elle importe des cartes depuis l’Asie, y installe ses propres firmwares, puis les envoie à des clients répartis dans toute l’Europe. En interne, une petite équipe assure le maintien en condition opérationnelle. Un modèle efficace, mais fragile, où chaque dysfonctionnement logiciel peut paralyser toute la chaîne.
Le niveau de sécurité est préoccupant. Aucune rotation des secrets, aucune supervision réelle, et des mises à jour rarement appliquées. Les accès perdurent, les vulnérabilités s’accumulent, et personne ne s’en étonne vraiment. Un environnement fragile, où le moindre incident pourrait tout faire basculer.
Pour notre client, qui dépend directement de cette société, la question ne se discute pas : il faut sécuriser. L’infrastructure soutient une activité critique, répartie sur plus de 620 sites. Chaque vulnérabilité devient un risque industriel. L’urgence, ici, n’est pas théorique.
Le problème
Le fournisseur fonctionne sous pression constante. Les impératifs de livraison priment sur tout le reste. La cybersécurité passe souvent après, jugée moins urgente que les délais clients. Pourtant, le delivery dépend directement de la disponibilité et de la fiabilité de ses systèmes.
Le fournisseur dispose bien d’un RSSI, principalement pour répondre aux exigences de certains clients. Pourtant, sa voix reste marginale en interne. Malgré une solide expertise et plusieurs années d’expérience dans la maison, ses alertes peinent à franchir le mur des priorités opérationnelles.
À force de persévérance, la direction finit par accepter une visite sur site. Quatre ateliers de deux heures sont programmés, chacun consacré à une thématique clé pour structurer enfin la démarche de sécurité.
Le Debrief
Avec le RSSI, nous planifions les ateliers en réunissant les bons interlocuteurs : production, IT, qualité, direction. Pas simple de coordonner tout le monde sur deux jours, mais le planning finit par se caler.
Les quatre ateliers sont définis : sécurité dans le développement des solutions, contrôle et actions de sécurité avant expédition, maintien en condition de sécurité, et gestion des incidents. Quatre sujets concrets, au cœur des pratiques quotidiennes, pour comprendre où se situent réellement les problèmes et comment l’organisation y répond aujourd’hui.
Lors du premier atelier, nous faisons le point sur les contrôles de sécurité appliqués au développement : analyses de vulnérabilités statiques, formations des développeurs, exigences cybersécurité intégrées aux backlogs. Les échanges sont francs. Certains appliquent correctement les principes, d’autres improvisent. Aucun cadre formel, mais des pratiques qui émergent peu à peu. On sent une volonté réelle, mais encore dispersée, de professionnaliser la sécurité dans le cycle de développement.
Le deuxième atelier démarre dans une atmosphère tendue. Rapidement, on réalise qu’on ne parle pas le même langage : les termes de sécurité, de validation ou de contrôle n’ont pas la même signification pour chacun. Il faut un temps d’adaptation, quelques frictions, avant de réussir à poser un cadre commun. Le niveau de maturité est très faible : pas de contrôle qualité industrialisé, uniquement du réactif. Ma réaction de surprise passe mal auprès du prestataire. J’apaise le ton. Déjà réussir à décrire l’existant, c’est un vrai progrès.
Le troisième atelier est plus délicat. L’objectif : comprendre le maintien en condition de sécurité. Rapidement, la discussion dérape. Aucun processus n’existe, aucune mise à jour de sécurité n’a jamais été appliquée. En face, on m’explique que ce n’est pas nécessaire, que “le terrain, c’est différent”. Je ne conteste pas leur réalité, mais le risque est clair. Avec le RSSI, on réexplique calmement les enjeux. L’un des participants menace de démissionner. Il faut apaiser, rester ferme, et surtout garder le dialogue ouvert.
Le quatrième atelier, consacré à la gestion des incidents, est plus fluide. Cette fois, l’équipe est bien outillée et le RSSI maîtrise son sujet. Les échanges deviennent concrets : modalités de notification, formats, délais d’alerte en cas d’incident. Le niveau de maturité est bon, mais un point bloque : leur refus, compréhensible, d’installer notre EDR sur leurs infrastructures. Le débat reste ouvert. On devra concevoir une architecture commune, capable de concilier leurs contraintes industrielles et nos exigences de supervision sécurité.
On clôture les deux jours par un plan d’action sécurité commun. À ce stade, il reste théorique, mais les deux parties s’accordent sur les sujets. Les priorités sont fixées ensemble. Et rien que cet alignement, c’est déjà une victoire importante pour la suite.
Il ne restera plus qu’à aborder la partie la plus sensible : la négociation des priorités et des moyens financiers. Et cette fois, personne ne se fait d’illusion, ce ne sera pas réglé en deux jours.
Conclusion
Loin des yeux, loin du cœur. Je crois profondément au télétravail, mais sur des sujets complexes où il faut aligner des équipes, rien ne remplace la présence physique. Voir les visages, sentir les réactions, comprendre les silences. Un proche me répète souvent : “C’est toujours une question d’humains.”
Écouter, vraiment écouter, c’est sans doute l’étape la plus sportive pour moi. Comprendre pourquoi une absence de sécurité, même choquante, peut parfois avoir du sens dans leur réalité quotidienne. Avant de corriger, il faut comprendre. Écouter sans juger permet de maîtriser le contexte, et souvent, d’obtenir bien plus d’adhésion que la démonstration technique.
Enfin, la négociation. En cybersécurité, j’aimerais toujours atteindre vite la cible idéale. Mais la vraie question, c’est le voyage. Comment le commencer, comment embarquer tout le monde, et combien de temps on s’accorde pour y arriver. C’est là que se joue la réussite : dans la trajectoire.
Ressources CyberLead
Afin de faire connaitre CyberLead, dont je suis le CEO , j’ai conçu le Kit RSSI avec un ensemble de templates et documents issus de mon expérience de RSSI dans des structures de différentes tailles et différentes maturités :
CVTHEQUE CYBERLEAD
Pour être efficace en cybersécurité il faut surtout les bonnes personnes au bon endroit. C’est pour cela que je lance la CVthèque Cyberlead dédiée à la cybersécurité. Celle-ci a pour but de connecter les candidats et les recruteurs au moyen de fiches standardisées, de tags de compétences, de niveaux d’expérience, de la localisation et de la disponibilité.
A la recherche d’une nouvelle opportunité ?
REX CYBERLEAD
Il y a quelques temps j’ai accompagné une structure dans le cadre d’attaque d’une ligne de métro. Aujourd’hui j’ai décidé de proposer un atelier pour partager avec vous un REX anonymisé “Décontamination d’une ligne de métro”. Ce REX est exclusivement réalisé sur site.
Pour des raisons de confidentialité et de criticité, ce REX est réservé exclusivement à destination des clients finaux comportant des infrastructures critiques .
Dans le cadre de cet atelier je vous présenterai :
Le contexte d’un OT hétérogène soumis à de fortes contraintes d’exploitation et marqué par des dépendances IT↔OT
La restitution de l’historique avec une vision globale et structurée de la situation.
Les résultats que j’ai obtenu ainsi que les leçons tirés directement de la situation de crise.
Les recommandations définies et applicables directement sur le terrain.