L’importance d’une IDMZ dans un monde sans périmètre

Au cours de la dernière décennie, chaque fabricant s’est un jour ou l’autre interrogé sur la meilleure façon de protéger son système de commande ainsi que les données, l’ingénierie, les technologies et les produits qui le composent. Un tel système de commande doit communiquer avec les systèmes de gestion de l’entreprise. Cependant, avec l’évolution du paradigme de la sécurité des réseaux, comment les fabricants peuvent-ils tenir le rythme ?

Les systèmes de gestion chargés de la chaîne logistique, de la gestion de l’énergie, des essais en laboratoire, de la maintenance, de la collecte de données réglementaires et de la gestion de la productivité ont tous besoin de données provenant des systèmes de fabrication. Les technologies et protocoles sous-jacents grâce auxquels ces systèmes récupèrent ces données reposent sur divers types de bases de données, de serveurs Internet, d’accès à distance et de transferts de fichiers. Ainsi, afin de protéger un système de commande des risques de sécurité associés aux systèmes de gestion d’entreprise, la meilleure méthode est de créer une limite de sécurité qui sépare les systèmes de gestion d’entreprise du système de commande, appelée zone démilitarisée industrielle (IDMZ).

Qu’est-ce qu’une IDMZ ?

Une IDMZ (zone démilitarisée industrielle) est une séparation qui permet de créer une zone tampon au sein d’un établissement de fabrication entre les systèmes de gestion d’entreprise et les systèmes de commande, qui présentent des exigences de sécurité différentes et ne sont pas conçus pour se faire mutuellement confiance. Cette séparation utilise les commandes de sécurité des réseaux et applications pour gérer le flux de données entre les zones non fiables.

Il y a quelques années, la cybersécurité n’existait que dans un monde complètement « clos » d’un point de vue physique. Puis, en 2006, sans que cela attire particulièrement l’attention, une nouvelle façon de stocker les données a été inventée. Le cloud public, une infrastructure de serveur et de réseau fournie par un tiers sur Internet (AWS, Microsoft Azure, Google Cloud, IBM Cloud), a changé la façon dont les entreprises IT stockent les données et gèrent leurs charges de calcul. Nombre d’entreprises IT utilisent désormais un cloud hybride combinant des services de cloud public et une infrastructure de serveurs sur site. À mesure que l’infrastructure réseau publique et le cloud public se fiabilisent, de plus en plus d’opérations de stockage et de calcul sont externalisées vers des fournisseurs de services de cloud public tiers.

Avec le recul, il était inévitable que le cloud public s’impose comme le stockage de choix des entreprises IT. Il fut un temps où les immenses salles de serveurs étaient réservées aux racks de serveurs physiques, qui occupaient l’intégralité de la pièce. Les murs de ces pièces constituaient la quasi-totalité de la sécurité IT : ils formaient un pare-feu périmétrique. Le cloud hybride a non seulement réduit le besoin d’espace mémoire sur des serveurs physiques, mais il s’est aussi débarrassé de la limitation physique des salles de serveurs grâce à la virtualisation. Le pare-feu existe toujours, mais si une grande partie (ou la totalité) de vos charges liées aux opérations de stockage de données et de calcul se trouvent en dehors du pare-feu, ce périmètre n’est plus suffisant. Pour s’adapter aux limites évolutives du périmètre et aux nouvelles menaces de sécurité qui existent en raison de l’exposition à Internet lors de l’accès au cloud public, un nouveau paradigme de sécurité est né : le modèle zéro confiance (Zero Trust).  

Qu’est-ce qu’un modèle zéro confiance ?

Le modèle zéro confiance maximise le principe du privilège minimal, selon lequel seul le nombre minimal de droits nécessaires à l’exécution d’une tâche est accordé à un utilisateur ou à un système. Ce principe applique un postulat de non-confiance : il n’autorise le transfert de données ou la communication entre les appareils que si l’utilisateur, les données, l’ordinateur et l’emplacement disposent des autorisations nécessaires. On s’éloigne ainsi de l’ancien modèle qui préconisait la confiance dès que les différents éléments appartenaient à la même zone, pour passer à un modèle de méfiance à l’égard de tout ce qui n’est pas vérifiable de plusieurs façons.

L’éventail des menaces pesant sur les systèmes de commande évolue. Les attaques de ransomware de grande envergure (comme WannaCry ou l’imposteur NotPetya) et les attaques ciblées sur les infrastructures critiques à l’aide de maliciels (Crash Override, Triton ou LookBack, par exemple) sont de plus en plus courantes. Les environnements des systèmes de commande et leurs administrateurs, qu’ils en soient conscients ou non, ont toujours été fortement tributaires de la sécurité du périmètre IT. Même pour ceux qui disposent d’une IDMZ, la sécurité du périmètre IT constituait la première ligne de défense contre le monde extérieur. L’IDMZ était la dernière ligne de défense. Alors que le périmètre IT disparaît, elle peut devenir le seul bastion de protection.

L’environnement d’un système de commande peut-il adopter un modèle zéro confiance ?

Si seulement c’était si simple… Les environnements IT typiques peuvent s’avérer complexes, mais ils présentent certains points communs :

