Introduction
Comme indiqué dans mon premier article sur le sujet, cette année, j’ai eu l’occasion de parler sur la scène principale de s4, une conférence de 3 jours, dédiée à la cybersécurité ICS, qui s’est tenue à Miami South Beach du 19 au 21 avril 2022 et organisée par Dale Peterson.
Le thème de cette année était « No Limits ! ». Ce thème m’a donné l’idée de réfléchir à l’avenir des architectures de réseaux ICS.
La vidéo de la conférence est maintenant disponible sur la chaîne YouTube de S4Events : lien
C’est donc l’occasion de vous donner plus de détails sur la présentation.
Genèse de la présentation
Dans le cadre de mes missions chez Wavestone, je travaille beaucoup sur la cybersécurité des SCI au sein de différentes entreprises. Ces dernières années, mon travail d’assistance et de soutien aux RSSI s’est de plus en plus concentré sur les architectures réseau.
J’ai beaucoup entendu ce genre de déclarations :
- « J’ai besoin d’envoyer des données vers le Cloud pour pouvoir optimiser ma production ».
- « Mon usine est exploitée par un partenaire externe, et j’ai besoin de me connecter à son système d’information ».
- « Dans mon secteur d’activité, je suis tenu légalement et contractuellement d’envoyer ce type de données industrielles à un tiers ».
Il y a de plus en plus de besoins professionnels nécessitant des interconnexions avec le SCI qui semblent légitimes. Mais comment permettre ces interconnexions de manière sécurisée ? Et pouvons-nous dire oui à tout ?
Les exigences en matière de cybersécurité des SCI ont toujours été les mêmes. Et en termes d’architecture de réseau, nous en arrivons toujours au modèle Purdue, ainsi qu’à la méthodologie des zones et des conduits. Traditionnellement, il y a une certaine rigidité quant à ce qu’est une architecture ICS « sécurisée ».
L’Internet a tendance à être considéré comme le « mal ultime » quand on parle d’ICS.
Eh bien, « No Limits ! » m’a donné envie de rêver un peu. Et si je pouvais partir de zéro et construire l’architecture ICS de mes rêves sans aucunes limites ?
Dans ma présentation, je compare et oppose les exigences et l’architecture de réseau sécurisée ICS correspondante de deux activités très différentes au sein de la même entreprise : les centrales électriques et les fermes solaires/éoliennes.
L’histoire de deux architectures ICS sécurisées (très différentes)
Présentation d’un cas pratique
J’ai travaillé pour des entreprises qui possèdent une grande variété de systèmes de contrôle :
- Activités historiques : centrales électriques (nucléaires, chimiques), raffineries.
- Nouveaux métiers : parcs solaires et éoliens
Ces différents métiers se retrouvent aujourd’hui au sein d’une même entreprise.
Pour ces entreprises, la politique de cybersécurité ICS existante doit être adaptée aux nouveaux usages et métiers. Dans ce cadre, comment définir des exigences/règles de cybersécurité qui s’appliqueraient à l’ensemble de l’entreprise ?
Durant mon intervention, je présente en détail les deux cas d’utilisation.
L’architecture historique sécurisée ICS
Parlons d’abord de l’architecture historique. Elle suit le modèle Purdue, avec les bonnes vieilles exigences de cybersécurité des SCI :
- Une zone démilitarisée (DMZ) entre le réseau informatique et le réseau opérationnel, protégée par des pare-feu (un pare-feu entre le réseau opérationnel et la DMZ et un pare-feu entre la DMZ et le réseau informatique).
- Pas de communication directe entre les réseaux IT et OT
- Rupture de protocole dans la DMZ (utilisation de serveurs relais)
- Pas d’accès local à Internet sur le réseau OT (l’accès à Internet passe par le réseau IT)
Lorsque nous essayons d’appliquer les mêmes principes d’architecture au cas d’utilisation d’une ferme solaire/éolienne, nous aboutissons à quelque chose qui n’a pas de sens :
- Des communications d’OT à OT passant par le réseau IT
- Plusieurs DMZ et deux pares-feux pour chaque site industriel, même ceux qui n’ont que quelques actifs sur le réseau.
L’architecture sécurisée de la ferme solaire/éolienne
Ce cas de figure nous montre qu’il est nécessaire d’essayer autre chose et de repartir de zéro. Et si nous pouvions construire un réseau industriel géographiquement distribué en exploitant la technologie SD-WAN ?
- Réseau OT :
- Bordure SD-WAN avec pare-feu de nouvelle génération sur chaque site
- Tunnels VPN IPSEC entre les sites
- Règles de filtrage à travers le VPN pour n’autoriser que les flux légitimes, comme Modbus par exemple.
- Détection avec activation de l’IDS sur les firewallsDMZ in the Cloud
- Principalement une DMZ entre le réseau OT et l’Internet directement (nous avons accès à l’Internet sans passer par le réseau IT)
- Plusieurs firewalls pour protéger les différentes zones
- Services centraux pour le réseau OT
- Bastion pour l’accès à distance
- Antivirus et serveurs de mise à jour : ils obtiennent leurs mises à jour directement d’Internet (sites officiels) par le biais d’une liste blanche d’URL avec des proxies et distribuent ensuite les mises à jour au réseau OT par le biais de l’architecture SD-WAN.IT network
- Interconnexion à travers le Cloud uniquement avec un autre pare-feu dédié
Voici les principales différences avec l’architecture précédente :
- Nous ne passons plus par le réseau informatique pour faire communiquer les sites industriels entre eux.
- Nous avons une DMZ entre le réseau OT et l’Internet directement
- Nous n’avons besoin que d’une seule DMZ globale pour le réseau industriel.
Cependant, soyez prudent. Cette architecture est plus risquée que l’architecture historique.
- Maintenir un bon niveau de cybersécurité est difficile. Des erreurs peuvent être observées avec le temps sur le SD-WAN.
Par exemple, on peut exposer un site directement sur Internet à cause d’une mauvaise configuration du SD-WAN edge.
- Plusieurs exigences doivent être respectées pour protéger les actifs industriels :
- Les communications doivent être contrôlées de bout en bout.
- Les communications sont sécurisées en fonction du niveau et des besoins de l’entreprise : Tunnels VPN IPSEC, filtrage réseau, relais si nécessaire, authentification, chiffrement, détection, etc.
La rigueur est la clé avec cette architecture. Et finalement, ce que j’aime le plus, c’est le fait que les bases de la cybersécurité doivent être respectées… enfin !
Méthode de classification ICS
Revenons maintenant à notre objectif initial : comment formaliser les exigences de cybersécurité pour l’ensemble de l’entreprise et différencier les architectures sécurisées ICS ?
Pouvons-nous construire quelque chose autour des risques ?
Je présente une méthodologie de classification des SCI basée sur une approche standard basée sur les risques :
- Impact : en utilisant l’échelle d’impact HSE standard de l’entreprise.
- Probabilité : prise en compte de plusieurs facteurs, tels que la fonctionnalité du système ou sa connectivité.
Avec l’impact et la probabilité, nous pouvons placer notre système sur une matrice de risque qui donne la classification du système. Dans cet exemple, nous avons 4 classes d’ICS.
Ensuite, je l’applique à nos deux cas d’utilisation. Nous nous retrouvons avec une classification différente pour nos systèmes :
- Système de classe 2 pour la ferme solaire/éolienne
- Impact limité (2) car il n’y a pas de risque HSE
- Probabilité importante (3) en raison de la haute connectivité du système
- Système de classe 3 pour la centrale électrique
- Impact élevé (3) en raison du risque HSE
- Probabilité faible (2) car les interconnexions du système sont limitées.
Ainsi, dans notre politique de cybersécurité ICS, nous pouvons avoir différentes exigences de cybersécurité en fonction de la classification du système.
A retenir
Plusieurs facteurs peuvent être pris en compte pour une décision d’architecture :
- Que fait le système de contrôle ?
- Quel serait l’impact d’une cyberattaque ?
- Quel est le niveau d’exposition du système ?
Pour conclure la présentation, j’encourage les entreprises à lancer un groupe de travail pour soutenir les projets et construire une architecture sécurisée pour les nouveaux usages des SCI. Une bonne idée pourrait être de créer des modèles d’architecture : identifier plusieurs cas d’utilisation pour l’entreprise et créer des architectures de référence basées sur l’analyse des risques.
Cependant, il faut trouver le bon équilibre : avoir différentes architectures sécurisées pour chacun des cas d’utilisation au sein de l’entreprise est une bonne chose, mais seulement jusqu’à un certain niveau de gestion. En effet, vous devrez assurer la maintenance de toutes ces architectures et solutions. Donc, malheureusement, vous ne pouvez pas avoir autant d’architectures que de systèmes de contrôle !
