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 !

Cet article S4x22 – L’histoire de deux architectures ICS sécurisées (très différentes) est apparu en premier sur RiskInsight.

Notre méthodologie d’audit

Retrouvez l’étude détaillée et le replay du webinar.

Cet article Cybersécurité des sites industriels : benchmark sur 40 audits est apparu en premier sur RiskInsight.

Rappel de l’état de la menace

L’ANSSI indique dans ÉTAT DE LA MENACE RANÇONGICIEL – À L’ENCONTRE DES ENTREPRISES ET INSTITUTIONS[1] publié le 05/02/2020 : « Depuis 2018, l’ANSSI et ses partenaires constatent que de plus en plus de groupes cybercriminels possédant des ressources financières et des compétences techniques importantes favorisent le ciblage d’entreprises et institutions particulières dans leurs attaques par rançongiciel. ».

Face à ce constat, il est plus que jamais nécessaire de sécuriser les systèmes d’information. Cela passe bien entendu par l’application des fondamentaux de la sécurité : application des mises à jour, gestion des comptes et des mots de passe, gestion de la segmentation réseau etc. Pour rappel, l’application de ces premières mesures permet déjà de réduire sensiblement la probabilité qu’un système d’information soit sujet à un rançongiciel, mais ne peut en aucun cas garantir que cela n’arrivera pas.

Spécificité du secteur industriel

Cependant, même si de nouvelles solutions de défense sont continuellement développées, le coût et la complexité de déploiement de certaines d’entre elles les rendent finalement peu usitées. Cela est d’autant plus vrai en milieu industriel, où leur intégration peut s’avérer complexe, certains systèmes étant figés dans une configuration fonctionnelle. De plus, les budgets alloués à la sécurité informatique en milieu industriel, bien qu’en augmentation ces dernières années, ne sont pas encore suffisants pour bon nombre de sites.

Par ailleurs, un système d’information industriel partage une base commune avec un système d’information classique, et est donc sujet aux mêmes attaques. Bien entendu, des attaques telles que Stuxnet, Triton, ou encore BlackEnergy (à plus faible échelle) nécessitent des compétences supplémentaires. Cependant, il est toujours bon de rappeler que les cibles d’intérêt pour les groupes possédant ce type de moyens sont généralement déjà soumises à des obligations règlementaires (LPM, directive NIS etc.), qui si respectées, limitent grandement les risques qu’une attaque soit réussie à leur encontre. Pourtant, ces systèmes ne sont pas invulnérables, et doivent donc également se préparer à y répondre.

Attaque inévitable sur les systèmes industriels : comment minimiser l’impact et redémarrer les opérations rapidement ?

Il apparait donc que :

• Se protéger de la menace est souvent limité à l’application des mesures de sécurité basiques si aucune obligation règlementaire n’est applicable au système d’information cible ;
• Identifier les sources de menace et détecter une attaque avant qu’elle n’atteigne son objectif nécessite dans l’immense majorité des cas des moyens trop importants vis-à-vis des budgets des systèmes d’information industriels actuels.

En partant du principe que la probabilité qu’un système d’information subisse une cyberattaque réussie, et plus spécifiquement un rançongiciel, dans un avenir proche est quasi certaine, la question suivante se pose donc : « Comment se préparer à une cyberattaque majeure, maintenir les activités critiques dans un mode dégradé, le tout en regagnant rapidement confiance dans le système d’information industriel ? ».

La réponse à cette question est couverte par les deux derniers piliers de la sécurité informatique d’après le framework NIST : respond (répondre) et recover (récupérer). Une tentative de réponse à cette question est présentée dans cet article.

Note : la première partie de cet article « Comment répondre à une attaque avant qu’il ne soit trop tard ? » n’est pas nécessaire à la mise en place des recommandations détaillées dans la seconde partie « Comment récupérer après une attaque si elle n’a pas pu être circonscrite ? ». Bien que l’implémentation de mesures de filtrage réseau soit vivement conseillée, il peut être intéressant pour les sites où la mise en place desdites mesures de filtrage est trop longue, de commencer par la partie préparation de la remédiation à une cyberattaque, plus facile à mettre en œuvre.

Comment répondre à une attaque avant qu’il ne soit trop tard ?

Impliquer les équipes industrielles

Avant de parler des mesures pouvant être mises en place pour répondre à un incident de sécurité numérique, il peut être intéressant de rappeler que le personnel industriel est habitué la gestion de crise.

En effet, bon nombre d’industries organisent régulièrement des exercices de gestions de crises (incendie, risque chimique, catastrophe naturelle etc.). Sur la majorité des sites sensibles, des procédures sont donc déjà disponibles pour répondre à ce type d’incident, le tout sous la direction d’un responsable dédié. Par ailleurs, des protections physiques autonomes sont généralement disponibles : soupape de surpression, clapet anti-retour, sprinkler etc. bien qu’ils soient parfois remplacés par des systèmes instrumentés de sécurité connectés.

