Surveillance de sécurité de l'OT et des infrastructures critiques des bases militaires

Une base militaire n'est pas un réseau unique. C'est un environnement en couches : le domaine IT administratif qui gère la messagerie et la logistique, les réseaux opérationnels qui transportent les données C2 et de mission, et un troisième domaine fréquemment négligé par les équipes de sécurité – la couche de technologie opérationnelle (OT) qui fait fonctionner l'infrastructure physique. La production et la distribution d'énergie, les systèmes de stockage et de transfert de carburant, le traitement de l'eau, le CVC, le contrôle d'accès, les capteurs périmétriques et l'éclairage des pistes sont tous gérés par des systèmes ICS et d'automatisation du bâtiment qui sont antérieurs aux pratiques modernes de cybersécurité, exécutent des protocoles propriétaires et, dans de nombreux cas, ne peuvent être corrigés ou mis à jour sans perturber les opérations en cours. Ces systèmes sont également, du point de vue d'un adversaire, des cibles extrêmement attrayantes : perturber l'alimentation électrique ou le carburant d'une base peut clouer des aéronefs au sol, désactiver les communications et neutraliser une installation bien plus efficacement qu'une cyberattaque conventionnelle contre des réseaux classifiés.

Cet article examine l'architecture et les pratiques opérationnelles d'une surveillance complète de la sécurité OT sur les installations militaires – couvrant la visibilité ICS passive, la modélisation comportementale de référence, la hiérarchisation des alertes et l'intégration des données d'installations dans le SOC IT. Pour un traitement complémentaire de la façon de détecter les intrusions lorsqu'un adversaire est déjà présent dans un environnement OT, consultez l'article sur la détection d'intrusion pour les systèmes OT et ICS militaires.

Pourquoi la surveillance OT exige une approche différente

L'instinct d'une équipe de sécurité IT confrontée à un réseau inconnu est de lancer un scanner de vulnérabilités. Sur un réseau OT, cet instinct peut provoquer une panne. Les automates programmables (PLC), les RTU (unités terminales distantes) et les contrôleurs d'automatisation du bâtiment sont des systèmes embarqués conçus pour un contrôle de processus déterministe et en temps réel. Ils allouent des tampons de mémoire fixes, fonctionnent sur des piles minimales et n'ont aucune logique défensive pour un trafic réseau inattendu. Une analyse NMAP ou un agent Nessus qui s'exécuterait sans danger sur un poste de travail IT peut épuiser la pile de communication d'un automate et le faire passer en état de défaut – ce qui signifie que le processus qu'il contrôle s'arrête.

Cette contrainte impose la règle fondamentale de la surveillance de sécurité OT : tout doit être passif. Le système de surveillance observe le trafic qui circule déjà sur le réseau – il n'en génère aucun. Cela est mis en œuvre via des TAP réseau ou des ports SPAN (miroir) de commutateur géré qui copient le trafic vers une interface de surveillance dédiée sans injecter aucun paquet sur le segment OT. Le capteur de surveillance a une présence en lecture seule : il reçoit une copie du trafic réseau, l'analyse et transmet les données normalisées via une interface complètement distincte qui est isolée du réseau OT.

La deuxième contrainte est la spécificité du protocole. Les environnements OT utilisent une gamme de protocoles industriels et d'automatisation du bâtiment – Modbus TCP/RTU, DNP3, BACnet/IP, IEC 61850, EtherNet/IP, PROFINET, LonTalk – que les outils de surveillance IT standard n'analysent pas. L'analyse de ces protocoles n'est pas facultative pour une surveillance efficace. Le contenu pertinent en matière de sécurité du trafic OT se situe au niveau du protocole : quels codes de fonction Modbus sont utilisés, quels objets DNP3 sont lus ou écrits, quelles propriétés BACnet sont modifiées. Un système de surveillance qui ne voit que les flux au niveau IP est aveugle aux opérations réelles effectuées sur l'équipement contrôlé.

L'inventaire des actifs OT comme fondement de la surveillance

Une surveillance efficace nécessite de savoir ce que l'on surveille. La plupart des bases militaires ne disposent pas d'un inventaire des actifs OT précis et à jour – la gestion des installations dispose de registres de ce qui a été installé, mais les ajouts, remplacements et modifications non documentés s'accumulent au fil des ans. La première étape de la construction d'un programme de surveillance consiste à dériver un inventaire à partir de l'observation passive.

Une session de découverte réseau passive – capturant le trafic sur tous les segments OT pendant un cycle opérationnel complet, idéalement une à deux semaines – révèle chaque équipement qui communique sur le réseau : son adresse IP et MAC, les protocoles qu'il utilise, ses pairs de communication et (pour de nombreux équipements OT) son identifiant de fabricant et de modèle intégré dans les poignées de main de protocole. Les objets d'équipement BACnet rapportent eux-mêmes l'ID du fabricant, le nom de l'objet et le numéro de modèle. Les équipements Modbus répondent à un ensemble limité de requêtes d'identification qu'un analyseur passif peut capturer à partir du trafic existant. Les équipements EtherNet/IP échangent des objets d'identité d'équipement dans la messagerie I/O normale.

