Go to content

Recommandations de sécurité pour les environnements industriels

Nous constatons clairement un lien fort entre les évènements géopolitiques actuels et l’escalade continue autour des enjeux de la cybersécurité, notamment autour des environnements industriels. Pour rappel, l’industrie 4.0 a en partie pour objectif de converger vers la numérisation des environnements de production. L’IoT fait essentiellement partie de cette approche. Je vous propose d’aborder, avec plus ou moins de détails, les recommandations de bases de la cybersécurité à destination des environnements industriels connectés.

La cartographie des biens et des objectifs de sécurité

Cette recommandation n’est pas vraiment une recommandation liée directement à la sécurité de l’environnement industriel, mais plutôt une préparation à la recevoir correctement. Cette première étape est assez classique : déterminer les biens à défendre et leurs criticités. Une analyse de risques (EBIOS RM ou autre) permettrait de répondre à cet objectif qui est essentiel pour la bonne application de nos recommandations plus techniques.

  • Cartographie des biens ;
  • Réalisation d’une analyse de risques.

Architecture

La première recommandation de sécurité technique, et surement une des plus importantes, porte sur l’architecture de votre environnement industriel. Il est important, comme pour tout type de système d’information, de définir une architecture sécurisée avec des principes de base dont la segmentation des actifs par rapport à leurs sensibilités, leurs fonctionnements, leurs architectures et des risques identifiés précédemment. Un exemple simple serait de segmenter le système d’information d’entreprise du système d’information industriel. Cette segmentation représente une base sur laquelle nous pouvons rajouter un ensemble d’éléments liés à la sécurité périmétrique (pare-feu, sondes de détection d’incident de sécurité, etc.) et à la défense en profondeur (durcissement des systèmes).

Les points suivants peuvent être instruits :

  • Segmenter votre architecture en zone selon les principes d’indépendance des biens et isoler les systèmes et réseaux ICS/SCADA des réseaux d’entreprise et d’Internet à l’aide de contrôles périmétriques et limiter toute communication entrante ou sortante des périmètres ICS/SCADA ;
  • Déterminer des barrières ou lignes de protection (moyen technique, procédural et humain) ;
  • Intégrer une authentification multifactorielle pour tous les accès à distance aux réseaux et dispositifs ICS/SCADA, dans la mesure du possible, même si nous ne recommandons pas l’utilisation des accès distants aux systèmes d’information industriels ;
  • Limiter les connexions réseau des systèmes ICS/SCADA aux seuls postes de travail de gestion et d’ingénierie spécifiquement autorisés ;
  • Installer des solutions de détection et de réponse (EDR) et assurez-vous que des paramètres de réputation des fichiers antivirus sont configurés ;
  • Protéger solidement les systèmes de gestion en configurant les moyens de protection de type Device Guard, Credential Guard et Hypervisor Code Integrity (HVCI).

Je voudrais ajouter un point de vigilance qui me semble important autour de la segmentation de l’architecture. La notion de segmentation nous semble claire pour le monde de l’IT, mais c’est moins le cas sur les environnements industriels. Lors de nos études d’architecture, nous remarquons que cette notion de segmentation est bien prise en compte, mais certaines machines sont des ponts entre deux ou plusieurs réseaux. Pour un « OT », une machine qui a deux cartes réseau ne représente pas un pont entre les deux réseaux. Malheureusement, c’est bien le cas, et lors des scénarios d’attaque, nous montrons jusqu’où pourrait s’étendre un rançongiciel via ses ponts.

Configuration

Encore une fois, cette recommandation est assez basique et pourtant nous la rappelons souvent (trop à mon gout) lors de nos différents audits. Tout dispositif et système ICS/SCADA arrive avant la mise en production avec une configuration de base qui est fournie par le fabricant. La bonne configuration du dispositif est importante pour qu’il ait le fonctionnement attendu, c’est évident, mais sa configuration est aussi un élément de base de sa sécurité. En voici quelques exemples, même si certains ne sont pas applicables à tous les systèmes :

  • Modifier les mots de passe par défaut des dispositifs et systèmes ICS/SCADA en utilisant des mots de passe forts et propres à chacun, et cela avant les mises en production ;
  • Modifier les certificats présents par défaut des dispositifs et systèmes ICS/SCADA ;
  • Changer régulièrement l’ensemble des mots de passe des dispositifs et systèmes ICS/SCADA afin de limiter, en partie, les attaques par force brute ;
  • Sauvegarder, hors ligne de production, les microprogrammes et les fichiers de configuration des contrôleurs ;
  • Réaliser une veille constante et mettre à jour régulièrement les dispositifs et systèmes ICS/SCADA ;
  • Appliquer le principe du moindre privilège. N’utilisez les comptes administrateurs que lorsque cela est nécessaire pour certaines tâches, comme l’installation de mises à jour logicielles.

Voir et prévoir

Une des dernières notions de base à prendre en compte est l’intégration des moyens de détection des incidents de sécurité et la préparation à la réponse aux incidents. Il vaut mieux prévenir que guérir en préparant l’exercice de crise avant la crise.

La détection d’incident de sécurité représente un enjeu fort qui pourrait limiter, tant que possible, l’action d’un acteur malveillant sur le système d’information industriel.

  • Utiliser une solution de surveillance continue permettant la détection des comportements malveillants en surveillant les systèmes et les communications internes afin de détecter les actions hostiles, les mouvements latéraux, etc. Une multitude d’outils existe afin de répondre à cet objectif et d’identifier le trafic anormal ;
  • Intégrer une collecte et une conservation robustes des journaux des systèmes ICS/SCADA et des sous-réseaux de gestion. Cela sera utile aussi bien pour la détection que pour la réponse à un incident de sécurité ;
  • Disposer d’un plan d’intervention en cas d’incident et l’exercer régulièrement avec les parties prenantes de la cybersécurité, des opérations et n’oubliez pas la direction et la communication qui joueront un rôle essentiel ;
  • Auditer vos systèmes d’information régulièrement et appliquer les plans d’action associés.

Un point essentiel liant l’ensemble des recommandations est la réalisation régulière d’un plan de contrôle afin d’affirmer l’application de la politique de sécurité ainsi que sa bonne application.

Cette liste n’est pas exhaustive, je le sais bien, mais elle permet d’intégrer les bases sur un sujet qui est parfois compliqué à mettre en place à cause des objections liées à la production. Plusieurs publications existent et vous trouverez plusieurs références à la fin de cet article, mais gardez à l’esprit qu’il est impératif de prendre le sujet en main avant d’être impacté.

Je sais que certains points sont difficilement applicables du fait de la responsabilité du fabricant qui contractuellement, n’a souvent aucun engagement en matière de cybersécurité. Nous recommandons d’ajouter la notion de cybersécurité à chaque nouveau contrat afin d’engager le fabricant dans le maintien en condition de sécurité des systèmes ICS/SCADA. Pour conclure, n’hésitez pas vous faire accompagner sur vos projets, nos (avec nos confrères du domaine) retours d’expériences sont à votre disposition.

 

Références :