Le contexte est donc propice à l’ajout d’une nouvelle procédure afin de répondre à une attaque informatique. Celle-ci consistera généralement en l’isolation du système d’information industriel de l’extérieur via une procédure dite de « bouton rouge ». Afin de rédiger la procédure associée, l’implication du personnel du site sera essentielle, notamment pour s’assurer que l’application de cette dernière ne soit pas plus nocive que l’attaque elle-même.

Un prérequis à la mise en place de posture d’isolement : la maitrise de ses flux et l’implémentation de cloisonnement/filtrage réseau

En effet, il est nécessaire de mesurer les impacts engendrés par l’usage du « bouton rouge ». Pour cela, il faut tout d’aborder lister les interconnexions du site industriel avec d’autres systèmes.

Lister les interconnexions avec d’autres systèmes d’informations

Il peut être intéressant de commencer par lister les flux entre le système d’information industriel et l’extérieur. En premier lieu, il convient de définir ce que contient ce système. Dans un cas basique, il regroupe les automates industriels, la supervision, ainsi que le matériel nécessaire à l’interconnexion des deux premiers.

D’autres équipements peuvent ensuite venir s’y greffer : un serveur d’historisation, des postes clients pour la supervision, un NAS etc. Ce réseau, nommé réseau industriel par la suite, est généralement connecté avec d’autres réseaux afin de partager des informations avec des équipements de ces derniers.

Il est notamment possible de citer :

• Des échanges avec l’ERP de l’entreprise (qu’un MES – Manufacturing Execution System soit présent ou non), généralement localisé sur le réseau bureautique ;
• Des échanges avec des partenaires : régulation des réseaux électriques, d’eau, de gaz etc.
• Des échanges avec des fournisseurs de service : météo, solutions cloud d’optimisation énergétique, de maintenances prédictives etc.

Ces flux, bien qu’utiles pour simplifier l’exploitation, peuvent généralement être temporairement coupés ou remplacés par des moyens de substitution (appel téléphonique pour indiquer les niveaux de production par exemple).

Par ailleurs, chaque site industriel est différent, et gère donc différemment ces interconnexions. Il est notamment courant de voir des réseaux MPLS dédiés aux sites industriels lorsque l’entreprise en possède plusieurs. Dans d’autres cas, le réseau bureautique sera utilisé pour les fédérer. Il en va de même pour les besoins de connexion entre ces réseaux industriels et Internet, qui passent parfois d’abord par le réseau bureautique, ou bénéficient d’une sortie directe.

Lister ses flux internes

Après avoir listé les interconnexions entre le réseau industriel et l’extérieur, il reste à lister les flux internes. La majorité de ces flux devraient être strictement nécessaires au bon fonctionnement du processus industriel, tels que ceux entre la supervision et les automates. La coupure de ces connexions nécessiterait donc de stopper le processus industriel, ou au minimum de le mettre en sûreté.

Il peut alors être intéressant de séparer les équipements et flux associés en plusieurs zones :

• Supervision ;
• Réseau de terrain ;
• Autres (postes clients de la supervision, serveur d’historisations, etc.).

La mise en place de ces zones permet de réduire drastiquement l’exposition de ces composants. En effet, seule la supervision devrait avoir accès aux réseaux de terrain, tandis que la catégorie « autres » ne devrait pouvoir accéder qu’à la supervision.

D’autres zones peuvent être nécessaires à implémenter telles que :

• Une zone d’administration : qui pourrait également être utilisée pour programmer les automates en fonction de la répartition des rôles et des responsabilités sur le site ;
• Une DMZ : pouvant accueillir un serveur relais afin que les équipements extérieurs au site industriel ne se connectent pas directement à la supervision pour venir récupérer les données de production etc.

En fonction des services proposés (serveur WSUS, serveur antivirus, Terminal Server pour la prise en main à distance etc.) d’autres zones peuvent bien évidemment encore être ajoutées.

Evaluer le réel besoin de ses flux

Après avoir listé l’ensemble de ces flux, il est intéressant d’identifier le besoin réel de chacun d’entre eux. Par exemple, est-ce vraiment nécessaire de pouvoir accéder à ses courriers électroniques depuis un serveur de supervision ?

Afin de limiter l’exposition du réseau industriel à l’extérieur, il pourrait également être nécessaire de sortir certains équipements de ce dernier. Par exemple, si une base de données accédée depuis le réseau bureautique est alimentée par la supervision, mais non utile à celle-ci, l’héberger directement sur le réseau bureautique peut s’avérer plus simple que de tenter d’en limiter les accès.