L'inventaire résultant pilote deux fonctions en aval : la classification de criticité (quels équipements, s'ils étaient perturbés, affecteraient les systèmes critiques de la mission par rapport aux installations non critiques) et la portée de la référence (quelles relations de communication sont normales et devraient être modélisées). Un relais de protection de sous-station et un contrôleur d'éclairage apparaissent tous deux comme des équipements IP sur le réseau – l'inventaire des actifs est ce qui indique au système de surveillance que l'un justifie une escalade SOC immédiate s'il se comporte de manière anormale, tandis que l'autre peut être mis en file d'attente pour investigation.

Modélisation comportementale de référence

Les réseaux OT sont hautement répétitifs. Un automate contrôlant une pompe à carburant exécute le même cycle d'interrogation toutes les quelques centaines de millisecondes. Un maître SCADA lit le même ensemble de registres du même ensemble de RTU selon le même calendrier, jour après jour. Cette répétabilité est opérationnellement essentielle – c'est ce qui rend le système prévisible et fiable – et c'est aussi ce qui rend la modélisation comportementale de référence si efficace comme mécanisme de détection.

La modélisation de référence capture l'état comportemental attendu du réseau OT : quelles paires d'équipements communiquent, en utilisant quels protocoles et codes de fonction, à quelles fréquences, avec quelles distributions de taille de charge utile. Après une période d'apprentissage de deux à quatre semaines (suffisamment longue pour capturer les cycles de maintenance hebdomadaires, les schémas de changement d'équipe et les variations saisonnières du CVC), la référence représente un modèle complet des opérations normales. Les anomalies sont des écarts par rapport à ce modèle qui dépassent un seuil statistique – un nouveau pair de communication apparaissant, un code de fonction qui n'a jamais été observé sur un circuit, un taux d'interrogation qui double sans événement de maintenance correspondant dans le journal des modifications.

Le défi d'ingénierie critique dans la modélisation de référence est de gérer la variabilité légitime sans générer un excès de faux positifs. Les réseaux OT changent plus lentement que les réseaux IT, mais ils changent : la maintenance planifiée, le comportement saisonnier des systèmes, le remplacement d'équipements et les changements de rythme opérationnel produisent tous des schémas de trafic qui s'écartent de la référence historique. Une plateforme de surveillance bien conçue gère cela par la suppression des fenêtres de maintenance (les fenêtres de changement connues suppriment la notation d'anomalie pour les équipements concernés), les dérogations manuelles de référence (l'ingénieur des installations peut marquer un nouvel équipement comme attendu) et des références fenêtrées dans le temps qui modélisent séparément les schémas quotidiens, hebdomadaires et saisonniers plutôt que de les réduire à une seule moyenne.

Détection d'anomalies au niveau du protocole

Au-delà des dimensions de paire de communication et de fréquence de la référence, la détection d'anomalies au niveau du protocole examine le contenu des échanges de protocole OT. Les anomalies les plus significatives sur le plan opérationnel se produisent au niveau du code de fonction et de l'objet : une commande d'écriture Modbus vers une bobine qui n'a jamais été que lue par le système SCADA ; une commande DNP3 direct operate (code de fonction 3) là où seules des lectures de données s'étaient produites auparavant ; une commande BACnet WriteProperty ciblant un point de consigne qui contrôle des systèmes environnementaux critiques. Ces anomalies de classe de commande sont la signature d'un adversaire qui a obtenu l'accès au réseau OT et tente de manipuler des équipements de processus.

La détection au niveau du protocole couvre également les schémas d'abus de protocole – paquets malformés, codes de fonction inattendus, équipements interrogeant des pairs avec lesquels ils n'ont jamais communiqué auparavant. L'architecture de segmentation réseau de l'installation détermine quelles relations de communication sont architecturalement permises ; le système de surveillance les impose en signalant toute communication inter-segments qui viole la topologie prévue.

Connecter la surveillance OT au SOC IT

La sécurité des installations et la sécurité IT ont historiquement fonctionné comme des domaines organisationnels distincts sur les installations militaires. L'équipe de gestion des installations possède le réseau OT ; la fonction S6 ou IT équivalente possède le réseau IT et le SOC. Cette séparation crée un écart de visibilité : le SOC manque des données pour détecter les attaques qui prennent naissance dans la couche OT ou s'y propagent, et l'équipe des installations manque de l'expertise en sécurité pour interpréter les données d'anomalie comme des menaces potentielles.

Combler cet écart nécessite deux choses : une architecture technique qui permet un flux de données unidirectionnel de la plateforme de surveillance OT vers le SIEM IT, et un modèle organisationnel qui donne au SOC suffisamment de contexte sur les actifs OT pour agir sur les alertes OT sans nécessiter une expertise ICS intégrée au sein du SOC.

L'architecture technique utilise une diode de données ou une passerelle de sécurité unidirectionnelle positionnée à la frontière entre le réseau de surveillance OT et le réseau SOC. Le capteur de surveillance OT transmet les données d'alerte normalisées et les journaux d'événements via ce chemin unidirectionnel – la diode impose physiquement qu'aucun trafic ne puisse circuler du côté IT vers le côté OT. Les données normalisées arrivent au SIEM dans un format standard (CEF syslog, JSON ou un connecteur natif), où elles sont corrélées avec les événements de sécurité IT. Un événement de mouvement latéral qui commence par une anomalie de protocole OT, progresse à travers la frontière IT-OT et apparaît dans les journaux d'événements Windows comme l'installation d'un nouveau service n'est visible comme une séquence connectée que si les deux flux de données atteignent le même SIEM.

Pour que le SOC agisse efficacement sur les alertes OT, le SIEM doit être enrichi avec le contexte des actifs OT : criticité de l'équipement, emplacement physique, fonction métier associée et impact opérationnel d'une perturbation. Une alerte indiquant « nouveau pair de communication sur 192.168.40.15 » est inexploitable sans contexte. La même alerte enrichie avec « 192.168.40.15 = relais de contrôle de sous-station, alimentation électrique principale du bâtiment 14, criticité : ÉLEVÉE » produit une décision d'escalade immédiate et sans ambiguïté. Cet enrichissement est dérivé de l'inventaire des actifs construit lors du déploiement de la surveillance et maintenu par le processus continu de gestion des actifs.

Hiérarchisation des alertes et gestion de la charge de travail du SOC

Une base militaire dotée d'un déploiement de surveillance OT mature générera un volume substantiel de candidats à l'anomalie – non pas parce que l'environnement OT est constamment attaqué, mais parce que l'écart par rapport à la référence est structurellement courant dans une installation vaste et opérationnellement active. La maintenance planifiée, le vieillissement des équipements, les variations saisonnières et les mises à niveau périodiques des systèmes produisent tous des schémas de trafic qui s'écartent des normes historiques. Sans une hiérarchisation efficace, une équipe d'analystes SOC sera ensevelie sous les anomalies de faible importance et manquera les événements de haute importance qui nécessitent une réponse immédiate.

Une hiérarchisation efficace utilise un modèle de notation des risques qui combine trois dimensions : la criticité de l'équipement (à partir de l'inventaire des actifs), la gravité de l'anomalie (une nouvelle connexion sortante vers une IP externe obtient un score plus élevé qu'une augmentation de 10 % du taux d'interrogation) et le contexte opérationnel (un changement pendant une fenêtre de maintenance documentée obtient un score plus faible que le même changement un jour opérationnel normal). Les événements qui dépassent un seuil de risque combiné après suppression contextuelle génèrent des alertes SOC actives. Les événements en dessous du seuil sont journalisés et accessibles pour une investigation rétrospective, mais ne génèrent pas d'entrées de file d'attente.

