Collecte de logs d’installations industrielles isolées

1. Windows Event Forwarding (WEF)

Un service de transfert et collecte des logs Windows existe nativement depuis Windows Vista/2008. Il s’agit de « Windows Event Forwarding ». Il repose sur Windows Remote Management (WinRM) qui est l'implémentation de Microsoft pour Windows du protocole Web-Service Management (WS-Management).  La centralisation des logs nécessite de mettre en place un collecteur destiné à recevoir les logs, et des sources destinées à fournir leurs logs au collecteur. Le lecteur intéressé pourra trouver des guides de configurations sur la toile (dont [1]).  

Le choix de la technologie WEF a pour avantage principal, outre la relative simplicité de configuration, de ne nécessiter aucune installation de logiciels tiers sur les postes et serveurs Windows. Seules les anciennes versions de Windows (XP SP2/2003SP1) nécessitent une installation logicielle préalable de WS-Management 1.1 ou 2.0. C’est donc globalement une technologie de choix, notamment dans un contexte industriel où les risques d’incompatibilités logicielles sont particulièrement redoutés (toute absence d’installation et de qualification de nouveaux logiciels est donc appréciable).

Le principe est simple : un serveur « collecteur » (WEC) a pour objectif de collecter les événements. Pour cela des abonnements sont configurés, désignant pour un ensemble de machines donné, les événements des journaux/channel (et eventid si besoin de raffiner) à récupérer.

La remontée de logs peut être configurée suivant deux modes :

• mode « push » (« source initiated ») : chaque machine (source de données) initie une connexion sur le collecteur qui fournira à chaque machine les abonnements désirés. C’est le mode classique d’un point de vue sécurité réseau où il n’y a pas d’exceptions à faire sur la politique de filtrage « entrant » sur les postes et serveurs à collecter ;
• mode « pull » (« collector initiated ») : le collecteur est à l’origine de la connexion sur les différentes machines afin de collecter les événements liés aux abonnements configurés sur celui-ci.

1.1 Collecteur WEC

Le collecteur (serveur Windows) est configuré en lignes de commandes (via les commandes wecutil qc et winrm qc) qui activent :

• le service winrm et son listener de requêtes WSMAN (http) ;
• le service de collecte (wecsvc) ;
• les règles de filtrages nécessaires sur le firewall Windows.

À noter que le service winrs (Windows remote shell) est activé via la commande winrm qc et n’est pas nécessaire pour la collecte de logs. Ce service peut être désactivé par la commande suivante :

Il est conseillé de vérifier que l’URL réservée http://+:5985/wsman/ fait bien référence aux deux services winrm et wecsvc (des tests de collecteur sous Windows 2016 ont montré qu’il fallait redéfinir son ACL comme ci-dessous afin de donner les droits nécessaires au service wecsvc).

Sur ce serveur, des abonnements aux journaux et événements désirés sont configurés soit via l’interface de l'observateur d'événements (limitée), soit via la commande wecutil qui permet de configurer beaucoup plus précisément les abonnements (via des fichiers xml).

Notamment, les options de customisation permettent de:

• gérer les paramètres de fréquence de remontée ;
• choisir de remonter ou non les événements déjà existants ;
• choisir le format des événements remontés : « events » ou « renderedtext » par défaut, qui possède la chaîne de description de l’événement (« localized strings »).

1.2 Sources

Les sources (ensemble des machines Windows devant être collectées) sont configurées par GPO afin de :

• démarrer et configurer le mode de démarrage du service winrm sur chaque poste ;
• définir l’URL HTTP du collecteur ;
• permettre aux événements du journal sécurité d’être remontés si nécessaire : le service winrm tournant sous l’identité « Network service », ce compte doit appartenir au groupe « Lecteurs des journaux d’événements » pour permettre la lecture du journal sécurité. Pour permettre la prise en compte de cette nouvelle affectation sans passer par le reboot du système, une solution possible est de configurer le service winrm afin qu’il ne soit pas partagé avec d’autres services au sein d’un hôte svchost.exe. Le redémarrage du service winrm crée alors un nouveau processus svchost.exe, possédant un « access token » à jour.