Une fois les flux nécessaires clairement identifiés, il convient de configurer les règles de filtrage associées de manière fine (adresse IP source, adresse IP destination, port de destination). Ce travail nécessite généralement un investissement humain important, principalement des équipes en charge du site industriel, ainsi qu’un coût matériel non négligeable pour se doter d’équipements de sécurité. C’est cependant un prérequis à la mise en place des postures de repli décrites par la suite. Dans un cas idéal, un filtrage applicatif (niveau 7 du modèle OSI) pourrait également être implémenté.

Ce travail, bien qu’essentiel à la mise en place de postures d’isolement, est également l’une des actions fondamentales à réaliser dans le cadre de la sécurisation d’un système d’information (industriel ou non). En effet, chaque flux coupé est un flux qu’il n’est pas nécessaire de surveiller, ainsi qu’un flux de moins exploitable par un attaquant.

Préparer ses postures de repli

L’isolation complète de l’ensemble des équipements d’un système d’information industriel n’est pas toujours souhaitable, même en cas d’attaque. Après avoir listé ces flux, il peut alors être intéressant de ne pas mettre en place une seule posture d’isolement, mais plusieurs postures de repli, permettant dans certains cas de pouvoir continuer à travailler presque normalement.

Posture de repli préventif : isoler l’usine en cas d’attaque sur un réseau tiers

Après avoir identifié les flux entre le réseau industriel et l’extérieur, il est possible de créer une posture de repli associée afin de les désactiver en cas de besoin. L’objectif de cette posture est de couper toutes les interconnexions du réseau industriel avec l’extérieur afin d’empêcher toute propagation d’une attaque. Une solution éprouvée est de regrouper ces flux sur quelques ports Ethernet dédiés. Ainsi, il suffit d’indiquer dans les procédures associées de débrancher les câbles associés pour activer la posture de repli. Cela évite également d’intervenir sur la configuration des pare-feux en cas d’incident de cybersécurité.

Par ailleurs, il est également nécessaire de définir les cas où cette posture devrait être activée. Si elle peut l’être sans poser de problème particulier à la production, ni ajouter trop travail au personnel du site, la question peut se poser de la réelle nécessité de ces flux.

Si cette posture a bel et bien des impacts sur les activités industrielles du site, il faut donc trouver un bon équilibre entre la déclencher trop tôt (dès que l’antivirus d’un poste de travail bureautique remonte une alerte), ou trop tard (après le chiffrement des premiers postes industriels). Cela dépendra également du contexte de l’entreprise et de ses moyens (équipe de veille sécurité dédiée ou non etc.).

Spécificité (sites distribués, non autonomes etc.)

Dans le cas où l’ensemble des flux avec l’extérieur n’ont pas la même destination, il peut être également intéressant de décliner plusieurs postures de repli spécifiques. En effet, si le prestataire en charge de la gestion des caméras du site alerte sur le fait qu’il subit une attaque par rançongiciel, il semble plus optimal de ne déconnecter que les flux entre ce prestaire et le réseau de l’usine, plutôt que l’ensemble des flux, incluant notamment ceux vers l’ERP.

Dans le cas où le processus industriel est distribué sur plusieurs sites (usine de production et de distribution notamment), l’activation de la posture de repli préventif ne devrait pas couper les flux entre ces différents sites. En effet, des liaisons spécifiques devraient y être dédiées. Si cela n’est pas le cas, utilisation du réseau bureautique pour assurer ces connexions par exemple, un projet de refonte du réseau industriel est probablement à prévoir (déploiement d’une VRF dédiée, ou d’un réseau SDWAN par exemple).

Enfin, il est toujours bon de rappeler que chaque usine étant différente, une étude locale sera à mener sur chacune pour en comprendre les spécificités.

Posture de repli de dernier recours : couper le système d’information en cas d’attaque avérée sur l’usine

Enfin, il peut être intéressant de préparer une posture de repli de dernier recours. Cette dernière devrait consister en l’isolation de chaque VLAN (si définis, de préférence avec une interface locale homme-machine par VLAN pour assurer un mode dégradé) ou de chaque équipement (extinction des commutateurs – switch) afin d’empêcher l’attaquant de continuer ses actions, qui, dans les cas d’attaques les plus avancées, pourraient cibler directement le processus industriel du site.

L’objectif est alors de mettre le site en sûreté ou d’en assurer les services essentiels. L’activation de cette posture implique de travailler sans système d’information, et ne devrait être appliquée qu’en cas de compromission avérée d’au moins un équipement du site puisqu’elle aboutit au même résultat immédiat qu’un rançongiciel, si ce n’est pire.

