Pourquoi les tests « hors ligne » ne sont pas sécurisés : prendre la cybersécurité au sérieux avec le CMC 500
Pendant des années, une hypothèse incontestée a défini la sécurité des postes : « Nous sommes en sécurité parce que nous réalisons des tests hors ligne. » C’est une pensée rassurante qui a guidé nos procédures et façonné notre sentiment de sécurité. Mais aujourd’hui, cette croyance est devenue une hypothèse dangereuse.
Ce vieux sentiment de sécurité est désormais une vulnérabilité, car les menaces elles-mêmes ont évolué. Elles ne sont plus juste en dehors du pare-feu, à essayer de s’infiltrer. Elles arrivent sur une clé USB ou dans un fichier de paramètres compromis, déjà à l’intérieur de votre périmètre de confiance.
Quand la menace est déjà dans la pièce, être déconnecté d’Internet n’a plus d’importance. Votre équipement de test n’est plus isolé ; il devient la principale cible, et potentiellement le maillon faible de votre chaîne de sécurité.
Cette nouvelle réalité vous force à faire un choix critique. Devez-vous vous fier seulement à des procédures pour vous protéger des vulnérabilités potentielles au sein de vos outils ? Pour le CMC 500, ce choix est la base de sa conception. Pour comprendre ce que cela signifie dans le monde réel, examinons un exemple simple de deux personnes qui illustrent ce conflit.
La cybersécurité n’est pas une fonction. C’est un principe architectural non négociable.
Une cybermenace réelle sur le terrain :
l’histoire de John et Jane
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.
Prévenir les attaques par interception/usurpation grâce à la communication cryptée
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.
Pas de certificat, pas de connexion. Pas d’identité, pas d’accès.
Protéger les connexions Wi-Fi contre les accès non autorisés
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.
Pas de mot de passe, pas d’accès. Pas de failles de sécurité.
Garantir l’intégrité du firmware grâce au démarrage sécurisé et mesuré
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.
Pas de vérification, pas d’exécution.
C’est un engagement, pas une case à cocher :
notre approche de la sécurité tout au long du cycle de vie
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.
La sécurité n’est pas juste une fonction. C’est notre engagement. Chaque jour, dans chaque équipement CMC 500.
Défense en couches :
comment le CMC 500 sécurise les tests
Vérification d’identité et protection des identifiants
- Cryptographie à clé publique
- Communication cryptée de bout en bout
- Module de plate-forme fiable (TPM 2.0)
- Authentification mutuelle
Intégrité du firmware
- Démarrage sécurisé et mesuré
Sécurité intégrée au cycle de vie du produit
- Gestion des vulnérabilités tout au long du cycle de vie
Vous voulez aller plus loin ?
À mesure que des attaquants comme Jane évoluent, notre compréhension des tests de cybersécurité sur le terrain doit elle aussi évoluer.
Pour aller plus loin, écoutez notre prochain épisode de podcast : #116: Why Testing Offline Is Not Cyber Secure
Dans cet épisode, nos experts abordent en détail les points suivants :
- Pourquoi « hors ligne » ne veut pas dire « sécurisé »
- Scénarios d’attaques réels et comment ils contournent la sécurité traditionnelle dans les postes
- Comment la sécurité intégrée telle que TPM 2.0 avec démarrage sécurisé et mesuré permet de créer un équipement à protection véritablement renforcée
Parce que la sécurité n’est pas juste une fonction, c’est un état d’esprit.
Choisissez un équipement de test prêt avant l’arrivée de la menace
N’attendez pas la prochaine faille pour découvrir le maillon faible de votre chaîne de sécurité. Les mesures réactives ne suffisent plus. Il est temps de faire de la confiance un principe intrinsèque et de construire votre posture de sécurité sur une défense proactive et sophistiquée.
Sécurisez votre réseau grâce à un outil conçu pour les menaces de demain, non pour les hypothèses d’hier.
Découvrez la gestion proactive des menaces en action
Découvrez comment le CMC 500 peut renforcer vos procédures de test et protéger votre infrastructure critique.
