[Debrief Cyber] Descente chez le Fournisseur
Teodor Chabin
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.