Pour les postes XP, généralement l’identité du compte du service winrm est modifié pour « Local System ».

L’utilisation du protocole HTTP (vs HTTPS) peut laisser penser que la confidentialité de la remontée de logs est négligée. En fait, en environnement Active Directory (AD), WinRM assure par défaut le chiffrement des communications (authentification mutuelle et échange de clés par Kerberos, permettant ensuite d’assurer le chiffrement AES 256bits de la communication). L’usage d’un « Listener HTTPS » n’est pas nécessaire pour permettre d’assurer la confidentialité de la collecte de logs entre la source et le collecteur en environnement AD.

Dans la pratique, la collecte de logs implique de définir en amont une stratégie d’audit permettant de spécifier les événements intéressants à auditer puis remonter via la collecte. Il peut être fort utile (lorsque les systèmes d’exploitation le supportent) d’enrichir les événements avec le logiciel Microsoft Sysmon ou de veiller a minima à la présence du KB3004375 (W7/2008R2) (qui améliore l’audit de création de processus en donnant la ligne de commandes complète pour les systèmes ne le supportant pas nativement).

Une fois la configuration terminée, les événements reçus seront disponibles dans le journal Windows « événements transférés » du collecteur.

1.3 Le cas Windows XP

Concernant les postes obsolètes nécessitant un ajout logiciel, lorsque le choix entre la version 1.1 ou 2.0 de WS-Management est possible, la version 1.1 a été préférée pour des raisons d’instabilités constatées avec la version 2.0 (exception Win32 récurrente), mais également pour limiter l’ajout logiciel au strict nécessaire (la version 2.0 embarque PowerShell 2.0, non nécessaire pour le besoin). La collecte de logs sur les postes XP n’est pas aussi efficace que sur les systèmes récents, principalement pour les deux raisons suivantes qui ont été observées (quelle que soit la version de WS-Management installée) : 

• Les postes XP ne supportent pas d’abonnement aux événements d’un journal non existant sur le poste. Si l’un des journaux configurés dans un abonnement n’est pas présent sur le poste, l’ensemble de l’abonnement est rejeté et aucun événement ne sera remonté par cet abonnement. À l’inverse, sur les systèmes récents, il sera simplement notifié que l’abonnement sera incomplet (de par l’absence d’un journal), mais tous les autres événements configurés dont le journal existe seront remontés par l’abonnement. Cela implique dans un environnement hétérogène de système d’exploitation de créer un abonnement minimaliste à associer aux postes XP.
• Les postes XP ne supportent pas toutes les options de configuration avancées des abonnements, notamment celles concernant la fréquence de remontée des événements. Dans la pratique, cela se traduit par une attente « non configurable » entre la génération d’un événement et sa remontée vers le collecteur. Afin d’obtenir les événements à fréquence régulière, une solution, certes peu élégante, consiste à redémarrer périodiquement le service winrm sur ces postes obsolètes (les événements sont transférés au redémarrage du service).

1.4 WEF : Workgroup vs Active Directory

Même si la technologie WEF est supportée en environnement Workgroup, la lourdeur d’exploitation dans ce mode provient de l’utilisation nécessaire d’une PKI pour la gestion des certificats machines (authentification mutuelle entre source et collecteur et chiffrement des communications HTTPS).

À l’inverse, en environnement AD, comme évoqué au paragraphe précédent, les mécanismes de sécurité sont transparents lors de la configuration de WEF (Kerberos).

Le plus souvent, les installations industrielles rencontrées ne disposent pas d’un environnement Active Directory pour leurs machines Windows. Un choix est donc possible : garder le mode Workgroup et apporter un service de PKI dans l’installation isolée ou prévoir la migration en domaine Active Directory.

La migration en domaine Active Directory, outre sa capacité à répondre au besoin, facilite d’un point de vue exploitation informatique le MCO/MCS de l’installation industrielle (facilité de déploiement et centralisation des configurations par GPO, capacité d’abandon des certificats pour le « mirorring SQL », amélioration de la gestion des comptes…). Cette option est présentée dans la suite de l’article.