Un travail en amont avec les exploitants sera nécessaire afin de lister l’ensemble des actions à réaliser lors de l’activation de cette posture et définir des modes dégradés. En effet, cela va généralement nécessiter d’activer des astreintes afin de réaliser manuellement certaines tâches : vérification du bon fonctionnement des équipements, notamment sur les sites distants, utilisation des interfaces hommes-machines locales, etc. Par ailleurs, certains processus industriels ne sont plus pilotables manuellement aujourd’hui, et devront donc être compléments stoppés puisqu’aucun mode dégradé n’est disponible.

Afin d’estimer les impacts de l’activation d’une telle posture, il peut être intéressant de s’intéresser aux impacts listés en cas d’incendie ou de panne générale d’électricité. Par ailleurs, seul un test réel de cette posture permet de s’assurer de ses impacts opérationnels.

Comment récupérer après une attaque si elle n’a pu être circonscrite ?

Dans certains cas, l’activation des postures de repli peut ne pas suffire à protéger l’ensemble du système d’information industriel, notamment si elles sont activées trop tard. Il est alors essentiel de pouvoir procéder à la reconstruction de tout ou partie dudit système dans un temps suffisamment court pour limiter les impacts associés.

Les principaux prérequis nécessaires à la restauration d’un système d’information industriel sont listés ci-après.

Que faut-il sauvegarder pour pouvoir restaurer ses automates ?

Afin de pouvoir redémarrer l’usine, il est nécessaire dans la plupart des cas de commencer à restaurer les automates, ce qui nécessite deux éléments principaux.

Posséder une copie à jour de ses programmes automates

Les automates sont épargnés dans la plupart des attaques actuelles, probablement puisque cibler les postes Windows suffit aux attaquants pour atteindre leurs objectifs visés. Cependant, les attaques sont amenées à être de plus en plus ciblées, et la majorité des automates actuellement en service ne sont pas sécurisables (communications non chiffrées et non authentifiées, mots de passe par défaut, fonctionnalité d’administration non désactivables etc.).

Il convient donc de sauvegarder ces programmes, ce qui est déjà généralement le cas, notamment sur le poste de programmation (appartenant parfois à un prestataire) utilisé lors de la mise en service de l’appareil. Il est à noter que ces sauvegardes devraient être stockées sur au moins un support hors-ligne, de façon à ne pas les voir chiffrer au même moment que le poste les hébergeant.

Ces constats restent valables même pour les nouvelles gammes d’automates, qui, bien que bénéficiant d’un niveau de sécurité sans commune mesures avec leurs prédécesseurs, ne sont pour autant pas invulnérables.

Sauvegarder un moyen de télécharger ces programmes sur les automates

La majorité des automates nécessite un logiciel dédié pour être programmé. Et ce, même pour simplement télécharger un programme déjà écrit. Il convient donc de posséder une copie de ces programmes.

Dans certains cas, un poste de programmation déconnecté du réseau et réservé à cet usage peut être une solution. Il est cependant à noter que le maintien en condition de sécurité d’un tel poste peut rapidement s’avérer complexe. Si cette solution est sélectionnée, ce poste pourrait également héberger la copie des programmes automates. Garder un second jeu de sauvegarde hors-ligne (disque dur externe par exemple) serait cependant une sécurité supplémentaire.

Par ailleurs, si de nouvelles gammes d’automates sont utilisées, avec les dernières fonctionnalités de sécurité activées, d’autres éléments sont à sauvegarder tels que : les mots de passe des programmes automates, les certificats utilisés pour certaines communications (ou un moyen d’en regénérer) etc.

Ces prérequis sont également valables pour les équipements réseaux (pare-feux, commutateurs etc.).

Que faut-il sauvegarder pour pouvoir restaurer son matériel informatique essentiel ?

Identifier ce qui est vraiment nécessaire

La restauration des superviseurs, et des postes clients associés, revient généralement à restaurer un système Windows et les programmes associés. Plusieurs questions sont alors à se poser pour identifier les éléments à sauvegarder :

• Quels sont les équipements nécessaires ? Un poste d’ingénierie, un superviseur, quelques postes opérateurs ?
• Est-il possible de réinstaller le superviseur de zéro (nouvelles installations de Windows et du logiciel de supervision) puis d’y déposer une sauvegarde de la configuration du superviseur ? Est-ce réalisable en un temps suffisamment court ?
• Une copie complète du disque du superviseur ne serait-elle pas plus simple ? Il suffirait en effet d’insérer le disque sauvegardé pour redémarrer.
• Des modifications sont-elles régulièrement apportées au logiciel de supervision ? Si oui, est-il nécessaire de toutes les sauvegarder ? Dans ce cas, il parait complexe de réaliser une copie complète du disque à chaque fois.

Sauvegarder intelligemment

