Heathrow, Bruxelles, et Berlin paralysés.

L'incident Collins Aerospace a d'abord été lu comme une histoire de négligence sur les mots de passe. C'en est une, en partie. Mais la vraie question n'est pas pourquoi ces credentials n'avaient pas été changés. C'est pourquoi ils donnaient encore accès, trois ans plus tard, à un serveur exposé sans segmentation ni supervision. C'est cette question-là qui vous concerne directement.

Collins Aerospace : quand un flux FTP non surveillé coûte neuf jours d'exploitation

Le 10 septembre 2025, le groupe Everest accède aux serveurs FTP de Collins Aerospace. Pas par une faille zero-day sophistiquée. Pas par une attaque sur le cloud. Par deux identifiants volés lors d'une infection infostealer en 2022 : aiscustomer et muse-insecure. Des credentials qui n'avaient jamais été changés en trois ans.

En neuf jours, Everest exfiltre plus de 50 Go de données : dossiers passagers, fiches employés, bases SQL complètes. Le 19 septembre, Collins coupe ses serveurs. Heathrow, Bruxelles, Berlin : les systèmes d'enregistrement tombent, des milliers de passagers traités à la main pendant une semaine.

En décembre 2025, les données sont publiées sur un forum cybercriminel. L'enquête post-incident révèle des serveurs exposés sous des stacks techniques en fin de vie, des flux FTP non segmentés, des credentials statiques jamais audités.

Selon le rapport Verizon DBIR 2025, les identifiants compromis figurent au premier rang des vecteurs d'intrusion. Mais un credential volé seul ne fait pas une attaque : il lui faut un système accessible, mal isolé, pour causer des dégâts. Collins en est l'illustration. En 2025, Jaguar Land Rover et FAI Aviation Group ont subi des intrusions par des vecteurs comparables.

L'angle mort que votre schéma réseau ne montre pas

Dans les environnements industriels complexes, multi-sites, multi-équipes, la surface d'attaque ne ressemble pas à ce que représente un schéma réseau classique. Elle ressemble plutôt à l'accumulation de décisions prises sous contrainte, sur dix ans, par des équipes qui avaient d'autres priorités.

Un flux Modbus entre un automate et un système de supervision, ouvert en 2011 pour un projet pilote et jamais fermé. Un accès VPN créé pour un sous-traitant lors d'une campagne de maintenance, toujours actif deux ans après la fin du contrat. Une API REST exposée sur un segment peu surveillé pour faire communiquer un outil de simulation legacy avec un système de reporting.

Chacun de ces flux a été créé pour une bonne raison. Aucun n'a été conçu pour être sécurisé. Selon une étude cybermalveillance.gouv.fr de décembre 2025 auprès de PME/ETI françaises, 58 % des entreprises admettent ne pas savoir évaluer les conséquences d'une cyberattaque sur leur infrastructure. Ce chiffre n'est pas surprenant quand on réalise que la plupart des audits inventorient des machines, pas les flux qui circulent entre elles.

La situation est aggravée par un angle mort organisationnel propre aux environnements industriels : les équipes méthodes et ingénierie pilotent les outils de production et de simulation, la DSI pilote les réseaux, et personne ne supervise l'espace entre les deux.

Trois actions concrètes pour réduire le risque sans attendre le prochain budget

1. Cartographiez vos flux, pas seulement vos équipements. Commencez par un atelier avec les équipes IT et OT réunies. Demandez à chaque responsable de lister les systèmes qui communiquent avec l'extérieur de son périmètre, les protocoles utilisés, et la date de la dernière revue de ces accès. L'objectif n'est pas l'exhaustivité : c'est d'identifier les trois ou quatre flux les plus exposés pour les traiter en priorité. Cette cartographie partielle est aussi ce que NIS2 exige des ETI industrielles depuis octobre 2024, autant en faire un levier budgétaire plutôt qu'une contrainte supplémentaire.

2. Traitez les identifiants comme une dette technique. Un audit trimestriel des identifiants actifs sur les systèmes exposés (FTP, VPN, API, accès distants) est une mesure simple, peu coûteuse, et qui élimine une classe entière de risques. Commencez par les accès créés pour des prestataires extérieurs : ce sont les plus souvent oubliés, et les plus fréquemment exploités.

3. Segmentez avant de moderniser. Remplacer un système legacy prend du temps. Le segmenter du reste du réseau prend quelques jours. Concrètement : des VLANs dédiés aux flux OT, des règles de filtrage sur un firewall industriel (Stormshield ou Fortinet sur ces environnements). L'objectif : qu'une intrusion sur un segment de simulation ne puisse pas atteindre les automates de production. C'est le type de mesure qu'un DSI peut lancer sans attendre le prochain budget de transformation.

La dimension organisationnelle est au moins aussi importante que la technique. La sécurité des flux inter-systèmes ne peut pas être portée par un seul côté. Elle nécessite une gouvernance partagée entre IT et OT, construite avec les deux équipes, pas imposée de l'extérieur.

Ce que Kaptngo change dans les environnements où la refonte est impossible

Dans beaucoup d'environnements industriels, l'obstacle n'est pas la volonté de sécuriser les flux legacy : c'est que les protocoles concernés sont anciens, parfois propriétaires, et ne supportent pas nativement le chiffrement ni l'authentification forte. Reconstruire l'infrastructure réseau pour les sécuriser est une opération lourde et souvent hors de portée à court terme.

C'est ce problème spécifique qu'akawan a outillé avec Kaptngo. Le principe : une couche de communication sécurisée en zero trust qui s'intercale entre vos systèmes existants pour encapsuler n'importe quel protocole et le transporter de manière chiffrée et authentifiée sur le web, sans refonte de l'infrastructure. Un flux ancien, un échange de fichiers inter-sites, une communication entre automates et supervision centrale : Kaptngo les prend tels quels, sans modifier les équipements ni les protocoles source.

Chez akawan, on ne livre pas l'outil seul. On commence par analyser vos flux réels, on identifie les communications les plus exposées, et on co-construit le périmètre de déploiement avec vos équipes IT et OT. C'est ce qui fait la différence entre une solution installée et un dispositif qui tient dans la durée, dans un environnement où la coopération entre équipes est aussi importante que la technologie elle-même.

Un pilote ciblé sur six à huit semaines, limité aux flux les plus critiques entre deux sites ou deux équipes, est suffisant pour valider l'approche et démontrer la valeur avant tout déploiement plus large.

Vos protocoles hérités ne sont pas une fatalité. Leur exposition non surveillée, si.

L'incident Collins Aerospace n'a pas été causé par une attaque sophistiquée. Il a été causé par trois ans d'inaction sur des credentials volés, et par des flux de communication exposés sans surveillance. Ce type de scénario n'est pas réservé aux grandes entreprises aéronautiques. Il se reproduit dans tous les environnements industriels où la pression de la production a toujours primé sur l'audit des flux inter-systèmes.

La question n'est pas de savoir si vous avez des systèmes legacy dans votre SI. Vous en avez. La question est de savoir combien de ces systèmes communiquent avec l'extérieur de manière non supervisée. La réponse à cette question vaut plus que n'importe quel audit de conformité