2. Migration vers une infrastructure Active Directory

Afin d’apporter les services AD/DNS et un collecteur WEC dans l’installation industrielle isolée, le recours à une technologie de virtualisation est d'abord dicté par un contexte où la salle « serveurs » de l’installation industrielle peut se limiter à une ou deux baies informatiques avec un taux d’occupation déjà élevé.

Deux serveurs physiques utilisant par exemple la brique hyper-V permettant de monter des VM (contrôleur de domaine/DNS en redondance physique sur les deux serveurs, VM Collecteur WEC) constituent une solution possible. Ainsi d’autres services pourront se greffer facilement sur cette infrastructure virtualisée (WSUS…). Sur toutes ces briques qui seront apportées dans l’installation, un durcissement sécurité à l’état de l’art peut s’opérer (systèmes d’exploitation récents, firewall actif, durcissement système, etc.) tant qu’il ne casse aucune compatibilité avec les clients de l’installation utilisant ces services. En tant que nouveaux services apportés au sein de l’installation, l’ensemble des serveurs et services offerts ne doit évidemment pas affaiblir le niveau de sécurité existant dans l’installation.

Ainsi donc, sont préparés en amont :

• deux contrôleurs de domaine AD/DNS et les différentes GPO nécessaires ;
• un serveur de collecte WEC.

Au niveau de l’organisation Active Directory, une séparation via OU est réalisée pour distinguer tout le futur périmètre de l’installation industrielle du périmètre « infrastructure SOC » contenant les services apportés dans l’installation (typiquement le serveur WEC). Cela permet ensuite de facilement lier des GPO minimalistes sur le périmètre de l’installation industrielle dans un premier temps, tout en permettant de durcir plus profondément les services d’infrastructures apportés.

2.1 Intégration dans le domaine

Une fois les postes et serveurs éventuellement mis à niveau pour la collecte WEF dans l’installation industrielle (cas d’obsolescence du système d’exploitation), que les serveurs contrôleurs de domaine AD/DNS et collecteur WEC sont configurés et les serveurs physiques rackés, arrive le moment de la bascule : intégration séquentielle des différents postes et serveurs industriels au domaine Active Directory.

L’intégration est généralement un moment où il est nécessaire de s’entourer des équipes de la TMA industrielle. Les périodes propices pour modifier le système sont généralement assez courtes. L'intégration est donc une action à obligation de résultat, en temps contraint. C'est pourquoi il est nécessaire que les différentes équipes soient présentes pendant les opérations.

Il est recommandé de jouer un cahier de tests fonctionnels avant l’intégration afin de ne pas imputer injustement des « casses » à l’issue des opérations, car le syndrome nostalgique « c’était mieux avant » guette. Prouver que le temps de réponse sur demande d’arrêt moteur n’a pas changé et n’est pas plus « lent » qu’avant, nécessite l’appui précieux des compétences de la TMA industrielle, qui est jugée indispensable dans une telle l’opération.

Quelques points clés liés à l’environnement Windows doivent être pris en compte lors de l’intégration dans un domaine AD. La séquentialité inhérente à l’opération fait qu’inévitablement, certains postes auront basculé dans le domaine quand d’autres pas encore. Réaliser des tests tant que l’intégration n’est pas totalement finalisée est bien naturel pour « se rassurer », mais des problèmes purement temporaires existent et ne doivent pas alarmer outre mesure avant la fin de l’opération. Parmi ces problèmes, on peut citer :