Dans la majorité des cas, les sauvegardes des postes Windows sont réalisées de la même manière que celles des programmes automates, c’est-à-dire en réalisant des copier/coller. Il pourrait alors être intéressant de s’intéresser aux mécanismes de sauvegarde automatique. Cependant, ces derniers sont probablement à proscrire pour les usines partant de zéro et ne bénéficiant pas d’un budget suffisant pour les installer sereinement. En effet, la mise en œuvre de ce type de solution de manière sécurisée reste généralement plus complexe que de réaliser une simple copie bit à bit d’un disque dur.

Ne pas négliger la documentation et l’entrainement

Avoir à disposition des sauvegardes complètes n’est cependant pas suffisant. Il est également nécessaire de rédiger les modes opératoires détaillés permettant de restaurer ces sauvegardes. En effet, si une crise venait à survenir, le stress des équipes, et l’indisponibilité potentielle de certains des sachants, pourraient mener à des erreurs de manipulations en l’absence de documentation.

Ces procédures n’ont pas vocation à permettre une restauration complète de l’ensemble des systèmes, mais au moins de permettre de redémarrer les éléments essentiels précédemment identifiés :

• Un poste d’ingénierie avec les logiciels de programmation automates associés ;
• Un superviseur ;
• Deux à trois postes de travail des opérateurs ;
• Les automates essentiels de l’usine.

Par ailleurs, il est généralement recommandé de bénéficier d’au moins deux jeux de sauvegardes, l’un stocké à proximité des équipements concernées, l’autre à stocker sur un site physiquement éloigné, et dont l’accès est limité à un nombre restreint de personnes. Il peut être tentant de stocker un jeu de sauvegarde supplémentaire en ligne, mais il est à noter qu’en cas de cyberattaque, et d’activation des postures de repli, il soit complexe de télécharger ces sauvegardes et de les déposer sur les systèmes à restaurer.

Enfin, il est essentiel de tester l’ensemble de ces procédures pour s’assurer qu’elles sont exhaustives. Un test pourrait par exemple être l’occasion de se rendre compte que la sauvegarde de la configuration du superviseur n’inclut pas la clé de licence, ou encore que les mots de passes configurés lors de la copie complète du disque aient été modifiés depuis sans en garder l’historique.

Conclusion

La gestion des crises est une composante importante du métier de beaucoup d’exploitants de systèmes industriels. Ces mêmes personnes sont également les plus en maitrise sur leur périmètre. Pour autant, il ne s’agit généralement pas d’experts en informatique. Des mesures pragmatiques, et adaptées à leur contexte, seront donc bien plus utiles qu’un guide générique de 200 pages regroupant l’ensemble des bonnes pratiques à appliquer sur un système d’information.

Tout comme en développement avec le principe KISS (Keep it simple,stupid), les postures de repli, ainsi que les procédures de restauration, devraient rester simples à comprendre, et stupides à appliquer.

Par ailleurs, bien que l’application d’une politique de filtrage réseau stricte ne peut qu’être conseillée, elle n’est pas strictement nécessaire à la mise en place des actions de sauvegarde et restauration. Ainsi, même si la probabilité qu’une attaque aboutisse n’en sera que plus forte, il sera toujours possible de restaurer les systèmes critiques.

Enfin, il est à noter que de plus en plus de processus industriels fonctionnent aujourd’hui en flux tendu. Dans ce type de contexte, la préservation du système industriel d’une attaque, ou la capacité de le restaurer rapidement, ne serait pas suffisant à maintenir le niveau de production si la gestion des commandes ou de la distribution par exemple sont indisponibles. La cyber résilience doit donc être prise en compte à l’échelle de l’entreprise, et non uniquement au niveau du site industriel.

Eléments clés

Pour répondre à une attaque avant qu’il ne soit tard il est nécessaire :

• D’impliquer les équipes industrielles (sans quoi il est fort probable que l’informatique survive à l’attaque, mais sans que l’usine ne continue de répondre à sa mission première) ;
• De maitriser ses flux et implémenter un cloisonnement/filtrage réseau afin de pouvoir mettre en place des postures de repli :
  • Préventives, afin d’isoler l’usine en cas d’attaque sur un réseau tiers sans pour autant impacter de manière trop significative le processus industriel ;
  • De dernier recours, afin de couper le système d’information en cas d’attaque avérée sur l’usine avant que l’attaquant ne modifie le processus industriel.
• De tester ces postures de repli, afin de s’assurer que leur activation ne soit pas pire que l’attaque.

Et dans le cas où l’attaque n’a pu être circonscrite, les éléments suivants sont généralement nécessaires afin de pouvoir récupérer de ladite attaque :

