Pourquoi les tests « hors ligne » ne sont pas sécurisés : prendre la cybersécurité au sérieux avec le CMC 500

Voici John : un technicien de protection méticuleux aux routines précises et aux exigences élevées, qui a totalement confiance en ses outils. Les actions qu’il effectue sont essentielles au maintien de l’intégrité du réseau. 

Et voici maintenant Jane : une hackeuse qui prospère en tirant parti de la confiance et des hypothèses.

La journée de John commence par un travail de routine au poste Alpha. Il télécharge les fichiers de test nécessaires depuis le serveur de fichiers. Sur site, il reçoit une mise à jour du fichier de paramètres du client sur une clé USB. Il suit chaque procédure à la lettre : toutes les connexions réseau sur son PC, y compris celle vers le serveur du bureau (sauf celle reliée à son équipement de test) sont désactivées.

Rien ne peut mal tourner, n’est-ce pas ?

Mais Jane a déjà préparé son coup : il y a quelques jours, elle a utilisé l’ingénierie sociale pour installer un logiciel malveillant sur le serveur de fichiers du bureau. Le PC de John dispose des derniers correctifs de sécurité et d’un antivirus à jour, mais Jane tire parti d’une vulnérabilité zero-day.

Alors que John commence son test, le logiciel malveillant sur son PC est activé. Le premier objectif du logiciel malveillant est d’écouter. Il tente d’analyser la communication entre le PC et l’équipement de test, dans le but de découvrir des mots de passe, des configurations IP ou des détails sur le firmware. 

Résultat : comme la communication du CMC 500 est cryptée dès le tout premier paquet, les données, si elle sont capturées, ne sont rien d’autre que du bruit brouillé.

Frustré, le logiciel malveillant passe au niveau supérieur : il se positionne au milieu, se faisant passer pour l’équipement de test vis-à-vis du PC de John et pour le PC vis-à-vis de l’équipement de test. Il s’agit d’une attaque par interception/usurpation classique, conçue pour intercepter et manipuler les commandes.

Comment le CMC 500 répond : le CMC 500 ne fait aucune hypothèse. Il utilise la cryptographie à clé publique et des certificats numériques, permettant au PC de vérifier l’identité du CMC 500. La clé privée unique du CMC 500 est stockée dans le Module de plate-forme fiable 2.0 (TPM 2.0) basé sur matériel, qui garantit sa sécurité physique. Comme le logiciel malveillant de Jane ne peut pas produire de certificat valide, la connexion est refusée instantanément. Cela contraste fortement avec les pratiques classiques qui reposent sur un système de test hors ligne ; un tel système partirait du principe que la connexion est fiable et ignorerait complètement la présence d’une attaque par usurpation d’identité comme celle-ci.

John passe aux tests d’injection primaire. Il utilise son équipement de test multifonctions CMC 500 pour injecter des courants primaires. Il se connecte par Wi-Fi pour se déplacer librement et effectuer des mesures efficaces. 

Pendant ce temps, Jane n’a pas abandonné. Après que sa première tentative a été bloquée, elle a décidé de changer de tactique et s’est rendue au poste pour se connecter directement à l’équipement de test via le réseau Wi-Fi. En cas de réussite, elle pourrait injecter des commandes malveillantes, déclencher des opérations dangereuses, voire porter atteinte au personnel dans le poste. Il s’agit d’une attaque directe sur les contrôles d’accès de l’équipement.

Comment le CMC 500 répond : c’est ici que la sécurité procédurale simple rencontre une conception renforcée. John ne fait pas que se connecter, il crée plus de sécurité : son PC a déjà authentifié le CMC 500 par défaut, mais en ajoutant un mot de passe, John permet une authentification mutuelle : maintenant, le CMC vérifie également qui essaie de se connecter. Sans les identifiants corrects ou un accès physique pour les réinitialiser, Jane est bloquée.

Après avoir été à nouveau déjouée, Jane change de stratégie pour passer au niveau d’attaque le plus fondamental. Lorsque John se connecte au réseau du poste pour une mise à jour des paramètres, elle essaie d’introduire un firmware malveillant dans le CMC 500. En cas de réussite, ce firmware corrompu pourrait lancer des opérations indésirables, attaquer d’autres IED sur le réseau ou rester en sommeil jusqu’à un moment critique.

C’est ici qu’une conception proactive se distingue d’une politique réactive. Un autre équipement de test pourrait d’abord charger son système d’exploitation, en comptant sur une analyse post-installation pour détecter une menace, mais la porte est déjà ouverte à ce stade.

Comment le CMC 500 répond : la porte du CMC 500 ne s’ouvre jamais en présence d’un code non vérifié. Il utilise un démarrage sécurisé et mesuré, un processus ancré dans le matériel de son TPM 2.0. Avant même que l’installation n’exécute sa première instruction, la signature OMICRON du firmware le valide. Lors de l’exécution, chacun des composants du firmware est vérifié cryptographiquement, mesuré et comparé à des sommes de contrôle connues.

Le firmware malveillant de Jane n’est pas signé. Résultat ?  Pas d’installation. Il reste silencieux. 

L’histoire de John et de Jane n’a rien d’unique. Alors même que vous lisez ceci, des attaquants comme Jane travaillent sans relâche à contourner les défenses et à exploiter des vulnérabilités non traitées. C’est pourquoi la sécurité n’est pas une case à cocher une seule fois pour toutes. Elle doit être un engagement continu, intégré dans l’ensemble du cycle de vie d’un produit.

Nous mettons en œuvre un processus de gestion des vulnérabilités transparent et proactif que vous pouvez découvrir dans notre article de l’OMICRON Magazine. Qu’elles soient découvertes par nos équipes internes ou signalées par les utilisateurs, nous traitons toutes les vulnérabilités potentielles grâce à :

• Des mises à jour logicielles régulières pour corriger et renforcer le système.
• Des divulgations publiques et des contre-mesures pour que vous soyez toujours informé et disposiez des informations nécessaires pour protéger vos équipements.