L'intégration de la surveillance OT dans des flux de travail SIEM et SOAR plus larges permet aux alertes OT hautement prioritaires de déclencher des playbooks de réponse automatisés – isoler un équipement compromis à la frontière du réseau, notifier l'ingénierie des installations et lancer le processus de réponse aux incidents – sans nécessiter d'intervention manuelle d'un analyste SOC pour chaque événement. L'automatisation SOAR pour les incidents OT doit être conçue de manière conservatrice : les actions de confinement automatisées (blocage d'un chemin réseau, isolation d'un équipement) peuvent avoir des conséquences physiques immédiates dans un environnement OT. La notification automatisée et la collecte de preuves sont des points de départ sûrs ; le confinement automatisé nécessite une autorisation organisationnelle explicite et une analyse de scénario détaillée avant le déploiement.

Hygiène et réglage de la surveillance continue

La surveillance OT n'est pas une capacité que l'on déploie et oublie. L'environnement OT change au fil du temps – les équipements sont remplacés, les systèmes sont mis à niveau, les procédures opérationnelles évoluent – et la référence de surveillance doit évoluer avec lui. Une référence qui était précise il y a dix-huit mois peut maintenant générer un taux de faux positifs significatif parce que l'installation a changé et que la référence n'a pas été mise à jour. Un cycle de réglage mensuel avec l'équipe d'ingénierie des installations est la cadence opérationnelle minimale : examiner le volume d'alertes du mois précédent, identifier les sources systématiques de faux positifs, mettre à jour les exceptions de référence pour les changements planifiés et ajouter des règles de détection pour les nouveaux types d'équipements ou protocoles introduits depuis la dernière révision.

Les mises à jour de firmware sur les équipements OT nécessitent une attention particulière. Une mise à jour de firmware peut modifier le comportement de communication d'un équipement – intervalles d'interrogation différents, nouveaux messages de diagnostic, utilisation modifiée des codes de fonction – et apparaîtra comme une vague d'anomalies si la référence de surveillance n'est pas mise à jour en même temps que le déploiement de la mise à jour. La coordination des mises à jour de la référence de surveillance OT avec le processus de gestion des changements pour les équipements OT est une dépendance organisationnelle qui doit être intégrée dès le départ dans le modèle de coordination IT-installations de la base.