Ce qu’il y a d’étonnant dans l’affaire des frigos d’Intermarché

C’est un grand classique : on a des matériels en pagaille qui nécessitent une supervision. À un moment donné, on connecte ces équipements sur un réseau IP (alarmes, vidéosurveillance, détecteurs de fumée, etc.) avec soit une console de supervision interne (un bête PC sur le LAN) avec un opérateur humain devant (quand on en a les moyens), et à un moment donné on externalise la supervision de ces équipements auprès du fabricant / fournisseur / installateur. On a tous fait cela, on continue de le faire.

Il y a plusieurs façons d’externaliser la supervision, l’une d’elles étant de mettre ledit PC de supervision sur la DMZ avec un accès direct au fabricant. Il y a quelques années, on avait des prises de main à distance sur le PC en question. L’évolution fait que ces PC ont de plus en plus souvent embarqué des serveurs Web pour que le mainteneur puisse s’y connecter, tout comme on se connecte au site Web de la boîte.

Ce descriptif sommaire doit être pris avec du recul : il existe de très nombreuses variantes. PC sur le LAN avec un serveur Web déporté en mode reverse proxy sur la DMZ, PC sur le LAN avec un accès à distance par rebond sur un Citrix, par rebond sur un bastion, canal IP sur des ports propriétaires montés directement entre le PC interne et le réseau du fournisseur, VPN de site à site avec restriction IP, etc. : la liste est longue. Et à chaque configuration le risque varie : la version reverse proxy n’est pas du tout soumise à la même cartographie des risques que l’accès en VPN LAN to LAN. À chaque fois, on doit y aller à la pince à épiler pour l’analyse, sans parler de la remédiation.
(D’ailleurs, j’attire votre attention sur le fait que pas mal d’équipements de domotique pilotables à distance, tel le chauffage, sont accessibles par exactement ce type d’architecture.)

Mais la plupart du temps, le hic n’est pas là. Le hic s’exprime très simplement par une approche processus : le propriétaire d’un asset (actif) est propriétaire de ses risques (ceux associés à l’asset). Or, le hic, c’est que personne ne s’estime propriétaire du « bout informatique » du « machin technique ». Souvent les services techniques vous rétorquent que c’est de l’IT, la DSI vous rétorque que ce sont des systèmes industriels, et dans pas mal de cas les systèmes ont été acquis par des directions Achats. De sorte que la DSI vous explique que « je maintiens ce que j’achète » et que les ST vous expliquent « je prends en charge les systèmes industriels et pas l’IT qui les accompagne » (qui est vue, au mieux, comme un porte-clés, au pire comme une verrue). Et encore, quand la DSI a connaissance du machin, ce qui n’est pas toujours le cas.

Parce qu’il faut débunker tout de suite une croyance généralisée et totalement erronée : sécuriser la télémaintenance de ce genre de système par un fournisseur externe, même offshore, non seulement ne présente aucune difficulté technique (pour chaque variante ci-dessus, on a les briques sur étagère), mais en plus ne coûte quasi rien. Une des pires configurations est celle où le fournisseur a besoin d’un accès LAN to LAN (dans certaines situations, notamment celle où le fournisseur télésupervise des centaines d’équipements, c’est difficile de faire sans). Mais même dans ce cas, cela se résout par de la segmentation réseau, du filtrage interne, la tenue à jour de matrices de flux, etc. En termes de matos / logiciels, quasi rien, juste un peu d’huile de coude : bon, OK, parfois beaucoup d’huile et beaucoup de coudes, mais rien d’impossible ni de très cher.

Bref, les deux root causes principales dans ce genre d’attaque par la supply chain de systèmes techniques sont... (roulement d’octets) : « ben non oh quoi il raconte n’importe quoi le RSSI ça arrive jamais » et « pasnouspasnous ». Parce que la root cause est toujours managériale, rarement voire jamais technique.

Ce qui amène à une autre réflexion : le nerf de la guerre de la protection de l’IT d’une organisation, ce n’est pas d’être ORADAD niveau 18. J’ai été, à une époque, un fervent partisan de cette orientation de sécurisation des AD, mais l’évolution de la menace et des modes d’attaque conduit à réviser cette position. Clairement, en 2026, la priorité est de contrôler les portes d’accès à son LAN : point d’entrée de la supervision dans le cas des frigos ci-dessus, URL de réinitialisation de mot de passe accessible sur le Web dans le cas de la récente attaque subie par l’ANSSI, absence de zero trust sur les comptes d’accès VPN (cause technique d’une bonne partie des attaques dans le monde de la santé depuis cinq ans), etc.

On crame une énergie de fou à blinder nos AD, et dans le même temps quasi aucune task force sur des chantiers élémentaires : genre monter le DMARC de nos systèmes de messagerie, genre du Shodan systématique, genre l’obligation de généralisation du MFA, genre le zero trust partout où cela s’applique. Ce sont pourtant l’un des premiers points d’entrée sur nos réseaux. Je suis preneur de vos avis critiques et constructifs sur ce genre de considération.

[1] https://youtu.be/Z3FNh5G84uM?si=1_kZINZuHLQHowZM