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.

Les Systèmes de Contrôle Industriel (ICS – de l’anglais Industrial Control Systems) sont des systèmes complexes visant au contrôle des processus industriels. De nombreux secteurs mettent en œuvre des ICS : l’énergie, le nucléaire, les transports, la chimie… Ces systèmes contrôlent, au sein des processus de production des entreprises ou des états, beaucoup d’actifs critiques. Leur compromission peut être source de risques majeurs sur l’environnement et la sécurité des populations.

La sécurisation des ICS est de ce fait cruciale et, en raison de leur nature complexe (les ICS sont généralement des superpositions de technologies diverses, dont la durée de vie est plus élevée que les systèmes d’information classiques), cette sécurisation sera d’autant plus difficile.

En vue de répondre aux besoins et futures attentes de ses clients, Wavestone a mené une veille cybersécurité centrée spécifiquement sur les ICS. Pour 2017, plus de 80 études, attaques, incidents et autres rapports publiés sur la sécurité des ICS ont été étudiés de façon approfondie.

La suite de cet article détaille les leçons qui peuvent en être tirées.

Alors, que pouvons-nous dire de 2017 ?

Premièrement, il est clair que les ICS ont subi leur lot d’attaques cette année. Et, plus que les années précédentes, celles-ci ont eu un impact mondial. Alors que les attaques sur les ICS se cantonnent traditionnellement à des périmètres restreints,  tels un équipement ciblé (équipements de santé,…), une usine (un malware visant à « miner » des monnaies virtuelles a par exemple été trouvé sur les systèmes d’une usine de traitement des eaux – voir détails ci-dessous) voire une région (les sirènes d’alerte incendie en Avril 2017 à Dallas par exemple), 2017 a vu certaines d’entre elles démarrer à un échelon local, et se répandre rapidement sur de nombreuses lignes de production à travers le monde (WannaCry et NotPetya principalement).

En 2017, plusieurs attaques ont marqué les actualités grand public. De plus, de nombreux gouvernements, agences nationales ou personnalités politiques ont alerté quant à des attaques, ou tentatives d’attaques, sur des infrastructures critiques. L’énergie fut semble-t-il le secteur le plus visé. De nombreux incidents survenus en Turquie (janvier), aux Etats-Unis (mars et juillet), dans les Etats Baltes (mai), au Royaume-Uni (juillet), en Irlande (juillet) ont montré que ce secteur constituait une cible de premier plan pour les attaquants (qu’ils soient mandatés par des Etats ou non).

Le secteur de l’énergie ne fut pas le seul en alerte cette année : les problèmes de sécurité détectés sur les voitures autonomes ont également fait les gros titres (ce sujet n’étant cependant pas totalement du domaine des ICS). Cela est principalement dû au fait que la cybersécurité des automobiles est un marché encore émergent. Aujourd’hui, les experts en sécurité recherchent des failles et vulnérabilités (par exemple, des vulnérabilités ont été trouvées dans les unités de contrôle des airbags), alors que les constructeurs initient des partenariats et initiatives dans le but de démontrer que la cybersécurité est désormais un de leurs principaux centres d’intérêt (par exemple General Motors a invité des hackers à éprouver la sécurisation de ses véhicules).

Enfin, le marché de la cybersécurité des ICS est en pleine expansion, comme en témoignent les nombreux partenariats et levées de fond enregistrés cette année. Plus généralement, trois catégories d’acteurs peuvent être identifiées sur le marché de la cybersécurité des ICS :

• Les pure-player de la cybersécurité ICS : généralement des entreprises de petite taille ou des start-ups. Ces acteurs se concentrent sur le développement et la mise sur le marché de solutions dédiées aux ICS (Sentryo, CyberX, Nozomi …);
• Les fournisseurs ICS : l’année dernière, plusieurs fournisseurs de solutions ICS ont initié des partenariats avec des entreprises du premier groupe (les pure-player) dans le but d’améliorer la sécurité de leurs systèmes (par exemple, les partenariats Siemens-PAS en septembre, ou Schneider-Claroty en août);
• Les entreprises de cybersécurité : ces entreprises (bien connues dans le monde des technologies de l’information) adaptent leurs solutions au contexte industriel. Elles démontrent un intérêt croissant pour les ICS, notamment en publiant des rapports et analyses d’attaques spécifiques au domaine (par exemple Kaspersky, McAfee).

Que peut-on attendre des prochaines années ?