• Le firewall Windows : s’il n’est pas spécifiquement désactivé pour le profil « domaine », il s’active lors de l’intégration au domaine (passage du profil « standard » au profil « domaine »). La supervision est temporairement cassée, les flux DCOM/RPC utilisés dans le monde industriel (OPC) sont coupés par le firewall qu’il convient de remettre dans son état d’origine (soit le plus souvent : désactivé) après intégration au domaine.
• La résolution de nom d’hôtes : elle est modifiée par la configuration d’un DNS. Avant l’intégration, l’installation fonctionne dans les cas rencontrés sans DNS configuré. Sans DNS, les composants logiciels s’appuyant sur la résolution de noms d’hôtes peuvent bénéficier de la résolution NETBIOS, ce qui permet une résolution de noms d’hôtes fonctionnelle pour les noms d’hôtes NetBIOS. Cependant, une fois le DNS configuré lors de l’intégration, la résolution de nom d’hôtes ne donne plus nécessairement la main à la résolution NetBIOS même en cas d’échecs de résolutions du DNS [2]. C'est pourquoi certains flux de communications ne sont plus établis tant que la machine destination n’est pas inscrite au DNS (ce qu’elle sera lors de son intégration au domaine).
• L’ouverture de session automatique « Autologon » : elle n’est plus opérationnelle suite à l’intégration dans un domaine. Souvent utilisée sur des postes de supervision partagés lors des rotations des opérateurs, elle doit donc être reconfigurée.

Deux points d’attentions méritent d’être soulignés, en dehors des aspects transitoires.

L’intégration au domaine fait prendre à chaque poste l’horloge d’un contrôleur de domaine. Des décalages d’horloges peuvent donc survenir si l’horloge du contrôleur est en écart avec le reste de l’installation avant l’intégration. Suivant la stratégie retenue, il peut être utile de synchroniser en amont l’horloge du contrôleur ayant le rôle FSMO « PDC Emulator » avec un poste référence de l’installation industrielle.

L’absence de DNS au sein de l’installation industrielle avant l’intégration au domaine implique qu’aucune résolution de nom d’hôtes FQDN n’est possible (hormis par fichier « hosts »). Lors de la configuration des DNS, certains logiciels peuvent tenter alors des résolutions de noms FQDN qu’ils ne pouvaient pas réaliser avant. Suivant la configuration des DNS, cela peut engendrer des latences logicielles perceptibles. La configuration par défaut du DNS Windows, récursif, va tenter de contacter les serveurs racines (« root hints »), évidemment sans succès en environnement isolé, mais retardant la réponse d’échec de la résolution. Une solution possible est de désactiver la récursivité du DNS ou chercher à reconfigurer le logiciel pour éviter la résolution des FQDN incriminés.

Une fois l’intégration réalisée, les événements commencent à remonter dans le journal « événements transférés » du serveur collecteur et le système industriel fonctionne en mode nominal. Un bon point d’étape pour la collecte. Maintenant il s’agit de transférer les événements de ce journal au SOC situé sur un réseau tiers à l’installation.

3. Transfert vers le SOC

La collecte d’événements d’installations industrielles isolées implique l’utilisation de produits de sécurité garantissant le respect de l’exigence d’isolation. Dans ce contexte, l’utilisation du mécanisme traditionnel de filtrage réseau vers le SOC n’est pas possible : la remontée des journaux s’opère par conséquent par transferts de fichiers à travers une diode matérielle.  

Il convient d’adapter chaque maillon de la chaîne de collecte pour qu’il puisse être compatible avec cette contrainte. Cela implique notamment d’oublier toute solution de type « forwarders Splunk » qui nécessiterait d’établir une communication réseau entre le serveur de collecte et le SIEM.

Ainsi pour assurer la chaîne de remontée des événements vers le SOC, l’infrastructure mise en place consiste en :

