Le problème d'audit dans l'OT
Un auditeur demande : « Montrez-moi qui a accédé au PLC-14 le 3 mars et quelles commandes ont été exécutées. »
Dans la plupart des environnements OT, cette question est sans réponse. Voici pourquoi :
- Comptes partagés : les opérateurs se connectent aux HMIs avec un compte « opérateur » partagé. Trois équipes, douze personnes, un seul nom d'utilisateur.
- Accès fournisseur par VPN : le fournisseur se connecte via un VPN site à site. Le journal du pare-feu affiche une connexion depuis la plage d'adresses IP du fournisseur. Il n'indique ni quelle personne s'est connectée, ni ce qu'elle a fait.
- Absence de journalisation au niveau des commandes : les historiens SCADA enregistrent les valeurs de processus. Le Syslog capture les événements réseau. Aucun des deux n'enregistre les commandes spécifiques qu'un utilisateur a envoyées à un PLC ni les écrans qu'il a parcourus sur un HMI.
- Absence d'attribution de session : même lorsque des journaux existent, ils sont liés à des adresses IP ou à des comptes partagés, et non à des individus authentifiés.
Cet écart n'est pas théorique. C'est précisément ce que les auditeurs CMMC et NIS2 signaleront.
Ce qu'exigent les réglementations
Exigences CMMC
AU.L2-3.3.1 (Événements d'audit) : créer et conserver les journaux et enregistrements d'audit système afin de permettre la surveillance, l'analyse, l'investigation et le signalement de toute activité illicite ou non autorisée. Avec l'échéance CMMC d'octobre 2026 imposant une certification tierce, le respect de ce contrôle est urgent.
AU.L2-3.3.2 (Contenu des audits) : garantir que les actions de chaque utilisateur du système peuvent être retracées de manière unique jusqu'à cet utilisateur.
AC.L2-3.1.7 (Fonctions privilégiées) : empêcher les utilisateurs non privilégiés d'exécuter des fonctions privilégiées et consigner l'exécution de ces fonctions dans les journaux d'audit.
Le mot clé du contrôle 3.3.2 est individuel. Les comptes partagés ne satisfont pas ce contrôle. La journalisation par adresse IP ne le satisfait pas non plus. Une traçabilité par utilisateur et par session est indispensable.
Exigences NIS2
L'article 21 impose des mesures de gestion des risques en matière de cybersécurité, notamment en ce qui concerne la gestion des incidents. Plus précisément :
- Les organisations doivent mettre en œuvre des mesures de détection, de réponse et de rétablissement après incident
- Les preuves doivent être conservées et disponibles pour l'analyse post-incident
- Les mesures de sécurité de la chaîne d'approvisionnement doivent inclure la surveillance des accès tiers
Lorsqu'une session fournisseur vers un PLC provoque une perturbation de processus, la NIS2 exige que vous puissiez reconstituer exactement ce qui s'est passé, qui l'a fait et quand.
Fonctionnement de l'enregistrement de session
L'enregistrement de session dans une architecture à base de proxy capture l'intégralité du contenu de chaque connexion entre un utilisateur et un actif OT. Le proxy intercepte la session, de sorte que l'enregistrement s'effectue de manière transparente, sans aucun logiciel sur le terminal.
La chaîne d'enregistrement :
- L'utilisateur s'authentifie auprès de l'Access Gate avec MFA. L'identité est vérifiée et liée à la session.
- La politique est évaluée. Le système vérifie si cet utilisateur est autorisé à accéder à cet actif, à ce moment, avec ce protocole.
- La session est établie. Le proxy ouvre une connexion médiatisée vers le dispositif cible.
- La session complète est enregistrée. Pour les sessions RDP/VNC : capture d'écran. Pour les sessions SSH : commandes terminal et sorties. Pour Modbus/OPC UA : commandes et réponses au niveau du protocole.
- La session est indexée. L'enregistrement est stocké avec des métadonnées : identité de l'utilisateur, actif cible, protocole, heure de début, heure de fin, durée.
Le résultat est un enregistrement consultable et attribuable de chaque interaction avec chaque actif OT.
Correspondance entre l'enregistrement de session et les contrôles de conformité
| Exigence de conformité | ID de contrôle | Ce que demandent les auditeurs | Ce que fournit l'enregistrement de session |
|---|---|---|---|
| Création d'événements d'audit | CMMC AU.L2-3.3.1 | Journaux de tous les accès aux systèmes CUI | Chaque session est journalisée avec l'utilisateur, l'actif, le protocole et l'horodatage |
| Traçabilité individuelle | CMMC AU.L2-3.3.2 | Preuve que les actions sont attribuées à des individus | Utilisateurs authentifiés par MFA liés aux sessions enregistrées |
| Journalisation des fonctions privilégiées | CMMC AC.L2-3.1.7 | Journaux des actions d'administration et d'ingénierie | Opérations d'écriture et modifications de configuration capturées au niveau du protocole |
| Application du moindre privilège | CMMC AC.L2-3.1.5 | Preuves des restrictions d'accès | Le moteur de politique restreint l'accès par utilisateur, par actif et par opération |
| Détection et réponse aux incidents | NIS2 Article 21(b) | Procédures de gestion des incidents avec preuves | Les sessions enregistrées fournissent des preuves forensiques pour la reconstruction des incidents |
| Conservation des preuves | NIS2 Article 21 | Journaux conservés pour l'analyse post-incident | Enregistrements de session stockés avec rétention configurable et protection contre la falsification |
| Surveillance de la chaîne d'approvisionnement | NIS2 Article 21(d) | Contrôles d'accès fournisseur et piste d'audit | Sessions tierces enregistrées avec la même fidélité que les sessions internes |
| Rapports de gestion des risques | NIS2 Article 21(a) | Contrôles de sécurité démontrables | Les tableaux de bord d'enregistrement de session affichent les schémas d'accès et l'application des politiques |
Ce que l'enregistrement de session capture par protocole
Les différents protocoles produisent différents types de données d'audit :
| Protocole | Type de session | Ce qui est enregistré |
|---|---|---|
| RDP / VNC | Accès HMI, postes de travail d'ingénierie | Capture d'écran complète (vidéo), frappes clavier, activité du presse-papiers |
| SSH | Contrôleurs Linux, équipements réseau | Commandes terminal, sorties, transferts de fichiers |
| Modbus TCP | Communication PLC | Codes de fonction (lecture vs. écriture), adresses de registres, valeurs |
| OPC UA | SCADA vers PLC, connexions historien | Accès aux nœuds, opérations de lecture/écriture, activité de navigation |
| HTTP/HTTPS | HMIs web, gestion de dispositifs | URLs, soumissions de formulaires, appels API |
Cette granularité au niveau du protocole distingue l'enregistrement de session de la journalisation réseau. Un journal de pare-feu indique qu'une connexion Modbus TCP a eu lieu. L'enregistrement de session indique que l'utilisateur X a envoyé une commande Write Single Register (code de fonction 06) au registre 40001 avec la valeur 1, modifiant ainsi la consigne d'une pompe.
Guide de déploiement pratique
Le déploiement de l'enregistrement de session dans un environnement OT n'a pas à se faire en une seule fois. Une approche par phases réduit les risques et renforce la confiance organisationnelle.
Phase 1 : Accès distant des fournisseurs (semaines 1-2)
Commencez ici. Les sessions fournisseurs représentent la cible la plus risquée et la plus visible.
- Faites transiter tous les accès distants fournisseurs par l'Access Gate
- Activez l'enregistrement de session sur toutes les sessions fournisseurs
- Exigez le MFA pour chaque connexion fournisseur
- Définissez la politique de rétention (90 jours minimum pour CMMC, en conformité avec les exigences NIS2)
Pourquoi commencer ici : les fournisseurs accèdent à des actifs critiques, souvent avec des privilèges élevés, via des identifiants partagés. C'est l'écart que les auditeurs recherchent en premier.
Phase 2 : Accès interne des ingénieurs (semaines 3-4)
Étendez l'enregistrement aux ingénieurs et opérateurs internes accédant aux PLCs et HMIs.
- Définissez des politiques d'accès par utilisateur (qui peut accéder à quels actifs)
- Activez l'enregistrement sur les sessions des postes de travail d'ingénierie
- Mettez en œuvre des politiques tenant compte du protocole (par exemple, autoriser la lecture, bloquer l'écriture pendant les heures de production)
Phase 3 : Couverture complète (mois 2-3)
Étendez l'enregistrement à tous les chemins d'accès OT.
- Enregistrez toutes les sessions vers les serveurs SCADA et les historiens
- Intégrez les journaux de session au SIEM pour la corrélation
- Générez des rapports de conformité associant les sessions aux exigences de contrôle
- Réalisez un audit simulé en utilisant les sessions enregistrées comme preuves
Ce qu'attendent les auditeurs
Lorsqu'un évaluateur CMMC ou un auditeur NIS2 examine votre environnement OT, il demandera :
- Des journaux d'accès indiquant qui a accédé à quels systèmes et quand
- Des preuves d'attribution individuelle (pas de comptes partagés)
- La preuve de l'application du moindre privilège (utilisateurs limités aux actifs autorisés)
- Des preuves de réponse aux incidents (capacité à reconstituer ce qui s'est passé lors d'un événement de sécurité)
L'enregistrement de session fournit une source unique et consultable de preuves pour les quatre points. Au lieu d'assembler des journaux de pare-feu, des journaux VPN, des entrées d'historien SCADA et des journaux d'événements Windows, vous orientez l'auditeur vers une session enregistrée avec le nom de l'utilisateur, l'actif cible et le contenu complet de son interaction.
Cessez de traiter l'accès OT comme un problème réseau. Traitez-le comme un problème d'identité avec des preuves au niveau de la session. Pour approfondir les raisons pour lesquelles une architecture à base de proxy constitue la bonne fondation pour l'enregistrement de session dans l'OT, commencez par là. C'est ce qu'attendent les auditeurs, et c'est ce qu'exigent les cadres de conformité.
Pour plus de ressources CMMC, d'études de cas et de guides de mise en œuvre, consultez le hub CMMC Compliance for On-Premise.
Pour plus de ressources NIS2, d'options de déploiement souverain et de guides de conformité, consultez le hub NIS2 Compliance for On-Premise OT.