• Posséder une copie à jour de ses programmes automates ;
• Sauvegarder un moyen de télécharger ces programmes sur les automates ;
• Posséder au moins une copie de l’ensemble des sauvegardes critiques sur un support hors-ligne (disque dur externe par exemple) ;
• Identifier son matériel informatique essentiel (notamment afin de ne pas restaurer le serveur d’historisation avant celui de supervision…) ;
• Sauvegarder intelligemment, parfois une copie bit à bit du disque dur est plus efficace qu’une copie automatique sur un serveur dédié, généralement chiffré en même temps que le système dont il héberge les sauvegardes ;
• Ne pas négliger la documentation et l’entrainement (dans le cas contraire, une clé de licence oubliée, ou un sachant en vacances pourrait rapidement signer la fin de la restauration…).

[1] www.cert.ssi.gouv.fr/uploads/CERTFR-2020-CTI-001.pdf

Une nouvelle version de l’état de la menace a été publiée en ce début d’année : https://www.cert.ssi.gouv.fr/uploads/CERTFR-2021-CTI-001.pdf

Cet article Cyber résilience en milieu industriel est apparu en premier sur RiskInsight.

Pourtant, le volet IAM « Identity and Access Management » est souvent relégué au second plan dans les Programmes de mise en conformité LPM/NIS mis en œuvre par les Opérateurs d’Importance Vitale (OIV) / Opérateurs de Service Essentiel (OSE).

Comment comprendre cette situation et quelles leçons en tirer pour construire sa feuille de route IAM pour ses infrastructures critiques ?

L’IAM est un des piliers du volet cybersécurité de la LPM/NIS

Les mesures IAM à mettre en place sur les infrastructures critiques sont décrites dans les quatre règles suivantes :

Auxquelles il convient d’ajouter la règle portant sur les indicateurs (règle 20 pour la LPM et règle 4 pour NIS).

Les bonnes pratiques IAM habituelles à appliquer à tous les accès

Les exigences des trois premières règles reprennent les bonnes pratiques habituelles à appliquer à la gestion des comptes et des droits, tant pour les utilisateurs physiques que pour les processus automatiques accédant aux infrastructures critiques :

• Gérer le cycle de vie des utilisateurs, notamment les mutations et départs
• Affecter les droits selon le principe du moindre privilège
• Revoir (ou recertifier) régulièrement les droits affectés, a minima annuellement
• Contrôler et auditer les droits
• Attribuer des comptes et des moyens d’authentification strictement nominatifs

Le cadre ci-dessous résume les règles concernées :

Ces règles fixent un cadre mais laissent une grande liberté aux Opérateurs pour les décliner dans leur contexte.

Des comptes d’administration dédiés et soumis aux mêmes exigences

La quatrième règle (n°14 LPM et n°11 NIS) traite spécifiquement des comptes d’administration, destinés aux seuls personnels en charge de l’administration des infrastructures critiques : installation, configuration, maintenance, supervision, etc. L’exigence forte est la mise en place de comptes d’administration dédiés à la réalisation des opérations d’administration.

Au-delà du principe de moindre privilège explicitement mentionné, les comptes d’administration doivent respecter les mêmes exigences que les autres comptes telles que décrites précédemment.

Des indicateurs à produire pour surveiller les comptes à risque élevé

Enfin, la règle sur les indicateurs prévoit la définition de plusieurs indicateurs concernant la gestion des comptes présentant un niveau de risque élevé :

• Pourcentage de comptes partagés
• Pourcentage de comptes privilégiés
• Pourcentage de ressources dont les éléments secrets ne peuvent pas être modifiés

Au vu de ces exigences, l’intégration des infrastructures critiques dans les outils IAM (ci-après appelés « l’IAM ») de l’Opérateur apparaît comme la réponse nécessaire ; à compléter par l’application de mesures de durcissement (suppression, désactivation ou changement de mot de passe des comptes par défaut).

NB : les exigences LPM et NIS étant très similaires, nous emploierons par la suite le terme « OIV » pour désigner aussi bien les Opérateurs d’Importante Vitale et les Opérateurs de Service Essentiel, et le terme « SIIV » pour désigner les Systèmes d’Informations d’Importance Vitale et les Systèmes d’Informations Essentiels.

Pourtant, les Opérateurs hésitent encore à raccorder leurs infrastructures critiques à l’IAM

Les règlementations LPM et NIS ont accéléré la mise en place et le déploiement de solutions de bastion d’administration afin de sécuriser les accès d’administration. Cependant, bien que ces projets soient nécessaires, ils ne permettent de répondre que très partiellement aux exigences évoquées précédemment.

Ces règlementations devraient pourtant être un bon driver pour les projets IAM, mais les Opérateurs sont confrontés à deux principaux problèmes :