Il est (malheureusement) relativement évident que la cybersécurité des ICS sera encore un sujet d’actualité majeur, au vu notamment des alertes lancées sur de potentielles attaques visant des systèmes critiques et dangereux pour certaines vies humaines, tels que les contrôleurs de sûreté instrumentés. Mais nous pourrions observer également de plus en plus d’évènements touchant des secteurs spécifiques, comme le secteur maritime, les transports, la santé…qui ne sont aujourd’hui pas aussi exposés que l’énergie et le nucléaire dans les médias. Le marché de la cybersécurité des ICS devrait poursuivre son essor, appuyé particulièrement par des partenariats et acquisitions. Les systèmes de contrôle industriel continueront à affronter de nouvelles menaces, et des défis sans cesse renouvelés.

>>Dernières actualités:

	CyberX lève 18 millions de dollars dans la lutte contre les menaces visant les IIOT et infrastructures critiques, portant son financement total à 30 millions de dollars (CyberX, 27 Février) CyberX a annoncé une levée de fonds de 18 millions de dollars, dans le but de développer des outils de détection de menaces dans le domaine des IIOT (Industrial Internet of Things) et des infrastructures critiques. Cette entreprise développe une plateforme de surveillance des menaces et réduction des risques, qui incorpore des modules de threat intelligence spécifiques aux ICS. Lien vers le communiqué de presse
	Jouons avec Modbus 0x5A (Blog Security Insider, 9 Février) Lors de la dernière édition de la DefCon à Las Vegas, Wavestone a présenté une étude sur la sécurité du protocole ModBus, et plus spécifiquement sur la fonction 90. Grâce à cette fonction, un attaquant pourrait démarrer ou arrêter un contrôleur, ou le forcer à envoyer en sortie une donnée prédéterminée. Lien vers l’article
	Résultats de l’ICS Detection Challenge (Dale Peterson, 7 Février) En Janvier, la conférence S4x18 a hébergé l’ « ICS Detection Challenge ». Quatre entreprises ont répondu au défi lancé : Claroty, Gravwell, Nozomi Networks et Security Matters. La première partie du défi consistait en l’évaluation de trois produits de détection ICS : Claroty, Nozomi Networks and Security Matters, et fut remportée par Claroty Les produits présentés par les compétiteurs devaient détecter des cyberattaques et incidents touchant une entreprise du domaine de l’énergie. Lien vers les résultats
	Une compagnie des eaux Européenne touchée par un malware de minage Bitcoin (eWeek, 7 Février) Un malware de minage Bitcoin a été détecté par  l’entreprise de cybersécurité Radiflow au sein des réseaux d’un fournisseur d’eau Européen. Dans un premier temps, ce malware a été téléchargé depuis un site publicitaire infecté, puis s’est propagé au réseau SCADA, qui fonctionnait toujours sous Windows XP. Le malware dégradait la performance du système, mais les opérateurs de la compagnie ne l’avaient pas encore remarqué. Lien vers l’article
	Le distributeur d’énergie ukrainien prévoit 20 millions de dollars pour un plan cyberdéfense (Reuters, 6 Février)  Le distributeur national d’énergie en Ukraine, Ukrenergo, qui a été la cible de nombreuses cyberattaques ces deux dernières années  (Décembre 2016 et Décembre 2017), va investir 20 millions de dollars dans un nouveau système de cyberdéfense. Les dirigeants d’Ukrenergo ont indiqué avoir identifié, avec l’aide de consultants à l’international, environ 20 menaces pour sa sécurité qui seront adressées par le nouveau système. Le principal objectif est de rendre « physiquement impossible la perturbation du système énergétique Ukrainien par des menaces extérieures ». Lien vers l’article
	Une étude publiée sur l’augmentation du nombre de systèmes industriels accessibles depuis Internet (Security Week, 2 Février)  Un rapport publié par Positive Technologies explique que le nombre d’ICS accessibles depuis Internet a augmenté de manière significative en une année. La plupart des vulnérabilités de ces systèmes pourraient être exploitées à distance, sans qu’aucun privilège ne soit requis. Les principaux types de vulnérabilités sont l’exécution de code à distance (24%), la divulgation d’informations (17%), et les débordements de tampon (12%). La plupart de ces systèmes sont accessibles via HTTP, mais également par le protocole Fox (protocole de construction automatisée, lié au framework Niagara), Ethernet/IP, BACnet, et Lantronix Discovery Protocol. Lien vers l’article | Lien vers le rapport [PDF
	Un faille dans un logiciel de stations essence permet à des hackers de changer les prix, voler du carburant et supprimer les traces de leur passage. (Motherboard, 31 Janvier) Des chercheurs en sécurité informatique ont réussi à se connecter à une interface web de gestion d’une station essence grâce à Shodan (moteur de recherche des objets connectés). Après avoir utilisé les identifiants administrateurs par défaut, puis un nom d’utilisateur et son mot de passe codés en dur, les chercheurs ont stoppé les pompes à essence, intercepté des paiements par carte bancaire et volé  les numéros de ces cartes. Lien vers l’article
	Le gouvernement britannique appelle les industries sensibles à se préparer aux cyberattaques (Sky news, 29 Janvier) Toutes les entreprises engagées dans des industries critiques et services essentiels, tels que l’énergie, les transports, l’eau, la santé et les infrastructures numériques, ont reçu une alerte du gouvernement britannique, annonçant que des sanctions seraient prises si celles-ci n’intègrent pas des règles de cybersécurité à leurs systèmes. Les premières amendes vont être émises alors  que le gouvernement retranscrit la directive NIS (Network and Information Systems), permettant ainsi de couvrir des évènements semblables aux attaques WannaCry. Lien vers l’article
	Les outils de gestion de licences Gemalto exposent des ICS et entreprises à des attaques (Security week, 22 Janvier) Les chercheurs du Kaspersky Lab ont détecté 14 vulnérabilités dans le produit logiciel Gemalto Sentinel LDK et le matériel USB Dongle (SafeNet) associé. Le dongle USB est utilisé pour activer le logiciel. Une fois le matériel connecté, des drivers sont installés et le port 1947 est ajouté aux exceptions du pare-feu local de Windows. Ce port peut par la suite être utilisé pour identifier des équipements accessibles à distance. Lien vers l’article
	Le ransomware SamSam touche des hôpitaux, municipalités et entreprises ICS (Bleeping Computer, 19 Janvier) L’entreprise Hancock Health a admis avoir payé la rançon demandée (d’un montant de 55.000$), bien que des sauvegardes des SI touchés aient été disponibles. Ce ransomware se propage par brute-forcing des connexions RDP. Lien vers l’article
	Les systèmes industriels essaient de répondre à Meltdown et Spectre The Register, 18 Janvier  Les vulnérabilités Meltdown et Spectre ont également eu des impacts sur les ICS. Certains fournisseurs ont décidé de communiquer publiquement sur leurs produits vulnérables (OSISoft par exemple) ; d’autres, tels qu’Emerson et General Electric, ont conservé ces informations pour leurs clients uniquement ;  certains enfin sont toujours en phase d’investigation afin de savoir si leurs produits sont vulnérables. Lien vers l’article Pour plus d’ information sur les vulnérabilités Meltdown et Spectre,l’article de  Wavestone sur Security Insider peut être consulté
	Des chercheurs détectent 147 vulnérabilités au sein de 34 applications mobiles SCADA SC Magazine, 11 Janvier Des chercheurs d’ IoActive et Embedi ont trouvé 147 vulnérabilités dans 34 applications mobiles liées à des systèmes SCADA (Supervisory Control and Data Acquisition). Les principales vulnérabilités sont : possibilités d’altération du code, autorisations mal gérées, stockage des données non sécurisé… Ces failles de sécurité permettraient à un attaquant de compromettre les infrastructures d’un réseau industriel par le biais de ces applications vulnérables. Lien vers l’article
	Nozomi, spécialisée dans la cybersécurité industrielle, lève 15 millions de dollars (Security Week, 10 Janvier) Nozomi est une entreprise de cybersécurité industrielle, et avait déjà levé 23,8 millions de dollars récemment. Son offre, “SCADAguardian”, met en œuvre apprentissage automatique et analyse comportementale afin de détecter en temps réel des attaques 0day. Cette technologie permet de répondre rapidement aux alertes levées par les ICS. L’entreprise a annoncé que ces fonds supplémentaires seraient dédiés à l’extension géographique de son marketing, de ses ventes et de son support, ainsi qu’à l’innovation. Lien vers l’article

>>Main ICS vulnerabilities

>>Recent and upcoming ICS events

24-26 Avr.	ICS Cyber security London, UK
24-26 Avr.	Industrial control systems (ICS) Cyber Security Conference Singapore
9-10 Avr.	Cyber Security for critical assets MENA Dubai, UAE
27-29 Mar.	Cyber Security for Energy & Utilities Abu Dhabi, UAE
13-14 Mar.	Maritime Cyber Security London, U.K
6-7 Mar.	Cyber Security for critical assets USA Houston, USA

Cet article Newsletter cybersécurité des Systèmes de Contrôle Industriel (ICS) #1 – Que retenir de 2017 ? est apparu en premier sur RiskInsight.

Des risques bien réels : les exemples Jeep Chrysler et Tesla

Une voiture autonome, c’est par définition une voiture connectée : GPS, capteurs, accès Internet par 3G/4G… Tous ces éléments sont autant de portes d’entrée vers une voiture qui devient ni plus ni moins qu’un réseau où sont connectés des dizaines d’ordinateurs spécialisés. Ces derniers sont en charge de gérer les différents composants du véhicule. Volant, frein, accélérateur, tous doivent être informatisés pour que le « cerveau » de la voiture autonome puisse les diriger.

La combinaison de ces connexions externes et de l’informatisation des fonctions de conduites pose aujourd’hui des risques bien réels. Pendant longtemps jugées théoriques, la capacité d’attaque des voitures connectées a été démontré dans 2 cas emblématiques. Le 1^er visait une Jeep Chrysler, a l’été 2015. Charlie Miller et Chris Valasek ont montré comment, après plusieurs années de recherche, ils ont pu prendre le contrôle du véhicule de série à distance. En aout 2016, ils ont montré qu’ils pouvaient aller encore plus loin dans la capacité à contrôler les fonctions de pilotage. Le 2^ème a touché Tesla en septembre 2016, dans le même esprit une équipe de chercheurs Chinois de Tencent a réussi à piéger une Tesla et à en prendre le contrôle intégralement.

Derrière, les conséquences ont été lourdes : impact sur l’image des constructeurs et surtout programme de rappel coûteux pour Jeep Chrysler via l’envoi de clés USB aux millions de clients concernés. Tesla, plus habitué à l’environnement cyber, disposait de moyens pour mettre à jour ces véhicules à distances et a réussi en une dizaine de jours à couvrir ces failles. À noter que ce délai est particulièrement court par rapport au contexte actuel des objets connectés.

Une prise de conscience en progression

Ces deux démonstrations ont fait prendre conscience au grand public et aux constructeurs des enjeux de la cybersécurité. Beaucoup d’entre eux investissent et se renforcent sur cet aspect. Volkswagen vient par exemple d’investir pour créer la société Cymotive. Tesla a lancé historiquement un programme de « bug bounty » permettant aux chercheurs en sécurité d’être rémunérés s’ils trouvent des failles sur les véhicules, ceci pouvant éviter aussi que ces failles soient revendues sur les marchés noirs de la cybercriminalité.

Le crash test cyber ou comment bien choisir sa voiture autonome !

Tous les constructeurs ne sont pas au même niveau de prise de conscience et d’investissement. Mais alors comment en tant que particulier choisir une voiture qui sera « cybersécurisée » ? Aujourd’hui, au-delà de quelques papiers de recherche, il n’y a pas de moyens simples de répondre à cette question. Il serait temps que les organismes en charge des crash-test, tel qu’EuroNcap, s’empare du sujet et définissant des indicateurs de cybersécurité d’un véhicule ! Quelques éléments simples peuvent permettre d’évaluer le niveau de sécurité : niveau d’isolation des fonctions de pilotage de celle de connexion à Internet, capacité de mise à jour fiable et non bloquante, alerte du conducteur et du constructeur en cas d’attaque…

Ceci permettrait simplement, par un système d’étoiles compréhensible par tous, d’évaluer la cybersécurité des véhicules. Les clients pourraient alors faire leur choix en connaissance de cause. Et comme pour les crash tests habituels, cela mobiliserait les constructeurs sur la cybersécurité !

Cet article Crash test cyber : la solution pour sécuriser la voiture autonome ? 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.

Cet article Dossier – La Responsabilité Environnementale (Partie 2) est apparu en premier sur Insurance speaker.

Cet article Dossier – La Responsabilité Environnementale (Partie 2) est apparu en premier sur RiskInsight.

Cet article Dossier – La Responsabilité Environnementale (partie 1) est apparu en premier sur Insurance speaker.

Cet article Dossier – La Responsabilité Environnementale (partie 1) est apparu en premier sur RiskInsight.

Il ne s’agit pas de la seule méthode qui peut être imaginée pour pirater un avion, et la maintenance au sol peut aussi être un moment de choix pour s’infiltrer dans le système informatique d’un avion.
Quels sont les risques et comment s’en prémunir ?

Piratage d’un avion depuis le siège passager : un scénario probable ?

Si le récit fait par Chris Roberts a rendu quelques experts dubitatifs, le FBI prend la menace très au sérieux. En effet, l’événement a suscité l’ouverture d’un mandat d’investigation. Celui-ci a révélé que le matériel saisi à sa descente d’avion par le bureau fédéral se composait notamment d’un câble réseau modifié qui lui aurait permis de connecter son ordinateur au système.

Quelle réalité du risque ?

L’utilisation de plus en plus courante de technologies standardisées ou universelles (type port Ethernet) à la différence des particularités de la construction aéronautique conduit à faciliter les cyberattaques puisqu’elles nécessitent moins de connaissances spécifiques à l’aviation.

En raison de l’utilisation de réseaux multiplexés, des passerelles existent entre le système destiné aux passagers et le système avionique qui permet de contrôler l’avion (navigation, communication, pilote automatique…).

Quels scenarii de risque ?

Plusieurs scenarii peuvent être imaginés à partir de ces risques d’intrusion. En effet, le piratage des outils informatiques des autres passagers par le biais du WiFi ou d’un câble Ethernet branché sur le système ouvert est une possibilité. Il serait également possible d’accéder aux informations de communication de l’avion pour diffuser de faux messages sur les écrans des passagers afin de créer des mouvements de panique.

Mais on pourrait également imaginer des injections de logiciels malveillants, des actions sur des systèmes critiques (désactivation ou activation d’équipements de sécurité…).

Maintenance au sol : des avions connectés par 3G ou Wi-Fi

Aujourd’hui, les opérations de maintenance logicielle sur les avions les plus modernes (B787, A380 et A350) peuvent être réalisées à distance. Elles nécessitent une suite logicielle sol, développée par le constructeur, déployée dans la zone de confiance de la compagnie. Ce système sol communique avec l’appareil, lorsqu’il est au sol uniquement, par une connexion 3G ou Wi-Fi avec l’avion afin d’opérer diverses opérations de maintenance informatique. La chaîne de liaison se veut très sécurisée : infrastructure d’authentification en partie cloisonnée, lien VPN, signature de tous les composants. Néanmoins, elle constitue une faille potentielle supplémentaire d’intrusion et de corruption du système.

Quels risques peuvent être identifiés ?

Dans ce cas de figure, le risque de sabotage est prépondérant. Les fonctions avioniques critiques ont peu de chances d’être touchées. Mais des données EFB erronées donneraient déjà des sueurs froides aux pilotes. Les EFB (Electronic Flight Bag) sont des équipements d’aide au vol (carte, approche d’aéroport, procédures…). Une intervention frauduleuse sur ces données semble alors plus probable par une corruption du système que par une attaque directe de l’avion. En effet, elle ne permettrait pas de contourner les mécanismes de signature électronique. Néanmoins, elle est loin d’être infaillible. En effet, de nombreuses attaques reposent désormais sur du vol de certificats, voire des attaques par rebond visant déjà l’émetteur des certificats afin de produire des certificats falsifiés, qui permettent par la suite de conduire l’attaque finale.

Comment atténuer les risques ?

Face à la multiplication des cyberattaques, une coordination européenne est nécessaire pour mettre à jour les mécanismes de sécurité. Elle permettrait d’assurer leur bon déroulement, afin de tenir compte des attaques et des failles les plus récentes. Elle développerait également davantage la certification des systèmes au sol comme à bord. Ces opérations sont potentiellement complexes dans le monde de l’aérien avec les principes de certification des équipements.

La mise en place d’une évaluation du risque selon une approche holistique, qui prendrait en compte tous les cas de figure possibles (risques internes et externes à l’entreprise), permettrait une meilleure identification des acteurs se connectant aux systèmes impliqués dans le fonctionnement de l’aviation civile.

Les récentes annonces sur la sécurité des automobiles connectées montrent que les problèmes de cybersécurité sont de plus en plus prégnants dans les systèmes embarqués, quel que soit le secteur d’activité !

Cet article Cybersécurité dans l’aérien : pirater un avion, c’est possible ? est apparu en premier sur RiskInsight.

Quels sont les risques de ces évolutions dans l’environnement aérien ? Comment s’en prémunir ?

Pourquoi le passage au protocole IP

Le protocole IP va devenir le standard général d’échange de données pour le contrôle aérien, dans le but de mettre en place un système de communication performant entre le sol et l’avion, ainsi qu’entre les avions eux-mêmes.

Les avions, naviguant désormais très précisément, peuvent ainsi négocier des ajustements de trajectoire en permanence. À terme, l’usage du protocole IP et des moyens de navigation satellitaires permettront de fluidifier le trafic aérien et d’améliorer la performance de l’espace aérien. Cette nouvelle génération de gestion du trafic aérien est mise en place aux États-Unis (programme NextGen) comme en Europe (programme SESAR – Single European Sky Air Traffic Management Research).

De nombreux acteurs seront connectés en même temps par le biais du système de gestion des données au sol SWIM (System Wide Information Management). Ce système permet de connecter de nombreux services comme la météo, le contrôle aérien, ainsi que différentes informations transmises par les compagnies aériennes et les aéroports.

À quels risques doit faire face l’environnement aérien ?

L’augmentation de la connectivité entre les différents systèmes d’information multiplie donc les possibles points d’entrée pour une attaque informatique. Des vulnérabilités nouvelles sont à prendre en compte, notamment par l’attaque des points les plus faibles comme les systèmes d’information des compagnies aériennes qui sont, par nature, plus ouverts vers le monde extérieur. Même si des systèmes de protection peuvent être mis en place pour protéger les différents SI communicant entre eux, la découverte et l’exploitation d’une faille n’est jamais qu’une question de temps.

Par ailleurs, les aéronefs communiquent sur le réseau hertzien, notamment avec des liaisons de données non cryptées (ADS-B – Automatic Dependent Surveillance Broadcast). Il est donc possible de capter des données en mode lecture en se connectant à la bonne fréquence et, par exemple, de géolocaliser des avions facilement. C’est ce que font certains sites internet comme flightradar24 qui présente une carte des avions en temps réel.

Des attaques par déni de service ou dans l’objectif de déstructurer le système afin de provoquer une crise de confiance (forcer l’envoi de fausses informations) sont donc plausibles. Elles pourraient rendre des centres de contrôles, et donc des espaces aériens entiers, inopérants pour des durées potentiellement longues comme dans le cas des avions de LOT.

Face aux diverses menaces, comment réagir ?

Le rapport du GAO est un signal d’alerte pour les problématiques similaires que peut rencontrer l’Europe notamment avec le programme SESAR. Il est nécessaire de réestimer les programmes en cours à l’aune de la cybersécurité. Une plus grande coordination à l’échelle européenne permettrait de prendre conscience d’un plus grand nombre de risques et de mettre en place des mesures de protection appropriées.

Le développement d’un domaine réglementaire fixant clairement les dispositifs de gouvernance et dont les rôles de chacun permettraient également de coordonner les efforts de chaque acteur afin d’éviter les redondances ou les impasses sur certains sujets de sécurité.

Toutes ces thématiques sont actuellement un sujet d’intérêt pour nombre d’autorités européennes comme en témoignent l’étude lancée par la SESAR Joint Undertaking en mai 2014 et la conférence  organisée par l’EASA (European Aviation Safety Agency) sur la cybersécurité pour l’aérien en mai dernier. À l’échelle de la France, des groupes de travail existent sur ces sujets au niveau de l’ANSSI et de la DGAC.

Les risques sont donc connus, les acteurs identifiés, il faut maintenant aller vite et bien accompagner les acteurs qui conçoivent les systèmes pour éviter l’apparition de dispositifs vulnérables qui ne pourraient pas, notamment, être mis à jour en cas d’apparition de nouvelles menaces !

Cet article Passage au protocole IP : quelles conséquences pour la cybersécurité dans l’espace aérien ? est apparu en premier sur RiskInsight.

Cet article Quand Pacifica et Airbus Defence and Space s’allient contre les risques climatiques agricoles est apparu en premier sur Insurance speaker.

Cet article Quand Pacifica et Airbus Defence and Space s’allient contre les risques climatiques agricoles 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.

Le contexte : une menace persistante et croissante

Dans le courant des années 90, un certain nombre de producteurs de biens de consommation électroniques (Compaq, Intel, Sun Microsystèmes…) ont commencé à s’inquiéter du volume des pertes financières associées au vol de leurs marchandises. À cette époque, l’industrie électronique américaine chiffrait ses pertes pour vol à environ 3 millions de dollars US par an (chiffre estimé à 60 milliards de dollar US aujourd’hui, tous biens manufacturés confondus). Sous l’impulsion de trois responsables de la sécurité industrielle de ces sociétés, l’association TAPA s’est réunie pour la première fois en juin 1997, avec pour objectif de développer des normes et recommandations pour renforcer la sécurité et diminuer les vols.

Que vole-t-on aujourd’hui ? Des produits manufacturés, des produits électroniques de grande consommation, des produits alimentaires et boissons, des métaux, du textile, prêt à porter…Ces produits sont « prélevés » tout au long de la chaîne logistique. L’évolution de la menace est maintenant telle que l’enjeu n’est plus d’éviter le vol, mais de mettre en place des dispositifs afin de minimiser les impacts sur la supply chain et ses acteurs. TAPA fournit ainsi des éléments pour développer une protection active de la chaîne logistique.

TAPA, qu’est-ce que c’est ?

TAPA est un réseau de professionnels composé de membres appartenant à 3 cercles distincts. Le premier cercle regroupe les professionnels qui assurent tout au long de la supply chain des rôles de fabrication, transport, stockage, assurance. Le deuxième cercle comprend des professionnels qui offrent des services de sécurité à ceux du premier cercle. Le dernier cercle regroupe les acteurs du secteur public, les auditeurs sécurité, ainsi que les enseignants et étudiants spécialisés sur le crime organisé / droit / logistique.

Une animation est par ailleurs assurée sur une base régionale (Amérique, Europe / Afrique / Moyen Orient, Asie / Pacifique), au travers de rencontres, les « TAPA « T » meetings ».

TAPA est également un ensemble de normes. La première norme établie par la TAPA est la C-TPAT (2001), qui regroupe un ensemble de recommandations pour améliorer la sécurité des frontières des États-Unis. En 2005 la norme TSR (Trucking Security Requirements) a été diffusée. Elle vise à établir des critères d’évaluation de la sécurité des transports. Cette même année, la norme FSR (Freight Supplier security Requirement) a été élaborée : elle fixe des exigences de sécurité sur l’ensemble de la supply chain. En 2011, la norme FSR a évolué pour se focaliser sur les exigences sécurité des entrepôts : Facility Security Requirement.

Depuis 2011, deux nouvelles normes ont été déployées : l’une (TACSS) pour l’aérien, l’autre pour les Parcs de stationnement (IRU/ transpark).

TAPA est enfin une base de données. Dénommée « IIS » pour « Incident Information Service », cette base répertorie par région les incidents. Elle permet d’identifier les tendances et « zones à risque ». Elle formalise un profil du risque encouru pour chacun de ses membres. Elle constitue également un vecteur d’échange d’informations entre acteurs de la supply chain et agents de protection.

Quels apports du TAPA pour les entreprises ?

Les normes et recommandations TAPA permettent à tout professionnel de se faire rapidement une idée de la maturité sécurité de son organisation. Nous recommandons en particulier la norme FSR 2011 « Freight supplier minimum security requirement » à tout responsable industriel (logistique, fabrication, sécurité), car cette norme permet d’effectuer un balayage large de tous les dispositifs – défenses au sens de J. Reason – qu’il convient de mettre en place.

Nombre de sociétés se focalisent en effet sur les dispositifs techniques et « oublient » qu’au-delà de ces systèmes il convient de mettre en place une organisation et des moyens de traitement de l’information.

En dernier lieu, le volet humain n’est pas oublié. En effet, une organisation industrielle qui ne s’appuie pas sur des hommes sensibilisés, entraînés et formés pour répondre aux menaces quotidiennes, est une organisation vulnérable et faiblement résiliente. Au-delà du caractère « terrain » de ces normes, celles-ci s’inscrivent parfaitement dans toute démarche ISO 28000.

Cet article TAPA ou la sécurité des transports de marchandises…vous connaissez ? est apparu en premier sur RiskInsight.

Les initiatives posent la question de la sécurité de l’information

Un système de transports intelligents, quel qu’il soit, permet de diffuser et partager de l’information, de la traiter de manière autonome et intelligente. Les objectifs de telles évolutions ? Ils sont multiples : optimiser la gestion de trafic, améliorer la sécurité routière, aider à développer la multi-modalité, etc.

De tels usages nécessitent l’échange de nombreuses informations, entre les véhicules, ou entre les véhicules et les infrastructures routières : vitesse, positionnement GPS, changement de trajectoire, alertes sur le trafic… Protection des données à caractère personnel, préservation de l’intégrité des informations, disponibilité des dispositifs qui concourent à la sécurité routière : les enjeux de sécurité de ces informations ressortent clairement comme essentiels pour que la voiture connectée de demain donne confiance aux usagers.

Ces transformations font aujourd’hui l’objet de réflexions de standardisation et de normalisation menées par divers groupes de travail (l’ISO, la Commission européenne de normalisation,  et l’ETSI – European Telecommunications Standards Institute). Ces organismes mènent des réflexions qui portent par exemple sur les formats de messages à utiliser, les canaux de communications envisageables (Wi-Fi véhiculaire, réseaux cellulaires ou réseau satellite) ou la sécurisation des protocoles de communication.

En complément, de nombreux consortiums européens (Drive C2X, CAR2CAR, FOTsis) mènent des réflexions sur le déploiement de systèmes routiers collaboratifs. Certains d’entre eux peuvent intégrer le sujet de la sécurité de l’information.

Si ces réflexions portent sur un périmètre plus ou moins large, mener un projet lié aux voitures connectées implique de revenir sur les usages et d’identifier les risques puis les mesures de sécurité à mettre en place sur l’ensemble des briques du dispositif : la voiture, les bornes, les systèmes d’informations du gestionnaire, etc.

Focus sur le véhicule : la prise de contrôle par un hacker est-elle réellement possible ?

Les attaques informatiques sur des systèmes embarqués de véhicules ne sont pas une nouveauté en soi. Des démonstrations d’attaques ont été réalisées par manipulation physique des boîtiers. Mais aujourd’hui il est indispensable d’intégrer la dimension communicante du véhicule, et donc la capacité à prendre le contrôle à distance. En effet, les voitures ont historiquement été conçues pour fonctionner en système fermé, sans ou avec très peu d’interactions avec le monde extérieur. La multiplication des connexions des véhicules avec le monde extérieur constitue de nouvelles surfaces d’attaque.

Le « car hacking » est donc possible, et pour la sécurité de l’information dans les véhicules de demain, les constructeurs intègrent la cybersécurité dans les réflexions sur l’architecture technique du véhicule avec notamment la mise en œuvre d’un cloisonnement entre les réseaux de fonctionnement liés au système de conduite (freinage par exemple) et les réseaux liés « aux médias » et à la sécurisation du boîtier de communication.

Au-delà des projets en cours, comment anticiper la « smart security » dans le transport routier ?

Si le sujet est innovant, la démarche de sécurité est en somme « classique » : intégrer la sécurité dans toutes les phases du projet ! Il s’agit d’un point essentiel pour mener la réflexion sur l’ensemble des briques. Dans un premier temps, analyser les usages et donc les besoins de sécurité. Ensuite, comprendre les fonctions, l’architecture de sécurité et donc les menaces et vulnérabilités. Puis, en fonction des risques, les mesures de sécurité à mettre en place puis à maintenir doivent être définies qu’elles soient techniques ou organisationnelles.

Une spécificité néanmoins liée au caractère innovant : mener une veille permanente sur le sujet. Quels nouveaux projets peuvent présenter des adhérences ? Quels nouveaux standards ? Quels travaux des chercheurs sur les vulnérabilités, sur les solutions ? Quels consortiums, groupes de travail portent une réflexion sur une brique ? Le secteur est en pleine transformation, et son évolution doit donc être suivie.

Cet article Voiture connectée : quels enjeux de sécurité de l’information ? 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.

Une situation souvent désastreuse sur le plan de la sécurité de l’information

Les réseaux industriels et leurs composants les plus emblématiques, systèmes SCADA et automate (PLC/API) sont souvent dans des postures de sécurité très faible. Ils ont été construits par des équipes d’automaticiens alors peu confrontés aux problématiques des technologies telles qu’IP ou encore Windows qui ont pourtant depuis envahi les chaînes de production. Nos audits le montrent clairement : en termes d’architecture comme en termes de sécurisation unitaire des composants, beaucoup reste à faire. Avec un problème majeur : des équipements et des protocoles vulnérables « par construction » !

Des solutions d’attentes ont vu le jour

Dans ce contexte, de nombreuses solutions de sécurité ont vu le jour. Elles permettent de compenser une partie des vulnérabilités des systèmes. Nous pouvons en particulier citer les pare-feux industriels, tels ceux conçus par la société Tofino ou encore Industrial Defender. Des solutions plus classiques de sécurité (pare-feu, détection d’intrusion…) peuvent également être utilisées et dans une certaine mesure adaptées aux technologies des réseaux industriels.

Un réveil tardif des constructeurs

Il aura fallu un cas d’attaque de l’ampleur de Stuxnet pour que les constructeurs comprennent les enjeux autour de la sécurité des systèmes industriels. Ce réveil, certes tardif – mais mieux vaut tard que jamais- entraîne aujourd’hui des avancées significatives chez les constructeurs informatiques. On voit ainsi peu à peu apparaître le chiffrement des échanges, la capacité à mettre à jour plus simplement les équipements, des designs types intégrant les exigences sécurité, le durcissement des configurations par défaut…  Il est même question de signatures de code déployé sur les automates !

Quelle stratégie adopter à long terme : protéger ou reconstruire ?

Il s’agit d’un débat qui fait rage actuellement et oppose deux camps aux stratégies différentes. Les partisans de la reconstruction prônent un remplacement volontariste, sur un délai de deux ou trois ans des anciens équipements par des nouveaux, mieux sécurisés. Bien que cela soit possible, la question de l’investissement nécessaire se pose particulièrement en ces temps de crise. En effet, les lignes de production sont souvent conçues pour une durée de vie de 10 à 15 ans ; changer l’ensemble des équipements a un coût non négligeable, à la fois financier mais aussi en perte d’exploitation potentielle sur des systèmes où la disponibilité est cruciale.

D’autres préconisent l’ajout de couches de sécurité additionnelles. Cela n’a cependant jamais été une solution idéale et nécessite également des investissements importants, complexifie les architectures et fait courir de nouveaux risques en particulier sur la disponibilité.

Je reste persuadé que la bonne approche est à trouver dans un compromis entre ces deux solutions. Et en particulier, qu’elle dépend de l’analyse de risques à réaliser sur chacun des systèmes de production concernés. Dans certains cas, un changement pourra être salutaire et permettra une sécurisation au plus près de la production, de manière fiable et pérenne. Dans d’autres cas, l’ajout de mécanismes complémentaires sera suffisant en attendant le renouvellement des systèmes.

Il s’agit donc de prendre le recul nécessaire pour choisir la ou les bonnes solutions  sans oublier que les solutions techniques seules ne font pas tout. Bien souvent dans ces projets, une meilleure gestion des accès, une refonte de l’architecture sur la base des équipements déjà en place, une revue des filtrages en place et surtout une sensibilisation / formation des équipes d’automaticiens apportent beaucoup plus que l’ajout de fonctions de sécurité pure !

Cet article Réseaux industriels : protéger ou reconstruire ? est apparu en premier sur RiskInsight.