• Un serveur de collecte WEC : il exécute un script Powershell chargé de vider (et sauvegarder) le journal des événements transférés à fréquence régulière et transférer les fichiers au format « evtx » compressés à un serveur « guichet bas ».  Les fichiers ne sont alors archivés localement qu’en cas de réussite du transfert. Sinon, ils restent en file d’attente, permettant ainsi un mécanisme simple et automatique de reprise sur incident. À noter que chaque nom de fichier est normalisé afin d’en connaître sa provenance, sa date de création et son numéro d’ordre permettant ainsi de l’identifier de façon unique.
• Un serveur sous Linux « guichet bas » :  il reçoit les fichiers compressés via SFTP. Un daemon surveille leur réception via le mécanisme « inotify », qui permet de mettre en place des actions sur modification du système de fichiers. L’événement système « CLOSE_WRITE » est ainsi intercepté et déclenche l’exécution d’un script s’appuyant sur la solution open source hairgap [3], afin de transférer les fichiers à travers la diode matérielle, vers le « guichet haut ». À ce stade, et en raison de la diode, il n’est pas possible de s’assurer de la réussite du transfert, les fichiers sont alors archivés systématiquement.
• Un serveur sous Linux « guichet haut » : il réceptionne les fichiers via hairgap et transfère chaque fichier reçu sur un share CIFS coté SOC. Ici aussi, un daemon surveille la réception grâce à « inotify », afin de déclencher la copie des fichiers vers le partage. Tout comme sur le serveur de collecte, les fichiers ne sont alors déplacés de la file d’attente vers les archives qu’en cas de succès de leur copie.
• Un serveur de fichiers côté SOC : il exécute un script Powershell chargé de décompresser et extraire les événements des fichiers « .evtx » au format XML pour générer un fichier CSV placé dans un répertoire dédié à l’installation supervisée. La génération du CSV permet un prétraitement des données permettant notamment de gagner en taille d’indexation par le SIEM : renommage, réduction ou suppression de certains champs. En fonction du débit du flux de données à traiter, il peut être nécessaire d’optimiser le script de traitement afin de ne pas pénaliser le délai global de remontée des logs.

Le schéma ci-dessous illustre l’architecture mise en œuvre :

L’interconnexion via une diode matérielle introduit des contraintes techniques dans la gestion de la chaîne de remontée de logs.

Afin de garantir que les journaux d’événements ne soient pas « perdus » en cours de route, chaque élément de l’architecture doit pouvoir permettre de stocker les fichiers avec un délai de rétention permettant de pallier toute défaillance d’une des autres briques. De plus, le numéro d’ordre des fichiers peut être utilisé pour détecter toute perte lors de transfert, notamment au niveau de la diode. Pour permettre de superviser et d’identifier depuis le SOC tout élément d’architecture défaillant, toutes les actions sont journalisées et transférées au SOC et les services et binaires nécessaires au transfert des fichiers sont surveillés pour prévenir, et si possible corriger, tout arrêt inopiné. Le monitoring s‘appuie sur le logiciel monit [4] et des scripts Shell développés pour répondre à des problématiques spécifiques. De plus, il est important d’apporter une attention particulière à la gestion des erreurs dans les scripts développés. La capacité à réémettre automatiquement les journaux non transférés lors d’une reprise après défaillance, ou lors d’une opération de maintenance, est notamment utile afin de limiter les actions à réaliser au sein même d’une installation. Bien entendu, l’absence d’événements indexés au niveau du SIEM constitue une alerte d’exploitation.

La mise en œuvre de cette architecture est relativement complexe, mais elle a l’avantage de permettre la remontée de toutes données utiles pour la supervision de la sécurité de l’installation. Ainsi, il suffit désormais d’utiliser les mécanismes de journalisation internes au système d’exploitation Windows ou de générer un fichier et de le « pousser » par SFTP afin qu’il puisse être analysé dans le SOC.

Conclusion

Au-delà de l’aspect technique non négligeable de mettre en musique les différentes briques pour la collecte de logs d’installations industrielles, la collaboration entre les équipes (IT/OT) amenées à intervenir est un facteur clé du succès pour sa réalisation.

Outre l’apport d’une supervision sécurité, la démarche s’avère dans notre contexte bénéfique à plusieurs égards. Les tâches d’exploitation pour le MCO sont facilitées par le transfert de compétences important entre les équipes et la capacité à surveiller en quasi temps-réel les postes et serveurs des installations industrielles. Les briques de base sont également posées pour envisager sereinement les évolutions techniques futures telles que les durcissements sécurité.

Références

[1] https://securite.intrinsec.com/wp-content/uploads/2016/03/Intrinsec-CERT-Handbook-Deploiement-WEF-SIEM.pdf

[2] https://support.microsoft.com/fr-fr/help/172218/microsoft-tcp-ip-host-name-resolution-order

[3] https://github.com/cea-sec/hairgap

[4] http://mmonit.com/monit