• La complexité d’intégration des systèmes industriels avec l’IAM – pour les Opérateurs industriels.
• Le risque induit par le raccordement des infrastructures critiques à l’IAM.

Des systèmes industriels complexes à intégrer

Les systèmes industriels présentent en effet des spécificités qui, d’une part complexifient le raccordement à un outil IAM, et d’autre part le rendent moins indispensable. Car, de façon générale :

• le nombre d’utilisateurs est limité ;
• ces systèmes sont cloisonnés, voire isolés du réseau d’entreprise ;
• la maturité sécurité des éditeurs et constructeurs est en retrait, les capacités d’interfaçage sont réduites, tant pour la gestion des comptes que pour la délégation d’authentification ;
• la granularité des droits d’accès est faible, se limitant souvent à autoriser l’accès ou non à l’ensemble du système, et non fonctionnalité par fonctionnalité.

Une intégration potentiellement génératrice de risques

Mais, au-delà de ces considérations propres aux systèmes industriels, les Opérateurs sont parfois réticents à mettre en place cette intégration, car elle est perçue comme génératrice de risques. En effet, si l’outil IAM ne présente pas un niveau de sécurité à la hauteur des règlementations, il pourrait paradoxalement constituer un point d’entrée sur les SIIV et ainsi amener de nouvelles vulnérabilités : création de compte ou attribution de droit illégitime, suppression malveillante de tous les comptes, etc.

Quant à mettre en place un IAM entièrement dédié au périmètre SIIV, cela représente un investissement très conséquent, parfois disproportionné, et qui ne permet pas de tirer tous les avantages d’un IAM mutualisé, par exemples les liens avec les sources autoritaires comme le SI RH.

Différentes approches d’intégration IAM permettent de répondre aux exigences règlementaires en maintenant un niveau de cloisonnement élevé

Dès lors, comment répondre efficacement aux exigences de la LPM et de la directive NIS ? Comment tirer parti des services proposés par les outils IAM sans ouvrir de nouvelle porte sur les infrastructures critiques ?

Nous distinguons différentes approches pour intégrer un système avec les outils IAM.

L’approche « délégation », à l’état de l’art mais fortement couplée

La première approche consiste à déléguer l’authentification et l’autorisation à l’IAM, en l’occurrence au service d’authentification et de contrôle d’accès, via un protocole de Fédération d’Identités (SAML2, OpenID Connect / OAuth2) ou via un raccordement Active Directory / LDAP.

Cette solution permet une gestion des comptes et des accès à l’état de l’art, mais rend le SIIV totalement dépendant de ce service et l’expose aux risques évoqués précédemment. Même en situation de crise, une isolation du SIIV serait difficilement envisageable.

Cette approche est donc plutôt à réserver aux applications qui fonctionnent déjà sur ce principe, typiquement les applications du SI de gestion avec un grand nombre d’utilisateurs. Pour les systèmes industriels, la solution à privilégier est de conserver le service d’authentification au sein du SIIV et d’opter pour une autre approche.

L’approche « provisioning », avec un niveau de couplage à ajuster au contexte

Cette approche consiste à conserver un système d’authentification et de contrôle d’accès propre au SIIV mais provisionné – c’est-à-dire alimenté – par l’IAM : les comptes et droits des utilisateurs sont stockés dans un référentiel interne au SIIV, et la solution IAM les gère au travers d’un connecteur. En fonction du niveau d’isolation souhaité, ce connecteur peut prendre différentes formes :

• Un connecteur automatique, permettant à l’IAM d’écrire directement les informations sur les comptes et accès dans le SIIV. Une isolation temporaire devient possible, en situation de crise ou en cas de détection d’activité anormale (par exemple : suppression massive de tous les comptes). Mais rien n’empêche un utilisateur malveillant ayant la main sur l’IAM de se donner accès au SIIV.
• Des ordres transmis aux administrateurs du SIIV (par ticket ITSM ou par mail) qui réalisent les actions manuellement. Un « sas » d’isolation est ainsi maintenu entre l’IAM et le SIIV, avec une étape de contrôle par les administrateurs.

Cette approche permet de bénéficier des processus de gestion des identités et des accès : validation et traçabilité des demandes d’accès, retrait des comptes et droits en cas de mutation ou de départ, etc. tout en préservant un degré de cloisonnement du SIIV.

L’approche « revue », orientée contrôle a posteriori

L’approche « revue » (également appelée « recertification ») se distingue des autres par le fait qu’elle repose sur une logique de contrôle a posteriori plutôt que de gestion a priori. Il s’agit cette fois d’analyser périodiquement les accès déclarés dans le SIIV afin de vérifier s’ils sont toujours légitimes. Cette vérification peut reposer sur un rapprochement des comptes avec un référentiel de collaborateurs (fichier RH, solution IAM, etc.), ou sur une validation explicite de la part des responsables des utilisateurs.