• Matériel informatique standard avec un plan de cycle de vie
• Système d’exploitation standard auquel des correctifs sont régulièrement appliqués
• Outils logiciels de bureautique standard
• Solution de gestion des identités et des accès mise en œuvre pour les utilisateurs et les actifs
• Mise en œuvre de méthodes et de mises à jour permettant à un actif d’identifier les attaques et de s’en défendre

Un environnement de système de commande se compose de centaines de produits différents de plusieurs générations, développés par une multitude de fournisseurs et qui communiquent à l’aide de plusieurs protocoles. Il s’agit de plates-formes matérielles uniques qui utilisent leur propre firmware et logiciel personnalisés. Même les solutions purement logicielles ne sont compatibles qu’avec des systèmes d’exploitation extrêmement dépassés qui, très souvent, ne sont plus pris en charge. Même si une solution est basée sur un système d’exploitation qui reçoit encore des correctifs, le personnel en charge des systèmes de commande est toujours réticent à appliquer ces derniers, de peur que leur mise en œuvre entraîne un temps d’arrêt. Et ses inquiétudes ne sont pas infondées.

Ainsi, pour que la sécurité d’un système de commande soit assurée dans un modèle zéro confiance, ses actifs devront devenir aussi autonomes en matière de protection que les actifs IT communs. Pour y parvenir, voici tous les changements qu’il faudrait apporter aux plates-formes et aux technologies des systèmes de commande :

• Le modèle zéro confiance fait immédiatement basculer le bit de 1 à 0.
• Actuellement, les appareils des systèmes de commande font confiance à tout appareil qui peut communiquer avec eux. Ils n’ont aucun moyen de vérifier l’utilisateur, l’appareil, l’emplacement ou la raison pour laquelle un actif communique avec eux, ni les objets auxquels l’actif en question a accès. De leur côté, ils n’ont pas la possibilité de vérifier quand ils lancent une connexion.
• La plupart des appareils de système de commande ne disposent d’aucune méthode d’authentification. Si c’est le cas, ils n’ont pas les règles, les dispositifs de journalisation ou les capacités d’administration nécessaires.
• Ils n’ont aucun moyen de déterminer s’ils sont attaqués ou si un actif tente de communiquer avec eux de façon anormale.
• Aucune technologie comportementale ne permet d’identifier des comportements inédits ou d’analyser les conséquences de plusieurs actions.
• Pour finir, même la culture de l’organisation des systèmes devrait changer.

Par exemple, même si un composant d’un système de commande nécessite une authentification à l’aide du modèle commun nom d’utilisateur/mot de passe, il sera configuré avec les informations d’identification les plus simples possibles, sera partagé par tout le monde et restera perpétuellement connecté. Des technologies et des compétences requises pour le personnel de l’usine à la culture de la sécurité, en passant par la gestion de la surveillance et de l’administration, tout ce qui concerne les systèmes de commande doit changer. Et, bien entendu, ce changement doit se produire sans affecter la production.

Défis liés aux IDMZ

Toutes les entreprises ne sont pas prêtes à investir dans une IDMZ. Il peut s’avérer difficile et pénible d’en concevoir une et de l’intégrer dans les systèmes de réseaux OT et IT existants. Pour concevoir et mettre en œuvre une zone démilitarisée industrielle, il est nécessaire d’avoir une excellente compréhension des domaines suivants :

• Sécurité du réseau
• Plates-formes de pare-feu et ACL
• Technologies de serveur virtuel
• Renforcement du système
• Sécurité des applications
• Fonctionnalité et sécurité des domaines
• Méthodes sécurisées de transfert de données et de fichiers
• Méthodes sécurisées d’accès à distance
• Etc.

Pour compliquer les choses, l’IDMZ doit ensuite être entretenue par une équipe tout aussi compétente dans ces domaines afin de maintenir l’infrastructure, d’approuver les modifications du réseau et de réagir face aux menaces pour la sécurité.

Bien que l’adoption d’une IDMZ ne soit ni simple, ni bon marché, cela vaut la peine de déterminer s’il s’agit de la bonne solution pour vous. Les coûts liés à l’IDMZ sont-ils inférieurs au coût de ce qu’elle protège ? Si l’IDMZ protège l’ensemble de votre système de commande, elle constitue un très bon investissement. Compte tenu de la multiplication des menaces qui pèsent sur les systèmes de commande extrêmement vulnérables, dans un monde sans périmètre, l’IDMZ est en fait la seule protection complète disponible à ce jour capable de les protéger.

Les systèmes de commande ne sont pas encore assez matures pour présenter une tolérance raisonnable au risque de sécurité dans un monde sans périmètre. Il est fortement conseillé de monter des défenses en profondeur. Cependant, tant que ces appareils ne peuvent pas se protéger eux-mêmes ni interagir avec des systèmes de protection externes, une IDMZ reste la meilleure défense pour les systèmes de commande. Pour l’instant, nous ne pouvons pas nous passer du « mur intérieur » renforcé par une IDMZ.

Découvrez comment Rockwell Automation peut vous aider à créer et à maintenir une IDMZ dans le cadre d’une approche de défense en profondeur de la sécurité des réseaux.