Ce peut être l’occasion de réaliser des contrôles approfondis (par exemple détection de combinaisons toxiques), de produire des indicateurs et des rapports d’audit.

Adapter son projet IAM – Infrastructures critiques à son niveau de maturité et à la typologie du SIIV

Sur la base de ces différentes options, nous proposons ci-dessous des pistes pour construire la feuille de route de mise en conformité LPM/NIS en fonction du niveau de maturité IAM et de la typologie des SIIV concernés.

Conserver la brique d’authentification et autorisation localement dans chaque SIIV

Il est préférable de conserver un référentiel de comptes et de droits d’accès localement dans chaque SIIV. Cependant, pour les systèmes déjà raccordés à un service mutualisé d’authentification et d’autorisation, le système mutualisé peut être conservé mais l’Opérateur doit lui appliquer les mesures prévues par la LPM et NIS : a minima le cloisonnement réseau, le durcissement, le maintien en conditions de sécurité, l’administration depuis un SI d’administration dédié, l’envoi des logs au SIEM, etc.

Dans un environnement de gestion des identités et des accès non mature, commencer par la revue des comptes et des droits

En l’absence d’outillage de gestion IAM mature, le moyen le plus rapide d’atteindre un premier niveau de maîtrise des risques et de conformité est de définir et mettre en œuvre un processus de revue régulière, sur une base a minima annuelle.

Sur un SIIV au nombre d’utilisateurs limité, le processus peut être déroulé manuellement, avec un niveau de qualité acceptable et une charge de travail raisonnable. Mais pour gérer des volumétries plus importantes, un outillage adéquat est à envisager : il facilite le pilotage des campagnes de revue et garantit la traçabilité des décisions. Il constitue en outre une opportunité pour envisager ensuite la mise en place d’un outil de gestion IAM.

Lorsqu’un outil de gestion IAM est en place, le sécuriser pour y raccorder les SIIV

Lorsque l’Opérateur dispose d’un outillage IAM mature, le provisioning des SIIV par l’IAM est recommandé : l’automatisation, la fiabilisation et la maîtrise que permettent les outils doivent compenser les risques induits par le couplage. A condition toutefois de garantir la sécurité de l’IAM : en complément des mesures techniques précédemment évoquées, l’Opérateur doit configurer l’IAM de sorte à ce que seuls les utilisateurs susceptibles d’accéder au SIIV peuvent demander l’accès, que le propriétaire du SIIV valide les demandes d’accès et puisse consulter facilement la liste des utilisateurs autorisés, et enfin que des contrôles permettent de détecter des anomalies sur les comptes et accès.

Le rehaussement de la sécurité profitera d’ailleurs à l’ensemble du Système d’Informations.

Trouver le bon équilibre risques / bénéfices pour construire son projet IAM – Infrastructures critiques

Ces propositions doivent permettre à tout Opérateur de construire sa feuille de route IAM pour ses infrastructures critiques en trouvant le bon équilibre entre les bénéfices apportés, les risques induits et le coût de mise en conformité.

Cet article Quelle approche pour gérer les identités et les accès sur les infrastructures critiques ? est apparu en premier sur RiskInsight.

La sécurité des Systèmes d’Informations Industriels (SII) est aujourd’hui au centre des préoccupations dans les entreprises concernées. Ces systèmes permettent une action directe dans le monde « physique » à l’aide d’instructions provenant du monde « logique » et pilotent les outils de production de nombreuses entreprises.

Du fait du manque de sécurité de ces systèmes, de nombreuses attaques ont été recensées dans le monde ces dernières années. La dernière en date ayant eu le plus gros impact est l’attaque du réseau électrique de l’Ukraine en décembre dernier [1]. De nombreuses personnes se sont retrouvées sans électricité suite à une attaque du réseau industriel.

Le plus bas niveau des SI industriels est le réseau de production. Les capteurs et les actionneurs sont reliés aux entrées/sorties des automates industriels. Les protocoles utilisés pour communiquer avec ces automates sont généralement des protocoles propriétaires. Parmi les plus utilisés, on retrouve : Modbus, S7comm, DNP3, Profibus, Hart… Ces protocoles manquent souvent des principales fonctions de sécurité à savoir l’authentification et le chiffrement des flux. Il est donc possible de rejouer des requêtes et de réaliser des actions malveillantes directement sur les automates.
Modbus, protocole de Schneider Electric publiquement documenté et libre de droits, est une norme de référence pour les communications industrielles. De nombreux outils utilisant ce protocole existent pour communiquer avec les automates Schneider :

Cet article S7comm : un outil de communication avec les Automates Programmables Industriels Siemens est apparu en premier sur RiskInsight.