Où en est le secteur? 

La montée en puissance de Part-IS s’est faite par étapes. Après l’entrée en vigueur progressive des textes en 2022 et 2023, l’année 2025 a été marquée par la préparation des dossiers de conformité et la structuration des SMSI. 

Depuis le 22 février 2026, le règlement d’exécution est pleinement applicable, ce qui signifie que de nouveaux périmètres sont désormais couverts, notamment les activités de maintenance et de réparation à travers la Part-145. Part-IS concerne aujourd’hui l’ensemble de la chaîne opérationnelle, de la conception jusqu’aux opérations et au support. 

Aujourd’hui, les acteurs du secteur concernés par la Part-IS ont pris connaissance du sujet et transmis leur SMSI. Dans ce contexte d’engagement généralisé, l’EASA a, de son côté, ajusté le cadre en précisant et en assouplissant certaines modalités, à travers la mise à jour des AMC et GM de la Part-IS. 

L’EASA prévoit une phase de développement de 18 mois après la date d’applicabilité pour atteindre une mise en œuvre pleinement opérationnelle. Cette progression peut se lire simplement en trois étapes : un dispositif d’abord présent et adapté (P + S), puis opérationnel (O), avant d’atteindre un fonctionnement effectif dans la durée (E).

Les mises à jour EASA : qu’est-ce qui change concrètement ? 

Fin 2025, l’EASA a mis à jour les AMC et GM relatifs à Part-IS et consolidé ces évolutions dans une nouvelle version des Easy Access Rules associée. 

Concrètement, ces évolutions introduisent plusieurs allègements importants : 

• Les organisations déclarées n’ont plus besoin d’une approbation préalable de leur SMSI.
• Pour rappel, les organisations agréées sont soumises à un processus d’approbation formelle par l’autorité (EASA ou autorité nationale). Elles doivent obtenir un agrément, faire approuver leur manuel SMSI et soumettre certaines modifications à validation préalable contrairement aux organisations déclarées, qui sont supervisées a posteriori par l’autorité. Vous pouvez retrouver la liste des organismes déclarés soumis à Part-IS ici. 
• Les modifications du SMSI, lorsqu’elles sont couvertes par une procédure interne définie, ne nécessitent plus de « feu vert » formel de l’autorité : une notification suffit. 
• Le rôle de l’autorité est recentré sur la supervision et l’audit, plutôt que sur une logique d’approbation systématique. 

Cependant, les attentes restent les mêmes : le SMSI (SGSI au sens du règlement) doit être robuste, cohérent, traçable, et réellement appliqué. L’allègement apporté par la mise à jour des AMC et GM est donc administratif et non opérationnel. 

Sur le terrain, cela résonne avec les premiers retours de l’OSAC sur les SMSIs : la gouvernance autour de ce dernier apparaît comme un point central. Les autorités portent une attention accrue à la dimension cybersécurité que doivent avoir les acteurs identifiés. La qualité du document est également scrutée, non seulement sur le fond, mais aussi sur la forme (structure, cohérence…). 

Les cinq chantiers du secteur pour passer Part‑IS à l’échelle 

Au‑delà de ces premiers retours, nous avons pu observer lors de nos accompagnements que la mise en œuvre de Part-IS fait émerger cinq défis chez la plupart des acteurs : gouvernance & coordination, validation de l’inventaire, finalisation des analyses de risques, formation des responsables et équipes, contraintes RH et contrôle des personnes. 

Mais le plus chronophage reste l’analyse de risques, en particulier pour les grandes organisations multi‑sites. Celle‑ci ne peut plus être uniquement centralisée, et doit être déclinée localement, intégrer les réalités de chaque site, les chaînes fonctionnelles, ainsi que les sous‑traitants. Cette approche holistique est exigeante, mais indispensable pour démontrer une application cohérente de Part‑IS. 

Une approche pragmatique pour passer à l’échelle 

Face à ces enjeux, la clé réside dans l’anticipation du déploiement. Un SMSI efficace repose sur un socle commun solide, mais aussi sur des outils concrets permettant une déclinaison locale : modèles, guides, méthodes d’analyse de risques adaptées aux réalités opérationnelles. 

La réussite de Part-IS repose sur la coordination entre les équipes cybersécurité, les équipes métiers et les fonctions qualité et conformité. Part-IS n’est pas une couche supplémentaire : c’est un cadre transverse qui structure durablement la gestion du risque cyber au service de la sécurité aérienne. 

En conclusion 

En 2026, Part-IS entre en phase d’application. La consolidation des AMC/GM fixe un terrain clair et allège la charge administrative par rapport à la 1ère monture. 

En complément, ces mises à jour fin 2025 ont notamment étendu le périmètre de la Part‑IS aux prestataires d’assistance en escale via le règlement délégué (UE) 2025/22 amendant le (UE) 2022/1645, applicable à compter du 27 mars 2031. Pas d’impact opérationnel immédiat en 2026, mais un signal utile pour anticiper la cartographie des interfaces, sans urgence à court terme. 

Cet article Part-IS en 2026 : du cadre réglementaire à la réalité du terrain est apparu en premier sur RiskInsight.

C’est précisément là que se positionne la version 2.0 du guide « La cybersécurité des systèmes industriels – Mesures détaillées », publiée le 27 novembre 2025 : traduire les classes de cybersécurité en mesures concrètes, au moment où l’OT doit composer avec une menace plus pressante, des architectures plus interconnectées, et des exigences de conformité plus visibles. 

Ce guide fait directement écho à la publication de la deuxième version de la Méthode de classification des systèmes industriels de l’ANSSI en mars 2025, pour laquelle nous avions déjà rédigé un article. 

Une mise à jour dans la continuité : même ossature, même logique 

Évolutions du guide des mesures détaillées entre la première et la deuxième version

Sur la forme, le guide 2025 reste très proche de la version 2014 : on retrouve une première partie rappelant les contraintes et faiblesses propres aux environnements industriels, puis un découpage entre mesures organisationnelles et mesures techniques. Les thèmes, eux, ne surprendront pas : gouvernance, maîtrise des accès, cloisonnement, accès distants, sauvegardes, supervision, gestion des vulnérabilités, intégration de la cybersécurité dans le cycle de vie, préparation à l’incident. La continuité est assumée. 

Cette stabilité a un avantage : elle permet à une organisation déjà alignée sur la version 2014 de ne pas repartir de zéro. Mais elle montre aussi que la plupart des “grands sujets” étaient déjà connus il y a plus de dix ans. La question n’est donc pas tant “qu’apprend-on de nouveau ?” que “qu’est-ce qui devient réellement plus actionnable, et à quel prix ?”. 

Sur ce point, le guide est clair sur son périmètre : il propose un socle pour les dossiers d’homologations. Pour autant, le guide ne prétend pas se substituer à l’IEC 62443, ni offrir un cadre de certification. Il se contente d’en reprendre certains principes et exigences, et rappelle que les mesures ne suffisent pas, à elles seules, pour les systèmes les plus critiques.

Ce qui change concrètement : une nouvelle grammaire d’exigences restructurée 

Le changement le plus visible n’est pas une nouvelle thématique, mais une nouvelle manière d’exprimer les exigences : 

En 2014, le guide s’appuyait sur une distinction structurante : recommandations (R) et directives (D), avec un mécanisme de durcissement selon la classe. En 2025, cette grammaire disparaît. Le guide formalise une lecture par classe (C1 à C4) et introduit des variantes : recommandations “à l’état de l’art”, alternatives de niveau moindre représenté par un –, ou recommandations renforcées complémentaires représentées par un +. 

Schéma type d’une recommandation 

Deuxième évolution structurante : l’ajout explicite d’une quatrième classe et l’alignement renforcé avec l’IEC 62443, en accordement avec la mise à jour de la méthode de classification. Pour chaque recommandation, une correspondance avec une exigence de l’IEC 62443 est indiquée lorsqu’elle existe et référencée dans une annexe. 

Concernant l’évolution de ces mesures, une large partie des 214 recommandations trouve, comme détaillé dans l’annexe B, un équivalent direct dans l’ancienne version. Cela confirme que la refonte repose davantage sur une réorganisation et une reformulation que sur une remise en cause du fond. Après analyse des 35 mesures étant identifiées comme sans équivalence directe, nous pouvons affirmer que ces dernières ne sont pas nécessairement nouvelles. Comme représenté sur ce tableau, elles traduisent : 

Catégories des raisons de non-équivalence directes et exemples illustrés 

Résumé des recommandations sans équivalences directes dans l’annexe B 

Une doctrine plus architecturée sur les interconnexions et accès distants 

Là où la version 2025 change réellement la dynamique, c’est sur certains sujets traités de manière plus structurée. Dans la première version, la doctrine sur les interconnexions et les accès distants était déjà relativement prescriptive : elle insistait sur le fait que la télégestion augmente considérablement la surface d’attaque, posait des règles opérationnelles et allait jusqu’à interdire la télémaintenance en classe 3, avec une logique d’uni-directionnalité des flux.

La modernisation apportée par la version 2025 est d’avoir rendu l’ensemble plus cohérent et mieux structuré : on passe d’un raisonnement principalement centré sur des composants et des moyens (pare-feu, VLAN, diode, VPN) à une lecture en fonctions de sécurité que l’on doit composer et positionner selon les classes et les sens de flux dans le tableau 3. Les lignes de ce dernier correspondent à la classe émettrice (from) et les colonnes à la classe réceptrice (to) ; les icônes indiquent les fonctions de sécurité à implémenter pour autoriser le flux dans ce sens. Par exemple, de la classe C1 vers IT, seul un système permettant de vérifier si la donnée provient d’une source autorisée – Aut(IT) – est requis. 

Résumé du tableau 3 – Section 4.2.1 : toutes les mesures qui figurent sont accompagnées d’une fonction d’unidirectionnalité du transfert de données 

Il est à noter que la définition d’Inno (OT) ne figure pas directement dans le document. 

Du référentiel à l’application terrain 

La version 2025 des Mesures détaillées referme logiquement la refonte initiée par la publication de la seconde version de la méthode de classification et renforce la compatibilité avec l’IEC 62443. Dans un contexte où la menace sur les environnements industriels est désormais très visible, ce document tombe à point nommé : c’est l’occasion d’adapter son plan d’action ou carrément lancer une roadmap 2030 – un guide non appliqué n’a jamais arrêté un attaquant ! 

Dans les chantiers prioritaires à lancer on identifie régulièrement : 

• Revoir la cartographie et dépendances IT vis-à-vis du métier 
• Adapter son architecture technique en troquant de nouvelle autorisation contre un renforcement de l’authentification et un meilleur contrôle du contenu
• Durcir et centraliser les accès distants notamment liées aux nombreux fournisseurs présents dans l’environnement industriel 
• Renforcer ou raccorder les environnements industriels à son SOC 

Cet article La cybersécurité des systèmes industriels : la refonte du guide de l’ANSSI des « Mesures détaillées »  est apparu en premier sur RiskInsight.

Menaces quantiques : une nouvelle ère pour la cryptographie industrielle 

L’informatique quantique représente une menace pour les algorithmes cryptographiques classiques qui garantissent l’intégrité, l’authenticité et la confidentialité des communications, y compris celles des systèmes OT et des produits. Même si le “Q-Day” (le jour où les ordinateurs quantiques casseront la cryptographie actuelle) est encore à quelques années devant nous, le risque est déjà là : les attaquants peuvent d’ores et déjà procéder à des attaques de type « Harvest Now, Decrypt Later », stockant des données chiffrées aujourd’hui pour les déchiffrer dès que les algorithmes cryptographiques actuels seront brisés. Mais un autre risque, tout aussi critique, se profile : « Trust Now, Forge Later ». Les signatures numériques ou certificats jugés fiables aujourd’hui pourront être falsifiés demain, rendant possible l’installation transparente de logiciels malveillants ou encore la compromission de chaînes d’approvisionnement. Contrairement à la fuite progressive de données, cette attaque provoque une rupture immédiate de la confiance et de l’intégrité, avec des impacts massifs sur les environnements industriels et les produits connectés. Avec la feuille de route européenne jalonnant 2026, 2030 et 2035, la question réside dans l’ordonnancement de la transition.  

Dans l’industrie, où les équipements vivent plusieurs décennies, c’est un enjeu majeur. 

L’industrie est particulièrement touchée : les environnements OT et les produits embarqués reposent sur des usages cryptographiques critiques qui seront directement impactés par l’arrivée des algorithmes post-quantiques. 

Plusieurs cas d’usages industriels et produits prioritaires identifiés : 

• Administration sécurisée des systèmes OT et produits : garantir l’intégrité et la confidentialité des opérations. 
• Signature numérique et intégrité des firmwares : garantir la fiabilité des mises à jour logicielles (secure boot, code signing, X.509…).
• Accès distants sécurisés aux actifs industriels et produits : protéger les connexions VPN, SSH, RDP, et autres protocoles contre les attaques futures.
• Échanges de données IT/OT : sécuriser les flux entre les systèmes d’information et les environnements industriels (TLS, MQTTS, HTTPS…). 
• Confidentialité des données des processus industriels : préserver la confidentialité des données sensibles en transit ou au repos.
• Journalisation et historisation sécurisées : assurer la traçabilité et l’intégrité des logs et historiques critiques.

PQC pour l’OT & Produit : intégrer les  contraintes, préserver la crypto-agilité 

Contexte OT & Produit : des contraintes spécifiques 

Les systèmes OT et produits n’ont jamais été conçus pour la crypto-agilité. De nombreux protocoles industriels comme DNP3, Modbus ou MQTT ne sont pas chiffrés aujourd’hui car l’architecture OT repose historiquement davantage sur l’isolement réseau que sur la cryptographie, alors il n’y a pas de raison de penser qu’ils seraient tous chiffrés demain avec des algorithmes postquantiques.

Néanmoins, les communications chiffrées subiront cette rupture cryptographique.

Dans un second temps, beaucoup d’équipements OT présentent des contraintes matérielles importantes (processeur, mémoire, capacité de stockage) et disposent d’une durée de vie très longue, souvent entre 10 et 30 ans. Ces caractéristiques rendent les mises à jour difficiles et coûteuses : les mécanismes de mise à jour sécurisée à distance restent rares, et la signature des firmwares n’est pas systématiquement implémentée, ce qui est dans les faits une mauvaise pratique.

Ces contraintes expliquent pourquoi les environnements OT ne peuvent pas intégrer de nouvelles primitives cryptographiques au même rythme que l’IT, et pourquoi la PQC n’est pas encore prise en compte nativement.

Néanmoins, même si les produits et systèmes OT actuels ne sont pas conçus pour la cryptographie post-quantique, l’émergence des standards PQC, l’évolution des obligations réglementaires et la montée des risques liés au quantique rendent cette transition incontournable à moyen terme. 

Rendre la crypto-agilité opérationnelle pour l’industrie et les produits 

Le cadrage du projet PQC pour les Produits et l’OT peut s’axer en 4 volets principaux :

1. Réaliser l’inventaire cryptographique et prioriser les actifs critiques

Initier dès maintenant le dialogue avec vos fournisseurs de socles crypto (PKI, KMS, HSM) pour anticiper la migration.

2. Concevoir et déployer des architectures crypto-agiles

S’appuyer exclusivement sur les algorithmes standardisés par le NIST (ex : ML-KEM, ML-DSA, SLH-DSA), et proscrire tout développement interne ou adoption de librairies non standards pour les composants cryptographiques en privilégiant des solutions éprouvées et validées.

Concevoir des architectures crypto‑agiles implique de prendre en compte la dimension embarquée et ses contraintes (mémoire limitée, circuits imprimés, ressources énergétiques).  L’implémentation des algorithmes PQC sur ces systèmes reste incertaine. Toutefois, des algorithmes optimisés pour l’embarqué émergent et ouvrent la voie à une adoption réaliste.

3. Migrer progressivement via l’hybridation et l’itération

La transition vers la cryptographie post-quantique ne peut pas être pensée comme un projet ponctuel ou une migration « One Shot ». Il s’agit d’un processus itératif, à piloter dans la durée, en commençant par l’hybridation des algorithmes : c’est la stratégie explicitement recommandée par l’ANSSI et la Commission européenne.

La crypto-agilité n’est pas une option, mais une nécessité pour garantir la résilience, la conformité de vos environnements industriels et produits face à la menace quantique. Elle s’appuie sur une démarche structurée, pilotée par l’inventaire, l’architecture, la migration hybride et la gouvernance.

Retours terrain & cas d’usage concrets : des acteurs à des stades différents 

Notre expérience terrain révèle un écart de maturité saisissant entre deux profils d’acteurs industriels face à la cryptographie post-quantique : 

1. Les industriels avec une compréhension encore embryonnaire 

• Constat : Dans de nombreux environnements industriels, la PQC reste un concept abstrait, souvent perçu comme lointain ou réservé aux experts. 
• Symptômes :  
  • Les équipes opérationnelles et métiers ne sont pas impliquées dans les réflexions stratégiques sur la cryptographie. 
  • Les roadmaps actuelles manquent de maturité et de clarté, les chantiers sous-jacents sont souvent sous-estimés quant à leur coût. La priorité reste la continuité de service, la sécurité quantique étant reléguée au second plan. 
  • Les notions de HNDL & TNFL sont peu comprises, voire ignorées. 
• Risques :  
  • Perturbation de la production et fuite de données de processus industriels :  des communications vulnérables entre équipements critiques, basées sur des algorithmes obsolètes, exposent les données sensibles et peuvent entraîner des interruptions ou des perturbations majeures dans les opérations industrielles (perte d’intégrité des données).
  • Indisponibilité de production liée à une migration brutale : Une transition forcée vers la cryptographie post‑quantique, sans préparation ni crypto‑agilité, peut provoquer des arrêts de production, des surcoûts importants et des impacts sévères sur la continuité opérationnelle. 

 2. Les fournisseurs de produits : des pionniers déjà en phase d’industrialisation 

• Constat : À l’opposé, certains fournisseurs de produits (notamment dans l’automobile, ou les objets connectés) ont pris une longueur d’avance. 
• Symptômes :  
  • Les chantiers PQC sont priorisés sur les cas d’usage critiques : signature de firmware et mises à jour (OTA), gestion des identités d’équipements, sécurisation des accès distants, etc. 
  • Des pilotes sont lancés sur des lignes de produits ou des environnements représentatifs, avec des retours d’expérience concrets sur la performance, la compatibilité et la robustesse des solutions hybrides. 
  • La démarche s’industrialise : intégration de clauses PQC dans les contrats fournisseurs, automatisation de l’inventaire cryptographique CBOM, montée en compétence des équipes, et gouvernance dédiée. 

Conclusion & Roadmap : Passez à l’action pour bâtir un futur “quantum-safe” 

La menace quantique n’est plus une perspective lointaine : elle impose dès aujourd’hui une transformation profonde de la cybersécurité industrielle et produit.

1. Anticipez pour protéger l’avenir

Démystifiez les concepts quantiques et intégrez-les dès maintenant dans vos processus de cybersécurité, que ce soit pour vos produits, vos environnements OT ou vos systèmes IT. L’anticipation est la clé pour éviter la rupture.

2. Faites de la crypto-agilité une vision stratégique

Ne la considérez plus comme un simple projet technique, mais comme un pilier de votre résilience et de votre souveraineté numérique. Construisez une feuille de route claire, avec des jalons à court, moyen et long terme.

3. Appuyez-vous sur des partenaires de confiance

Le marché est prêt : des experts et des solutions existent pour vous accompagner dans la modernisation et la sécurisation de vos infrastructures critiques. Ne restez pas isolés face à la complexité.

4. Industrialisez la démarche

Passez du pilote à la généralisation : 

• Mettre en place une stratégie PQC pour cartographier, prioriser et piloter la migration des usages critiques (inclure des clauses PQC dans les contrats).
• Lancer un programme de transition pour moderniser les socles de confiance (PKI, CLM, HSM), automatiser l’inventaire et assurer la continuité des opérations.
• S’appuyer sur les retours d’expérience des pairs et des secteurs déjà engagés dans la PQC.

Le risque quantique est déjà là : chiffrement asymétrique fragilisé, signatures et données exposées.  

Comme mentionné précédemment, nous partons du constat que Les éléments qui ne sont pas chiffrés aujourd’hui dans l’environnement OT, n’ont pas vocation à être chiffrés demain avec des algorithmes postquantiques, car les mesures existantes assurent déjà un niveau de risque jugé acceptable.

Autrement dit, la PQC ne vise pas à transformer l’ensemble de l’OT, mais à protéger les usages qui reposent réellement sur des mécanismes cryptographiques exposés au risque quantique.

Pour autant, ce constat ne réduit pas l’importance de la préparation.

Les deux priorités restent les suivantes :  

• Migrer vos actifs critiques avant 2030 et agir dès aujourd’hui pour protéger la confidentialité des données.  
• Définir votre périmètre, et bâtir votre plan d’action, et surtout engager une démarche de migration dès aujourd’hui. 

Cet article La cryptographie post-quantique pour les produits et l’OT : de la tendance à la réalité industrielle est apparu en premier sur RiskInsight.

Les cyberattaques ne visent plus uniquement le système d’information interne : elles exploitent de plus en plus les dépendances externes, là où la gouvernance, la visibilité et le contrôle sont souvent plus faibles. Une vulnérabilité chez un tiers (third-party en anglais) peut désormais entraîner des impacts directs sur la production, la sécurité des personnes, la conformité réglementaire ou la réputation de l’organisation.  

L’attaque subie par Jaguar Land Rover en 2025 illustre cette réalité : l’arrêt des systèmes a paralysé la chaîne de production du constructeur, mais aussi l’ensemble de son écosystème de partenaires. Résultat : plus de 25 000 véhicules non produits et des pertes estimées à près d’un milliard de livres sterling. 

Maîtriser les risques cyber liés aux tiers n’est donc plus un sujet périphérique : c’est une composante centrale de toute stratégie de cybersécurité industrielle, généralement désignée par les acronymes TPRM (Third-Party Risk Management) ou TPCRM (Third-Party Cyber Risk Management), qui recouvrent respectivement la gestion globale des risques liés aux tiers et sa déclinaison spécifique aux risques cyber. 

Les tiers au cœur de la chaîne de valeur industrielle 

La notion de « tiers » recouvre toute entité ou personne externe qui collabore avec une organisation et interagit avec ses systèmes, ses données ou ses processus. Ces acteurs contribuent directement ou indirectement à l’activité de l’entreprise et forment ce que l’on appelle la chaîne d’approvisionnement (supply chain en anglais). 

En milieu industriel, les tiers peuvent être regroupés en cinq grandes catégories, reflétant la diversité des rôles qu’ils jouent dans le fonctionnement et la maintenance des systèmes industriels :  

Cartographie des tiers constituant la chaîne d’approvisionnement 

Pour garantir une continuité opérationnelle sans faille, les acteurs industriels s’appuient massivement sur leurs prestataires. Cette dépendance, alimentée par l’externalisation d’activités critiques et des obligations réglementaires, transforme chaque fournisseur en maillon essentiel. Une seule compromission chez un tiers suffit à paralyser la production, désorganiser les opérations et exposer l’entreprise à des risques majeurs. 

Une chaîne d’approvisionnement étendue, difficile à maîtriser et fortement exposée 

La diversité et le nombre de ces acteurs posent plusieurs défis majeurs aux entreprises. En premier lieu, l’écosystème des tiers est souvent extrêmement vaste : une organisation peut compter des centaines, voire des milliers de partenaires. 

À cette ampleur s’ajoute une forte complexité, car la chaîne d’approvisionnement ne se limite pas exclusivement aux tiers directs, mais inclut également leurs propres prestataires, indispensables à leur continuité d’activité. À mesure que l’on descend dans ces niveaux successifs (tiers de second rang, puis de rangs ultérieurs), la visibilité de l’organisation cliente sur ses tiers diminue fortement :  

Complexité de la chaîne d’approvisionnement illustrée 

Cette combinaison d’étendue et de profondeur rend la maîtrise globale de l’écosystème particulièrement difficile : à titre d’exemple, on estime que seules 3 % des organisations disposent d’une visibilité complète sur l’ensemble de leur chaîne d’approvisionnement (Panorays, 2025). Ce manque de visibilité en fait une surface de risque étendue et difficilement contrôlable. 

Risques liés aux tiers : une menace croissante sous pression réglementaire 

On constate ainsi, ces dernières années, une augmentation significative des cyberattaques impliquant des tiers. Le phénomène est particulièrement marqué en milieu industriel, où les tiers interviennent dans des processus souvent critiques et vulnérables : accès distants aux systèmes, présence physique sur site, gestion des identités et des accès, intégration de logiciels ou de composants matériels… 

Ces chiffres illustrent deux constats majeurs : d’une part, les risques liés aux tiers sont bien réels et constituent une menace croissante pour l’écosystème cyber ; d’autre part, le niveau de maturité des organisations reste globalement insuffisant, alors même que le TPCRM s’impose comme un levier stratégique de réduction du risque. 

Ces constats sont d’ailleurs désormais intégrés par les régulateurs : la directive européenne NIS 2, en cours de transposition dans les États membres, impose aux organisations concernées de maîtriser les risques liés à leur chaîne d’approvisionnement. La gestion des risques cyber liés aux tiers devient ainsi une exigence réglementaire à part entière, en cas de non-conformité, les sanctions peuvent atteindre jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires mondial. 

Mettre en place une gestion des risques tiers adaptée aux contraintes industrielles 

Alors, face à ces enjeux, comment structurer une gestion efficace des risques cyber liés aux tiers ? Si les approches varient selon les organisations, plusieurs principes clés se dégagent : 

• Implication transverse des parties prenantes : la gestion du risque tiers ne peut pas relever uniquement des équipes IT ou cybersécurité. Les achats, les équipes opérationnelles et les métiers doivent être pleinement intégrés, car les tiers interviennent à tous les niveaux de l’organisation. 
• Approche sur l’ensemble du cycle de vie du tiers : le risque doit être pris en compte dès la sélection du fournisseur, et suivi jusqu’à la fin de la relation commerciale. Chaque étape (contractualisation, intégration, exploitation et sortie) doit être encadrée par des exigences de sécurité adaptées. 
• Exigences contractuelles claires : les contrats doivent formaliser et intégrer des obligations précises en matière de cybersécurité, afin de garantir un niveau de protection cohérent tout au long de la collaboration. 
• Priorisation des tiers : les efforts de sécurisation doivent être proportionnés à la criticité des partenaires (par exemple : niveau d’intégration dans les systèmes, dépendance opérationnelle, sensibilité des données échangées, historique de la relation…). L’évaluation de leur rôle opérationnel et de leur maturité cyber permet de concentrer les ressources sur les tiers les plus sensibles. 
• Collaboration et partage d’informations : la résilience de la chaîne d’approvisionnement repose sur la capacité des acteurs à partager l’information et à coordonner leurs réponses en cas d’incident. 
• Outillage et automatisation : face au volume de tiers, l’automatisation, l’analyse continue et l’intégration d’outils spécialisés deviennent des leviers indispensables. 

Pour accompagner les organisations dans cette démarche, plusieurs références font autorité, notamment le standard NIST SP 800-161 Rev. 1 “Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations” (2022) ou “Good Practices for Supply Chain Cybersecurity” publiée par l’ENISA (2023). 

Le TPCRM, un pilier de la résilience industrielle 

Dans un contexte industriel où les risques cyber deviennent systémiques, la maîtrise de la chaîne d’approvisionnement ne relève plus d’une approche purement technique, mais constitue un enjeu stratégique de gouvernance et de résilience. 

Une démarche TPCRM mature permet non seulement de répondre aux exigences réglementaires, mais surtout de mieux anticiper les scénarios de crise, de limiter les impacts opérationnels et de renforcer la confiance dans l’écosystème de partenaires.  

En combinant gouvernance, processus, technologies et collaboration avec l’écosystème, le TPCRM s’impose comme véritable un levier stratégique pour sécuriser durablement les environnements industriels. 

Cet article TPCRM en milieu industriel : maîtriser les risques cyber de la chaîne d’approvisionnement est apparu en premier sur RiskInsight.

Certaines industries comme la pharmaceutique, la chimie ou l’agroalimentaire dépendent d’équipements de laboratoire, en particulier pour des besoins de contrôle qualité, R&D ou analyses chimiques. Certains de ces équipements sont essentiels au maintien des opérations et à la conformité réglementaire (i.e. en milieu pharmaceutique pour le contrôle qualité des matières premières et des produits finis pour la libération des lots, ou encore la production de rapports réglementaires). Leur disponibilité et leur fiabilité constituent donc des enjeux majeurs pour ces entreprises. Cependant, ces dispositifs, initialement conçus pour fonctionner de manière isolée, sont désormais de plus en plus connectés afin d’améliorer l’efficacité opérationnelle grâce, entre autres, à la collecte automatisée des données et à l’harmonisation des méthodes d’analyse entre les différents sites.

Ces besoins opérationnels ont conduit à une utilisation généralisée des systèmes de gestion des informations de laboratoire (LIMS). Les LIMS offrent un large éventail d’applications concrètes : dans les environnements pharmaceutiques, ils gèrent les dossiers analytiques des lots, surveillent les paramètres de qualité et assurent une traçabilité complète pour les audits réglementaires. Dans le domaine des analyses environnementales, les LIMS facilitent la collecte, la validation et la production de rapports sur les données de terrain, réduisant ainsi les erreurs manuelles. Dans les laboratoires de sécurité alimentaire, ils automatisent la génération de rapports de conformité et déclenchent des alertes lorsque les seuils de contamination sont dépassés.

Centraliser la gestion des équipements de laboratoire au travers des LIMS nécessite leur mise en réseau, même lorsque cela n’avait pas été initialement prévu par les fabricants. Cette connectivité accrue entraîne de nouveaux défis de cybersécurité, car de nombreux systèmes de laboratoire reposent sur des technologies obsolètes, augmentant ainsi la surface d’attaque.

Systèmes obsolètes : Un risque de sécurité croissant

De nombreux équipements de laboratoire fonctionnent encore avec des systèmes d’exploitation propriétaires ou obsolètes (par exemple, Windows XP) qui ne bénéficient plus de mises à jour de sécurité. Ces systèmes hérités sont vulnérables à des failles connues et ne peuvent pas être patchés facilement.

Au-delà de l’obsolescence des systèmes souvent constatée, ces équipements font rarement l’objet de publication de correctifs ou patchs de la part de leurs fabricants, malgré leur cycle de vie long. Une fois en production, la mise à jour de ces systèmes représente également des enjeux, en particulier à la gouvernance — en particulier, la détermination des équipes responsables de la mise à jour.

La plupart des instruments de laboratoire disposent de capacités de sécurité intégrées limitées. Ils reposent souvent sur des protocoles de communication non sécurisés ou obsolètes — tels que HTTP, FTP ou SMBv1/v2 — ou sont déployés avec de mauvaises pratiques de configuration qui affaiblissent encore davantage leur posture de sécurité. Bien que les modèles plus récents prennent en charge des standards plus sûrs comme OPC UA ou SFTP, ces fonctionnalités ne sont pas toujours activées ni correctement configurées.

Figure 1 : Architecture réseau type en milieu pharmaceutique.

La gestion des identités et des accès constitue un autre défi majeur dans les environnements de laboratoire. De nombreux instruments ne reposent pas sur des mécanismes d’authentification ou alors nécessitent l’utilisation de comptes locaux ou partagés. Ces systèmes sont rarement compatibles avec des annuaires centralisés via des protocoles comme LDAP, ce qui complique l’application de politiques de sécurité cohérentes entre les sites. D’un point de vue opérationnel, l’authentification peut sembler superflue, mais combinée à des systèmes d’exploitation obsolètes, des protocoles de communication non sécurisés et un contrôle d’accès limité, ces faiblesses transforment les appareils de laboratoire en points d’entrée faciles pour les cyberattaques.

À mesure que les laboratoires interconnectent de plus en plus leurs instruments avec les LIMS, les solutions d’analyse Cloud et les systèmes centralisés d’historisation des données, ce manque d’hygiène de sécurité expose non seulement les équipements directement, mais met également en danger le reste du réseau d’entreprise.

Sécuriser les systèmes de laboratoire grâce à l’isolation et aux passerelles réseaux

Lorsque les équipements de laboratoire ne peuvent pas être sécurisés en raison de leurs limitations inhérentes, il est essentiel de réduire leur exposition autant que possible. Cela implique de placer ces dispositifs derrière des systèmes intermédiaires sécurisés — tels que des passerelles ou des postes de travail dédiés — et de définir des zones réseaux spécifiques afin de limiter la surface d’exposition en cas de compromission. En segmentant le réseau et en filtrant les flux de données, il devient possible de mieux contenir les compromissions potentielles et de limiter leur impact sur les autres systèmes critiques.

Trois solutions clés peuvent renforcer la sécurité dans ce contexte :

• Mise en place de postes de travail équipés d’outils de cybersécurité pour assurer la compatibilité entre les équipements de laboratoire et les réseaux sécurisés. Cette approche est particulièrement efficace lorsque des postes de travail modernes servent d’intermédiaires, en assurant une transmission sécurisée des données et en permettant leur surveillance. Cette solution est en réalité une des manières les plus utilisées pour gérer les équipements de laboratoire et manipuler les données qu’ils génèrent.
• Isolation des équipements de laboratoire par rapport aux environnements réseaux plus larges afin de limiter leur exposition. Cette approche étend les pratiques standards de segmentation réseau aux systèmes de laboratoire, en contrôlant leur exposition sans les isoler complètement, tout en maintenant les flux de données nécessaires aux opérations. Elle est peu coûteuse et facile à déployer, ce qui la rend particulièrement adaptée aux systèmes anciens qui ne peuvent pas être mis à jour.
• Déploiement d’équipements « Edge » pour la traduction des protocoles et l’isolation réseau. Ces dispositifs sont particulièrement efficaces dans les environnements nécessitant un échange de données en temps réel entre des systèmes incompatibles.

Figure 2 : Architecture réseau pharmaceutique intégrant des mesures de protection des équipements de laboratoire.

Bien que ces solutions contribuent à sécuriser les environnements industriels, elles introduisent également de nouveaux défis, tels que la gestion des correctifs et la responsabilité des équipements — des facteurs cruciaux pour maintenir la sécurité à long terme. Il s’agit de réponses à une situation initialement non sécurisée et, par conséquent, elles ne sont pas parfaites : par exemple, l’utilisation de postes de travail comme passerelles constitue une bonne pratique, mais nécessite la mise à jour des systèmes, la gestion du cycle de vie, et peut impliquer des coûts supplémentaires ainsi qu’une empreinte accrue dans les salles serveurs (besoin accru d’infrastructure).

Le choix de la solution pour atténuer les risques de cybersécurité doit être en adéquation avec les contraintes techniques et le contexte opérationnel de l’organisation. Quelques pratiques courantes permettent d’illustrer la diversité des stratégies :

• L’isolation des équipements de laboratoire dans un VLAN dédié reste une première étape efficace. Cependant, même les systèmes segmentés doivent utiliser des protocoles de communication sécurisés afin de garantir l’intégrité des données et d’empêcher tout accès non autorisé.
• La mise en place des équipements « Edge » offre une couche de protection supplémentaire. Cependant, ils présentent leurs propres défis, notamment en ce qui concerne la responsabilité organisationnelle, ainsi que la gestion et la maintenance.
• Le déploiement de postes de travail équipés d’outils de cybersécurité qui font souvent office de passerelles par défaut, convertissant les données en formats pouvant être lus et traités — que ce soit par les LIMS, les plateformes cloud ou les bases de données internes. Cette configuration est courante et reste sécurisée tant que le poste est correctement administré et durci, afin de ne pas devenir un point de défaillance ou d’introduire une surface d’attaque supplémentaire. La mise en place de cette couche intermédiaire est idéale, mais elle nécessite le développement ou l’intégration de mécanismes de traduction fiables, parfois non pris en charge par le fournisseur.

Conclusion : Renforcer la cybersécurité en environnement de laboratoire

Dans les industries concernées, garantir l’intégrité des données, la qualité du produit final et la sécurité des consommateurs reste une priorité majeure. Cependant, à mesure que les laboratoires deviennent de plus en plus numérisés et interconnectés, de nouveaux cas d’usage émergent, remettant en question les architectures et les modèles opérationnels traditionnels. Cette évolution exige une approche de cybersécurité plus complète et globale — intégrant des mesures techniques, une maturité des processus et une gouvernance claire à l’échelle de l’ensemble de l’écosystème laboratoire.

La mise en œuvre d’un processus de cybersécurité « by design » tout au long du cycle de vie des projets semble essentielle — non seulement pour anticiper les risques cyber au plus tôt, mais aussi pour aider les équipes métiers à intégrer la sécurité de manière fluide dans leurs opérations.

Néanmoins, le Cyber Resilience Act (CRA) vient renforcer la cybersécurité des produits numériques au sein de l’Union Européenne aussi bien pour les fabricants de produits, que les importateurs ou distributeurs de ces produits.

Pour aller plus loin : Cyber Resilience Act : Une révolution qui redéfinit la sécurité des produits et transforme l’écosystème – RiskInsight

Cet article Protéger les instruments connectés : un enjeu croissant pour les laboratoires est apparu en premier sur RiskInsight.

Dans cet article précédent : Quelle détection pour l’OT ?  Situation actuelle & perspectives, nous avons constaté que l’OT, bien que moins touché que l’IT, n’est pas exempt ni immunisée contre les cyberattaques. Toutefois, en raison de la difficulté à mettre à jour les systèmes de contrôle industriels (ICS), les mesures de cybersécurité sont souvent ajoutées après le déploiement. Le monitoring continu est perçu comme un substitut pratique à une protection intégrée dès la conception (cyber-by-design).

En matière d’outillage de monitoring, nous avons observé que 100 % de nos clients disposent d’outils de détection déployés du côté IT. Cependant, seul un tiers étend cette surveillance jusqu’aux couches inférieures de l’environnement industriel :

Il existe une grande variété de sources de détection permettant une surveillance (monitoring) à travers les différents niveaux du modèle Purdue :

• Logs de pare-feu (y compris industriels)
• Logs des protection des endpoints (antivirus, whitelisting d’applications, EPP, EDR, etc.)
• Logs d’authentification et d’accès (par exemple, Active Directory ou authentification locale)
• Logs d’accès distant (par exemple, VPN, serveurs de rebond, bastion)
• Les honeypots et autres
• Sondes de détection et de surveillance réseau (écoute des réseaux industriels)
• Logs des stations blanches (par exemple, bornes USB)
• Logs industriels (provenant des systèmes SCADA, IHM, PLC… lorsqu’ils sont disponibles)

Traditionnellement, peu de ces logs sont collectés et analysés par les solutions SIEM et/ou SOAR, avec ou sans modèles de détection OT spécifiques. Pourtant, ils devraient permettre à l’équipe du SOC de détecter, d’enquêter sur les événements de sécurité et d’y répondre.

Élaborer une stratégie de détection cohérente pour les environnements OT ne nécessite pas de collecter les données de toutes les sources possibles. En réalité, quelques sources bien choisies, correctement configurées, peuvent permettre d’offrir une forte visibilité et de solides capacités de détection. L’essentiel est de se concentrer sur les sources de logs qui sont à la fois pertinentes au regard de l’architecture OT et facile à mettre en place sans perturber les opérations. Prioriser la qualité et la pertinence opérationnelle des sources de détection plutôt que leur quantité permet d’assurer une posture de cybersécurité plus efficace et durable.

Comment tirer le meilleur parti des sources de détection ?

Commencer avec les logs déjà disponibles

Une approche pragmatique et rentable de la détection OT consiste à commencer par exploiter les logs et les modèles de détection déjà disponibles dans l’environnement industriel, en particulier ceux qui sont déjà utilisés pour vos environnements IT. Par exemple, les logs des pares-feux, notamment ceux qui surveillent les périmètres IT/OT, peuvent fournir des informations précieuses sur les schémas de trafic réseau, les violations de segmentation ou les tentatives d’accès distant suspectes. De même, les logs Active Directory (AD) peuvent révéler des comportements utilisateurs anormaux, des échecs d’authentification ou des élévations de privilèges — tous étant des signaux critiques dans les contextes IT et OT. L’exploitation de ces sources existantes permet aux organisations de mettre en place des capacités de détection initiales sans investissement lourd, tout en posant une base solide pour une surveillance plus avancée à l’avenir.

Plutôt que de commencer par le déploiement d’outils de détection complexes spécifiques à l’OT, les organisations devraient construire leurs capacités de détection initiales en utilisant ce qui est déjà déployé, configuré et maîtrisé. Cette approche permet non seulement de réduire les coûts, mais aussi d’accélérer la mise en œuvre sur l’ensemble des sites industriels. L’objectif est d’assurer un niveau de visibilité de base cohérent sur les applications, les systèmes et les infrastructures critiques avant d’approfondir la surveillance.

En commençant par l’existant et en se concentrant sur la couverture plutôt que sur la complexité, les organisations peuvent aborder la détection OT avec rapidité, pertinence et réalisme opérationnel, tout en préparant le terrain pour des capacités plus avancées à l’avenir.

Nous allons maintenant aller plus loin en nous concentrant sur les deux outils de détection les plus déployés et discutés dans les environnements industriels aujourd’hui : les solutions EDR et les sondes de détection réseau.

EDR

Les solutions EDR (Endpoint Detection & Response) offrent une surveillance et une analyse continues des activités des points de terminaison afin de détecter les cybermenaces, d’y enquêter et d’y répondre en temps réel. L’EDR collecte des données détaillées telles que l’exécution des processus, les modifications de fichiers, les connexions réseau et le comportement des utilisateurs. En s’appuyant sur l’analyse comportementale et les renseignements sur les menaces (threat intelligence), les outils EDR peuvent identifier des activités suspectes comme les infections par logiciels malveillants, les mouvements latéraux ou les élévations de privilèges.

Cet outil de détection, largement utilisé dans les environnements IT, est désormais adopté par la majorité de nos clients pour un déploiement au sein de leurs environnements industriels.

Cependant, cela ne signifie pas que 100 % des dispositifs OT sont compatibles avec les solutions EDR. En réalité, la compatibilité des EDR varie considérablement selon la diversité des systèmes industriels et leurs contraintes opérationnelles. Le déploiement de l’EDR est généralement simple aux niveaux supérieurs du modèle Purdue, tels que la Couche 3 et la Couche 3.5, où les systèmes (serveurs et postes de travail) ressemblent à des environnements IT traditionnels. À la Couche 2, l’implémentation exige des tests approfondis et une personnalisation, car les dispositifs et les protocoles sont plus spécialisés et leurs ressources limitées. Enfin, aux niveaux les plus bas (contrôleurs, PLC et équipements de terrain), l’EDR n’est généralement pas viable en raison de leur capacité de traitement limitée, de leurs systèmes d’exploitation propriétaires et de leurs exigences de performance en temps réel. Le déploiement sur de tels dispositifs risque de perturber les processus critiques ou de provoquer l’instabilité du système, et doit donc être évité.

Pour les environnements qui le supportent, l’extension de la couverture EDR permet :

• Répondre à la faible maturité : Commencer par des outils plus simples à mettre en œuvre et nécessitant une maturité moindre.
• Couverture étendue : Se concentrer sur la couverture rapide d’un large éventail de systèmes, de sites et d’applications critiques.
• Exploiter les outils IT : Utiliser des solutions basées sur la IT, comme l’EDR, pour une détection efficace sans nécessiter de lourdes exigences d’infrastructure.

Pour conclure, le déploiement d’agents EDR sur les serveurs et les postes de travail OT devient de plus en plus pertinent et représente une possibilité de gain rapide pour la détection OT, selon les retours de nos clients.

Les Sondes de Détection OT

Une sonde de détection (detection probe) est un équipement, qu’il soit virtuel ou physique, connecté au système d’information afin de le cartographier et de le surveiller. Elle est composée de capteurs distribués à travers le réseau pour collecter des données, et typiquement, d’une console centrale pour agréger, corréler et analyser ces informations.

 Les sondes destinées aux environnements industriels, que nous appellerons ici simplement sondes OT, se caractérisent par leur écoute passive et non invasive sur le réseau, ainsi que par leur compréhension des protocoles et comportements industriels. Toutes ces solutions de sondes fonctionnent sur le même principe : le trafic réseau est collecté via une duplication de flux (SPAN, ERSPAN…) ou un duplicateur physique (Taps, etc.). Les paquets sont inspectés en temps réel pour fournir plusieurs types de données : inventaire et cartographie des flux, gestion des actifs et des vulnérabilités, et enfin, détection des anomalies et des incidents. Ce sont précisément les larges capacités de détection promises ainsi que la variété des cas d’usage possibles de ces données et des types d’utilisateurs impliqués (équipes opérationnelles et métiers, équipes de cybersécurité, etc.) qui rendent les sondes OT si populaires.

Cependant, nos clients sont souvent confrontés à des défis importants lorsqu’il s’agit de déployer ces sondes à grande échelle et de les exploiter efficacement pour la détection sur l’ensemble des réseaux industriels.

Voici les défis fréquemment rencontrés lors du déploiement des sondes OT :

• Défis liés aux capacités et aux ressources du réseau des sites industriels : Le déploiement des sondes OT présente souvent des défis significatifs en raison des limites de l’infrastructure réseau industrielle. Les taps réseau et les ports SPAN sur les commutateurs, couramment utilisés pour la surveillance du trafic, ne sont pas toujours manageables ou disponibles dans les environnements OT, ce qui limite les options de capture de trafic passif. De plus, les coûts associés à l’installation de taps réseau peuvent être prohibitifs. Enfin, le déploiement et la maintenance des sondes exigent des ressources qualifiées sur place.
• Défis liés à la sélection des points d’écoute : Les sondes OT collectent et corrèlent l’information via la capture de trafic réseau. Pour être efficace, leur déploiement nécessite une sélection minutieuse des points d’écoute en fonction des cibles visées. Les points d’écoute doivent être adaptés à l’architecture de chaque site, un processus souvent limité par les connaissances des équipes locales et le manque de documentation. De plus, comme les environnements industriels varient d’un site à l’autre au sein d’une même organisation, il est très difficile d’établir un standard unique. Par conséquent, la sélection et la configuration des points d’écoute constituent un processus répétitif et itératif qui doit être ajusté pour chaque déploiement afin de garantir une visibilité et des capacités de détection optimales.

Au-delà du déploiement, l’exploitation de ces sondes s’accompagne également de défis et exige une charge de travail significative. Elles ont tendance à générer un nombre élevé de faux positifs, ce qui oblige les équipes à créer des règles de détection et des playbooks sur mesure pour filtrer et répondre efficacement aux alertes. En moyenne, nous estimons qu’un analyste SOC à temps plein est requis pour gérer les alertes générées par 50 sondes.

En conclusion, bien que les sondes OT soient populaires, les coûts et les ressources nécessaires à leur déploiement et à leur exploitation limitent leur pleine utilisation. Notre recommandation est de prioriser le déploiement des sondes OT sur les sites critiques ou au sein des segments réseau clés qui exigent des capacités avancées de surveillance industrielle. Cette approche ciblée permet de maximiser le retour sur investissement tout en garantissant une détection efficace là où elle est essentielle pour nos clients.

Envisager d’autres solutions ?

Concernant la détection pour le périmètre industriel, bien que cet article se concentre sur des sources clés comme les solutions EDR et les sondes réseau OT, il est important de reconnaître que d’autres solutions, telles que les technologies de leurre comme les honeypots, peuvent également jouer un rôle précieux et être pertinentes dans des scénarios ou environnements spécifiques, en fonction de l’architecture de vos sites industriels ou des scénarios de compromission redoutés.

Conclusion

Pour conclure, voici les recommandations clés pour élaborer une stratégie d’outillage de détection efficace pour mettre sous surveillance des environnements industriels :

1. Tirez parti des outils existants pour un impact immédiat

Commencez par maximiser la valeur des sources de détection déjà disponibles dans votre environnement industriel : logs de pare-feu, EDR, Active Directory, logs d’accès distant, etc. L’adaptation à l’OT des patterns de détection IT éprouvés permet aux organisations d’atteindre rapidement un niveau de visibilité de base sans nécessiter d’investissements lourds. Cette première approche garantie un déploiement plus rapide et une couverture plus large de vos assets industriels.

2. Déployer des solutions avancées là où elles sont pertinentes

Lorsque vous étendez vos capacités de détection, donnez la priorité au déploiement d’outils avancés tels que les sondes réseau OT là où ils apportent le plus de valeur. Pour les sondes réseau, concentrez-vous sur les sites ou segments critiques et sélectionnez soigneusement les points d’écoute afin d’optimiser la visibilité, le coût et les frais généraux opérationnels. Cette approche de déploiement ciblée garantit une utilisation efficace et stratégique des ressources.

3. Prioriser la qualité et la pertinence plutôt que la quantité

Pour élaborer une stratégie de détection OT efficace, il n’est pas nécessaire d’écouter toutes les sources de données possibles. Concentrez-vous plutôt sur les sources qui sont à la fois pertinentes pour votre environnement et techniquement exploitables, sans perturber les opérations. Cette approche permet de réduire les coûts de stockage et de gestion des journaux et de créer des règles de détection pertinentes et de meilleure qualité.  

N’hésitez pas à nous contacter pour discuter de la manière dont vous pouvez élaborer et améliorer votre stratégie de détection pour surveiller vos actifs industriels !

Dans notre prochain article, nous examinerons comment évaluer la détection en environnements industriels en utilisant des exercices de purple team, une méthode pratique pour évaluer et améliorer vos capacités de détection.

Cet article ​​Stratégie d’outillage cybersécurité pour une détection industrielle efficace​ est apparu en premier sur RiskInsight.

En 2024, on estimait le nombre d’appareils IoT connectés dans le monde à environ 18 milliards, soit plus de deux fois la population mondiale. Des alarmes connectées aux ascenseurs intelligents, en passant par les capteurs industriels ou les dispositifs médicaux, ces technologies rythment désormais notre quotidien. 

Les récentes avancées dans le domaine de l’IoT ont transformé la façon dont nous interagissons avec les objets connectés. Conçus pour être intuitifs, ils sont accessibles sans expertise spécifique. Les connexions entre ces derniers, souvent sans fil, passent presqu’inaperçues aux yeux des utilisateurs. Pourtant, derrière cette apparente simplicité se cachent des protocoles de communication élaborés dont MQTT fait partie.   

En raison de sa popularité et de sa présence croissante au sein d’opérations sensibles, MQTT fait depuis plusieurs années l’objet de recherches quant aux risques liés à son utilisation. Nous nous intéresserons ici à son fonctionnement, ses vulnérabilités potentielles ainsi qu’aux bonnes pratiques permettant d’assurer la sécurité des communications. 

MQTT et les raisons de sa popularité 

Les forces de ce protocole 

Développé en 1999 par Andy Stanford-Clark (IBM) et Arlen Nipper (Arcom), l’objectif derrière la conception de MQTT était de fournir une solution légère, efficace, avec une faible consommation d’énergie et de bande passante pour surveiller des oléoducs isolés dans le désert par le biais d’une liaison satellitaire. 

Si MQTT s’est aujourd’hui établi comme une référence pour la transmission de données IoT, c’est précisément pour ces propriétés fondamentales. Ce protocole est par ailleurs fréquemment utilisé pour la remontée de données provenant de capteurs ou d’objets connectés vers des plateformes Cloud. 

Figure 1 – Caractéristiques principales de MQTT 

Son fonctionnement

Définitions des termes clés 

Client MQTT : Un dispositif échangeant des informations. 

Broker MQTT : Une entité intermédiaire permettant à des clients MQTT de communiquer et par laquelle tous les messages MQTT transitent. En particulier, le broker reçoit les messages publiés et les distribue aux destinataires concernés (les abonnés au topic correspondant). 

Topic : Une chaine de caractères permettant de filtrer et d’organiser les messages selon une structure hiérarchique. Lorsqu’un client publie un message, il l’associe à un topic. 

Publish/Subscribe : Modèle dérivé du Client/Serveur classique pour lequel les demandes ne sont pas initiées par un client demandant des ressources à un serveur mais par un serveur envoyant régulièrement des mises à jour à des clients sans sollicitation active. 

MQTT est un protocole de communication « Machine à Machine » ou M2M qui opère selon un modèle Publish/Subscribe ce qui permet une grande souplesse dans son implémentation. 

Les clients MQTT peuvent endosser le rôle de publisher, subscriber ou les deux.   

Afin de recevoir les informations dont ils ont besoin, les subscribers s’abonnent à des rubriques ou topics (1), généralement organisés de manière hiérarchique au sein du broker (ex. Maison/Chambre/…). Dès lors qu’un publisher aura émis un message destiné aux abonnés de ce topic (2), ils seront notifiés par le broker (3).    

De ce fait, les clients MQTT ne sont pas contraints de partager un même réseau, ni d’être actifs au même moment et ne nécessitent pas de synchronisation entre eux.  

Figure 2 – Illustration d’une architecture MQTT simplifiée 

Par ailleurs, MQTT propose un mécanisme de « Qualité de Service » de ses messages permettant d’adapter les communications aux exigences de l’application. Il est ainsi capable, par exemple, de garantir la livraison des messages en cas de connexion instable. Les clients MQTT peuvent sélectionner un niveau parmi trois de « QoS » pour la distribution de leurs messages : 

• QoS 0 « Au plus une fois » – Le message sera distribué une fois ou pas distribué du tout, sans accusé de réception. 
• QoS 1 « Au moins une fois » – Le message sera distribué périodiquement tant que l’expéditeur n’aura pas reçu d’accusé de réception. 
• QoS 2 « Une seule fois » – Le message est garanti d’être distribué et une seule fois. 

Le niveau de « QoS » choisi a également une incidence sur la durée de stockage du message localement auprès de l’expéditeur et du destinataire. 

Cette architecture permet d’établir des communications décentralisées et extensibles (scalable). Ces caractéristiques s’avèrent particulièrement avantageuses dans le domaine de l’IoT où la flexibilité est essentielle pour répondre à la diversité des cas d’usage. Elles expliquent également pourquoi MQTT dépasse largement le cadre de l’IoT et trouve des applications dans de nombreux autres environnements tels que la télémétrie et la surveillance industrielle. 

MQTT est-il vulnérable ? 

A l’instar de nombreux autres protocoles de communication, MQTT n’est pas sécurisé par défaut. Bien que la plupart de ses implémentations intègrent à présent des solutions de sécurité robustes, certaines faiblesses et erreurs de configurations persistent, rendant les systèmes vulnérables. 

Pour souligner ces notions, nous nous intéresserons à un exemple standard d’utilisation de ce protocole en milieu industriel. 

Figure 3 – Illustration d’un exemple d’utilisation industrielle de MQTT 

Dans ce scénario, tous les systèmes représentés contiennent un client MQTT permettant de souscrire ou de s’abonner à des topics et de communiquer avec le broker « on-premise ». Les communications MQTT ne sont pas chiffrées et il n’y aucune authentification du broker ou des clients, laissant la possibilité à un attaquant d’accéder aux données de production échangées en clair ou de transmettre des ordres aux équipements en usurpant l’identité du broker ou de l’un de ces clients. 

Comment se protéger ? 

Pour se protéger efficacement contre ces risques, le broker et les clients MQTT doivent être déployés et configurés avec vigilance. Nous proposons ici différentes étapes de sécurisation afin d’assurer la confidentialité, l’intégrité, l’authenticité et la disponibilité des communications de bout en bout. 

Sécurisation du broker MQTT 

Activation du chiffrement par défaut des communications 

Lorsque le port 8883 est l’unique port MQTT défini, les tentatives de communication non-chiffrées sur le broker sont rejetées. Par ailleurs, il est essentiel que le broker ait accès à un certificat ainsi qu’une clé privée valides et que la suite cryptographique utilisée soit sécurisée (par exemple TLS 1.2 ou 1.3).  

Figure 4 – Activation du chiffrement sur un broker MQTT Mosquitto par le biais d’un fichier de configuration 

De nombreux dispositifs IoT ont une faible capacité de calcul et peu de ressources, ajouter des mécanismes tels que TLS peut représenter une surcharge importante. 

Mise en place d’une authentification des clients et d’un contrôle de leurs droits d’accès 

MQTT permet l’authentification des clients se connectant à un broker, via des méthodes courantes telles que l’utilisation d’un nom d’utilisateur et d’un mot de passe (avec un fichier de mot de passe associé) et la vérification du certificat du client, validé par une autorité de certification (le broker devant disposer du certificat de cette autorité). Certains brokers permettent également l’utilisation de solutions d’authentification externes. 

Afin de restreindre l’abonnement ou la publication sur certains topics par les clients, une logique d’Access Control List ou ACL peut être ajoutée.

Figure 5 – Ajout d’une authentification par certificat et mot de passe avec un contrôle d’accès sur un broker MQTT Mosquitto 

Une gestion rigoureuse des topics est essentielle pour prévenir les fuites de données et limiter les risques de compromission du broker. L’utilisation des wildcards # et + doit être attentivement surveillée, car une configuration trop permissive permettrait à un attaquant d’accéder à tous les échanges en cours. 

Déploiement de mesures de protection du broker  

Une rapide recherche sur le moteur Shodan révèle l’exposition de milliers de brokers MQTT sur Internet souvent laissés dans leur configuration par défaut, dont les utilisateurs ignorent l’existence ou les implications. Il est donc primordial de protéger le broker de menaces à la fois internes et externes en appliquant de bonnes pratiques de sécurité, telles que la mise à jour régulière du système ou la restriction du nombre de requêtes et connexions simultanées, pour prévenir les attaques par déni de service et garantir sa disponibilité. 

Sécurisation des clients MQTT 

Activation du chiffrement des communications 

Afin de se connecter sur le broker, les clients devront utiliser le port 8883 et posséder un certificat ainsi qu’une clé privée valides auquel cas la connexion sera rejetée.   

Figure 6 – Connexion chiffrée sur un client MQTT Paho 

L’utilisation de certificats auto-signés pour la connexion au broker est fortement déconseillée car ces derniers peuvent être facilement substitués. 

Mise en place d’une authentification du broker (authentification mutuelle) 

En plus de l’authentification des clients, MQTT permet l’authentification du broker via la vérification de l’autorité de certification ayant signé son certificat, assurant ainsi une authentification mutuelle (mTLS) et la sécurité des communications. 

Figure 7 – Authentification du broker sur un client MQTT Paho 

Déploiement de mesures de protection du client 

En cas de compromission d’un client MQTT, un attaquant pourrait accéder à des nombreuses informations en fonction de la configuration du broker ciblé. C’est pourquoi les clients et leurs secrets doivent aussi être protégés par l’application de bonnes pratiques de sécurité sur la machine hôte du client et sur le contenu des échanges (ajout de mécanismes anti-rejeu sur les requêtes par exemple).  

Quel futur pour MQTT ? 

Malgré sa maturité, MQTT demeure un protocole en évolution et intègre progressivement des fonctionnalités innovantes afin de répondre aux exigences croissantes des environnements connectés. Dans un contexte où la demande pour des communications fiables, sécurisées et à faible consommation d’énergie ne cesse d’augmenter, il est vraisemblable que les cas d’utilisation de MQTT continueront de se multiplier au cours des années à venir.

Cet article La sécurité du protocole MQTT est apparu en premier sur RiskInsight.

L’OT, bien que globalement moins touché que l’IT, n’est pas exempt de cybermenaces. Voici une vue simplifiée de ces principales menaces :  

• Hacktivisme : Les tensions géopolitiques accrues en 2025 ont entraîné des attaques de faible intensité par des groupes comme CyberArmyofRussia_Reborn et CyberAv3ngers.  
• Cybercriminalité / Ransomware : Une augmentation de 87 % des attaques par ransomware dans les groupes industriels a été constatées en 2025 d’après les chiffres de Dragos dans son rapport annuel.  
• Menaces étatiques : On note les campagnes récentes telles que Voltzite (vol d’informations OT) ou IOControl.

Ce panorama des menaces a notamment été dépeint par Chris Sistrunk, ICS/OT Technical Leader chez Mandiant, Google Cloud Security, lors de la Black Hat 2025 :  

Face à l’augmentation des menaces ciblant les environnements OT, leur surveillance continue est devenue essentielle. Les systèmes d’information industriels doivent être étroitement surveillés, et nous savons que nos clients y travaillent activement. Mais une question demeure : comment mesurer l’efficacité de la détection en environnement industriel, et surtout, comment l’améliorer ?  

Comment mesurer et améliorer l’efficacité de la détection en environnement industriel ? 

Pour répondre à cette question, nous avons élaboré une méthodologie visant à évaluer les capacités de détection au sein des SOC industriels.  

Cette évaluation s’articule autour des activités clés d’un SOC, réparties en quatre grands piliers : gouvernance & stratégie, prévention, détection et réponse.

En nous appuyant sur cette méthode, nous avons évalué une quinzaine de clients industriels afin de mieux comprendre leur niveau de maturité. Dans cet article, nous partageons les principales tendances qui en ont émergé, en nous concentrant spécifiquement sur les questions liées à la détection.  

Deux articles complémentaires seront publiés : l’un dédié à l’efficacité des différentes stratégies et solutions de détection, et l’autre aux méthodes de test des capacités de détection dans des environnements industriels à l’aide d’exercices de purple teaming et des modules dédiés que nous avons développés.  

Gouvernance et Stratégie  

La première question sur laquelle nous nous sommes concentrés était de savoir si la supervision des sites et environnements industriels est assurée par une équipe dédiée utilisant des outils spécifiques ou si, au contraire, elle est intégrée dans une approche d’un SOC unique et centralisé.  

Les réponses sont unanimes :  

Ces chiffres peuvent s’expliquer par plusieurs facteurs. L’une des principales raisons est l’optimisation financière. Maintenir deux équipes distinctes aux compétences et rôles similaires : gestion des alertes, configuration des outils … représente un coût important.  

Cependant, un SOC unifié implique généralement une extension du périmètre de son SOC IT pour inclure l’OT, sans pour autant garantir la présence d’outils ou d’expertises spécifiques à l’OT, et donc de véritables capacités de détection pour couvrir les environnements industriels.  

Même si cette approche ne garantit pas une détection et une réponse efficace sur l’ensemble du périmètre industriel, un SOC unifié peut tout de même gérer efficacement les incidents OT, à condition de : 

Assurer supervision de bout en bout  

En examinant de plus près le paysage simplifié des menaces, on constate que les cyberattaques ne sont pas forcément spécifiques à l’IT ou à l’OT (hacktivisme, ransomware …).  

Les ransomwares par exemple, qui représentent toujours aujourd’hui la principale menace, ne se limitent pas à un environnement industriel ou bureautique. Ils se propagent souvent à travers les deux, rendant indispensable le suivi des alertes de bout en bout.  

Ainsi, unifier les équipes et les outils de détection fait sens, puisque les attaques ne se limitent pas à l’IT ou OT. 

Faire le lien avec les sites industriels 

En cas d’incident cyber, le temps de réponse et le partage d’informations est essentiel. Comme la plupart des équipes de sécurité sont centralisées en un seul lieu, il est nécessaire d’établir un lien, au travers d’un relais cyber local, entre ces équipes centrales et les sites industriels locaux dans le processus de gestion des incidents cyber :  

• Ce relais connaît bien les sites industriels, leurs caractéristiques, contexte opérationnel et modes de fonctionnement.  
• Il maintient également un contact direct sur site pour recueillir rapidement les informations nécessaires au triage, ou à l’investigation.  
• De plus, dans les organisations globales, disposer de ressources situées dans les bons fuseaux horaires et capables de communiquer dans la langue locale est indispensable, en particulier dans le monde industriel.  

Appelés dans le schéma ci-dessous des « référents Cyber-OT », ces relais jouent un rôle actif dans le processus de résolution des incidents, en particulier durant les phases d’investigation et de remédiation :

En conclusion, bien que ces SOC unifiés couvrant à la fois les périmètres IT et l’OT résultent généralement d’un besoin d’optimisation des coûts, ce modèle fait sens dans la mesure où de nombreuses menaces concernent les deux environnements. Toutefois, il ne faut pas considérer un SOC unifié comme une simple extension du périmètre à couvrir : des relais OT dédiés et une expertise spécifique sont indispensables pour adresser efficacement les environnements industriels. 

Outillage et solution de détection  

En ce qui concerne les solutions de détection, nous avons constaté que 100 % de nos clients disposent d’outils de détection déployés côté IT. Cependant, seulement un tiers étend la supervision jusqu’aux couches inférieures de l’environnement industriel.  

Nous nous concentrerons par la suite sur les solutions les plus populaires pour adresser la détection dans les environnements industriels : les EDR et les sondes OT.  

EDR  

Quelques chiffres concernant les EDR :  

La plupart de nos clients ont commencé à déployer des EDR dans leurs environnements industriels. Cependant, cela ne signifie pas que 100 % des machines industrielles compatibles avec les EDRs sont couvertes.  

Pour les environnements qui le permettent, étendre la couverture EDR permet de :  

• Répondre à une maturité faible : commencer par des outils simples à déployer et qui ne nécessitent pas de connaissances avancées de l’architecture des sites.  
• Assurer une couverture large spectre : se concentrer sur la couverture rapide d’un large éventail de systèmes, de sites et d’applications critiques.  
• Tirer parti des solutions de l’IT : utiliser des solutions IT comme les EDRs pour une détection efficace sans nécessiter d’adaptation majeure des équipes SOC.  

Pour cette dernière raison, la plupart des organisations choisissent d’utiliser la même solution EDR pour les environnements IT et OT. Cela permet un déploiement plus rapide grâce à un outil connu et déjà intégré. Selon les besoins et les ressources disponibles, une solution différente peut toutefois être sélectionnée afin d’améliorer la résilience et la compatibilité OT.

Pour conclure, dans un contexte de convergence IT/OT, déployer des EDR sur les serveurs et postes de travail industriels devient de plus en plus pertinent et selon les retours d’expérience de nos clients, permet d’étendre rapidement et efficacement la couverture de détection des périmètres industriels.   

Sondes de détection OT 

Quelques chiffres concernant les sondes :   

En ce qui concerne les sondes, l’écart entre ces deux chiffres met en lumière le défi que représente leur déploiement à grande échelle et leur utilisation efficace pour la détection dans les réseaux industriels.  

En effet, les sondes collectent des informations via la capture du trafic réseau. Pour être efficaces, leur déploiement nécessite une sélection des points d’écoute en fonction des objectifs cibles. Ces points d’écoute doivent être adaptés à l’architecture spécifique de chaque site, souvent limité par la connaissance locale des équipes ou le manque de documentation.  

L’exploitation de ces sondes demande également une charge de travail importante. Elles ont tendance à générer un grand nombre de faux positifs, ce qui oblige les équipes à créer des règles de détection personnalisées et des playbooks pour filtrer et répondre efficacement.  

En conclusion, les sondes de détection OT sont peut-être populaires, mais les coûts et les ressources nécessaires pour leur déploiement et leur ajustement limitent leur pleine utilisation.  

Commencer par couvrir l’essentiel avec la détection d’outils OT 

En définitive, pour la détection OT, nous pensons qu’il faut commencer par des mesures basiques en tirant parti des outils « IT » afin d’assurer un premier niveau de couverture sur l’ensemble des sites, des applications critiques et de l’infrastructure en :  

• Priorisant les assets critiques : Se concentrer sur les systèmes clés (MES, outils de sécurité, infrastructure réseau) essentiels à la production, en veillant à leur mise sous supervision avant d’étendre le déploiement aux couches inférieures du modèle de Purdue.  
• Mettant en place une détection basique : Établir une détection fondamentale sur les sites et l’infrastructure pour permettre une identification en amont des incidents, avant de passer à des solutions OT plus avancées.  

S’entraîner et se tester 

Les capacités de détection ne reposent pas uniquement sur le déploiement d’outils ; cette dernière partie des conclusions du benchmark se concentrera sur la capacité des équipes à les exploiter efficacement.  

La nécessité de renforcer les connaissances spécifiques à l’OT 

Les chiffres issus du benchmark révèlent une connaissance et adaptation limitées des équipes et des processus aux environnements industriel :   

Pour combler cet écart, les équipes doivent bénéficier de formations spécifiques aux contextes industriels : une formation de base pour l’ensemble des analystes SOC, et une formation approfondie pour les spécialistes OT.   

De la même manière, les processus d’investigation et de réponse doivent également être adaptés pour répondre aux spécificités des environnements industriels, en prenant en compte des priorités comme la disponibilité.  

Testez vos capacités de détection !  

Enfin, l’amélioration de la détection commence par son évaluation, mais aujourd’hui… 

Seule une petite minorité de nos clients teste réellement ses capacités de détection, mais nous sommes convaincus de la valeur ajoutée des exercices de purple teaming dans les environnements industriels. Ces exercices collaboratifs avec le SOC OT, adaptés à son niveau de maturité et à ses objectifs, permettent de tester et d’améliorer à la fois les outils de détection et les processus du SOC OT.   

Il est possible de commencer simplement : en sélectionnant des environnements de production appropriés et en réalisant quelques tests basiques, comme l’insertion d’une clé USB contenant un échantillon de malware standard ou la tentative de quelques actions d’élévation de privilèges… 

On peut ainsi évaluer si l’EDR déployé sur un poste de travail connecté au SOC déclenchera une alerte et une investigation.  

Ces exercices permettent d’identifier les angles morts et d’ajuster en conséquence les outils déployés, les processus et les playbooks.  

Conclusion : Comment renforcer le faible niveau de maturité en matière de détection pour les systèmes industriels ? 

La première conclusion du benchmark est claire : les niveaux de maturité sont faibles, et cette réponse est constante dans toutes les réponses recueillies. Comment améliorer cette maturité globalement faible en matière de détection pour les systèmes industriels ? 

Voici les principaux enseignements concernant les trois thématiques abordées dans cet article : 

N’hésitez pas à nous contacter pour échanger sur la manière de renforcer vos capacités de détection et d’évaluer votre maturité par rapport au marché ! 

Cet article ​Quelle détection pour l’OT ?  Situation actuelle & perspectives est apparu en premier sur RiskInsight.

Au-delà de la simple interruption des opérations et la perte financière, les impacts sur l’intégrité physique des personnes et sur l’environnement sont des impacts HSE (Hygiène Sécurité Environnement) majeurs et qui impliquent des risques importants à prendre en compte pour le secteur industriel. 

Face à ces menaces et impacts grandissants, les industriels ont jusqu’à présent investi dans la protection des leurs systèmes d’information industriels. On constate désormais la prise en compte de la résilience et l’intégration de projets de résilience dans les feuilles de route cyber OT. En fonction du secteur et de l’entité industrielle, il peut être plus intéressant d’investir dans une reprise efficace que dans un trop grand nombre de protection. En combinant résilience et protection, les entreprises ont la capacité de reprendre au plus vite et en sécurité la majorité de leurs activités industrielles pour réduire les dégâts et les pertes financières.

Dans ce contexte, la cyber-résilience s’impose comme une nécessité absolue.

 Quelles sont les clés pour bâtir cette résilience et faire face aux défis de demain ? Découvrons-les ensemble. 

Les enjeux de la cyber-résilience pour les organisations

La résilience cyber est désormais une priorité stratégique pour les industries. Les enjeux vont bien au-delà de la simple sécurité des systèmes : 

• Mettre en sureté les personnes et l’environnement : Dans certains secteurs (hospitalier, énergétique, nucléaire, traitement des eaux, etc.), la priorité est de sécuriser les installations, même au détriment de la production. L’impact humain et environnemental d’une cyberattaque pouvant être bien plus grave qu’un simple arrêt de la production. 
• Protéger les installations critiques : Dans un second temps, la sécurisation des installations critiques à la production doit être pris en compte. Un impact sur ces systèmes entrainera d’importantes répercussions sur l’activité et le chiffre d’affaires de l’entreprise. 
• Préserver les données sensibles : Certaines informations industrielles sont cruciales pour la compétitivité et la sécurité. Toute fuite ou altération peut nuire gravement à l’entreprise et dans certains cas, à la sécurité nationale. 
• Reprendre rapidement et en toute sécurité : La cyber-résilience vise à redémarrer les opérations rapidement, tout en garantissant la sécurité des installations et des personnes. 

Les enjeux dépassent également la sécurité interne de l’organisation, avec des impacts géopolitiques et réglementaires croissants : 

• Risques géopolitiques : Les cyberattaques sur les infrastructures critiques, comme celles de l’énergie ou du secteur de l’eau, ont des conséquences politiques et sociétales majeures. 

• Pression réglementaire : Les lois comme la directive NIS, la LPM et le Cyber Resilience Act imposent des exigences strictes, poussant les entreprises à renforcer constamment leur cybersécurité. 

Quelles sont les principales activités de la résilience ? 

Les grandes activités de la cyber-résilience reposent sur trois axes principaux, chacun essentiel pour garantir la pérennité des opérations face aux incidents.

1. Maintenir les activités critiques en mode dégradé :
   • Identifier les activités critiques à restaurer en priorité
   • Industrialiser les fonctionnements en mode dégradé pour permettre une continuité partielle de l’activité en attendant la reprise totale
   • Endiguer la propagation des incidents afin de limiter les impacts
2. Tester sa gestion de crise :
   • Cela inclut la mise en place d’exercices réguliers pour identifier les points d’amélioration et renforcer la résilience de l’organisation face aux cyberattaques
3. Industrialiser sa reconstruction : reconstruire et restaurer un SI sain
   • Il ne s’agit pas simplement de rétablir les services, mais de vérifier et renforcer chaque composant du système pour garantir sa sécurité à long terme. Cette phase permet de regagner la confiance des parties prenantes et d’assurer une infrastructure robuste, prête à prévenir toute future menace

La mise en place d’un Plan de Reprise Informatique Industrielle : pierre angulaire de la reprise informatique 

Le PRII (Plan de Reprise Informatique Industrielle) est l’élément central de toute stratégie de cyber-résilience de l’industrie. Ce document regroupe l’ensemble des procédures techniques, organisationnelles et de sécurité nécessaires pour reconstruire et relancer un système d’information OT après un sinistre ou un incident majeur. Le PRII est activé pendant ou après un sinistre ou une crise. Son rôle est de garantir une reprise rapide et fiable des activités industrielles. 

Le PRII contient généralement les éléments suivants : 

• Une matrice de responsabilités claire 
• Un ordonnancement pour une reconstruction efficace 
• Des procédures détaillées pour la restauration des systèmes d’information et des actifs du SI OT 
• Des informations sur le mode de communication adapté 
• Des recommandations sur la fréquence de tests pour valider la reprise d’activité 

L’objectif principal du PRII est de réduire au maximum le temps de reprise tout en assurant un niveau de confiance élevé en son SII. Il protège également les données sensibles et aide à limiter les pertes financières liées aux interruptions d’activité. En garantissant un haut niveau de sûreté, le PRII minimise les impacts physiques, environnementaux et législatifs, tout en préservant l’image de l’entreprise et en facilitant le travail des équipes opérationnelles. 

L’architecture documentaire de la reprise doit être adaptée à la taille et à la structure de l’entreprise. Il est essentiel de choisir correctement la granularité de la reconstruction et le format approprié pour chaque système d’information (SI) et entité industrielle. 

Exemple

• PRII Groupe (Plan de Reprise Informatique Industrielle Groupe) : document principal définissant les principes, responsabilités et processus de reprise d’activité au niveau du groupe. Il renvoie vers les PRII spécifiques à chaque site. Revue : tous les 5 ans ou en cas de modification majeure. 
• PRII Site (Plan de Reprise Informatique Industrielle d’un Site) : Document détaillant les principes et responsabilités de la reprise pour un site spécifique. Il précise également l’ordre de reprise des systèmes en cas de sinistre affectant plusieurs SI, et renvoie vers les fiches de reconstruction des SII. Revue : tous les 5 ans ou en cas de modification majeure. 
• Fiches de Reconstruction Usine/SII : Documents opérationnels qui détaillent l’ordonnancement et les actions nécessaires pour la reprise de chaque SII, incluant les schémas d’architecture et l’inventaire des actifs. Revue : chaque année ou en cas de modification des SII. 

Les clés de succès d’une reprise efficace : l’importance de bien cadrer son projet de reprise

Focus | Définir en amont l’usage des fiches pour une reprise optimale

Avant de passer à l’écriture et la mise en place des fiches de reconstruction du SII, il est important de prendre en compte plusieurs aspects afin de faciliter leur rédaction et coller à la réalité et des exigences métier. 

Les prérequis indispensables à l’écriture d’un plan de reprise informatique industrielle : pourquoi une documentation SII bien structurée est cruciale 

Il est nécessaire de formaliser des prérequis documentaires essentiels pour garantir la reprise efficace du système informatique industriel (SII), en mettant l’accent sur les éléments clés suivants : 

• Maîtrise du SII : Une connaissance approfondie du SII est indispensable. Cela inclut une vision claire des systèmes, un inventaire détaillé des actifs, ainsi qu’une cartographie et des schémas d’architecture (logique et physique). Il est également crucial d’identifier les référents SII, détenteurs des connaissances clés sur ces systèmes et de s’assurer que leurs informations sont régulièrement mises à jour. 
• Plan de sauvegarde : Un plan de sauvegarde complet, incluant les données critiques au bon fonctionnement de l’usine, est indispensable pour assurer une reprise rapide et complète de l’activité. Cela inclut des éléments tels que la sauvegarde des programmes et configurations d’automates, des PC administratifs, des systèmes SCADA, et des historians. 
• Connaissance Métier : La présence d’un correspondant Plan de Continuité d’Activité (PCA) ou métier est un atout majeur pour définir un ordonnancement efficace. Il permet de s’assurer que le plan de reprise est non seulement applicable, mais aussi opérationnel et en adéquation avec les besoins spécifiques de l’activité. 

Ces trois éléments fondamentaux sont incontournables pour initialiser une démarche de reprise informatique efficace et alignée avec les besoins réels du métier. Le projet ne pourra démarrer sans leur présence, ainsi que le financement adéquat du site. 

Pour aller plus loin | La reprise : Une grande étape de la mise en conformité du SII

Le projet de reprise d’activité permet de réaliser un état des lieux approfondi du SII, qui sert de base à l’élaboration d’un plan d’action pragmatique pour sa mise en conformité. Ce processus inclut l’identification des obsolescences dans le parc industriel, des sauvegardes manquantes et d’autres points de faiblesse. Grâce aux tests de reprise, de nombreuses recommandations et améliorations peuvent être mises en place pour renforcer la sécurité du SII et le rendre plus résilient face aux crises. 

Le plan d’action qui en découle met en lumière plusieurs points clés (non exhaustifs) : 

• Gestion de l’obsolescence : L’obsolescence des infrastructures SI doit être prise en compte dans la stratégie de reprise d’activité. Les équipements vieillissants peuvent gravement compromettre l’efficacité des plans de récupération. 
• Logiciel non maintenu sur PC obsolètes : L’utilisation de logiciels de supervision non maintenus par l’éditeur, installés sur des PC obsolètes (matériel et système d’exploitation), et difficiles à remplacer, présente un risque majeur. En cas de crise, cela pourrait empêcher le bon fonctionnement de l’usine faute de supervision. 
• Absence de sauvegarde de données critiques : L’absence de sauvegarde d’un serveur clé, essentiel pour la reprise d’activité de plusieurs sites, met en péril la continuité des opérations de l’entité. 
• Manque de documentation et non-respect des contrats : L’absence de documentation sur certains équipements (configurations, procédures d’installation) et l’absence de schémas d’architecture pour certains SI montrent un manquement aux exigences contractuelles. Ces lacunes compliqueront la reconstruction du SI en cas de crise. 

En conclusion, la réussite d’un projet de reprise d’activité pour les industries dépend d’une préparation rigoureuse, incluant la définition du sizing ainsi que les besoins des usines, l’élaboration d’une roadmap priorisant les activités critiques, et la constitution d’une équipe projet avec les ressources dédiées nécessaires. Ces étapes permettent de garantir une reprise fluide, dans les délais et budgets, tout en renforçant la résilience face aux risques cyber.

Cet article Résilience cybersécurité : un pilier essentiel pour protéger nos systèmes industriels est apparu en premier sur RiskInsight.

Dans un contexte où les menaces cyber deviennent plus ciblées, sophistiquées et persistantes, notamment à l’encontre des systèmes industriels et des infrastructures critiques, l’ANSSI renforce son dispositif de sécurisation en publiant une version refondue de son guide de classification des systèmes industriels, initialement paru en 2012. 

Ce guide s’adresse à l’ensemble des acteurs impliqués dans la sécurité des systèmes industriels : exploitants, opérateurs d’importance vitale (OIV), opérateurs de services essentiels (OSE), intégrateurs et prestataires, en charge d’aligner les exigences techniques avec les enjeux métiers. 

Il vise à fournir une méthode pour définir la criticité des systèmes industriels, afin de les ranger en classes de cybersécurité sur une échelle à 4 niveaux : mineur, modéré, majeur et catastrophique. Cette évaluation se fait selon la gravité maximale d’un impact potentiel sur : la population, l’économie et l’environnement. La classification permet de faciliter l’identification des besoins de sécurité et d’orienter la mise en œuvre de mesures de cybersécurité. 

Schéma des 4 classes de cybersécurité du guide 

Pourquoi revisiter le cadre existant ? 

La première version du guide de classification, parue en 2012, avait permis de poser les fondations d’une approche par niveau de sécurité, en introduisant une première segmentation en trois classes, basées sur le risque (impact x vraisemblance). 

Évolutions du guide entre la première et la deuxième version 

Si cette première version a joué un rôle fondamental et a été un vrai élan dans l’émergence d’une culture de la cybersécurité industrielle en France, à une époque où les référentiels spécifiques au monde industriel étaient encore rares, elle s’est heurtée à plusieurs limites. 

Premièrement, l’intégration de la vraisemblance dans la classification créait un “phénomène de bouclage”, pour reprendre les termes du guide. En effet, “au fur et à mesure que l’architecture du système industriel intégrait des mesures de sécurisation, la vraisemblance d’une attaque diminuait, abaissant par rebond la classification du système”. Ce phénomène fragilisait la stabilité de la classification et de ce fait, il était difficile de maintenir une cohérence entre classification et mesures. Par ailleurs, la première version du guide ne proposait que trois classes, ce qui résultait trop souvent en une définition des systèmes en classe 3. Enfin, il y avait un manque de granularité dans la définition des périmètres, et très peu d’alignement avec les normes internationales, comme l’IEC 62443. 

Le nouveau guide répond à ces constats. Il propose une approche fondée exclusivement sur l’impact, afin de garantir la stabilité des classes, une cohérence dans les comparaisons entre zones, et une meilleure articulation avec des démarches structurées d’analyse de risque comme EBIOS RM. Cette évolution permet aussi de mieux s’adapter à la diversité des organisations industrielles et à la complexité croissante de leurs systèmes. 

Une démarche méthodologique claire et intégrable aux référentiels existants 

Schéma de la méthodologie de classification du nouveau guide 

La nouvelle méthodologie repose sur une approche en trois activités structurantes : 

1. La définition du périmètre technique 
2. La segmentation en zones cohérentes 
3. La classification de ces zones selon la gravité des impacts potentiels en cas de compromission 

Cette démarche permet de classer le système industriel dans l’une des 4 classes de cybersécurité en fonction de la gravité des impacts et ainsi donner une lecture rationnelle des besoins de sécurité. Elle met l’accent sur deux critères clés : la disponibilité et l’intégrité, en cohérence avec les préoccupations de sécurité propres aux environnements industriels. 

Le guide ne se substitue pas aux démarches d’analyse de risque mais s’y intègre. Il a été conçu pour alimenter directement les ateliers EBIOS RM, en fournissant une base de classification qui alimente ensuite l’identification des événements redoutés et des mesures de sécurité associées. Cela permet d’éviter d’avoir à adapter ou déformer EBIOS RM pour tenir compte des spécificités industrielles. Il s’appuie également sur les concepts issus de la norme IEC 62443, notamment les notions de zones, de conduits et de niveaux de sécurité (Security Levels), permettant une convergence vers les pratiques industrielles internationales. 

Cette volonté de convergence avec les pratiques industrielles internationales s’inscrit dans une démarche plus large de déploiement structuré de la SSI. Le guide propose ainsi un cadre d’action concret, organisé autour de thématiques clés telles que représentées ci-dessous pour intégrer efficacement la cybersécurité dans les environnements industriels. 

Thématiques dans le cadre du déploiement de la SSI – Chapitre 3.1 du guide 

Et pour la suite : le guide des mesures détaillées, chaînon manquant entre stratégie et action  

Attendu dans les prochains mois, le guide des mesures détaillées constitue la suite naturelle de la démarche initiée par la classification. Il vise à donner aux acteurs industriels les moyens de passer de la théorie à l’action, en traduisant les classes de cybersécurité en exigences opérationnelles concrètes. 

Inspiré du premier guide de 2012, qui proposait déjà une série de mesures par classe, ce nouveau référentiel promet une approche plus fine, plus à jour, et mieux alignée avec l’état actuel des menaces et des pratiques de sécurité. Il apportera ainsi aux exploitants et décideurs une boîte à outils claire et applicable, en détaillant des mesures techniques, organisationnelles et humaines adaptées au niveau de criticité des zones à sécuriser. 

La publication de ce guide est attendue courant 2025, et permettra d’assurer une continuité avec les démarches d’analyse de risque et de conformité déjà engagées, tout en clarifiant les attentes en matière de mise en œuvre concrète des mesures. À ce titre, on peut espérer qu’il prendra en compte des thématiques de plus en plus présentes dans les environnements industriels, telles que la virtualisation, l’usage du Cloud, les plans de continuité d’activité (PCA) ou encore les questions d’interconnexion croissante entre systèmes OT et IT. 

Sécuriser l’existant, anticiper le futur 

Au-delà de la publication du guide, l’enjeu est désormais de s’approprier la démarche et de l’intégrer aux stratégies de sécurisation des systèmes industriels, qu’elles soient déjà définies ou en cours de conception. 

Pour les systèmes déjà en place, le nouveau guide s’inscrit naturellement dans les cycles de vie de la sécurité recommandés par l’ANSSI dans son guide EBIOS RM. Les impacts seront à apprécier au cas par cas pour savoir s’il est utile de modifier l’architecture déjà en place avec un arbitrage entre coût de modification, intégration de nouveaux besoins métiers et gains de sécurité attendues. Son intégration pourra se faire :  

• Lors du cycle stratégique, conseillé tous les 3 ans ou en cas de changement majeur, qui sera l’occasion de revoir le découpage des périmètres, d’actualiser les zones fonctionnelles, et de réévaluer la classification des systèmes à la lumière de la nouvelle méthode ; 
• Ou lors du cycle opérationnel, typiquement annuel, où il s’agira de contrôler les événements redoutés, de vérifier l’adéquation des mesures en place en fonction des classes de cybersécurité définies, et d’ajuster la stratégie de protection si nécessaire. 

Pour les nouveaux projets industriels, le nouveau guide remplace officiellement la version 2012 et doit être intégré dès les premières phases de conception. Il permet de bâtir une architecture sécurisée en cohérence avec les enjeux métiers, et facilite également la conformité aux exigences réglementaires (NIS2, LPM…) ou contractuelles à venir. 

Côté Wavestone, l’intégration de ce guide dans notre grille d’évaluation de la maturité des systèmes d’information industriels ainsi que dans notre Cyberbenchmark se poursuit à côté des autres standards de référence comme l’IEC 62443 ou le NIST SP 800-82, plus qu’à attendre le guide opérationnel pour être complet ! 

Cet article Vers une cybersécurité industrielle maîtrisée : ce que change le nouveau guide de classification des systèmes industriels de l’ANSSI est apparu en premier sur RiskInsight.

Cette initiative s’inscrit dans un contexte de multiplication des normes, règlements et directives en cybersécurité, tels que NIS2 (Directive sur la sécurité des réseaux et des systèmes d’information), le Cyber Resilience Act (CRA) ou encore des régulations sectorielles spécifiques Ce cadre réglementaire en pleine expansion reflète la nécessité de sécuriser les infrastructures critiques et produits technologiques face à des menaces croissantes. 

Cet article explore la réglementation PART-IS, ses implications, son périmètre, les parties prenantes impliquées, les exigences essentielles et les démarches pour s’y conformer. 

Qu’est-ce que la PART-IS ? Pourquoi est-elle essentielle ? 

La PART-IS a été introduite pour renforcer la sûreté aéronautique en protégeant les systèmes d’information critiques dans l’aviation. Son objectif principal est de garantir que ces systèmes, qui incluent des technologies telles que les communications avioniques et la gestion du trafic aérien, soient résilients face aux cybermenaces pour garantir la continuité et la sûreté des opérations aériennes dans un secteur où toute défaillance peut entraîner des conséquences graves. En effet, avec l’intégration croissante des technologies numériques dans les opérations aéronautiques, des systèmes de navigation aux infrastructures au sol, la vulnérabilité du secteur aux cyberattaques a considérablement augmenté. 

En obligeant les acteurs de l’aviation à identifier et évaluer les vulnérabilités de leurs systèmes, la PART-IS constitue une réponse proactive aux défis actuels. 

Quels sont les systèmes concernés ? 

 La PART-IS s’applique à tous les systèmes numériques utilisés dans l’aviation civile. Cela inclut par exemple : 

• Les systèmes embarqués, tels que les Flight Management Systems (FMS) 
• Les infrastructures de gestion du trafic aérien (ATM) 
• Les systèmes de maintenance prédictives 

En raison de l’interconnexion croissante entre ces systèmes, une vulnérabilité dans un composant peut provoquer une réaction en chaîne à travers l’ensemble de l’écosystème aéronautique, mettant en péril la sécurité des opérations. 

Qui sont les parties prenantes ? 

 La mise en œuvre de la PART-IS repose sur une collaboration entre plusieurs parties prenantes. Les principaux acteurs concernés incluent : 

• Les opérateurs aériens, responsables de la sécurité des systèmes embarqués 
• Les fabricants, qui doivent intégrer des mesures de cybersécurité dès la conception des aéronefs et des équipements 
• Les prestataires de services de navigation aérienne, chargés de protéger les systèmes de gestion du trafic 
• Les autorités nationales, dont le rôle est de superviser et vérifier la conformité réglementaire 
• Les fournisseurs de service au sol  

La PART-IS sera obligatoire à partir d’octobre 2025 pour les organismes agréés par l’EASA, dans le cadre du règlement délégué (UE) 2022/1645, c’est-à-dire les organismes de production et de conception. Les organismes de maintenance dans le cadre du règlement délégué (UE) 2023/203 devront se mettre en conformité d’ici février 2026. 

Quelles sont les exigences de la PART-IS ? 

La réglementation PART-IS impose des principes fondamentaux pour garantir la sécurité des systèmes critiques. Les organisations concernées doivent adopter une approche rigoureuse pour répondre à ces exigences et assurer leur conformité. 

Gestion des risques (SMSI) 

Cette réglementation s’inscrit dans une démarche proactive visant à identifier, analyser et atténuer les risques qui pourraient compromettre la confidentialité, l’intégrité et la disponibilité des informations sensibles. En s’appuyant sur un cadre structuré tel que la norme ISO/IEC 27001, le SMSI devient un outil central pour établir des politiques de sécurité robustes, déployer des mesures techniques et organisationnelles adaptées, et sensibiliser les parties prenantes aux enjeux de la cybersécurité. 

La gestion des risques, pilier fondamental de cette approche, permet de prioriser les efforts en fonction des vulnérabilités identifiées, tout en assurant une amélioration continue grâce au cycle PDCA (Plan-Do-Check-Act). La réglementation impose aux opérateurs et entités de l’aviation civile de se doter d’une gouvernance de la sécurité de l’information solide, alignée sur les meilleures pratiques.  

Evaluation des risques 

Les organisations doivent établir une méthodologie structurée pour identifier, analyser et mitiger les risques cyber associés à leurs systèmes d’information. Cela inclut la réalisation d’analyses de vulnérabilité, l’évaluation des impacts en cas de compromission et la mise en œuvre de contrôles adaptés. 

Surveillance continue 

La surveillance en temps réel des systèmes est indispensable pour détecter et répondre rapidement aux incidents de sécurité. Cela nécessite l’utilisation d’outils avancés et la mise en place de protocoles de réponse aux incidents. Tous les incidents doivent être signalés rapidement et accompagnés d’un plan de réponse clair pour limiter leur impact. 

Formation et sensibilisation 

Le personnel doit être formé aux meilleures pratiques en matière de cybersécurité pour réduire les risques liés aux erreurs humaines. Des programmes de sensibilisation réguliers sont essentiels pour maintenir un niveau de vigilance élevé. 

Audits et documentation 

La conformité à la PART-IS est vérifiée à travers des audits réguliers menés par l’EASA ou des autorités nationales. Les organisations doivent ainsi maintenir une documentation complète couvrant les politiques de sécurité, les procédures mises en œuvre et les incidents rencontrés. 

Quelles sont les étapes clés pour démarrer votre conformité ?  

La mise en conformité avec la PART-IS offre une opportunité stratégique pour les entreprises de renforcer la sécurité de leurs systèmes critiques et de moderniser leurs pratiques. 

La date limite de mise en conformité étant fixée à octobre 2025 pour à minima une partie du périmètre, c’est le moment idéal pour entamer la démarche de mise en conformité. 

Pour y parvenir, nous accompagnons actuellement nos clients sur 3 activités principales :  

• Tout d’abord, il est essentiel de définir avec précision le périmètre concerné, en s’appuyant notamment sur celui des agréments délivrés par l’EASA, afin de cadrer efficacement les efforts.  
• Ensuite, la rédaction d’un Système de Management de la Sécurité de l’Information (SMSI) permettra de structurer les politiques et processus nécessaires à une gestion proactive des risques.  
• Enfin, réaliser les premières analyses de risques pour identifier les vulnérabilités et établir des plans d’action adaptés.  

Ces étapes posent les bases d’une stratégie solide et pérenne en matière de sécurité de l’information qui faudra par la suite faire vivre et évoluer dans l’esprit du processus d’amélioration continue prôné par PART-IS. 

Cet article PART-IS : Un pilier de la cybersécurité dans l’aviation européenne  est apparu en premier sur RiskInsight.

Or, ce sont des systèmes hautement informatisés et connectés, bien plus que les stations-essence traditionnelles. En effet, la digitalisation permet un écosystème intelligent et des gains opérationnels directs. Par exemple, le smart charging permet des économies financières et énergétiques en optimisant les usages d’électricité en fonction des pics de demande sur le réseau électrique. L’expérience du conducteur est également fluidifiée, grâce à la possibilité de localiser et d’interagir avec les bornes depuis son smartphone. 

Ces fonctionnalités intelligentes posent des défis particuliers de cybersécurité que nous décrypterons dans cet article. Nous décrirons les stratégies que peuvent mettre en place les Charging Point Operators (CPO – opérateurs de recharge en français), en nous focalisant sur le cas des bornes de recharge en lieu public. En effet, ces dernières sont plus exposées et présentent le cas d’étude le plus complexe, tant d’un point de vue opérationnel que cyber. 

Risques cyber sur l’écosystème de la recharge : de quoi parle-t-on ? 

Tout d’abord, pourquoi le risque cyber est-il important, et quelle en est la nature ? Pour le comprendre, il nous faut d’abord étudier l’écosystème de la recharge. 

L’acteur central de cet écosystème est le CPO, en première ligne des risques cyber. C’est lui qui assure l’opération directe des bornes de recharge, sur le terrain mais surtout à distance. En général, il utilise une solution logicielle de supervision appelée CSMS (Charging Station Management System), hébergée dans le Cloud.  

Le rôle du CSMS a été fortement standardisé grâce aux efforts de l’Open Charge Alliance (OCA), un consortium d’acteurs du secteur qui est à l’origine du protocole OCPP (Open Charge Point Protocol). Au travers d’OCPP, le CSMS n’a pas qu’un rôle de configuration et supervision ; il assure toutes les communications nécessaires au déroulé d’une recharge (réservation de la borne, authentification et autorisation du conducteur, facturation…). Ceci présente un premier risque : la compromission du CSMS peut entraîner une compromission générale des réseaux de bornes du CPO. 

Cependant, pour avoir une vue globale des risques, nous devons considérer également les autres acteurs métier qui partagent le risque cyber avec le CPO. 

En premier lieu, les fabricants de bornes jouent un rôle important. Responsables de la conception et de la fabrication des bornes, ils assurent le suivi logiciel et fournissent les correctifs en cas de vulnérabilités. Dans certains modèles de bornes, les fabricants conservent un accès de maintenance à distance permanent, utilisant une seconde connexion OCPP : cette dernière peut être vue comme un risque pour le CPO si elle n’est pas maîtrisée. 

Ensuite, pour assurer la connexion à distance des réseaux de bornes au CSMS, l’utilisation de solutions WAN (Wide Area Network) est fréquente. Il peut s’agir d’un lien 3G/4G ou d’une intégration à un réseau préexistant sur site. Dans les deux cas, ce lien n’est pas maîtrisé par le CPO, qui est dépendant de la maturité cyber du prestataire télécom qu’il sélectionne. 

Enfin, le CPO doit intégrer son SI avec le gestionnaire du site qui héberge ses bornes. Celles-ci peuvent être placées dans des endroits variés : aires de repos d’autoroute, parkings d’entreprise, centres commerciaux, voies publiques… Selon les cas, les bornes peuvent être interfacées à des systèmes du bâtiment (capteurs de présence, compteurs connectés…), ou encore à des systèmes d’authentification et paiement des usagers. Le CPO n’a généralement pas d’autorité sur ces systèmes et sur leur niveau de sécurité. 

Cette multiplicité d’acteurs tend à faire croître la surface d’attaque sur le SI du CPO. Or, une intrusion peut entraîner une fuite de données client ou servir de pré-positionnement pour une attaque cyber plus large ciblant le CPO et/ou ses partenaires, avec des impacts financiers et réputationnels. 

A l’échelle locale, les attaques possibles sont également sévères, incluant des risques cyberphysiques (modification malveillante des paramètres de charge, entraînant une surchauffe de la batterie et potentiellement un incendie), ou des risques de déstabilisation du réseau électrique (par l’activation/désactivation malveillante de recharges sur de nombreuses bornes en simultané). 

Ces scénarios devraient devenir plus plausibles, en raison de la popularisation des bornes de recharge ultra-rapides (notamment utilisées par les véhicules lourds), et des technologies de recharge bidirectionnelle, offrant la possibilité pour un véhicule stationné d’injecter l’énergie stockée dans sa batterie sur le réseau. 

Mettre en œuvre les nouveaux standards, est-ce suffisant pour répondre aux risques ?  

Du fait de sa forte croissance, le marché de la recharge se structure, et de nouveaux standards se développent : ceci présente une opportunité d’apporter une réponse cyber unifiée aux risques que nous avons évoqués. 

Prenons le standard ISO 15118-20. Publié en 2022, il spécifie des mécanismes de communication robuste entre véhicules et bornes. En plus des usages de smart charging et de recharge bidirectionnelle évoqués précédemment, la norme introduit le Plug & Charge : cette fonctionnalité permet d’autoriser les recharges en identifiant directement le véhicule, sans nécessité pour l’usager de présenter un badge ou une carte de paiement. 

Les buts premiers d’ISO 15118 sont donc la fluidification des usages, l’efficacité énergétique, et l’interopérabilité. Mais son adoption pourrait aussi révolutionner le modèle de sécurité, notamment via la mise en place d’une PKI (Public Key Infrastructure) globale aux acteurs de la recharge : fabricants de véhicules, opérateurs de mobilité, et CPO. 

Parallèlement, le développement et la démocratisation de l’OCPP devraient s’accélérer, suite à l’approbation officielle d’OCPP 2.0.1 en tant que norme internationale (IEC 63584) par la Commission électrotechnique internationale. 

Cependant, des freins forts subsistent concernant l’adoption de ces standards. Plusieurs acteurs majeurs, tels que Tesla, ont développé des protocoles propriétaires avec des fonctionnalités similaires. Et surtout, la plupart des bornes et véhicules existants ne sont pas compatibles avec ISO 15118 ou OCPP 2.0.1., et doivent être remplacés. 

Ainsi, nous ne pouvons pas nous contenter des standards comme seule réponse aux risques cyber : paradoxalement, bien que leur adoption soit cruciale pour que le secteur monte en maturité, il est impératif de trouver des moyens de sécuriser les infrastructures déjà existantes. 

Note : pour en savoir plus le Plug & Charge et le smart charging, n’hésitez pas à consulter les articles d’EnergyStream, le blog énergie de Wavestone : 

• Le Plug & Charge : une nouvelle solution d’authentification et de facturation sécurisée 
• Les défis du déploiement du Plug & Charge 
• Panorama des usages du smart charging 

Mais alors, comment les CPO peuvent-ils protéger leur architecture ? 

Les standards n’ont pas réponse à tout : c’est donc d’abord au CPO qu’il incombe d’appliquer une politique de cybersécurité exhaustive. Mais comment s’armer face à la complexité des risques évoqués ? 

La première étape, c’est de comprendre et documenter son architecture et ses solutions. Cela peut sembler basique, mais il n’existe pas aujourd’hui d’architecture de référence pour les infrastructures de recharge. Dans cet article, nous modéliserons l’architecture en quatre zones, comme présenté ci-dessous : 

Figure1. Modèle d’architecture standard pour les infrastructures de recharge

Pour sécuriser de bout en bout cette architecture, nous allons regarder les mesures-clés pour sécuriser chaque zone. 

Nous pouvons cependant ignorer l’interface véhicule dans notre analyse. En effet, en attendant la démocratisation d’ISO 15118, les connecteurs de charge actuels ne sont pas intégrés au SI et ne constituent donc pas un vecteur de risque cyber. 

Sur le réseau de bornes, les mesures d’hygiène cyber et de segmentation réseau sont primordiales. Les bornes de recharge sont souvent des systèmes vulnérables : présence de comptes par défaut, mots de passe faibles, ports réseaux ouverts, systèmes de stockage non chiffrés… Des bonnes pratiques de durcissement et de mise à jour des micrologiciels doivent être pensées par le CPO pour chaque fabricant et modèle qu’il sélectionne.  

La segmentation réseau implique généralement l’utilisation de firewalls et de VLANs, selon la topologie réseau locale et les systèmes externes devant être intégrés. La mise en place d’un contrôleur local peut permettre d’isoler plus facilement les bornes des réseaux externes. Ce contrôleur peut agréger toutes les bornes d’un site et servir de proxy avec le CSMS. 

Passons au réseau WAN. Celui-ci étant souvent un réseau externalisé, il est fondamental pour le CPO de pouvoir chiffrer les flux entre les bornes et le CSMS. La principale solution existante aujourd’hui est l’utilisation de TLS avec certificats serveur et client, prévue dans les versions les plus récentes d’OCPP. 

Enfin, comment sécuriser le CSMS ? Celui-ci peut généralement être assimilé à une plateforme IoT dans le Cloud, et être abordé de manière similaire. Citons en priorité les pratiques de sécurité du code et la bonne gestion des identités et des accès (suivant le modèle RBAC). A l’avenir, nous pouvons imaginer que le CSMS jouera aussi un rôle actif de détection des menaces cyber : l’analyse des logs et des communications OCPP pourrait être facilitée par la mise en œuvre de solutions basées sur l’intelligence artificielle. 

Conclusion : quelle architecture de référence pour les CPO ? 

Bien que les nouveaux standards offrent des espoirs d’homogénéisation des architectures, l’écosystème de la recharge reste complexe en raison de la variété des cas métier. C’est pourquoi nous encourageons les CPO à adapter les bonnes pratiques de cet article à leur cas d’usage ; le schéma d’architecture ci-dessous doit ainsi servir de base de réflexion, plutôt que de cible définitive. 

Figure 2. Modèle d’architecture sécurisée pour les infrastructures de recharge

Cet article Mobilité électrique – Comment les opérateurs peuvent-ils sécuriser leur infrastructure de recharge ?  est apparu en premier sur RiskInsight.

Cependant, cette évolution met en lumière les problématiques de cybersécurité spécifiques à ces systèmes, poussant les entreprises du secteur industriel à mener des réflexions sur la sécurisation de ces usages. 

Quelles opportunités sont amenées par l’Intelligence Artificielle dans le secteur industriel ?  

Quelles opportunités l’Intelligence Artificielle apporte-t-elle ? Et quels sont les éventuels risques de cybersécurité que cela apporte ?  

IA & Industrie 

Pour mieux comprendre l’étendue des possibilités offertes par ces technologies, Wavestone a établi le Radar des cas d’usages de l’IA générative pour les opérations 2024, répertoriant les tendances d’utilisation observées chez ses clients industriels, ainsi que d’autres cas d’usage susceptibles de se développer dans les prochaines années :  

Figure 1 – Radar des cas d’usages d’IA générative pour les opérations 

Wavestone a identifié 4 typologies d’usage (aide à la prise de décision, amélioration d’outils et de processus, génération de documents, assistance à la réalisation de tâches) impactant plusieurs fonctions industrielles (production, qualité, maintenance, gestion des stocks, chaîne d’approvisionnement, etc.).

Figure 2 – Typologies d’usage d’IA générative pour les opérations 

Voici quelques exemples concrets illustrant comment ces technologies s’intègrent aux opérations de divers secteurs, ce qu’elles apportent, tout en mentionnant les impacts que peuvent engendrer des cyberattaques sur ces systèmes : 

Figure 3 – Cas d’usage d’IA existants dans le secteur industriel 

Ces systèmes permettent d’obtenir des avantages technologiques et stratégiques, des gains financiers ou de temps non négligeables.  

Néanmoins, l’intégration de ces technologies peut ouvrir la porte à de nouveaux risques qui doivent être pris en compte par les entreprises. 

Cyber risques de l’IA 

Comment un attaquant peut-il compromettre ces systèmes ? 

Il existe plusieurs catégories d’attaques spécifiques à l’IA, toutes exploitant des failles présentes dans les différentes phases du cycle de vie de ces modèles, offrant une large surface d’attaque :  

Figure 4 – Cycle de vie d’un modèle d’IA : attaques possibles 

La majorité de ces attaques cherchent à détourner l’IA de son usage prévu. Les objectifs peuvent être d’en extraire des informations confidentielles, ou encore de lui faire exécuter des actions non autorisées, compromettant ainsi la sécurité et l’intégrité des systèmes. 

Pour comprendre ces attaques dans les détails, nos experts ont illustré des méthodes par évasion et par oracle dans un article dédié au sujet. 

Qu’en est-il de ces risques pour les entreprises industrielles ?  

En réalité, les risques liés à l’IA dans l’industrie varient considérablement selon le secteur et l’utilisation qui en est faite. 

Pour mener des attaques par oracle, manipulation et injection de prompt contre une IA, il est nécessaire de pouvoir interagir avec elle en lui fournissant des données d’entrée. Cela est possible avec certaines IA génératives, comme ChatGPT, qui nécessitent des requêtes textuelles. En revanche, d’autres systèmes, tels que ceux utilisés pour la maintenance prédictive (solutions permettant d’anticiper et de prévenir les pannes d’équipements), ne dépendent pas d’instructions humaines pour fonctionner, rendant les interactions plus complexes. De plus, les types de données d’entrée de ces systèmes sont souvent très spécifiques, difficiles à obtenir, et à manipuler. 

Des attaques par empoisonnement des données d’entraînement pourraient être réalisées sur ces systèmes. Cependant, cela nécessiterait d’abord de s’introduire dans les SI, comprendre en profondeur le fonctionnement de l’IA, puis de tenter d’altérer son comportement, sans garantie de succès. De plus, les entreprises dotées d’un bon niveau de cybersécurité disposent déjà de contre-mesures et de moyens de protection, réduisant considérablement les chances de réussite d’une telle attaque. 

En comparaison, d’autres méthodes ne ciblant pas spécifiquement l’IA sont plus simples à mettre en place et peuvent augmenter les chances d’un attaquant de causer des dommages à une entreprise. 

Toutefois, d’autres applications de l’IA sont vulnérables à ces types d’attaques. Par exemple, un assistant utilisant de l’IA générative, avec lequel un humain peut interagir, est susceptible de subir des manipulations ou des injections de données.  

Voici un exemple de scénario d’attaque sur l’assistant à la production de vaccins présenté en Figure 3. 

Contexte du cas d’usage 

Les employés écrivent leur demande à l’assistant et y joignent les spécifications du vaccin à produire. Celui-ci lance l’analyse et, à l’aide d’un module RAG (permet à l’IA de disposer de données supplémentaires sans réentrainement), croise ces informations avec la base de données de l’entreprise. Enfin, l’assistant retourne aux employés un fichier d’instructions pour les machines qu’ils peuvent directement pour lancer une production.  

Scénario d’attaque 

Figure 5 – Kill chain scénario d’attaque sur assistant à la production de vaccins 

Les suites d’un cas de vol de secrets industriels comme celui-ci peuvent-être la revente de ces informations à des concurrents, ou encore leur divulgation publique, pouvant entraîner d’importantes conséquences financières et sur la réputation de l’entreprise. Cependant, des mesures de sécurité classiques de gestion des accès permettent de réduire le risque de subir ce type d’attaque. 

En outre, bien que certaines applications de l’IA soient vulnérables à de nouvelles attaques, des mesures de sécurité spécifiques et adaptées aux faiblesses de chaque système permettent de maintenir une protection efficace. 

Alors que faut-il retenir ?  

En fin de compte, les risques associés aux technologies d’IA ne sont pas fondamentalement nouveaux. 

Bien que certains systèmes d’IA soient sensibles à de nouvelles attaques, les principes de cybersécurité permettant de s’en protéger et de limiter les impacts restent inchangés. 

Il reste donc essentiel d’adopter une approche par les risques et d’intégrer la sécurité dès la conception de toute application d’IA (cybersecurity by design).  

Cet article Intelligence artificielle, industrie, risques cyber : où en sommes-nous ? est apparu en premier sur RiskInsight.

Ainsi, devriez-vous vous lancer dans l’aventure des sondes OT ? Et si oui, comment réussir le déploiement d’un service de sondes ?  

Sondes OT : Un outil pour surveiller les réseaux industriels 

Image 1 : Écouter le réseau pour l’inventorier et détecter 

Une sonde de détection est un équipement, virtuel ou physique, connecté au système d’information (SI) afin de le cartographier et de le surveiller. Elle se compose de capteurs répartis dans le réseau pour collecter des données et d’un équipement central pour corréler ces données. Les sondes pour environnements industriels – que nous appellerons ici sondes OT – se caractérisent par leur écoute passive et non invasive du réseau, et leur compréhension des protocoles et comportements industriels. De nombreux acteurs sont présents, vous pouvez retrouver notre vision du marché ici : https://www.riskinsight-wavestone.com/2021/03/les-sondes-de-detection-en-milieu-industriel-notre-vision-du-marche/  

Toutes leurs sondes fonctionnent sur le même principe : le trafic réseau est collecté en utilisant de la duplication de flux (SPAN, ERSPAN …) ou des duplicateurs physiques comme les taps. Les paquets sont inspectés en temps réel pour fournir plusieurs types de données : inventaire et cartographie des flux, gestion des vulnérabilités, et enfin détection des anomalies et des incidents. 

La grande diversité des cas d’utilisation possibles de ces données et la variété de ses utilisateurs (équipe opérationnelle et commerciale, équipe de cybersécurité, etc.) font la popularité de ces sondes OT.  

Cependant, ces solutions, tout comme leur déploiement et exploitation, sont coûteuses et nécessitent une bonne compréhension des besoins, des utilisateurs potentiels et de la valeur ajoutée avant de se lancer. 

Prenons deux exemples … 

Imaginons deux entreprises envisageant de déployer des sondes OT sur leurs sites industriels.

1ère entreprise : WavePetro 

WavePetro possède un large site sensible, avec une bonne maturité cyber et une architecture très segmentée. L’entreprise souhaite déployer des sondes OT pour se conformer à la réglementation et améliorer ses capacités de détection. 

Compte tenu de son architecture et de ses besoins de détection, de nombreux points d’écoute seront nécessaires. WavePetro peut compter sur ses équipes locales et leur expertise et connaissance du site pour réaliser le déploiement. 

2nd entreprise : RenewStone 

RenewStone est une entreprise possédant de nombreux petits sites géographiquement dispersés et sans équipe locale, avec une maturité cyber hétérogène. Ses sites sont interconnectés avec l’infrastructure du groupe. 

L’entreprise souhaite déployer des sondes OT pour gagner en visibilité sur ses sites en utilisant les fonctions d’inventaire et de cartographie.  

Ainsi, RenewStone a besoin de standardiser un service de sondes OT pour ses sites et de pouvoir proposer des déploiements avec le moins de complexité locale possible.  

Image 2 : 2 entreprises, 2 besoins, 2 implémentations 

… et leurs déploiements vers un service de sondes fonctionnel 

Bien que ces deux entreprises aient des besoins et maturités cyber différentes, les 5 étapes clés de déploiement restent les mêmes, bien qu’avec des approches différentes.   

1.Preuve de concept 

La première étape est la preuve de concept (PoC : Proof of Concept).  
L’objectif pour les deux entreprises est de tester la faisabilité et la valeur ajoutée des sondes OT sur leurs périmètres. 

Alors que WavePetro doit valider la faisabilité sur un périmètre réduit dans son usine, RenewStone doit se concentrer sur la validation de la valeur du service de sonde OT sur quelques-uns de ses sites. 

Pour tirer le maximum du PoC, il est important de : 

• Adapter la sélection des fournisseurs à vos besoins : Le marché est très diversifié entre les pure-players, ceux spécialisé au secteur industriel ou qui étendent leurs solutions IT à l’OT …  
  Les questions à se poser : Est-ce que je veux de fortes capacités de détection ? Est-ce que je veux un service managé ? Est-ce que je veux une solution unifiée pour l’IT et l’OT ?  
• Sélectionner le champ d’application du PoC : Identifier un périmètre représentatif avec des ressources à tester afin que les résultats puissent être reproduits à l’échelle.  
• Rédiger une architecture cible avant le PoC : tester une architecture représentative de ce qui serait déployé à l’échelle, afin de valider les tests effectués. 

Le PoC est essentiel pour s’assurer que les sonde OT apporte de la valeur, mais également pour pouvoir convaincre de les déployer, en particulier lorsqu’elles ne sont pas contraintes par des réglementation. 

2.Construction d’un modèle opérationnel 

Dès le début du projet, il est important de se rappeler que l’objectif final du déploiement des sondes OT : Collecter des informations utilisables et valorisables. Pour ce faire, il est important de : 

• Définir un modèle opérationnel pour le traitement des alertes, de l’inventaire et la gestion des sondes. Alors que WavePetro peut avoir un modèle d’exploitation reposant sur les connaissances et l’expertise locales, RenewStone doit construire un modèle d’exploitation central avec les équipes du groupe telles que le SOC, la sécurité OT, le réseau, l’infrastructure, etc. 
• Décider de faire appel à un tiers ou de gérer vos sondes en interne : Peu de fournisseurs proposent des services de gestion, vous devrez donc créer votre propre modèle, qui pourrait également s’appuyer – en totalité ou partiellement – sur de l’externalisation. 
• Créer un RACI : Compte tenu des différents cas d’usage et du nombre d’acteurs impliqués dans l’utilisation ou la maintenance des sondes, un RACI est essentiel pour s’assurer que toutes les parties prenantes nécessaires seront impliquées et mobilisées. 

Cette étape doit être traitée en amont pour faciliter les étapes suivantes du déploiement. 

3.Préparation au déploiement 

Une fois que la première étape a démontré la valeur ajoutée d’une sonde et que son modèle de fonctionnement a été défini, préparons le déploiement ! Vous devez définir la cible finale : 

• Où déployer la sonde : En particulier si vous avez de nombreux sites différents, comme RenewStone, vous devez prioriser : quels sont vos sites sur lesquels déployer ? Vous pouvez vouloir déployer sur les sites les plus critiques seulement et rendre le service disponible pour d’autres à la demande. Les sites sélectionnés doivent également permettre un déploiement. Quels sont les prérequis au déploiement ? Ils peuvent par exemple être définis selon les équipements réseaux disponibles. 
• Quand déployer : Travaillez sur dès que possible sur des estimations budgétaires afin que les sites soient en mesure de prévoir un déploiement. Les sondes sont une solution coûteuse, non seulement en termes de matériel et de licences, mais également en ressources, pour les déployer et les exploiter. 
• Comment déployer : Dans tous les cas, vous devez construire une architecture pour le déploiement des sondes OT. En particulier, si vous avez de nombreux sites à déployer ou des ressources locales très limitées, vous devez travailler à l’élaboration d’une offre de service packagée à déployer.  

Cette préparation est un passage obligé pour éviter de perdre du temps lors des déploiements et garantir leur succès. 

4.Déploiement 

Il est temps de s’attaquer au déploiement ! Le mot d’ordre est la même pour les deux entreprises : Avancer pas à pas. La différence réside dans l’échelle : 

• Un déploiement progressif sur le site de WavePetro : Il faudra du temps pour pouvoir « écouter » efficacement partout. Concentrez-vous sur les données attendues pour prioriser l’emplacement initial de la sonde et ses points d’écoute. 
• Apprendre et s’améliorer d’un déploiement à l’autre pour RenewStone : Les déploiements sont centralisés et plus standardisés, donc les équipes apprendront et s’amélioreront d’un déploiement à l’autre. Inclure un panel de sites représentatifs dans la première vague permet de tester et améliorer le modèle de déploiement. 
• Ne pas négliger la conduite du changement : dans les deux cas, le déploiement d’une nouvelle solution doit absolument inclure de la sensibilisation et de la formation afin que les sondes OT trouvent leurs utilisateurs. 

Le déploiement de sondes OT peut être un processus long et fastidieux, mais ne vous découragez pas en chemin, car il reste encore une dernière étape à franchir !

5.Fine-tuning 

Une sonde OT est un outil d’amélioration continue, la détection doit gagner en valeur avec le temps. Vous devez donc consacrer du temps à : 

• Configurer le tableau de bord de la console : Prendre le temps d’améliorer le modèle de détection (liste blanche de certains comportements, priorisation des actifs sensibles…), l’inventaire automatique des actifs et la cartographie (enrichir l’inventaire, importer des données, taguer les VLAN…), et ainsi de suite. Ce fine-tuning doit être effectué par une personne familière avec les sites industriels.  
• Intégrer d’autres technologies : Vous pouvez lier les consoles à d’autres outils de votre entreprise, tels que le SIEM, les pares-feux ou la CMDB, afin d’exploiter au maximum les données collectées par les sondes. 
• Testez d’ajouter des fonctionnalités : une fois que vous avez acquis une certaine maturité avec la solution, vous pouvez aller encore plus loin avec les fonctionnalités disponibles, comme l’exécution de requêtes actives pour enrichir l’inventaire. 

Le fine-tuning permet de limiter le nombre de faux-positifs, afin de se concentrer sur les données qui apporteront de la valeur à votre entreprise et à sa sécurité. 

Image 3 : Les 5 étapes clés d’un déploiement de service de sondes OT 

Conclusion 

Ces deux exemples nous ont beaucoup appris sur les sondes de détection industrielle et sur les nombreux défis liés à leur déploiement et utilisation.  

Si demain, je fais face à un client industriel qui se demande que faire de ce projet sonde sur sa feuille de route, je lui partagerai ces 3 conseils :  

Image 4 : Les 3 clés d’un déploiement réussi 

Questionner la valeur ajoutée de ses sondes 

En l’absence de cas d’utilisation clairement identifiés et d’objectifs déterminés, vous pouvez vous retrouver avec des sondes fournissant des informations inutilisées ou sans réelle valeur ajoutée. Les sondes OT sont coûteuses, à la fois financièrement et en termes de temps. Vous devez être sûr qu’elles en valent la peine, et vous donnez les moyens de les exploiter pleinement. 

Pour ce faire, prenez le temps d’évaluer la qualité et la valeur des informations remontées par les sondes OT avec vos différentes équipes (cybersécurité, exploitation, business …). 

Avancer pas à pas 

Ne craignez pas de commencer petit et de croître progressivement, qu’il s’agisse du nombre de sites déployés, du nombre de points d’écoute ou de cas d’utilisation des sondes OT. 

L’exploitation à long terme des sondes OT est complexe et se construit au fil des déploiements. Prenez le temps de soigner l’adoption de la solution : si vous voulez que les équipes utilisent la solution, formez les et montrez en leur la valeur !  

Compter sur l’amélioration continue 

Les sondes OT peuvent fournir nombre de fonctionnalités allant de la détection d’incidents à la cartographie, en passant par la gestion des vulnérabilités et bien d’autres encore qui doivent être publiées par les éditeurs. 

Concentrez-vous d’abord sur les fonctionnalités qui réduisent vos risques OT, en améliorant progressivement les services au fur et à mesure qu’ils gagnent en maturité ! 

Cet article Sondes de détection pour l’OT : Les clés pour réussir son déploiement  est apparu en premier sur RiskInsight.

En quelques mots, si vous fabriquez, importez ou revendez un produit avec des éléments numériques, vous serez sûrement affecté par le CRA et devrez veiller à sa conformité. Cet article vise à éclairer sur : Que prévoit cette réglementation ? Qui est concerné ? Comment assurer la conformité ? 

Qu’est-ce que le CRA et qu’implique-t-il ?   

Pour comprendre la nécessité du CRA, il est crucial de considérer le contexte plus large de la cybersécurité en Europe. Le CRA est une réglementation ambitieuse conçue pour assurer la sécurité des citoyens de l’UE en s’attaquant aux faibles niveaux observés aujourd’hui de cybersécurité des produits avec des éléments numériques, par le biais d’une intervention politique de l’Union européenne. Pour ce faire, des études approfondies axées sur la cybersécurité des produits numériques ont été menées, aboutissant à la proposition d’une législation définissant les obligations pour l’ensemble des acteurs de la chaîne d’approvisionnement des produits, des fabricants aux distributeurs. 

L’implication de Wavestone dans ce processus souligne son engagement à améliorer les normes de cybersécurité. Nous avons participé à une étude exploratoire approfondie commandée par l’UE, en engageant un large éventail de parties prenantes, y compris des autorités nationales, des organes de l’UE, des fabricants de matériel et de logiciels, des associations professionnelles, des organisations de consommateurs, des chercheurs, des universitaires et des professionnels de la cybersécurité. 

Grâce à la position de Wavestone en tant que leader mondial, et particulièrement européen, dans le domaine de la cybersécurité, plusieurs interviews, groupes de discussion et ateliers ont été organisés. Des informations précieuses ont été recueillies auprès d’interlocuteurs variés, offrant une vision complète qui prend en compte les perspectives de toutes les parties prenantes et permettant de poser les bases du développement du CRA. 

Définition et périmètre 

Le CRA est une proposition législative qui définit les obligations des fabricants, importateurs et distributeurs de produits contenant des éléments numériques commercialisés dans l’UE, tous devant porter le marquage CE dans tous les secteurs. Tel que défini dans la réglementation, cela inclut « tout produit logiciel ou matériel ainsi que ses solutions de traitement de données à distance, comprenant des composants pouvant être commercialisés séparément ». L’objectif de cette réglementation est non seulement de sécuriser les produits autonomes, mais aussi d’assurer la sécurité des chaînes de transmission de données et des infrastructures centrales grâce à l’application de cette norme. 

À cette notion de produit s’ajoute une notion de criticité, le CRA distingue donc deux types de produits : les produits avec des éléments numériques et les produits critiques avec des éléments numériques. Comme détaillé ci-dessous dans la partie « Checklist de conformité au CRA », cela influencera la manière dont la conformité pourra être atteinte. 

Quelques exemples de produits avec des éléments numériques incluent les produits de consommation, les smart cities et les logiciels non essentiels. Les produits critiques avec des éléments numériques comprennent, par exemple, les systèmes de contrôle industriel et les pare-feu. La liste détaillée des produits concernés se trouve dans les annexes de la réglementation. 

 Cependant, comme détaillé ci-dessous dans « Un écosystème complexe », le CRA ne s’applique pas universellement, et les produits de certains secteurs spécifiques ne sont pas tenus de se conformer aux exigences. 

Parties prenantes et responsabilités 

Le CRA impacte tout le cycle de vie des produits numériques, depuis le développement par les fabricants, importateurs et distributeurs jusqu’au consommateur final, mais aussi la gestion des vulnérabilités depuis la conception jusqu’à la fin de vie du produit, au travers d’une responsabilité partagée. 

Exigences essentielles  

Comme mentionné précédemment, l’objectif du CRA est de garantir un niveau suffisant de cybersécurité dans les produits contenant des éléments numériques. Pour ce faire, il introduit des exigences essentielles reposant sur trois piliers  

• Sécurité des produits : Assurer que les produits sont conçus, développés et fabriqués pour atteindre des niveaux de cybersécurité appropriés et qu’ils sont exempts de vulnérabilités exploitables connues. 
• Documentation utilisateur : Fournir une documentation pour garantir une utilisation sécurisée, depuis la mise en service jusqu’à la fin de vie du produit. 
• Gestion des vulnérabilités : Identifier et documenter les vulnérabilités, réaliser des tests de sécurité réguliers, et mettre en place une politique de divulgation des vulnérabilités. 

En cas de non-conformité aux exigences essentielles, des sanctions peuvent être appliquées à l’une des trois parties prenantes. Comme pour le RGPD, chaque État membre doit déterminer les sanctions applicables en cas de violation de cette réglementation. Les pénalités sont basées sur le chiffre d’affaires annuel de l’entreprise et la gravité de l’infraction, avec des amendes pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial total pour les violations graves. 

Comment se conformer au CRA ? 

Chronologie du CRA  

Le CRA a été un projet à long terme, avec presque 10 ans entre l’identification du besoin et la mise en application, reflétant la complexité de l’établissement de réglementations de cybersécurité complètes: 

Les entreprises ont jusqu’en 2026 pour se conformer, avec des obligations intermédiaires. Des exigences similaires peuvent être trouvées dans d’autres réglementations, telles que la NIS2, mais contrairement à d’autres réglementations, le CRA ne nécessite pas de transposition nationale. Le CRA a été adopté par le Parlement européen en mars 2024, et il attend un vote du Conseil européen pour devenir une loi. 

Un écosystème complexe 

L’une des principales préoccupations soulevées lors de la préparation était de savoir comment naviguer dans la multitude de réglementations existantes et parvenir à une harmonie réglementaire, en particulier dans les secteurs où les normes de sécurité, de protection de la vie privée et de cybersécurité s’entrecroisent.  

Le CRA vise à favoriser l’interopérabilité en s’alignant sur le cadre général de la sécurité des produits, sur les exigences de la loi sur la cybersécurité pour les produits, processus et services TIC, et sur les normes de marquage CE pour la conformité européenne. 

Pour simplifier la mise en conformité, le CRA inclut des présomptions de conformité avec les réglementations existantes telles que la directive RED, la loi sur l’IA et certaines règles sectorielles.  

Toutefois, le CRA ne s’applique pas de manière universelle ; certains secteurs, tels que le secteur médical, l’aviation et l’automobile, sont déjà régis par des réglementations établies et sont donc exemptés des dispositions de la réglementation. 

 Checklist de conformité au CRA 

La mise en conformité au CRA implique une compréhension approfondie du texte principal du règlement et de ses deux annexes, qui détaillent la liste des produits concernés, les exigences essentielles, les obligations des fabricants, des importateurs et des distributeurs, ainsi que les autorités nationales compétentes et les sanctions.  

Le processus de certification varie en fonction de la criticité du produit : 

• Pour les produits non critiques : une auto-évaluation est nécessaire. 
• Pour les produits critiques : une évaluation par un tiers est nécessaire, ce qui signifie que la conformité du produit au CRA sera évaluée par une entité certifiée. Au moment de la rédaction de cet article, les schémas de certification exacts n’ont pas encore été spécifiés, mais en France, la certification CESTI est en discussion. 

Cinq points de contrôle principaux doivent être pris en compte pour assurer la conformité :   

1. Analyse d’écarts législatifs : Identifier les écarts entre les pratiques actuelles et les exigences du CRA en examinant les politiques, les processus et les contrôles existants en matière de cybersécurité afin d’identifier les zones nécessitant une amélioration. 
2. Évaluation de la sécurité des produits : Effectuer des évaluations approfondies pour garantir l’identification et la sécurité des produits.  
3. Mise à jour des instructions destinées aux utilisateurs : Fournir une documentation claire et complète à l’intention des utilisateurs en veillant à ce que tous les produits soient accompagnés d’une documentation conforme aux normes de la réglementation. 
4. Gestion des vulnérabilités : Mettre en place un processus d’identification et de partage des vulnérabilités. 
5. Revue de l’organisation interne : Mettre en œuvre une procédure permanente pour assurer la conformité, couvrant les points clés mentionnés ci-dessus et surveiller les changements de produits ou de législation qui pourraient impliquer de nouveaux écarts à remédier. 

En conclusion, le Cyber Resilience Act représente un cadre complet pour renforcer la cybersécurité des produits numériques au sein de l’UE. La conformité avec cette réglementation nécessite une préparation approfondie. Pour les entreprises, se conformer au CRA n’est pas seulement une obligation légale, mais aussi une opportunité d’améliorer leur position sur un marché de plus en plus conscient des enjeux de cybersécurité. 

Cet article Cyber Resilience Act : Une révolution qui redéfinit la sécurité des produits et transforme l’écosystème est apparu en premier sur RiskInsight.

A l’exception de deux lois fédérales (nLPD, LSI) et de plusieurs réglementations sectorielles (Directive CySec Rail – Cybersécurité des chemins de fer, Circulaires, Finma, Directive pour la sécurité des données des systèmes de mesure intelligents, …)  cette approche fait aujourd’hui que les cantons conservent une autonomie dans la mise sous contrôle des enjeux cyber. Cependant le besoin en cybersécurité tend à voir se multiplier les réglementations cyber et à gagner en caractère contraignant.

Réglementations concernant la cybersécurité en Suisse

Deux nouveaux textes nationaux contraignants sont entrés en vigueur le 1^er juillet 2024 pour fixer un seuil de cybersécurité minimal pour les secteurs de l’approvisionnement en électricité et le transport ferroviaire.

Cet article portera plus particulièrement sur la révision de l’Ordonnance sur l’Approvisionnement en Electricité (OApEl).

Tendance mondiale à la normalisation de la cybersécurité

Le paysage de la cybersécurité est façonné par divers cadres et législations nationaux ou internationaux :

• Le NIST Cybersecurity Framework (CSF) de 2017, aux États-Unis, est devenu un standard pour les agences fédérales américaines afin de gérer et réduire les risques de cybersécurité, suite à un décret présidentiel imposant indirectement son utilisation.
• En Europe, les Directives NIS (Network and Information Systems) de 2016, complétées par NIS 2 en 2023, visent à améliorer la résilience des opérateurs de services essentiels (OSE) et à renforcer la sécurité des réseaux et systèmes d’information.
• En France, la Loi de Programmation Militaire (LPM) de 2018 pour les années 2019-2025 impose des obligations aux opérateurs d’importance vitale (OIV) pour sécuriser les infrastructures critiques contre les cybermenaces.

Ces initiatives montrent un effort concerté à l’échelle mondiale pour renforcer la cybersécurité face à des menaces de plus en plus sophistiquées.

Ce qui change pour le secteur de l’électricité Suisse

Dans cette logique, la Suisse voit désormais sa norme minimale TIC devenir contraignante, mais seulement pour le secteur de l’approvisionnement en électricité.

• La Norme minimale pour les TIC en Suisse est une mesure mise en place par l’Office fédéral pour l’approvisionnement économique du pays (OFAE) pour protéger les infrastructures contre les risques cyber. Elle couvre l’identification, la protection, la détection, la réaction et la restauration, et s’inspire des standards du NIST pour évaluer la maturité en cybersécurité des organisations et fournir des orientations. Contrairement aux directives européennes NIS et à la LPM française, cette norme n’est pas contraignante per se.

• L’Ordonnance sur l’approvisionnement en électricité (OApEl) de la Suisse précise la Loi sur l’approvisionnement en électricité (LApEl) et réglemente l’ouverture du marché de l’électricité pour assurer la sécurité de l’approvisionnement électrique, elle a un volet cyber en son article 8b, sur la protection des données. Contrairement à la norme TIC, elle a un caractère contraignant. Sa nouvelle version, qui rend contraignante la Norme minimale pour les TIC pour les acteurs de l’électricité, est entrée en vigueur le 1^er juillet 2024.

Conformité obligatoire pour les acteurs suisses de l’électricité

Devront se conformer à la Norme nationale TIC, au titre de l’OApEl, 24 mois après son entrée en vigueur :

Les exigences minimales de l’OApEl révisée sont contraignantes dès leur entrée en vigueur, sans délai transitoire. La Commission fédérale de l’électricité (ElCom) est responsable de définir et de contrôler leur réalisation. Les entités concernées doivent s’auto-évaluer sur 2 ans et prouver leur conformité à l’ElCom.  Si les mesures ne sont pas mises en œuvre rapidement, l’ElCom dialogue avec les entreprises. En cas de difficultés justifiées, un délai supplémentaire peut être exceptionnellement accordé.

Le rôle de surveillance attribué à l’ElCom

En vertu de l’article 22, alinéa 1 de la LApEl, la Commission fédérale de l’électricité (ElCom) surveille le respect des dispositions de l’OApEl, et donc des ordonnances qui en découlent. Ainsi, l’ElCom se voit désormais dotée d’une mission particulière dans le cadre cybersécuritaire pour les acteurs suisses de l’électricité :

• Surveillance : L’ElCom surveille le respect des mesures de protection contre les cybermenaces en s’appuyant sur le cadre de cybersécurité NIST et les exigences minimales définies dans la législation.
• Enquête : Dans le cadre de son processus de surveillance, l’ElCom utilise des enquêtes d’auto-évaluation pour recenser les pratiques de cybersécurité des entreprises.
• Entretiens de sensibilisation : L’ElCom conduit des entretiens de sensibilisation avec les entreprises jugées cruciales pour la sécurité et la stabilité du réseau électrique.
• Audits : L’ElCom peut réaliser des audits ciblés, soit en réaction à des anomalies constatées lors des enquêtes ou des entretiens, soit sur la base d’indications externes.

Calendrier légal de mise en conformité

Niveaux de maturité attendus

La Révision de l’OApEl définit trois niveaux de protection (A, B, C) pour garantir que les mesures de cybersécurité exigées soient proportionnelles à l’impact potentiel sur l’écosystème suisse. Ces niveaux sont donc liés au volume d’énergie produit ou distribué. Chaque niveau a ses mesures spécifiques et définit les exigences en termes de score de maturité NIST (/4).

L’appartenance à chaque niveau est conditionnée proportionnellement au volume d’électricité produit et/ou distribué pour les gestionnaires de réseau et leurs prestataires, ainsi que pour les producteurs (hors nucléaire), exploitants de stockage et leurs prestataires :

• Niveau A : Plus de 450 GWh/an (gestionnaires) ou plus de 800 MW (producteurs)
• Niveau B : Entre 450 et 112 GWh/an (gestionnaires) ou entre 800 et 100 MW (producteurs)
• Niveau C : Moins de 112 GWh/an (gestionnaires) ou moins de 100 MW (producteurs)

Chaque niveau a des scores de maturité attendus par points de contrôle  NIST.

Par exemple, pour ID-AM 2 du NIST (Développez un processus d’inventaire garantissant en permanence un recensement exhaustif de vos équipements TIC), il sera attendu un niveau de maturité NIST de 4/4 pour le niveau A, 3/4 pour le niveau B, et 2/4 pour le niveau C.

Analyse

Une analyse détaillée des attendus de l’OApEl révèle 5 axes particulièrement attendus, et 4 autres qui peuvent apparaître étonnamment bas vu le secteur et le risque concerné.

Points de conformité majeurs (scores attendus les plus élevés):

• Gouvernance
• Gestion des accès
• Sensibilisation et formation
• Protection et solutions de sécurité
• Analyse de risques

Points de conformité mineurs (scores attendus les plus faibles)

• Communication pendant et après un incident
• Détection et Investigation
• Mitigation et Isolation
• Environnement de l’entreprise (business environment)

Il est cependant recommandé pour les organisations concernées de ne pas négliger la préparation en termes de communication sur les incidents de cybersécurité, ainsi que les capacités de réponse et d’isolation. Ces éléments paraissent essentiels vis-à-vis de la criticité du secteur pour l’économie Suisse, mais aussi par rapport au besoin de coopération opérationnelle pour une gestion efficace de crise.

Conclusion

Avec la révision de l’OApEl, l’appareil juridique de la Suisse se dote d’un nouveau texte sectoriel contraignant qui poussera les acteurs du marché de l’électricité à se conformer à la maturité attendue selon les niveaux fixés par ce nouveau texte.

Mise en perspective avec la directive CySec Rail et les circulaires Finma, la cybersécurité en Suisse tend à se normaliser au niveau national bien que les textes soient disparates. En effet, l’OApEl se fonde principalement sur le NIST via la Norme minimale pour les TIC, tandis que la Directive CySec Rail (pour le chemin de fer) réunit des éléments issus de l’ISO 2700X et du NIST, alors que les circulaires Finma (pour le secteur financier) formalisent des exigences particulières au secteur.

Dans cette logique, il n’est pas inenvisageable que d’autres secteurs soient prochainement impactés.

Cet article La Suisse renforce sa réglementation cyber : les secteurs essentiels sont visés est apparu en premier sur RiskInsight.

L’accroissement des exigences de sécurité concernant tant les environnements industriels que les objets connectés ont provoqué une profusion des clés cryptographiques, parfois difficile à gérer, dans les entreprises. Celles-ci servent à la fois à chiffrer et déchiffrer des documents ou échanges, mais aussi à la vérification de l’authenticité de messages ou fichiers, par exemple lors de la mise à jour du logiciel d’un composant, pour s’assurer de son intégrité. 

Une solution au problème de la complexité de gérer de nombreuses clés cryptographiques dans une entreprise est de mettre en place un KMS, pour Key Management System. Cet outil aide à protéger les données, la sécurité des produits et des processus sous la forme d’un outil centralisé de gestion des clés cryptographiques.  

Au-delà d’une simple standardisation des processus, ils peuvent aider à régler des problèmes tels que la génération de clés différentes en grand nombre, le stockage et accès aux clés ou encore la dépréciation des clés. 

Pourquoi utiliser un KMS ? 

Les KMS (Key Management Systems) sont des systèmes de gestion de clés cryptographiques qui permettent aux entreprises de gérer de manière centralisée et sécurisée leurs clés de chiffrement. Ils s’adressent aux organisations gérant de nombreuses clés cryptographiques, et améliorent ainsi la sécurité de leurs environnements, en standardisant les processus et en apportant des API pour la réalisation des fonctions crypto (signature, chiffrement, déchiffrement). Les organisations ayant de grands réseaux informatiques, mais aussi ceux industriels comprenant des objets connectés tels que des capteurs, des actionneurs ou des systèmes embarqués, ou vendant des produits connectés sont particulièrement concernées. 

L’importance d’une bonne gestion des clés est cruciale pour la cybersécurité. Les processus de chiffrement, de signature ou de vérification sont essentiels pour beaucoup d’organisations, même s’ils paraissent parfois comme transparents aux opérationnels. Il est important que les clés de chiffrement soient gérées de manière optimale, afin d’éviter par exemple un stockage non sécurisé des clés ou l’utilisation de la même clé pour plusieurs appareils. 

Nous allons examiner de plus près ce qu’est un KMS, comment il fonctionne et pourquoi il peut devenir essentiel. Plusieurs types de KMS seront présentés, ainsi que les avantages liés à leur utilisation et les difficultés à leur intégration. Enfin, quelques clés seront données pour cibler plus précisément les entreprises qui peuvent bénéficier de ce type d’outil. 

Pour plus d’informations sur l’architecture KMS, vous pouvez également regarder la conférence de Paul Chopineau à l’occasion de la Miami S4x24 : https://youtu.be/J5aeAYxcc24?feature=shared. 

Figure 1 : Architecture type d’un KMS 

Les différentes manières de déployer un KMS 

Il existe plusieurs manières d’implémenter un KMS, selon les options proposées par leur constructeur. Certains sont proposés en mode SaaS. D’autres peuvent être installés sur les serveurs de l’entreprise (on premise), et il existe aussi des KMS hybrides pour lesquels les clés sont stockées on premise mais l’applicatif est dans le cloud. 

Les premiers sont des solutions cloud qui permettent de gérer les clés de chiffrement depuis un ordinateur ou un serveur. Ce sont des produits plus scalables et agiles, aussi plus faciles à déployer et à mettre à jour. En revanche, la sécurité des clés sera dépendante de celle du service cloud, même s’il est possible d’introduire des surchiffrements. 

Les KMS on premise sont des solutions logicielles et matérielles qui permettent de gérer les clés cryptographiques en utilisant des serveurs et HSM internes à l’organisation. Ils sont généralement plus personnalisables et parfois plus adaptés à des besoins spécifiques que les KMS déployés en mode SaaS. En revanche, leur intégration sera plus longue et leur coût d’achat (CAPEX initial) sera plus élevé. Leur avantage est aussi qu’ils peuvent permettre à une entreprise de s’assurer de sa souveraineté sur ses clés cryptographiques. Ils conviennent donc mieux aux entreprises ayant des exigences très fortes de sécurité et une capacité plus importante d’investissement initial 

Enfin, les KMS hybrides pourraient représenter un juste milieu entre sécurité optimale et facilité de déploiement. L’objectif est de garder le contrôle sur les clés, celle-ci étant dans ce cas sauvegardées sur site, mais de bénéficier d’une plus grande facilité de déploiement et de montée en charge grâce à un applicatif hébergé dans le cloud. Le déploiement de l’applicatif est ainsi facilité, mais il reste à installer les ressources matérielles de gestion des clés (HSMs). La sécurité des clés s’approche de celle d’une solution on premise, mais le logiciel rend celle-ci dépendante du service cloud. Attention néanmoins à se protéger d’une exploitation frauduleuse des clés depuis les infrastructures cloud qui pourrait être plus difficile à détecter que pour un KMS on premise. 

Figure 2 : Les trois implémentations possibles pour un KMS 

Il est aussi possible de classer les produits sur le marché selon le type de fournisseur. 

On retrouve ainsi premièrement les produits des grands acteurs du cloud : 

• Amazon avec AWS Key Management Service (AWS KMS), 
• Microsoft qui propose Azure Key Vault, 
• Google avec le Cloud KMS (Key Management Service), 
• IBM qui propose un KMS (Key Management Service) intégré à IBM Cloud Private. 

Leurs produits s’intègrent parfaitement aux services fournis par ces grands fournisseurs, y compris leurs outils de stockage sécurisé des clés, comme le KMS de Google, qui permet de créer des clés dans le cloud et les stocker dans des HSM. 

Des entreprises spécialisées se positionnent également sur le marché : 

• Cryptomathic avec son CKMS (Crypto Key Management System), 
• Entrust, dont le produit se nomme KeyControl, 
• HashiCorp, avec son produit Vault, 
• Utimaco, dont le KMS se nomme KeyBridge, 
• Thales, avec par exemple son Trusted Key Manager (TKM). 

Ces entreprises proposent notamment de faire fonctionner leurs outils avec des ressources logicielles, telles que les KMS de Microsoft, Amazon et Google pour HashiCorp ou encore VMware pour Entrust. Mais aussi des ressources matérielles, tels que des HSM qui apportent un niveau supérieur de sécurité contre les attaques physiques. 

Enfin, le marché a aussi été rejoint par des intégrateurs, comme Atos avec sa suite Trustway DataProtect KMS qui se destine à une installation on premises, sur le matériel de l’entreprise. 

Thalès enfin, qui se positionne à la fois comme fournisseur hardware, comme éditeur et comme intégrateur, propose plusieurs produits de gestion des clés pour les entreprises. Ceux-ci fonctionnent de mise avec ceux proposés tant par les acteurs plus spécialisés qu’avec les services cloud préférés de leurs clients. 

Figure 3 : Trois grands types de fournisseurs de KMS 

Les avantages à utiliser un KMS 

Les KMS (Key Management Systems) sont des outils dont le potentiel complet est encore à explorer, mais qui peuvent se révéler particulièrement utiles pour gérer de manière centralisée et sécurisée les clés de chiffrement d’une entreprise. Voici quelques avantages que l’on peut tirer de leur usage. 

Tout d’abord, les clés seront plus faciles à déployer. Les KMS permettent de générer rapidement et de manière automatisée de nouvelles clés cryptographiques, ce qui est particulièrement utile lorsqu’il est nécessaire de générer de nombreuses clés différentes pour transmettre à des produits, objets connectés ou systèmes industriels. 

Dans un contexte où les clés des objets connectés ne sont souvent pas renouvelées et sont gérées de manière non standardisée, les KMS permettront aux entreprises d’introduire le niveau de sécurité qui leur permettra de respecter les futures régulations des systèmes IoT. Même chose pour le chiffrement de données sensibles dans une base de données, qui est le cas d’usage à l’origine de la naissance des produits KMS. 

Pour améliorer le stockage et l’accès aux clés, les KMS offrent des APIs et interfaces centralisées, intégrant une gestion des permissions en lien avec la gestion des accès et identités (IAM), ce qui peut être particulièrement utile pour les entreprises disposant de nombreux types de clés et utilisateurs des clés de chiffrement. La difficulté sera de convaincre les fournisseurs et partenaires extérieurs à l’entreprise de rentrer les clés par le biais du KMS. Ce sera un élément à négocier dans les contrats cadres futurs. 

Les KMS permettent également de gérer la dépréciation des clés de chiffrement, en les remplaçant automatiquement par de nouvelles clés lorsqu’elles expirent, qu’elles sont compromises ou tout simplement obsolètes, par exemple à l’issue d’un changement dans la PSSI. Cela permet de maintenir la sécurité de vos données à tout moment. 

En résumé, les KMS sont des outils précieux pour gérer efficacement et de manière sécurisée les clés de chiffrement d’une entreprise. Ils permettent ainsi d’améliorer sa conformité aux réglementations et aux normes de sécurité en s’assurant que les procédures de gestion de clés et les clés utilisées sont conformes aux standards établis. 

Les pièges à éviter lors de l’implémentation d’un KMS 

Mettre en place un KMS (Key Management System) est une démarche lourde, qui peut être freinée ou même stoppée par les aspects suivants : 

• Coût du déploiement : les KMS peuvent être très coûteux à déployer. Il s’agit des frais de licence, mais aussi des ressources matérielles comme les HSM à mettre en place pour le stockage des clés et à dimensionner en fonction de l’usage qui en sera fait (fréquence d’accès, volumétrie). 

• Complexité de la mise en place : la mise en place d’un KMS peut être complexe, en particulier pour les entreprises disposant de nombreux appareils ou systèmes chiffrés ; pour lesquelles il aura justement une forte valeur ajoutée. Il peut être nécessaire de mettre en place de nombreuses intégrations pour communiquer avec les APIs du KMS en fonctions des différents cas d’usages. 

• Procédures de change management spécifiques : il sera parfois difficile de convaincre tous les utilisateurs de l’entreprise de l’importance de la mise en place d’un KMS, et de les inciter à utiliser cet outil de manière efficace. Pour résoudre ce problème, il faudra s’appuyer sur une stratégie de communication et de formation pour sensibiliser les utilisateurs à l’importance de la sécurité des clés de chiffrement et à l’utilité du système. 

• Compétences rares sur le marché : des architectes informatiques, des spécialistes en cryptographie, ou encore des gestionnaires de projets capables de piloter des projets structurants en cybersécurité. Tout autant de profils durs à sourcer et qui seront d’autant plus nombreux à recruter qu’il existe de cas d’usages de clés cryptographiques au sein de l’organisation. L’appel à des expertises externes sera alors très profitable et difficile à éviter. 

Les KMS, une solution essentielle pour la gestion sécurisée des clés de chiffrement 

En conclusion, les KMS sont une solution essentielle pour gérer de manière sécurisée les clés de chiffrement de votre entreprise. Tant pour les grandes entreprises disposant de nombreux appareils ou systèmes chiffrés, ou une petite entreprise rencontrant le même type de problématiques, un KMS peut grandement aider à centraliser et à sécuriser la gestion des clés crypto. 

A titre d’exemple, prenons le cas d’une entreprise de fret. Celle-ci doit gérer de nombreux composants dans les véhicules comme des capteurs pour s’assurer du respect de la chaîne du froid ou simplement des appareils pour le suivi les produits. Ces objets se connectent à des réseaux publics ou d’entreprise, transmettent des données chiffrées, mais sont aussi mis à jour régulièrement. Il faut donc signer les firmware lors du déploiement d’une mise à jour, et s’assurer que les clés de chiffrement des données que transmettent les capteurs, pour s’assurer de leur intégrité et de leur confidentialité, sont bien stockées de manière sécurisées, mais aussi sont à disposition des opérateurs en cas de modification d’un capteur. Pour tous ces processus, à la fois pour les automatiser mais aussi pour faciliter le travail des opérateurs et s’assurer que chaque intervenant ne dispose d’un accès qu’aux clés qu’il utilise, le KMS sera particulièrement utile. L’outil se chargera de la génération des clés, ou de leur récupération si elles ont été générées de manière externe, puis de tout le reste des étapes du cycle de vie de la clé. 

Il reste à noter que l’évaluation de la pertinence de cette technologie est à prendre au sérieux. Des études en amont ainsi qu’une procédure d’appel d’offre seront nécessaires pour s’assurer de la mise en place du bon outil. En réalisant ces procédures avec une vision précise sur les usages métiers, l’entreprise s’assurera de ne pas avoir à en changer par la suite. 

Cet article Les KMS : la clé de la gestion sécurisée des objets cryptographiques  est apparu en premier sur RiskInsight.

En effet, de nombreux systèmes, équipements et canaux de communications d’un tel réseau sont : 

• Limités en mémoire et en puissance de calcul ; 
• Situés sur des sites éloignés avec peu ou pas de personnel et d’accès à internet (par opposition notamment à un système industriel au sein d’une usine) ; 
• Incompatibles avec les technologies sans-fil, en raison de l’environnement électrique des sous-stations et la fiabilité requise par certaines applications ; 
• Déployés pour une longue durée de fonctionnement, ce qui amène des contraintes sur le maintien en conditions de sécurité et sur l’interopérabilité avec d’autres systèmes. 

Dans un système électrique intelligent, deux infrastructures réseau cohabitent : un réseau électrique et un réseau informatique. 

Le réseau électrique relie les équipements utilisés pour générer, transmettre et distribuer l’électricité. Cela comprend les centrales électriques, les transformateurs, les lignes électriques, les sous-stations et les compteurs électriques.  

Le réseau informatique permet de surveiller, de contrôler et d’optimiser les opérations du réseau électrique. L’objectif de la norme IEC 62351 est de sécuriser ce réseau informatique. 

Les réseaux électrique et informatique coexistent en parallèle dans un contexte Smart Grid 

Aujourd’hui, l’affluence de standards industriels amène à nous demander ce qu’apporte cette norme par rapports aux autres, ou encore la pertinence pour un client de chercher à se conformer à certaines sections de la norme. 

Une norme à utiliser comme guide de bonnes pratiques 

À ce jour, nous n’avons identifié aucun organisme proposant une certification à la norme IEC 62351, même si certains organismes de certification proposent une évaluation de conformité (tests techniques et recommandations associées).  

Organismes proposant des évaluations de conformité IEC 62351 

Mais l’utilité principale de la norme reste de donner des armes aux équipes cyber pour intégrer la cybersécurité dans les spécifications techniques des systèmes industriels, à destination des opérateurs et des fournisseurs. Les tests de conformité pourront s’appuyer sur les sections 100 de l’IEC 62351.

Vue globale de la norme 

La section introductive de la norme a été publiée en 2007 dans un contexte industriel qui a depuis beaucoup évolué. La dernière section a été publiée en janvier 2023 et une nouvelle section est en cours de rédaction. Ainsi, les 11 documents principaux constituant aujourd’hui la norme IEC 62351, et leur calendrier de parution régulière, démontrent une volonté de s’adapter aux évolutions du contexte industriel. 

L’IEC propose une découpe de la norme en 4 sections principales 

La norme IEC 62351 vient compléter les normes cyber existantes 

Pour traiter les enjeux cybersécurité des Smart Grid de manière cohérente, une combinaison des normes ISO/IEC 27001, IEC 62443 et IEC 62351 est nécessaire. 

La famille des normes ISO/IEC 27001 s’applique à toute organisation possédant un système d’information : elle continue de s’appliquer dans les entreprises considérées ici. Elle permettra de donner un une organisation globale et des mesures de sécurité générales à appliquer.  

La norme ISA/IEC 62443 s’applique elle à l’industrie, et donne des mesures s’appliquant à des systèmes et composants industriels. Elle permettra de s’assurer que les spécificités des systèmes industriels sont prises en compte, à la frontière entre IT et OT. 

La norme IEC 62351 est dédiée à l’OT avec un domaine d’application très spécifique : la communication en environnement électrique. 

Ces normes abordent des sujets de plus en plus techniques, et de plus en plus spécifiques au secteur.  

La norme détaille notamment des mesures de sécurité aux protocoles de communications spécifiques au secteur 

Ces protocoles définis dans d’autres normes sont utiles à la collecte des informations venant des équipements sur le terrain et, inversement, à l’envoi de commandes. Malgré leur fonction clé, ces protocoles ne sont pas sécurisés by design. La norme IEC 62351 permet de mettre en œuvre des mécanismes de sécurité, en utilisant les mécanismes déjà présents pour limiter les impacts d’interopérabilité. Les protocoles concernés sont : 

Un chapitre de la norme IEC 62351 peut traiter un aspect de la sécurité de plusieurs protocoles. Par exemple, les aspects en lien avec le modèle TCP/IP sont traités en commun dans la section 3 de la norme. 

L’IEC 62351 a été rédigée par le même comité technique (TC57) ayant développé ces protocoles de communication. L’idée étant d’intégrer des mécanismes de sécurité à des protocoles qui en sont complètement dépourvus. En prenant en compte leur forte présence dans l’industrie et leurs contraintes intrinsèques, les spécifications de la norme permettent de favoriser l’interopérabilité. Il n’est pas nécessaire de changer de matériel. La norme donne les bons outils pour sécuriser les protocoles lorsque cela est requis. 

Afin d’illustrer les spécifications de cybersécurité que nous pouvons retrouver dans la norme IEC 62351, prenons l’exemple de la section 5, traitant du protocole IEC 60870-5 : 

En conclusion 

La norme IEC 62351 donne des bonnes pratiques pour la sécurisation des réseaux électriques, avec des mesures concrètes pour leur mise en œuvre.  

Cette norme pourra servir aux RSSI pour définir les mesures concrètes à mettre en œuvre sur leurs systèmes les plus critiques, et comme base de rédaction d’exigences vis-à-vis de leurs fournisseurs, à intégrer dans les cahiers des charges.  

Glossaire 

Cet article Décryptage de la norme IEC 62351 : Quelles mesures de cybersécurité adaptées pour les réseaux électriques ? est apparu en premier sur RiskInsight.

Historique

Remontons dans le temps : nous n’allons pas parler des différentes révolutions industrielles, mais notre histoire commence à l’entame des années 70. A l’époque, pas de réseau Ethernet, de modèle OSI ou même d’informatique. Les systèmes de production industriels reposent sur des mécanismes physiques à travers l’utilisation de signaux pneumatiques ou électriques. Les années 70 voient l’arrivée des premiers principes d’automatisation, et l’intégration des premiers équipements intelligents : les automates de programmation industrielle. Ces équipements permettent une mutualisation des ressources, un automate pouvant gérer plusieurs entrées et sorties électriques, et donc de centraliser la gestion des processus. Les automates intègrent aussi des modules de communications, et les systèmes industriels voient alors l’apparition des premiers bus réseau, avec l’utilisation de protocoles de communication série.

Ce modèle d’architecture continuera de se développer dans les années 80 avec la multiplication des protocoles industriels, notamment sur le modèle « Controller-Workers » : Un automate principal contient la base de données centralisée et joue le rôle de chef d’orchestre en étant relié aux « Workers », correspondant à d’autres automates, cartes d’entrées/sorties déportées, etc… Cette architecture permet de simplifier la programmation des processus en un point unique, et aussi la communication avec les organes de visualisation type interface homme-machine ou SCADA propriétaire.

Les années 90 voient la démocratisation du modèle TCP/IP et l’intégration de l’informatique « classique » dans les environnements industriels : plus besoin d’équipements propriétaires, un logiciel SCADA peut maintenant s’installer sur des systèmes classiques… encore faut-il que ces ordinateurs puissent communiquer avec les automates ! Des cartes de réseaux séries existent, mais les protocoles industriels commencent à s’adapter pour fonctionner sur du réseau Ethernet classique. Peu à peu, on remplace les automates maîtres afin de leur permettre d’utiliser les protocoles TCP/IP sur le réseau principal, tout en continuant à avoir des cartes réseaux séries pour les équipements de terrain. Et puis ce fut au tour des équipements de terrain de s’adapter à la standardisation de l’utilisation de TCP/IP plus ou moins partout, faisant qu’aujourd’hui l’utilisation de communications séries est minime. Même les entrées/sorties électriques tendent aujourd’hui à être délaissées au profit des liaisons IP sur des capteurs et actionneurs, via par exemple l’utilisation de connectiques « Single Pair Ethernet » assurant une connexion économique et peu encombrante.

Evolution des architectures terrains

On en arrive donc aujourd’hui à pouvoir rencontrer régulièrement l’architecture suivante : Un réseau physique industriel « principal » (en topologie étoile ou en anneau) sur lequel on retrouve tous les équipements de supervision et de communications avec l’extérieur (SCADA, Data Historian, poste opérateur…) ainsi que les automates « controllers », qui chacun possèdent un second port réseau. Ce second port réseau permet de créer sur chaque automate un sous-réseau isolé sur lequel se trouve les équipements au plus proche du processus physique. L’automate controller a alors un rôle de « pivot fonctionnel », échangeant d’un côté avec le SCADA principalement, et de l’autre avec les équipements de terrain via les registres de données de l’automate. Cette architecture peut être déclinée de plusieurs façon, par exemple en remplaçant l’automate pivot par un serveur classique, ou en combinant plusieurs couches de réseaux isolés avec un serveur SCADA possédant deux ports réseau, séparant le réseau industriel principal et le réseau de supervision dans lequel on retrouverait les automates controller sur lesquels se fait une nouvelle séparation avec des réseaux de terrain.

Exemple d’architecture industrielle intégrant des réseaux de terrain

Maintenant l’historique abordé, parlons du présent et notamment des trois évolutions qui nous amènent aujourd’hui à questionner la pertinence de ce modèle d’architecture :

• L’industrie 4.0 qui a changé l’exposition des réseaux industriels, passant d’un modèle isolé vers un modèle ultra-connecté afin de répondre aux enjeux de big data, d’interconnexion avec le Cloud, de jumeau numérique, etc…
• La standardisation des technologies industrielles permettant de se détacher des fournisseurs industriels, via le développement de « Soft PLC » sur Linux ou Windows embarqué ou l’utilisation de protocoles industriels standardisés type OPC-UA.
• L’introduction des solutions de cybersécurité dans le cœur du réseau industriel comme les serveurs de mise à jour, des pare-feux, des antivirus voire EDR ou même des sondes de cartographie, dont la présence prend sens avec la modernisation des infrastructures informatiques et le développement de la cybersécurité en milieu industriel.

Pour étudier la pertinence des réseaux de terrain face à ces nouveaux enjeux, nous allons aborder quatre sujets de sécurité opérationnelle : la sécurité des réseaux, la détection & cartographie, la gestion des mises à jour et les accès distants.

Sécurité réseau

La première question à se poser est simple : Quel est l’avantage des réseaux de terrain d’un point de vue cybersécurité ? Cet avantage se traduit dans le principe même du modèle d’architecture : l’utilisation d’un équipement en pivot offre une isolation physique entre un réseau industriel et un réseau de terrain. Il n’est donc par principe impossible de faire communiquer directement les deux réseaux, la transmission d’informations se faisant à travers une base de données (registres pour les automates, base de données OPC pour un serveur…). Pas besoin de pare-feu ou de diode : aucun flux ne peut aller d’un réseau à un autre, ce qui représente le meilleur moyen de se protéger d’une propagation vers les équipements de terrain.

Mais cette séparation via un équipement physique non-dédié au réseau est-elle vraiment infaillible ? Sur un équipement fonctionnant avec un système « classique » Windows ou Linux standard, la réponse est non. Il existe de multiples exemples d’attaques convertissant ces systèmes en pivot, exploitant les nombreuses possibilités offertes : exploitation de protocole d’accès distant type RDP, VNC ou SSH, RAT, implant C2C… De ce fait, une séparation avec ce type de système ralentira un attaquant mais ne réduit finalement pas fortement les possibilités d’atteindre les réseaux de terrain qui existeraient sur d’autres cartes réseaux.

Pour le cas d’un automate « classique », il s’agit la plupart du temps d’un équipement fonctionnant sur un système d’exploitation propriétaire qui offre peu de fonctionnalités : à minima il permet de faire tourner des programmes industriels et de communiquer avec un ou plusieurs protocoles industriels, et peut optionnellement contenir des serveurs plus classiques type HTTP ou FTP. L’équipement propose donc beaucoup moins de fonctionnalité qu’un ordinateur ou serveur, et n’a pas vocation à permettre des passerelles entre ses différentes cartes réseaux… du moins, c’est ce qu’on a tendance à croire. Il a été cependant prouvé qu’il est possible de créer des passerelles entre les différents ports réseaux d’un automate : via des travaux de recherches comme ceux de Nicolas Delhaye and Flavian Dola présentés lors de la GreHack 2020 (la vidéo ici), mais surtout plus concrètement à travers le malware Pipedream découvert en 2022. Notamment, ce malware permet de créer des routes sur des automates Schneider afin de les transformer en proxy et leur donner la capaciter de router n’importe quel protocole vers les réseaux de terrain.

Illustration du fonctionnement du module Pipedream ciblant les équipements Schneider

Nous avons donc la preuve que même dans le cas d’une séparation par un automate, le modèle n’est pas infaillible, mais il permet tout de même de fortement réduire les risques en n’exposant les réseaux de terrain qu’à des attaques très avancées.

Cartographie et supervision

Suite au paragraphe précédent se pose naturellement la problématique suivante : comment superviser un réseau dont le point fort est d’être isolé ? Premièrement au sujet de la journalisation, le constat actuel est que les automates et équipements industriels sont encore très peu inclus dans les périmètres de supervision de sécurité : pour des raisons techniques, tous les équipements n’étant pas forcément en capacité de remonter des journaux type syslog, mais aussi organisationnel, les SOC manquant encore de maturité pour exploiter correctement les journaux d’évènements de ce genre d’équipement industriel.

Afin de combler ce manque de visibilité, les environnements industriels sont de plus en plus sujet à l’installation d’une sonde réseau, permettant de répondre aux besoins de supervision et de cartographie. Les systèmes qui rentrent dans le périmètre d’application de la Loi de Programmation Militaire sont notamment dans l’obligation d’installer une sonde de détection qualifiée par l’ANSSI. Sur le plan technique, il est possible de faire communiquer des réseaux isolés avec une sonde en utilisant des TAPs réseau, qui ont pour fonction de copier le trafic réseau de manière passive pour permettre l’écoute dudit trafic. Sur le plan stratégique, les réseaux de terrain sont rarement l’endroit à surveiller côté réseau. On privilégiera les points d’interconnexions avec les autres réseaux (entreprise, fournisseur…) ou les équipements critiques pour le pilotage comme le SCADA.

Exemple d’architecture de supervision intégrant les réseaux de terrain

La solution des TAPs n’est cependant pas applicable pour des sondes « actives » qui vont chercher à faire de la cartographie en questionnant les différents équipements sur le réseau. Mais ce type de solution est rarement mis en place dans un contexte industriel afin d’éviter de « stresser » le réseau et les équipements.

Le modèle des réseaux de terrain reste donc compatible en se concentrant sur la supervision du réseau, avec l’installation de sonde pour de la détection, ainsi que de la cartographie passive. La remontée de journaux systèmes des automates et équipements industriels reste encore trop peu pertinente vis-à-vis des capacités d’analyse des SOC.

Mise à jour

Pour pouvoir faire des mises à jour, il est nécessaire d’avoir une interconnexion réseau avec un système permettant la redescente de ces mises à jour, ce qui s’oppose à l’isolement des réseaux de terrain. Le besoin de mise à jour en milieu industriel rend-il le modèle de réseau de terrain obsolète ?

Le maintien en condition de sécurité est un sujet complexe dans le cas des systèmes industriels : besoin de disponibilité fort empêchant toute intervention lourde, systèmes isolés d’internet ne permettant pas le téléchargement des mises à jour par le réseau… Dans le cas de réseaux composés principalement d’automates, les mécanismes de mise à jour ont évolué en prenant en compte ces contraintes, si bien qu’aujourd’hui les parcs automates maintenus à jour sont rares (même sur une base annuelle), et ces mises à jour sont principalement déployées manuellement par la maintenance. L’utilisation de réseaux de terrain pour cloisonner l’architecture n’entrave pas l’application de ces mêmes mécanismes sur les automates.

En revanche, l’intégration des technologies IT change la donne : l’une des premières solutions de sécurité recommandée sur un parc Windows est la mise en place d’un serveur WSUS pour centraliser le déploiement des mises à jour, le même principe étant aussi applicable pour des technologies Linux. Nous arrivons donc ici à une nouvelle contrainte des réseaux de terrain possédant des équipements type Soft-PLC ou PC opérateur dédié : un cloisonnement par double carte réseau empêche la centralisation de la gestion des mises à jour, obligeant la mise en place d’un processus d’application manuelle des patchs qui peut être complexe et chronophage sur un nombre d’équipements important.

Cette contrainte doit tout de même être évaluée par rapport au besoin. L’argument principal en faveur des mises à jour est le fait qu’elles permettent de corriger des vulnérabilités augmentant la surface d’attaque d’un équipement. Le modèle des réseaux terrain isolant fortement les systèmes, leur surface d’attaque est par définition déjà fortement réduite. Il est donc acceptable que ceux-ci ne soient pas constamment à jour, et dans ce cas une mise à jour manuelle et annuelle des équipements répond au besoin.

Ce modèle ne convient cependant pas avec les besoins des antivirus d’être à jour constamment pour garantir une protection optimale. C’est pour cela qu’il est nécessaire dans ce cas de s’appuyer sur le fait d’avoir des systèmes bougeant très peu dans le temps, ce qui facilite l’utilisation dans le temps de solution de filtrage applicatif en liste blanche type AppLocker ou WDAC (voir notre article sur le filtrage applicatif).

Finalement, les pratiques de mises à jour en milieu industriel se sont adaptées au principe même d’isolation réseau permettant de réduire ces besoins. Ces pratiques demandent cependant le durcissement des équipements à leur installation, ainsi que la mise en place de solutions permettant de maintenir le niveau de sécurité des systèmes avec un minimum de maintenance à effectuer.

Accès distant

Après avoir abordé les flux « automatisés » des mises à jour, qu’en est-t-il des flux initiés par un utilisateur pour accéder à un équipement à distance pour des opérations métier ou de maintenance ? Pour des automates, ces accès sont rares : ils n’ont pas besoin d’actions humaines pour effectuer leurs tâches, et dans le cas de maintenance effectuée en interne, elle est souvent réalisée en accédant à l’automate depuis le réseau sur lequel il se trouve (les réseaux dédiés à l’administration pour les automates sont encore très rares). Dans le cas où l’automate est accessible depuis le réseau de production principal, la maintenance peut être centralisée depuis un point de connexion unique. Par contre, les réseaux de terrain étant isolés du réseau de production, les automates s’y trouvant sont accédés en allant brancher l’ordinateur portable de maintenance au “bon” commutateur interconnectant les différents équipements du sous-réseau, voire même directement sur le port USB de l’automate avec une liaison série.

Les limitations apparaissent par contre pour des réseaux de terrain avec des équipements maintenus par un fournisseur ou prestataire de maintenance. En effet, la maintenance à distance est devenue le moyen privilégié, et il est assez rare aujourd’hui d’avoir du personnel tier de maintenance à disposition pour se déplacer physiquement sur site à tout moment. La solution la plus souvent rencontrée pour faire face à cette problématique est l’installation d’une terminaison VPN directement sur un réseau de terrain, avec un tunnel relié au prestataire. Cela répond effectivement à la problématique, mais contourne aussi tout le principe d’isolement des réseaux de terrain, qui sont alors exposés en cas de compromission du prestataire.

On atteint ici la plus grande limite du modèle de réseau terrain, renforcée qui plus est avec la tendance à la centralisation des accès distant et l’installation de solution type bastion qui ne peuvent pas couvrir les accès aux réseaux de terrain du fait de leur isolement.

Conclusion

L’existence des réseaux de terrain est principalement historique, du fait des anciens modèles d’architecture en controller/worker et de la mise en place graduelle du modèle TCP/IP dans les réseaux industriels. Ces modèles d’architecture se sont adaptés au cycle de vie des systèmes : ils sont très peu accédés par des utilisateurs et sont conçus pour fonctionner en autonomie en remontant les données à l’automate controller.

Le cloisonnement est le principal point fort des réseaux de terrain : transformer un automate en rebond sur deux interfaces réseaux différentes est une technique d’attaque très avancée. Afin de détecter de possibles attaques, des solutions existent pour mettre en place de la supervision sur des réseaux isolés, notamment via des TAPs.

L’autre avantage de l’isolement réseau est de réduire les efforts à faire sur le maintien en condition de sécurité. Le besoin de mise à jour d’un équipement isolé n’est forcément pas le même que sur un équipement utilisé par un humain et interagissant avec des réseaux tiers. Les équipements isolés ayant un cycle de vie avec peu de changement, l’effort doit être mis sur le durcissement à la mise en service.

A l’inverse, l’isolation de ces réseaux posent de nombreuses problématiques sur les accès distants : il est possible de les limiter quand la gestion du parc industriel est en interne, mais ils sont essentiels dans le cas où un prestataire doit intervenir à distance. Afin d’éviter les initiatives locales ou les solutions à la main des tiers, il est recommandé de mettre en place une solution d’accès distant maîtrisée (VPN, bastion…), vers les équipements accédés à placer dans un sous-réseau dédié avec un point d’entrée filtré et maîtrisé.

En synthèse, le modèle de réseau terrain est encore aujourd’hui pertinent. Cependant, les tendances récentes, notamment liées à l’industrie 4.0, vont poser de nouvelles problématiques : L’apparition notamment des Industrial IOT, impliquant la mise en place de bus IoT interconnectés avec l’extérieur, remet en question la pertinence d’avoir des réseaux IP isolés cohabitant avec des bus IoT plus exposés.

Sources

Dragos Analyzing PIPEDREAM: Results from Runtime Testing
https://www.dragos.com/blog/analyzing-pipedream-results-from-runtime-testing/

GreHack 2020: A full chained exploit from IT network to PLC’s unconstrained code execution
https://www.youtube.com/watch?v=PfdoaxYkmUE

Cet article Les réseaux de terrain : l’historique des systèmes industriels à l’épreuve du futur est apparu en premier sur RiskInsight.

La perception actuelle de la cybersécurité dans l’OT

En milieu industriel, la cybersécurité ne bénéficie pas toujours d’une image positive et est vue comme pouvant être un frein au développement des activités. Il est souvent reproché aux équipes cybersécurité de définir des règles, mais aussi de déléguer leur implémentation sans fournir de solution, ni d’accompagnement pour l’implémentation des changements demandés. Il est par exemple difficile de changer régulièrement les mots de passe de dizaines de comptes génériques industriels alors que cette règle est un standard sur un périmètre IT classique. Les équipes OT se retrouvent donc souvent seules pour répondre aux exigences des politiques de sécurité.

Laissées seules, les équipes métiers développent des solutions « maisons » pensées avec leur point de vue très local, à l’échelle de leur site. Ces solutions échappent au contrôle du groupe et sont très spécifiques (dépendance à un fournisseur locale, solution maison conçue pour l’architecture réseau spécifique du site, …), et les capacités de passage à l’échelle ne sont pas évaluées. Toutes ces solutions sont développées par des équipes expertes et passionnées qui sont capables de questionner les pratiques et les standards de sécurité, mais qui ont rarement en tête une vision stratégique, y compris à l’échelle locale, ce qui empêche l’intégration de leurs solutions à l’échelle d’un ensemble de sites industriels.

Des solutions court terme… voire dangereuses

Sur le long terme, ces solutions locales présentent de nombreux inconvénients :

• Elles ne sont pas au niveau des standards de production et restent à la phase de POC
• Elles sont mal documentées ce qui rend la maintenance difficile
• Le passage à l’échelle d’un groupe de sites industriels est impossible à long terme

Certaines solutions « maison » rencontrées se sont même révélées dangereuses comme on peut le voir ci-dessous :

Exemples réels tirés des audits de sites industriels sur la période 2020-2023

Standardiser l’intégration de la cybersécurité chez les métiers

Les entreprises industrielles se distinguent par leur fort besoin de disponibilité, ainsi que les impacts qu’ont leurs métiers sur le monde physique. Les investissements doivent donc être à la hauteur de ces enjeux qui nécessitent des solutions de cybersécurité de très grande ampleur et d’une grande complexité. Les services IT, cybersécurité et OT doivent coopérer durant l’intégralité du processus de développement afin de garantir que les solutions conviennent aux opérations tout en répondant aux standards de sécurité du groupe. Le but est d’industrialiser le développement des solutions de cybersécurité pour le périmètre OT, en fournissant des solutions clé-en-main et prêtes à être déployées à grande échelle.

La solution est le développement d’un catalogue de services cybersécurité dans lequel les services sont sélectionnés et développés à l’échelle du groupe, en collaboration avec tous les acteurs (Cyber, opérations, IT) et en intégrant la gestion de l’intégralité du cycle de vie de la solution (maintenance, documentation, décommissionnement…). Ainsi, le service cybersécurité et la DSI peuvent créer, avec la direction industrielle, une roadmap de gestion produit, avec un processus industrialisé de création de solution.

Concevoir une solution de cybersécurité OT

Le processus de création de solution doit répondre à plusieurs problématiques :

• Collecter les besoins de toutes les parties prenantes ;
• Retranscrire les besoins correctement ;
• Garantir l’adoption à grande échelle par l’ensemble des sites industriels.

Afin de garantir l’efficacité du processus et des solutions, le développement des différentes solutions est nécessairement long et peut s’étendre sur une période de 2 à 3 ans. Cette durée de développement réduit les risques de s’exposer à une mauvaise couverture des besoins opérationnels, pouvant conduire au développement de solutions locales non maîtrisées ou à un déploiement mal contrôlé et incomplet.

Fournir des solutions de sécurité : un processus en 6 étapes :

Processus de Solution Factory

1.     Recherche et développement

Le but de la phase de R&D est de trouver la meilleure solution pour répondre à tous les besoins de cybersécurité. Ainsi, en cas d’audit réalisés à l’échelle du groupe, le respect des politiques de sécurité est garanti si l’outil est utilisé. Plusieurs points sont cruciaux pendant la R&D :

• Rassembler une équipe projet avec des représentants de l’IT, de la cybersécurité et également du métier, pour garantir l’utilité et le bon usage de la solution ;
• Définir les contraintes métier au bon niveau (disponibilité, résistance dans un environnement difficile, support, …) afin de maîtriser les coûts sans compromettre l’utilisabilité du produit ;
• Prévoir les processus de maintenance, de mise à jour et de sortie dès la R&D pour éviter de se retrouver bloqué avec un produit imparfait ou obsolète ;
• Prévoir le budget et le modèle économique du produit. En particulier qui doit payer et quels sont les coûts d’opération et d’investissement. Cela permet d’éviter le blocage du projet au moment du déploiement sur site pour des problèmes de budget ;

Lors de la phase de R&D il est aussi intéressant de partir de l’existant. Cela permet d’identifier des experts sur lesquels s’appuyer ou des solutions qui pourraient être adaptées à grande échelle et sur un périmètre OT. Pour trouver des solutions, il y a deux approches possibles :

• Trouver des solutions utilisées localement par les équipes OT et les faire passer à l’échelle ;
• Chercher des solutions de cybersécurité parmi le catalogue IT for IT et les adapter au monde industriel.

Deux méthodes pour prendre en compte l’existant

2.     Prototype

Au moment de la présentation du prototype, il faut soigner l’expérience utilisateur et l’image du produit. Le prototype est avant tout une vitrine qui doit faciliter l’adoption du produit, mais qui peut également écorner son image s’il n’est pas pratique et fonctionnel. Il faut bien cadrer les cas d’usages couverts et présenter un produit fonctionnel et simple. Il faut garder en tête que la première image du prototype est celle dont le métier se souviendra.

3.     Minimum Viable Product

La phase de MVP a globalement deux enjeux : tester le produit, et rassembler des promoteurs. La communication autour du MVP doit être soignée, et tout doit être mis en œuvre pour éviter les échecs. Lors du test, il ne faut pas simplement tester la solution en elle-même, mais également toutes les fonctions de support et l’intégration avec le reste de l’environnement de production.

Le MVP pouvant être un Single Point of Failure pour la production, il faut prendre en compte les besoins de haute disponibilité et mettre en place des mécanismes de bypass en cas de problème, afin de rassurer les métiers et faciliter l’intégration. Un MVP peut gravement abimer la réputation d’un produit sur le long terme en cas d’échec.

4.     Packaging

L’étape de packaging permet de définir tous les prérequis au déploiement du produit. Il faut définir :

• Les process de l’ensemble du cycle de vie comme la gestion des demandes de déploiement, définir l’obligation ou non de déploiement, les process de maintenance, les process de mise à jour en prenant en compte les besoins opérationnels, …
• Définir les responsabilités, mais en prenant en compte que les sites industriels doivent garder une indépendance plus forte que ce qui se fait habituellement sur les périmètres IT. Il faut définir clairement ce qui est délégué aux responsables sur site en mode nominal et en cas d’urgence.
• Le modèle de coût, y compris à long terme, doit être clairement défini et comparé par rapport aux solutions externes.
• Le support doit être envisagé comme du Support as a Service et tous les process et outils doivent être mis en place et communiqués.

5.     Préparation de la maintenance

La dernière étape avant le déploiement effectif est la préparation à la maintenance opérationnelle. Pour chaque produit, un Solution Owner doit être identifié pour gérer les relations entre les utilisateurs, les fournisseurs et – pendant l’intégration – l’intégrateur. Cette personne doit être identifiée en interne avant le déploiement afin de garantir que la maintenance opérationnelle sur tout le cycle de vie sans avoir à dépendre d’un externe.

Avant de déployer la solution, trois points doivent encore être soignés pour préparer le cycle de vie du produit et favoriser son adoption à grande échelle :

6.     Déploiement

Pendant le déploiement du produit, les early-adopters doivent être supportés au maximum pour maximiser les chances d’adoption du projet par les autres sites. Des incitations financières, comme des réductions pour les premiers à adopter le système, peuvent également être mises en place. Différents scénarios de rapidité d’adoption doivent être anticipés afin d’être capable de déployer suffisamment vite en cas de grand succès, mais sans problèmes de coûts en cas de difficultés à l’adoption.

Conclusion

En milieu industriel, la cybersécurité est toujours vue comme trop restrictive, venant à l’encontre de la production, et trop prescriptive. Les départements IT mettent en place des politiques de sécurité mais ne donnent pas de solutions pour les respecter ce qui conduit au développement de solutions locales mal maîtrisées. Pour contrôler ces risques, une solution est le développement d’un catalogue de solution IT pour l’OT. Le développement de ces solutions est un processus long qui peut prendre plusieurs années, surtout lorsque plusieurs projets sont lancés en parallèle. Pour maximiser les chances de réussite, les besoins du métier doivent être pris en compte dès la phase de R&D, et jusqu’au déploiement. Notamment, l’intégration avec les processus métier, les processus de support et toutes les problématiques de budget doivent être pris en compte. Finalement, la dernière clé de la réussite du processus de développement de solution est la communication. L’image du produit doit être soignée et maîtrisée afin de maximiser l’adoption par les sites industriels après le début du déploiement.

Cet article IT for OT : Quel processus pour développer des solutions de cybersécurité adaptées aux métiers ? est apparu en premier sur RiskInsight.

Un SCADA (Supervisory Control And Data Acquisition ou Système de contrôle et d’acquisition de données) permet de gérer et de contrôler à distance des installations industrielles. Cela inclut des machines telles que des postes de supervision, serveurs de centralisation de données, portables de maintenance…).

Les postes SCADA incluent trois fonctions principales :

• Acquisition : Des capteurs sont présents sur les automates programmables industriels (API) qui agissent sur le processus industriel. Ces capteurs sont reliés au SCADA afin que les différentes données du processus puissent être récupérées ;
• Supervision : Les opérateurs accèdent aux données récupérées et supervisent en temps réel le bon déroulement du processus industriel ;
• Contrôle : Lorsque le processus industriel le permet, les opérateurs peuvent envoyer certains ordres de contrôles aux automates afin d’adapter le processus industriel.

La nature de ces postes en fait un élément important de la chaîne de production, c’est pourquoi il est nécessaire de sécuriser leur partie logicielle qui fonctionne souvent sous Windows.

Cependant, des contraintes sont présentes par rapport à un poste en environnement bureautique classique :

• Les postes fonctionnent en continu, avec une fréquence de mise à jour très faible (une fois tous les 1 à 2 ans) ;
• De plus, ces postes ont une durée de vie très étendue, pouvant aller jusqu’à plus de 10 ans. Un poste SCADA fonctionnera donc en partie sur un système d’exploitation obsolète qui ne recevra plus de patchs de sécurité durant sa période de fonctionnement ;
• Enfin, les systèmes industriels sont parfois totalement isolés, ce qui empêche l’utilisation de solutions de sécurité telles que des EDR qui ont besoin de communiquer avec une console centrale pour remonter les alertes et récupérer les actions à effectuer.

Les solutions de sécurité classiques ne sont donc pas applicables dans un écosystème soumis à ces contraintes.

Une solution possible : le contrôle d’application

Une des solutions permettant de pallier ces problèmes est le contrôle d’application : cela consiste à gérer quelles applications sont autorisées à être exécutées ou non sur une machine grâce à une liste blanche d’applications autorisées.

Les solutions de contrôle d’application gèrent aussi bien les .exe que d’autres types de programmes tels que les DLL, les pilotes ou encore les scripts (comme PowerShell, CMD ou encore VBS).

Une partie significative des menaces proviennent de programmes malveillants. Ce genre de solutions permet d’autoriser uniquement les applications nécessaires tout en bloquant toute application indésirable ou dangereuse. Le contrôle d’application garde également un bon niveau de sécurité dans un système obsolète et sujet à des vulnérabilités, car durant les étapes de compromission, un attaquant est souvent amené à exécuter des programmes malveillants sur un système.

Par ailleurs, le contrôle d’application s’intègre facilement dans le milieu industriel : les postes de supervision sont soumis à bien moins de changements qu’un poste de bureautique ; il n’y aura donc pas besoin de revoir en permanence la liste blanche afin d’y ajouter des applications à autoriser.

Solutions de contrôle d’application sous Windows

Deux solutions de contrôle d’application sont présentes nativement sous Windows : Windows Defender Application Control (WDAC) et AppLocker. WDAC est apparu avec Windows 10 ; c’est le successeur d’AppLocker qui est présent depuis Windows 7. Les deux solutions partagent un fonctionnement très similaire, cependant WDAC est activement maintenu par Microsoft, avec de l’ajout de nouvelles fonctionnalités, tandis qu’AppLocker ne reçoit que des mises à jour de sécurité.

Lorsqu’une application n’est pas autorisée par la liste blanche, son exécution sera bloquée. Le message d’erreur suivant sera alors affiché à l’utilisateur. Un évènement contenant les informations du blocage sera également inscrit dans les logs de Windows pour revue par le SOC ou les administrateurs du système d’information.

Le contrôle d’application peut fonctionner en mode bloquant ou audit. Le mode audit permet de tester la liste utilisée : les applications non autorisées sont exécutées, mais un évènement de blocage est tout de même inscrit pour indiquer qu’elles ne fonctionneraient pas en mode bloquant.

Afin d’avoir un contrôle d’application efficace, il est nécessaire de constituer une liste blanche la plus restrictive possible tout en autorisant les applications métier. Pour les deux solutions, la liste blanche peut se constituer avec trois règles différentes :

• Règles de chemin : Autorise l’application selon le chemin depuis lequel elle est exécutée. Ce sont les règles les plus faciles à utiliser mais elles peuvent induire des problèmes de sécurité. Il est en effet courant de retrouver des dossiers autorisés dans la liste blanche et accessibles en écriture par les utilisateurs. Ces derniers seront donc en mesure de déposer n’importe quelle application dans le dossier pour pouvoir l’exécuter, contournant ainsi le contrôle d’application ;
• Règles d’éditeur : Autorise l’application en fonction des éléments de sa signature numérique. Ces règles sont tout autant faciles à utiliser que les règles de chemin mais gardent un bon niveau de sécurité en n’autorisant que des applications provenant d’éditeurs légitimes. L’avantage principal de ce type de règle est qu’elles restent valables après une mise à jour des applications car l’éditeur ne change pas. Cependant, cela nécessite que les applications à autoriser soient signées, ce qui n’est pas toujours le cas en milieu industriel ;
• Règles de hash : Autorise l’application selon son hash. Ces règles imposent le plus haut restrictif possible. Le hash de chaque application étant unique, seul le code explicitement autorisé par la politique peut être exécuté. Toutefois, ce type de règle génère un coût organisationnel important : toute modification d’une application change son hash ; la règle doit alors être mise à jour afin d’autoriser correctement l’application.

Pour les choix des types de règles à utiliser, on distingue deux cas de figures :

• Sur les équipements recevant des mises à jour, les règles d’éditeur doivent être privilégiées afin de garder la validité de la liste blanche même après modification des fichiers des applications. Les règles de chemin pourront être utilisées en second lieux pour les applications non signées, en faisant attention aux règles d’accès des répertoires en question ;
• Sur les équipements dont la configuration ne changera pas, les règles éditeurs peuvent être utilisées pour autoriser facilement le code de base de Windows. Les applications métier pourront alors être autorisées avec des règles de hash car elles ne seront pas vouées à changer.

Démarches de déploiement

Maintenant que l’on sait quels types de règles utiliser, il reste à constituer la liste blanche pour la machine à sécuriser. Deux approches sont retenues selon le type de poste à gérer :

Approche temporelle : Déploiement par amélioration continue

Cette méthode consiste à déployer le contrôle d’application en partant d’une politique de base autorisant les composants de Windows qui est ensuite améliorée petit à petit grâce aux évènements générés par l’exécution des applications métier.

Cette approche est particulièrement adaptée pour les postes existants en production sur lesquels les administrateurs n’ont pas beaucoup d’informations. Chaque évènement généré doit alors être revu afin d’estimer si l’application exécutée est légitime ou non. Cela permet d’obtenir une liste blanche exhaustive sans pour autant autoriser des applications illégitimes.

Approche par modèle : Déploiement sur une « golden image » puis réplication sur le reste des machines

Dans cette approche, WDAC sera déployé sur une « golden image », c’est-à-dire une image propre contenant toutes les applications nécessaires à l’utilisation métier de la machine. Une fois la politique correctement configurée, la golden image pourra être clonée sur toutes les autres machines ayant le même rôle. Typiquement, la golden image pourra être produite à l’issue des tests d’acceptation (FAT/SAT) lors de la mise en place d’une nouvelle usine.

Cette approche est préférable pour les nouveaux postes à mettre en production. En partant d’une machine vierge où l’on installe l’ensemble des logiciels nécessaires au métier, on est assuré qu’aucune application illégitime n’est présente sur la machine. Il est alors possible d’utiliser les outils fournis par Microsoft afin de scanner la machine et générer automatiquement une liste blanche autorisant l’ensemble des applications présentes sur la machine.

Limites du contrôle d’application

Il est important de prendre en compte les limites de ces solutions, qui ne sont pas infaillibles. Par nature, les actions d’une application autorisée à être exécutée ne sont plus surveillées, l’application peut elle-même exécuter du code ou lancer d’autres programmes. Par conséquent, si un attaquant venait à découvrir une vulnérabilité sur une application autorisée par la liste blanche, le contrôle d’application n’empêcherait pas son exploitation qui permettrait d’influer sur le procédé industriel, mais cela empêchera l’exécution de programmes malveillants tels que des ransomware.

Il existe ainsi plusieurs manières de contourner le contrôle d’application en utilisant des programmes présents de base dans Windows. C’est notamment le cas de mshta.exe qui permet d’exécuter des applications HTML autonomes (.hta) qui sont capables d’exécuter du code sur une machine. C’est pourquoi Microsoft maintient en permanence une liste d’applications présentes de base dans Windows ou signées par Microsoft à bloquer afin de durcir le contrôle d’application.

Le même principe s’applique aux programmes métier. Il revient aux industriels de faire auditer leurs applications afin de s’assurer qu’aucune vulnérabilité pouvant permettre la compromission du poste ne soit présente.

Contrôle d’application sous Windows : WDAC ou AppLocker ?

Finalement, les deux solutions sont très similaires et compatibles avec les deux modes de déploiement présentés précédemment, il reste donc à choisir entre les deux.

Lorsque possible, il est préférable de choisir WDAC : sa force se trouve dans sa capacité de contrôle global et ses différentes fonctionnalités. En effet, AppLocker ne peut contrôler que les programmes exécutés par l’utilisateur, tandis que WDAC peut aussi contrôler les programmes exécutés par Windows tels que les pilotes.

De plus, WDAC intègre des fonctionnalités supplémentaires telles que des protections contre les élévations de privilèges ou encore la vérification automatique des accès utilisateur sur les règles de chemin. Microsoft continue également de supporter la solution et de l’améliorer en ajoutant de nouvelles fonctionnalités, tandis qu’AppLocker ne reçoit que des mises à jour.

AppLocker quant à lui est généralement plus simple d’utilisation que WDAC et permet de différencier l’application des règles selon les utilisateurs de la machine alors que les règles de WDAC s’appliquent à toute la machine sans distinction.

Cependant, WDAC n’est disponible qu’à partir de Windows 10. Ainsi, sur les machines utilisant Windows 7, encore très présentes sur les réseaux industriels, AppLocker est la seule solution native disponible, qui est donc à utiliser. Sur Windows 10 et supérieur, WDAC est la meilleure solution de contrôle d’application et est à préférer.

En complément, AppLocker peut être utilisé en parallèle de WDAC s’il y a besoin de différencier les règles selon les utilisateurs. WDAC devra alors être implémenté au niveau le plus restrictif possible, puis AppLocker peut être utilisé pour affiner les restrictions.

Cet article Le filtrage applicatif : quelle stratégie adopter pour son système de supervision industriel ? est apparu en premier sur RiskInsight.

D’après la dernière étude Digital Trust Insights réalisée par le cabinet PwC en septembre 2019, 53% des entreprises du secteur Ingénierie et Construction (AEC) interrogées (échantillon de 270 entreprises mondiales) ont indiqué avoir été victimes de cyberincidents ayant provoqué une interruption de leurs opérations entre 2017 et 2019.

Même les entreprises du BTP en France ne sont pas épargnées des attaques ciblées pour compromettre les données liées à des projets sensibles. A titre d’exemple, Bouygues Construction a été visée deux fois depuis 2019 et la dernière attaque en janvier 2020 a causé une paralysie qui a touché plus de 3 000 salariés du siège. Le groupe Rabot Dulliteul a été également attaqué en juillet 2020 causant un ralentissement de l’activité. Les assaillants ont réclamé une rançon de 973 bitcoins (~8 M€) en menaçant le groupe de divulguer des informations piratées.

Tous ces exemples nous apprennent qu’il est temps de remettre en question les processus d’ingénierie allant de la conception jusqu’à l’exploitation et la maintenance en identifiant les risques cyber menaçant ces processus. Il convient de mettre  en place des actions de prévention et d’hygiène permettant de réduire leur probabilité d’occurrence.

Dans cet article, nous allons nous focaliser sur l’une des méthodes collaboratives utilisées dans le domaine de la construction qui pourrait être la porte d’entrée de cyberattaques si les processus de collaboration ne sont pas bien maîtrisés et sécurisés. Il s’agit de la méthode BIM.

Qu’est-ce que c’est le BIM ?

Le BIM (Building Information Modeling) est un processus de collaboration digitale s’appuyant sur la création et l’exploitation d’un actif numérique d’un bâtiment. Selon la NF – EN ISO 19650, il se définit comme l’utilisation d’une représentation numérique partagée d’un actif bâti (bâtiments, ponts, routes, usines…) pour faciliter les processus de conception, de construction et d’exploitation et former une base fiable permettant les prises de décisions. De ce fait, cet actif numérique représente le bien le plus précieux et le plus sensible d’un projet de construction.

Comment fonctionne une collaboration BIM et sur quels actifs repose-t-elle ?

Processus de collaboration BIM niveau 2 selon la NF ISO 19650

Une collaboration BIM s’appuie essentiellement sur l’échange des données via des maquettes. Le point de départ est la modélisation des maquettes métier (MEP, Architecture, Structure) en se basant sur les exigences de la convention BIM. Ces maquettes sont déposées ensuite par le coordinateur BIM de chaque discipline dans le CDE. Le BIM Manager effectue les contrôles de la maquette (contrôle sémantique et géométrique) et la cellule de synthèse s’occupe de la compilation de toutes les maquettes dans une et seule maquette de synthèse à partir de laquelle une détection de conflit géométrique est réalisée.

Tous ces conflits sont remontés à l’équipe projet via des rapports en format BCF et ils sont discutés et revus dans la réunion de projet BIM. Si tout va bien, la maquette de synthèse servira à la préparation des livrables de projet qui sont ensuite publiés dans le CDE sous format DWG, IFC ou/et PDF.

Exemple de système d’information d’une collaboration autour d’une maquette MEP

Pour comprendre le socle technique sur lequel repose une collaboration BIM, il faut tout d’abord se focaliser sur le système d’information hébergeant les maquettes modélisées. Pour cela, nous avons pris l’exemple d’un modeleur MEP qui va modéliser sa maquette au sein d’un bureau d’études spécialisé MEP.

Généralement un modeleur MEP peut travailler sur la maquette soit au sein de l’entreprise en se connectant au réseau local soit chez lui en utilisant son PC professionnel et un VPN lui permettant de créer un tunnel vers le réseau local de son entreprise.

Dans les deux cas, les données modifiées dans la maquette sont enregistrées dans une base de données hébergées au sein de l’entreprise. L’accès à la maquette est fréquemment non-contrôlé au sein d’un bureau d’études et aucun système d’authentification n’est mis en place pour accéder aux ressources tant qu’on est connecté au réseau local de l’entreprise.

Ensuite l’accès à la plateforme collaborative se fait via Internet pour publier les maquettes ainsi que les documents et les partager avec l’ensemble des acteurs.

Quels sont les processus métier critiques associés à la collaboration BIM ?

Gestion de la maquette numérique

La maquette numérique représente le modèle de données d’un bâtiment qui est constitué d’un ensemble d’informations structurées selon un schéma particulier. Ces informations sont enrichies par les différents spécialistes métier (architecte, ingénieur structure, spécialiste électricité, spécialiste CVC, etc.) tout au long du cycle de vie du bâtiment.

La maquette est la cible propice des attaquants pour atteindre la donnée et l’exploiter pour des fins malicieuses (chantage, demande de rançons, attaque physique au bâtiment, etc). Ils pourront même la viser dans un but de détruire toutes les données pour les rendre indisponibles et inaccessibles. Pour cela, la sécurisation de la maquette est indispensable et ne peut pas être assurée sans avoir assuré la sécurité des données rattachées à la maquette.

Les besoins de sécurité d’un tel actif en termes de disponibilité, d’intégrité, de confidentialité et de traçabilité sont très forts.

D’une part, une maquette indisponible à cause d’une perte d’un serveur non-redondé par exemple a un fort impact financier. Des pénalités peuvent commencer à être appliquées dès que les jalons de projet ne sont plus respectés. Cette indisponibilité peut aussi affecter l’image de l’entreprise et ternir la confiance qui lui a été accordée par les partenaires.

D’autre part, les données et les informations contenues dans les objets de la maquette ont elles-aussi leur valeur. Elles ne doivent en aucun cas être altérées et doivent rester conformes aux données saisies par les spécialistes métiers. En plus de l’impact financier et celui sur l’image, cela pourrait impliquer des poursuites judiciaires dû au non-respect des documents contractuels et pourrait également porter atteinte à la sécurité des biens et des personnes en cas de non-constatation de ces altérations.

Par ailleurs, la protection des données au repos et en transit est un élément primordial en cas de fuite. Ces données peuvent toucher des volets sensibles comme les réseaux, le contrôle d’accès, ou le système d’alarme incendie. Un non-respect de cette exigence peut avoir d’importants impacts financiers, sur l’image de l’entreprise, et peut porter préjudice à la sécurité des biens et des personnes et déclencher ensuite des poursuites judiciaires.

En général, dans un processus de modélisation d’une maquette numérique, plusieurs acteurs peuvent intervenir dans la modélisation et apporter leur propre modification. Ces actions doivent être tracées et attribuées à leur auteur pour pouvoir identifier le responsable en cas de problème. Un manque de rigueur dans la traçabilité pourrait facilement impacter le délai d’exécution du projet et dans ce cas la seule solution est de revenir à une ancienne version à la place de corriger l’erreur de l’auteur en question.

Création et partage de livrables

Dans le BIM, un processus de création et partage/diffusion de livrables représente une pierre angulaire dans l’exploitation de la maquette numérique de synthèse pour en extraire des livrables servant à l’exécution du projet sur chantier.

L’altération des livrables à un niveau de gravité critique parce que la modification d’une note de calcul ou d’un plan d’exécution peut causer la ruine d’un bâtiment et donc peut porter atteinte à la vie des personnes. Et si on étend le champ à des projets de centrales nucléaires ou à des projets de caractère militaire, la compromission d’un livrable DOE (Dossier des Ouvrages Exécutés) peut nuire vitalement la nation.

Que ce soit l’indisponibilité des livrables ou leur fuite, ces scénarios de compromission ont un impact fort sur la sécurité de la donnée et peuvent entraîner des conséquences désastreuses sur le bureau d’études au niveau financier, opérationnel et/ou sur son image sans oublier l’impact sur les personnes.

Quels sont principaux scénarios de risques associés à la collaboration BIM ?

Scénario 1 : Perte de disponibilité d’une maquette BIM

Parmi les risques les plus courants dans la collaboration BIM, on trouve l’indisponibilité d’une maquette à la suite de la défaillance d’un serveur. Aujourd’hui, dans le domaine de la construction, certaines entreprises ne sont pas encore totalement sensibilisées aux enjeux de la cybersécurité et n’apprécient pas l’importance de la redondance des serveurs. Elles utilisent souvent un seul serveur ou rarement deux serveurs qui sont mis dans la même zone géographique ; ce qui ne permettra pas de couvrir tous les risques que pourraient encourir le bâtiment hébergeant ces serveurs (incendie, inondation, coupure électrique, etc.).

A vrai dire, la perte d’un serveur peut avoir un impact opérationnel et financier très important et elle pourrait même ternir l’image de l’entreprise vis-à-vis de ses clients et partenaires.

Scénario 2 : Accès non autorisé au SI de l’entreprise et compromission des données sensibles liées à la maquette

Une entreprise qui utilise uniquement un système d’authentification simple basée sur des identifiants de connexion et des mots de passe reste vulnérable aux attaques extérieures. Un attaquant malveillant peut facilement identifier une vulnérabilité dans le système d’information de l’entreprise et parvient à compromettre les informations d’identification d’un utilisateur autorisé et à accéder aux maquettes hébergées dans les serveurs de l’entreprise.

L’attaquant pourra par la suite accéder à l’ensemble des données sensibles renseignées sur la maquette et en particulier celles concernant les lots : le courant fort/faible, la sécurité incendie, la vidéo-surveillance, la climatisation et la ventilation. Ces données sont susceptibles de lui permettre une compréhension fine du fonctionnement du bâtiment et à la base desquelles, il pourra effectuer un braquage du bâtiment ou une vente de données à des parties externes.

Scénario 3 : Accès non autorisé au CDE et exploitation des droits d’accès aux livrables

De façon similaire au scénario 2, un Common Data Environment sans système d’authentification forte ne peut pas échapper d’une potentielle attaque notamment si quelqu’un arrive à récupérer les informations de connexion d’un utilisateur grâce à des techniques telles que le phishing ou l’ingénierie sociale.

Une fois que l’attaquant a gagné l’accès au CDE, il peut exploiter les droits d’accès associés à cet utilisateur pour accéder à des livrables sensibles : des plans, des schémas, des devis, et toute donnée stratégique et concurrentielle. Il peut ensuite les détruire ou les exploiter pour programmer d’autres attaques ou tout simplement les vendre à des parties tierces pour leur donner des avantages concurrentiels sur le marché.

Scénario 4 : utilisation de scripts ou plugins externes et altération ou vol des données sensibles

Le développement de plugins en interne en utilisant les fonctions, méthodes et propriétés de l’API du logiciel de conception BIM paraît parfois complexe et consommateur de temps. Certains développeurs recourent aux programmes partagés dans les blogs pour les réutiliser. L’utilisation de ces scripts non maîtrisés peut facilement pousser un élément malveillant dans le SI causant par la suite la compromission d’accès. L’assaillant peut ensuite avoir accès aux données des maquettes et a la possibilité de les voler pour une utilisation ultérieure ou les altérer pour qu’elles soient inutilisables.

Quelles sont les préconisations pour faire face à ces risques ?

Au vu des différents risques de sécurité compromettant les valeurs métiers liés à un processus BIM, il est primordial de réfléchir à des moyens de sécurisation permettant d’éviter tout éventuelle menace cyber pourront mettre en péril son socle SI.

Renforcer la resilience des serveurs des maquettes

Une maquette numérique peut être soit hébergée en local dans un serveur de l’entreprise soit hébergée en cloud dans un CDE. Cela n’empêche pas qu’elle soit indisponible à cause d’une indisponibilité du SI de l’entreprise ou celle du SI du fournisseur de la CDE.

Parmi les meilleurs pratiques pour éviter la perte d’accès à une maquette :

• La redondance des serveurs internes d’un côté pour faire l’équilibrage de charge en cas d’utilisation excessive et donc assurer des performances optimales et un accès fluide à la maquette et de l’autre pour assurer la continuité d’activités en cas de perte de l’un de ces serveurs. Il est fortement conseillé de redonder les serveurs dans deux zones géographiques différentes pour prendre en compte tous les risques (incendie, inondation, blackout, etc.).
• La mise en place de sauvegardes régulières et des réplications de données dans plusieurs emplacements ; ce qui permet de récupérer les données en cas de perte. Il est judicieux que ces procédures soient testées régulièrement pour vérifier l’intégrité des données et rendre les équipes fluides dans l’exécution de la démarche de restauration.

Mettre en place de l’authentification multifactorielle

Comme on l’a vu auparavant, la mise en place d’une authentification simple pour accéder à maquette depuis le serveur interne de l’entreprise ou depuis un Common Data Environment n’est pas suffisante pour se protéger contre les cyberattaques. Il est désormais primordial d’instaurer un mécanisme fort d’authentification factorielle (par exemple une authentification à deux facteurs) permettant d’identifier finement la personne :

• TOTP (Time Based OTP): c’est un mot de passe à usage unique basé sur le temps. L’idée est de pousser l’utilisateur à renseigner deux facteurs : son nom d’utilisateur et son mot de passe et un code unique à six chiffres générés toutes les 30 secondes.
• Clé FIDO2: elle permet aux utilisateurs de s’authentifier en toute sécurité à l’aide de données biométriques ou d’une clé de sécurité au lieu d’un mot de passe.
• Cartes à puces: c’est une méthode pour sécuriser l’accès à une ressource. L’utilisateur doit avoir à sa disposition une carte physique ou virtuelle pour accéder à un serveur interne de l’entreprise ou pour se connecter sur son compte CDE.

Il est important de souligner que ces mécanismes sont donnés à titre d’illustration et que la mise en place de l’authentification multifactorielle dépend fortement de plusieurs paramètres. D’un côté, cela dépend de la capacité du serveur et de l’infrastructure de l’hébergement du CDE et de son interopérabilité avec d’autres systèmes (capacité d’intégration avec d’autres parties tierces via API). De l’autre, il faut s’assurer que l’authentification à mettre en place est compatible avec les appareils des utilisateurs : types d’appareils (ordinateur de bureau, tablettes, téléphones, etc.), niveau de propriété (BYOD, COPE, COBO, etc), systèmes d’exploitation (Windows, Linux, MacOs, Android, etc).

Gestion du cycle de vie des accès et des identitiés

La gestion des identités et des accès à un CDE qui représente une mine d’or pour les assaillants ne doit pas être pris à la légère. La maîtrise du cycle de vie des identités et des accès en est un prérequis.

Gestion des identités

En cas d’arrivée d’une nouvelle personne dans l’équipe BIM :

• Création d’un compte : Lorsqu’une nouvelle personne rejoigne l’organisation, un compte utilisateur doit être créé dans le SI de l’entreprise ou dans le CDE en suivant des procédures standardisées.
• Attribution des rôles : En fonction de la fonction et des responsabilités de la personne, des rôles et des privilèges appropriés doivent être attribués pour accéder aux ressources nécessaires.

En cas d’un changement de poste ou mobilité au sein de l’équipe BIM :

• Réévaluation des privilèges : Les droits d’accès de cette personne doivent être mis à jour en conséquence, en révoquant les anciens privilèges et en accordant les nouveaux. Il est donc important de réévaluer régulièrement les privilèges d’accès pour s’assurer qu’ils correspondent toujours aux besoins réels de la personne.

En cas de départ de l’équipe BIM :

• Désactivation de compte : Le compte utilisateur de cette personne doit être désactivé immédiatement pour éviter tout accès non autorisé ultérieur.
• Révocation des droits : Tous les droits d’accès de la personne doivent être révoqués, y compris les accès aux systèmes, aux applications et aux données.

Gestion des accès

Lors de l’affectation des droits, les droits d’accès doivent être accordés selon le principe du moindre privilège, c’est-à-dire que les utilisateurs ne doivent avoir accès qu’aux ressources nécessaires pour accomplir leurs tâches professionnelles.
Par ailleurs, il est souhaitable que les droits d’accès doivent être demandés par les utilisateurs, généralement par le biais d’un système de demande d’accès, afin que toutes les demandes puissent être traçables et approuvées.
Concernant l’approbation de ces droits, il faut bien définir un processus d’approbation impliquant les responsables appropriés, pour garantir que les demandes sont examinées par les personnes adéquates avant d’être accordées.
Ce qui est également important est de revoir et réévaluer régulièrement ces droits d’accès pour s’assurer qu’ils sont toujours appropriés. Dans le cas les droits d’accès sont inutilisés ou non nécessaires, ils doivent être révoqués pour réduire la surface d’attaque du système.

Éviter l’installation des plugins ou l’utilisation de scripts non-contrôlés

Le plus souvent les modeleurs, les coordinateurs ou les BIM Managers recourent à des scripts de Visual Programming (Dynamo pour Autodesk Revit, Grasshopper pour Rhinoceros, etc.) ou à des développements spécifiques via C# ou Python sur l’IDE (Integrated Development Environment) du logiciel en utilisant l’API. Ces pratiques ne sont pas contrôlées et peuvent être une cause de la compromission d’accès au SI si quelque chose a été téléchargée depuis Internet.

Dans ce cas, il est recommandé de prendre des mesures de sécurité tels que :

• Contrôle des privilèges utilisateur: il faut donner l’accès à l’installation des plugins uniquement aux utilisateurs qui en ont besoin pour leur travail. Pour ce faire, il suffit de limiter les droits administratifs sur les postes de travail pour empêcher les utilisateurs standard d’installer des plugins.
• Gestion centralisée des installations : si l’entreprise dispose d’un réseau centralisé, il est possible de gérer les installations de plugins depuis un serveur administratif. Cela permet de contrôler quels plugins sont autorisés à être installés sur les postes de travail des utilisateurs.
• Sécurité du réseau d’entreprise : il est judicieux de mettre en place des pare-feux et des dispositifs de sécurité réseau pour bloquer l’accès à des sites Web non autorisés ou suspects, où les utilisateurs pourraient télécharger des plugins potentiellement malveillants.
• Contrôle des appels d’API: il est possible d’utiliser des stratégies de groupe GPO (sur des environnements Windows doté de l’Active Directory) pour désactiver ces appels sur les postes de travail des utilisateurs non autorisés
• Vérification des scripts: il est préconisé de mettre en place un processus de vérification et d’approbation des scripts avant toute utilisation. Il est également souhaitable que l’examen des scripts se fasse sur un environnement test avant de l’exploiter dans un environnement de production.

Conclusion

Il est évident que l’essor du Building Information Modeling (BIM) a révolutionné la manière dont nous concevons et gérons les actifs bâtis. Cependant, cette transformation a également ouvert de nouvelles portes aux cybermenaces. Dans cet article, nous avons exploré les nombreux enjeux liés à la cybersécurité dans le contexte de la conception digitale avec la méthode BIM, mettant en évidence les principaux scénarios de risques et les meilleures pratiques pour y répondre. Il est important à noter que toute l’approche présentée dans l’article est une méthode standard et adoptée par maintes entreprises matures d’un point de vue cyber (banques, assurances, acteurs de la grande distribution, etc). Elle peut être déclinée par tout secteur d’activité, qu’il soit accoutumé ou non à la cybersécurité.

Il reste primordial de considérer la cybersécurité comme un défi qui peut être relevé avec une approche proactive et des efforts concertés. Alors que nous continuons à exploiter les avantages du BIM pour la construction et la gestion d’infrastructures modernes, la protection de nos données et de nos systèmes doit rester au cœur de nos préoccupations.

La cybersécurité demeure non seulement un enjeu pour le BIM, mais un défi qui touche de nombreux aspects de notre vie moderne. L’évolution rapide des technologies et la sophistication croissante des cyberattaques exigent une vigilance constante. En tant que société, nous devons continuer à investir dans la recherche et le développement de nouvelles solutions de cybersécurité et à promouvoir la sensibilisation à ce sujet critique.

Cet article La cybersécurité, un nouveau défi pour la conception digitale des actifs bâtis en BIM est apparu en premier sur RiskInsight.

L’émergence de l’industrie 4.0 se caractérise par la numérisation de l’industrie et une plus grande interconnexion entre les différentes machines qui composent un SI (Système d’Information) industriel. Cependant, cette croissance des communications au sein des SI industriels engendre également une augmentation de leur surface d’attaque. De plus, les protocoles historiquement utilisés au sein de ces SI (comme Modbus), n’offrent que très peu, voire aucun mécanisme de sécurité. Certains de ces protocoles étaient également propriétaires ce qui pouvait poser des problèmes d’interopérabilités entre les différentes machines du SI.

Le standard OPC UA a été créé en 2008 par la fondation OPC pour répondre à ces problématiques, en proposant une uniformisation des communications entre les machines des SI industriels, et en intégrant de nombreux mécanismes pour garantir la sécurité de ces communications.

Le standard OPC UA

Le standard OPC UA est un standard de communication open-source, qui a été conçu pour être multiplateforme. Il peut être implémenté sur tout type de composant, quel que ce soit son système d’exploitation.

Communications permises par OPC UA (Source : site web de la OPC Foundation)

Le standard propose deux types d’architectures, pouvant être utilisées de manière complémentaire :

• L’architecture client-serveur : c’est l’architecture la plus utilisée. Elle est composée d’éléments matériels et/ou logiciels qui contiennent des données, de serveurs OPC UA qui mettent à disposition ces données ou des services, ainsi que de clients OPC UA qui peuvent interagir avec les serveurs pour utiliser leurs services ou accéder à leurs données.
• L’architecture PubSub : elle peut être est utile lorsque le volume de données échangées commence à devenir important. Elle est composée de Publishers qui émettent des messages, et de Subscribers, qui reçoivent ces messages par le biais d’un Message Oriented Middleware (MOM).

Sécurité de l’architecture client-serveur

L’architecture client-serveur étant de loin la plus utilisée, nous allons à présent nous pencher plus en détail sur les mécanismes de sécurité proposés par le standard OPC UA dans ce type d’architecture.

Tout d’abord, trois niveaux de sécurité dont disponibles concernant le chiffrement des communications entre un client et un serveur OPC UA :

• None : les messages sont envoyés en clair, sans aucune protection
• Sign : les messages sont signés. Cela protège l’intégrité des données transmises, mais pas leur confidentialité
• SignAndEncrypt : les messages sont signés et chiffrés. Dans ce cas, la confidentialité des messages est également protégée

Pour mettre en place ce chiffrement, le client et le serveur disposent chacun d’un certificat X.509 et d’une clé privée associée, qu’ils utilisent pour s’échanger une clé de session de manière chiffrée. Ils peuvent ensuite utiliser cette clé de session pour chiffrer la suite des échanges avec des algorithmes de chiffrement symétriques.

Plusieurs niveaux de sécurité concernant l’authentification des utilisateurs sont également disponibles. Pour s’authentifier, les clients envoient aux serveurs des jetons appelés UserIdentityTokens, qui contiennent les informations nécessaires à l’authentification. Il existe plusieurs types de UserIdentityToken, et c’est le serveur qui choisit quels types il accepte :

• AnonymousIdentityToken : ce jeton ne contient aucune information particulière. Si le serveur l’accepte, il authentifie l’utilisateur en tant qu’utilisateur anonyme
• UserNameIdentityToken : ce jeton contient un nom d’utilisateur et un mot de passe. Si ces derniers sont valides, l’utilisateur est authentifié et dispose ensuite du profil et des droits associés à son nom d’utilisateur
• X509IdentityToken : ce jeton contient un certificat X.509. Si le serveur a enregistré ce certificat, l’utilisateur est authentifié et dispose ensuite d’un profil et des droits associés au certificat
• IssuedIdentityToken : ce jeton encapsule un jeton d’accès fourni par un service tiers de gestion des accès, comme un serveur OAuth2 par exemple

Enfin, une fois authentifié, l’utilisateur a accès aux nœuds du serveur. Ci-dessous, un exemple de nœuds qui pourraient être rencontrés sur un serveur OPC UA :

Nœuds d’un serveur OPC UA

Un contrôle d’accès peut être mis en place pour restreindre l’accès à certains nœuds aux utilisateurs à haut privilège (administrateurs, …), ou bien pour exiger que le canal de communication soit chiffré pour accéder à certains nœuds sensibles. La figure ci-dessous récapitule comme la gestion de l’accès à un nœud se déroule :

Représentation de la gestion des permissions extraite du chapitre 2 des spécifications OPC UA

Outillage d’audit OPC UA

Les outils publics existants pour faciliter l’audit d’applications OPC UA sont très peu nombreux. Un des plus connus est le module Metasploit appelé « msf-opcua ».

Ce module est composé de trois scripts :

• opcua_hello : permet d’envoyer un « Hello Message » à une liste d’adresses IPs, pour un port donné, afin de détecter la présence de serveurs OPC UA parmi cette liste
• opcua_server_config : ce script s’utilise avec pour prérequis un accès authentifié à un serveur OPC UA. Si cette condition est remplie, ce script permet de récupérer des informations sur la configuration des points d’accès du serveur (chiffrement, authentification…)
• opcua_login : permet d’effectuer une attaque par dictionnaire sur un serveur utilisant une authentification par nom d’utilisateur et mot de passe

Bien que fournissant des premiers éléments utiles pour effectuer un audit, cet outil comporte tout de même quelques limites. Par exemple, il n’est pas possible de scanner plusieurs ports à la fois avec le script opcua_hello. Autre exemple, le script opcua_server_config requiert une authentification pour récupérer certaines informations de configuration alors que ces dernières sont en réalité disponibles sans authentification.

C’est pourquoi Wavestone a décidé de proposer une amélioration de cet outil. Il a été décidé de ne plus utiliser le framework Metasploit, qui imposait trop de contraintes et l’outil prend à présent la forme d’un script Python indépendant, renommé « opcua_scan ». Il s’appuie sur la bibliothèque opcua-asyncio contrairement au module msf-opcua qui utilise la librairie python-opcua déclarée comme dépréciée par ses auteurs.

L’outil est accessible via ce lien, et met à disposition deux commandes : « hello » et « server_config », qui reprennent les fonctionnalités des scripts opcua_hello et opcua_server_config du module msf-opcua. Le script opcua_login n’a pas été repris, car il n’a pas fait l’objet d’amélioration et peut être utilisé directement.

La commande hello

Cette commande s’utilise pour détecter les applications OPC UA dans un réseau. Elle permet d’envoyer des « Hello Message » à une liste d’adresses IP, sur une liste de ports donnée, et d’en déduire la présence ou l’absence de serveurs OPC UA sur les cibles. Ensuite, le service FindServers, supposé être implémenté par tout serveur OPC UA, est utilisé pour récupérer l’ApplicationDescription du serveur (et des autres applications OPC UA connues par le serveur). Cet objet contient des informations utiles, comme le productUri, qui donne des renseignements sur le logiciel ou la bibliothèque utilisée pour faire fonctionner le serveur détecté, ou encore les discoveryUrls, qui indique les URL vers les DiscoveryEndpoints du serveur. Ces endpoints peuvent être utilisés par la commande server_config pour récupérer davantage d’informations sur la configuration du serveur.

Plusieurs options ont été ajoutées à la commande, comme la configuration du timeout pour considérer une connexion à un serveur comme échouée ou la possibilité de récupérer la liste des serveurs détectés dans un fichier de sortie JSON.

Voilà comment la commande hello pourrait s’utiliser en pratique :

$ python opcua_scan.py hello -i <IPs> -p <ports> -o hello_output.json

Exemple de résultats générés par la commande hello

Et la capture d’écran ci-dessous montre un extrait du fichier JSON généré :

Extrait d’un fichier de sortie généré par la commande hello

La documentation complète de la commande hello et de toutes ses options est disponible ici.

La commande server_config

Grâce aux DiscoveryEndpoints récupérés avec la commande hello, nous avons à présent accès à l’ensemble du Discovery Service Set du serveur. Aucune authentification ni mécanisme de chiffrement n’est nécessaire pour utiliser ces services. Parmi ces services, celui appelé GetEndpoints peut être utilisé pour récupérer les endpoints pour se connecter au serveur, ainsi que des informations sur la configuration de ces endpoints. Ces informations sont données par le biais d’objets EndpointDescriptions, qui contiennent notamment :

• Le niveau de sécurité du chiffrement accepté sur l’endpoint (None, Sign ou SignAndEncrypt)
• L’algorithme de signature ou de chiffrement utilisé
• Les types de UserIdentityToken acceptés par l’endpoint (AnonymousIdentityToken, UserNameIdentityToken, X509IdentityToken ou IssuedIdentityToken)

La commande server_config permet de récupérer les EndpointDescriptions de tous les serveurs détectés via la commande hello, et d’identifier parmi ces serveurs ceux qui acceptent les authentifications anonymes ou le niveau de sécurité None. L’ensemble de ces informations sont accessibles et récupérables pour un utilisateur non authentifié.

De plus, si un accès authentifié à un serveur est possible, la commande permet également de parcourir les nœuds du serveur et d’énumérer les droits de l’utilisateur courant sur ces nœuds. Ainsi, il est possible d’obtenir la liste des nœuds de type Variable accessibles en écriture, ou bien la liste des méthodes exécutables par l’utilisateur.

Enfin, d’autres options utiles ont été ajoutées à la commande server_config :

• -o (ou –output) permet de configurer un fichier de sortie JSON pour stocker les résultats de la commande, et les parcourir plus facilement que sur un terminal. Des informations supplémentaires y sont stockées comme la valeur de l’attribut UserWriteMask des nœuds, qui indique quels attributs des nœuds peuvent être modifiés par l’utilisateur.
• -r (ou –root_node) permet de parcourir uniquement un sous-ensemble des nœuds du serveur à partir d’un nœud de départ précisé en argument. En effet le parcours de l’ensemble des nœuds peut être long et cette option peut être utilisée pour cibler les nœuds d’intérêt.

La documentation complète de la commande server_config et de toutes ses options est disponible ici.

En pratique, voilà comment la commande server_config pourrait s’utiliser :

Le fichier de sortie de la commande hello est donné en argument (via l’option -t) et sera utilisé pour récupérer les informations sur les endpoints des serveurs détectés :

$ python opcua_scan.py server_config -t hello_output.json

Exemple de résultats générés par la commande server_config

Ici, le serveur autorise les connexions non chiffrées et anonymes ou authentifiées avec un nom d’utilisateur et un mot de passe. Si le serveur n’acceptait pas les connexions anonymes, le script opcua_login du module msf-opcua pourrait être utilisé pour essayer de trouver des identifiants valides, mais cela n’est pas nécessaire dans cet exemple

Il est possible d’accéder anonymement au serveur et parcourir ses nœuds à la recherche de nœuds intéressants (le début du résultat de la commande a volontairement été coupé, et le répertoire « TemperatureControl » a été ciblé avec l’option -r pour réduire le nombre de nœuds parcourus) :

$ python opcua_scan.py server_config -t hello_output.json -o config_output.json -nw -r ‘ns=3;s=85/0:Simulation’

Exemple de résultats obtenu lors d’une recherche de nœuds accessibles en écriture

Les nœuds accessibles en écriture peuvent ensuite être analysés plus en profondeur dans le fichier de sortie qui a été configuré dans la commande précédente :

Extrait d’un fichier de sortie généré par la commande server_config

Ici, il semble possible pour un utilisateur anonyme d’allumer ou d’éteindre des climatiseurs à distance via le serveur OPC UA détecté

Conclusion

Malgré les mécanismes de sécurité apportés par le standard OPC UA, ces derniers peuvent présenter des défauts de configuration et exposer les SI industriels de manière non-négligeable. L’outil développé par Wavestone et présenté dans cet article permet de faciliter la démarche d’audit de ces configurations et d’assurer au mieux la sécurité de ces SI industriels.

Enfin, les spécifications OPC UA proposent davantage de mécanismes de sécurité, comme la gestion des certificats par un Global Discovery Server ou de chiffrement des messages PubSub grâce à la mise en place d’un Security Key Server. Le standard OPC UA pourrait donc permettre d’effectuer des progrès supplémentaires en matière de sécurité, mais peu d’implémentations de ces mécanismes existent à ce jour.

L’outil est disponible sur notre Github : https://github.com/wavestone-cdt/opcua-scan

Cet outil a également été mis en avant lors d’une session Arsenal Lab à la conference BlackHat Asia 2023 à Singapour : https://github.com/wavestone-cdt/bhasia23-opcuhack

Cet article Un regard sur OPC UA, un protocole industriel moderne et émergent est apparu en premier sur RiskInsight.

Cependant, dans le domaine des SI industriels, on ne parle quasiment jamais de la sécurité du code automate qui contrôle le procédé industriel. Pourquoi ?

Genèse du projet

Le projet a débuté avec la présentation de Jake Browdsky lors de la conférence S4 en 2019 

Dans cette conférence, le concept de sécurisation du processus industriel par l’application de pratiques de programmation sécurisée dans le code de l’automate est discuté et plusieurs exemples sont mentionnés.

Cette idée a ensuite été transformée en un projet collaboratif par Sarah Fluchs et Vivek Ponnada, auquel plus de 900 personnes ont contribué avec leurs idées !

Automates Programmables Industriels

Les automates programmables industriels (Programmable Logic Controller en anglais) sont situés au cœur de l’automatisation, au niveau 1 du modèle de Purdue.

Représentation ISA du modèle de Purdue

Le modèle de Purdue est-il mort ? – Dale Peterson : ICS Security Catalyst (dale-peterson.com)

Les automates programmables sont des ordinateurs embarqués avec un système temps-réel qui interagissent directement avec les capteurs et les actionneurs pour surveiller et contrôler une partie du processus industriel.

Ils exécutent une boucle infinie, composée de 4 étapes :

La « logique », ou code de l’automate, peut être écrite dans différents langages, tels que définis dans la norme CEI 61131-3 :

• Ladder Diagram
• Function Block Diagram
• Structured Text
• Instruction List [désormais obsolète]
• Sequential Function Chart

Le document TOP20

Le document TOP20 est le résultat des échanges en ligne visant à identifier les 20 pratiques de programmation les plus importantes et peut être téléchargé sur le site du projet.

Comme le TOP10 de l’OWASP, il ne vise pas à décrire toutes les pratiques de programmation sécurisée possibles, du moins pour le moment.

Chacune des pratiques du TOP20 est détaillée avec les mêmes informations :

Les 20 pratiques peuvent être organisées en trois catégories principales :

Quelques exemples

Voyons un exemple de chaque catégorie. Pour cela, nous utiliserons un automate d’entrée de gamme de notre laboratoire, un feu de signalisation ainsi qu’une supervision SCADA.

Malheureusement, chaque fournisseur d’automates – et même chaque famille d’automates – utilise son propre logiciel de programmation ; les exemples présentés ici ne peuvent donc pas être copiés-collés dans le code d’une autre marque d’automates et nécessiteront une implémentation différente.

Le code de l’automate ainsi que le projet SCADA utilisé pour la démonstration peuvent être téléchargés depuis notre page github.

Règle n°13 : Désactiver les ports et protocoles de communication inutiles / inutilisés

Cette pratique consiste à durcir l’automate. La plupart des automates d’aujourd’hui offrent un support pour plusieurs protocoles industriels, ainsi qu’une variété de services supplémentaires comme un serveur de fichier FTP, un serveur web et bien d’autres.

Désactiver les services non utilisés et renforcer la sécurité de ceux qui sont activés (changer les identifiants par défaut, etc.) est une étape nécessaire pour réduire la surface d’attaque et, par conséquent, limiter le nombre de correctifs de sécurité à appliquer à l’avenir (moins il y a de fonctionnalités activées, plus les vulnérabilités sont pertinentes, facilitant l’effort pour les corriger).

Jetons un coup d’œil à la vidéo :

Règles n°6 et n°8 : Vérification des entrées au niveau de l’automate.

Ces deux règles peuvent être démontrées dans le même exemple car elles suivent le même principe : ne pas faire aveuglément confiance aux entrées externes ! Pour quelqu’un comme moi qui a fait sa part de test d’intrusion d’applications web, je ne pourrais être plus d’accord !

Les plages valides pour les valeurs d’entrée sont souvent mises en œuvre au niveau SCADA, laissant la possibilité à un attaquant d’écrire directement une valeur hors plage dans le bon registre de l’automate.

Cela est particulièrement vrai pour les compteurs et les chronomètres, qui doivent être vérifiés pour s’assurer qu’ils sont supérieurs ou égaux à zéro, et que la valeur est inférieure à une limite supérieure qui a du sens pour le processus.

Jetons un coup d’œil à la vidéo :

Surveillance de l’automate programmable règles n°2 et n°5

Nous pouvons exploiter les données opérationnelles de l’automate pour essayer de détecter des situations anormales qui pourraient être des incidents de cybersécurité.

État de l’automate

S’assurer que l’automate est en mode « RUN » est essentiel pour la sûreté et la sécurité des opérations. Un automate à l’arrêt pourrait empêcher l’IHM SCADA d’afficher les bonnes informations à l’opérateur, ce qui entraînerait de mauvaises décisions.

De même, des fonctions telles que le « forçage » des entrées et des sorties peuvent empêcher l’IHM SCADA d’afficher l’état réel du processus, et doivent être détectées et clairement affichées à l’opérateur.

Jetons un coup d’œil à la vidéo :

Cette technique peut également être utilisée pour détecter les automates en mode « PROGRAM », ce qui permet de programmer l’automate à distance.

Firmware de l’automate et version du code

Ne serait-il pas formidable de pouvoir interroger la version du firmware de votre automate directement à partir d’un registre Modbus ? Eh bien, c’est possible !

En outre, sur notre automate, nous pouvons également obtenir une somme de contrôle du code de l’automate, ce qui signifie que nous pouvons détecter si quelqu’un a altéré le code de l’automate, déclencher une alarme et enquêter si nous ne pouvons pas faire correspondre cela à une entrée dans le registre de gestion des modifications.

Jetons un coup d’œil à la vidéo :

Alors, que pouvez-vous faire ?

Le document sur le top 20 est facilement disponible, mais comment l’utiliser ?

Si vous souhaitez en savoir plus sur la sécurité du code automate, vous pouvez également consulter le contenu que nous avons présenté lors de nos ateliers à DEFCON et BruCON sur notre page Github.

Cet article Top 20 Secure PLC Coding Practices est apparu en premier sur RiskInsight.

Le secteur de l’énergie est composé d’infrastructures considérées comme vitales et assure des services essentiels pour un pays. Le secteur, marqué par une digitalisation croissante, est sans conteste une cible privilégiée des cyberattaquants avec des conséquences qui peuvent toucher par rebond la quasi-totalité des infrastructures et services de notre société. Si l’approvisionnement en électricité était interrompu durant plusieurs jours, d’autres services tels que le transport, la santé, les communications, ne pourraient assurer leurs fonctions.

 Un secteur en pleine transformation

Le secteur de l’énergie amorce une transition énergétique avec l’arrivée des énergies renouvelables. Elle s’appuie également sur de nouvelle façon de gérer l’équilibrage du réseau, essentiel au secteur et qui devient de plus en plus complexe. A chaque instant, la quantité d’électricité injectée sur le réseau doit être égale à la quantité d’électricité soutirée. Cette transformation induit une augmentation du besoin de flexibilité pour assurer la sécurité de l’approvisionnement et des investissements importants sur le réseau.  C’est l’objectif de concepts comme les Smart Grids qui rendent possible le pilotage de la consommation d’énergie et son optimisation pour le consommateur.

Pour répondre à cette transformation métier, l’industrie énergétique est en pleine transformation numérique qui bouleverse les modes de production, de transformation, de stockage, de transport et de consommation de l’énergie. Les technologies de l’information et de la communication ont permis d’optimiser la chaîne d’approvisionnement dans son ensemble.

Ainsi, on remarque le déploiement d’un grand nombre de dispositifs de l’internet industriel des objets (IIOT), avec une connectivité plus importante. Cette transition a déclenché une explosion sans précédent des données. Les entreprises du secteur de l’énergie doivent maintenant être plus agiles dans leurs décisions en exploitant efficacement ces données.

Une telle transformation expose l’industrie énergétique à des risques cyber accrus. Cette situation oblige à faire de la cybersécurité une priorité du secteur de l’énergie.

Prenons un exemple concret : pilotés à distance, les éoliennes et les panneaux solaires sont par nature des objets connectés. Ils doivent être accessibles à distance et par conséquent sécurisés. Seulement, ces nouveaux projets ne prennent pas systématiquement en compte dès la phase de conceptions l’ensemble des contraintes cybersécurité et des solutions techniques associées (protocoles sécurisés, des technologies d’accès appropriés…).

Un secteur de plus en plus visé

Faisons un peu « d’archéologie » de la cybersécurité liée au secteur : la découverte de Stuxnet en 2010 a créé une onde de choc au sein de l’industrie énergétique. Cette attaque a servi de projecteur sur des vulnérabilités inconnues.

En décembre 2016, une partie des habitants de Kiev et de sa périphérie a été privée d’électricité pendant environ 1 heure dû à la déconnexion de la sous station du réseau de transport électrique de Pivnichna. L’attaque a commencé dans le cadre d’une campagne de phishing massive survenue en juillet de la même année, qui a exploité une vulnérabilité de Windows XP. La panne a été causée par la commutation à distance des disjoncteurs de manière à couper l’alimentation.

Depuis plus une année sans évènement cyber. Un autre exemple : Les énergies renouvelables sont des nouvelles cibles pour les cyberattaquants. En 2019, dans l’Utah aux Etats-Unis, un réseau éolien et solaire a subi des pertes de connexion pendant 12 heures avec le centre de contrôle de l’entreprise, ce qui a provoqué des pannes d’électricité dans les foyers aux environs. Les cyberattaquants ont exploité une vulnérabilité connue sur des pare-feu non patchés provoquant un déni de service des équipements.

En 2021, les dirigeants de Colonial Pipeline, qui relie les raffineries à travers tous les Etats-Unis, ont décidé de bloquer toutes leurs opérations de distribution suite à la propagation d’un ransomware. L’entreprise a déclaré avoir payé 4,4 millions de dollars de rançon pour que les hackeurs fournissent un outil informatique permettant de rétablir leur activité ^[1].

Le secteur de l’énergie est un des secteurs les plus visés. Selon le rapport X-Force Threat Intelligence Index 2022 ^[2], en 2021, le secteur de l’énergie s’est classé comme le quatrième secteur le plus touché, avec 8,2% des attaques observées, derrière l’industrie manufacturière, le secteur de la finance et le secteur des services professionnels.

En 2021, les ransomwares ont été le type d’attaques le plus courant contre les organisations énergétiques avec 25% des attaques. Les entreprises pétrolières et gazières sont particulièrement touchées par ce phénomène. Les attaques de cheval de Troie (RAT), de DDoS et d’usurpation d’identité en entreprise (BEC) sont aussi fortement recensées avec 17% des attaques chacune.

Alors que les cyberattaques ont dans le cas le plus fréquent une visée lucrative et d’espionnage, l’industrie énergétique est aussi confrontée à des intentions de sabotage, parfois pour des raisons géopolitiques. Certains hacktivistes peuvent également représenter une menace en s’attaquant aux infrastructures critiques. L’actualité récente de déstabilisation majeures géopolitique en cours renforce ces risques.

Le secteur de l’énergie possède des infrastructures de biens essentiels. Dans un monde de plus en plus interdépendant, toute perturbation, même initialement limitée à une entité ou une zone géographique, peut produire des effets en cascade plus larges comme présentés ci-dessous :

Chaine d’Impact-Wavestone

Afin de lutter efficacement contre ces nouvelles menaces, les états et l’Union Européenne ont adopté des règlementations contraignantes pour assurer un niveau de cybersécurité renforcé sur les installations les plus critiques.

Quel rôle pour la règlementation ?

En France, l’autorité compétente en matière de cybersécurité est l’Agence nationale de la sécurité des systèmes d’information (ANSSI). Pour répondre à l’accroissement des menaces, la stratégie de défense s’articule autour de la loi de programmation militaire depuis 2013 (LPM) afin de sécuriser les Opérateurs d’Importance Vitale (OIV). L’ANSSI insiste principalement sur des procédures d’homologation, de contrôle et de maintien en condition de sécurité des Systèmes d’Informations d’Importance Vitale (SIIV).

Au niveau européen, la volonté est aussi de protéger les organisations sensibles que sont les opérateurs de services essentiels (OSE) du secteur de l’énergie. Le point de référence pour la cybersécurité est actuellement la directive Network and Information System Security (Directive NIS). Elle a pour objectifs premiers d’accroître la coopération entre les Etats membres de l’UE, en facilitant l’échange d’informations stratégiques et opérationnelles, et d’améliorer la cyber-résilience des entités publiques et privées des secteurs essentiels tels que l’énergie. Ici, pour l’énergie, l’ENISA souhaite se prémunir des menaces de grandes envergures avec des réseaux de plus en plus transfrontaliers et interdépendants.

La complexité se trouve maintenant dans l’application opérationnelle de certaines mesures dans des milieux industriels où les équipements et moyens de production sont prévus pour durer plusieurs dizaines d’années. Ainsi, modifier les processus opérationnels d’exploitation et/ou les équipements pour y intégrer plus de cybersécurité est un réel défi. Les impacts de cette transition sont importants aussi bien en termes financier qu’en termes de modification des façons de travailler. Cela rend  le partage entre les acteurs de l’énergie d’autant plus primordial pour trouver des solutions pragmatiques et adaptées : architecture réseaux adaptés, solutions techniques compatibles avec le monde industriels, processus de gestion des vulnérabilités et mises à jour construites avec les équipes opérationnelles par exemple.

Conclusion

Compte tenu de la criticité des infrastructures, celles-ci sont des cibles de 1^er plan. Il est primordial que les acteurs métiers et cybersécurité du secteur de l’énergie communiquent sur les bonnes pratiques de cybersécurité, tirent les enseignements des précédentes attaques et contribuent à faire évoluer le niveau de protection globale. C’est dans ce contexte que le premier forum spécialement dédié aux acteurs de l’énergie « Cyber4Energy », se tiendra à Marseille le 30-31 mars 2022. Cet évènement sera l’opportunité pour les professionnels d’échanger sur les défis de la cybersécurité et les solutions spécifiques qui s’offrent au secteur.

Références :

[1] Etats-Unis : les oléoducs Colonial Pipeline ont versé une rançon de 4,4 millions de dollars à des hackeurs (lemonde.fr)

[2] X-Force Threat Intelligence Index 2022, IBM Security X-Force Threat Intelligence Index 2022 (ibm.com)

Cet article Secteur de l’énergie : Une obligation de cybersécurité face aux attaques pour garantir la fourniture de services essentiels est apparu en premier sur RiskInsight.

Dans cet article, nous vous proposons notre vision du marché et de la maturité de la cybersécurité des Systèmes d’Information (SI) industriels, ainsi que nos convictions et analyses sur le sujet.

Quelle menace pour les SI Industriels ?

En 2011, la cybersécurité des SI industriels, alors balbutiante, était arrivée d’un coup sur le devant de la scène avec l’attaque Stuxnet et la découverte de la menace étatique dans ce domaine. Pendant une décennie, les Advanced Persistant Threats (APT) ont été considérées comme étant les plus grandes menaces pour la sûreté des systèmes industriels, au travers d’attaques impressionnantes et complexes, comme la série d’attaques « Black Energy » contre le réseau électrique Ukrainien entre 2007 et 2014, ou l’attaque « Triton » contre les systèmes de sûreté d’une usine chimique en Arabie Saoudite en 2017.

Cependant, l’affaire Snake/EKANS en 2020 permet de mettre le doigt sur une tendance en constante augmentation depuis quelques années qui est l’apparition des ransomwares dans les SI Industriels. Ces ransomwares résultent d’attaques opportunistes sur des systèmes vulnérables ou sont des « dégâts collatéraux » d’attaques visant le SI de gestion, comme dans le cas de Colonial Pipeline, en mai 2021.

Avec la pérennisation du modèle économique des ransomwares d’un côté et l’apparition de SI industriels toujours plus connectés, il est réaliste d’attendre une hausse des attaques opportunistes et d’effet de bords de ransomwares sur des SI Industriels.

Devant une menace de plus en plus présente, les entreprises doivent mettre en place des mesures de cybersécurité sur les systèmes industriels et définir des caps stratégiques cohérents, mais cela demande un véritable investissement. C’est pourquoi nous avons travaillé sur cette synthèse des domaines et des solutions existantes pour sécuriser les SI industriels. Ce radar n’est pas exhaustif, mais il a pour but d’éclaircir le sujet en donnant une vision plus globale du sujet.

Méthodologie

Pendant cinq mois, ce radar a été conçu avec cinq experts en cybersécurité des SI Industriels, en plus de la centaine de consultants de l’offre de cybersécurité industrielle de Wavestone.

Ce radar dispose de deux cadrans : un cadran présentant des produits de cybersécurité spécialisés dans les SI industriels et un cadran présentant les différents domaines de la cybersécurité des SI industriels, classés par niveau de maturité

Les produits de cybersécurité industriels sont identifiés comme tels selon les critères suivants :

• Ils répondent à un besoin dans le processus de sécurisation des SI Industriels ;
• Ils sont adaptés à un environnement industriel sur les plans hardware et/ou software :
  • Le matériel est renforcé pour résister à des conditions difficiles et/ou présente une longévité importante ;
  • Les produits de sécurité réseau prennent en compte des protocoles industriels ;
  • Les produits de sécurité des terminaux sont compatibles avec des systèmes plus ou moins obsolètes.

Les domaines de cybersécurité sont également sélectionnés et évalués en se basant sur les observations de nos consultants sur le terrain, auprès de clients variés présents dans des domaines industriels tout aussi variés, mais largement ancrés dans le contexte français.

La suite de cet article revient sur certains domaines, des plus matures au plus émergents. Cette analyse fait écho à et permet de mettre à jour notre publication de 2019 sur les problématiques du maintien en conditions de sécurité des SI Industriels. En effet, si les grands sujets restent les mêmes (e.g. séparation IT/OT), les acteurs et leurs maturités évoluent très vite, amenant de nouvelles problématiques et faisant évoluer les anciennes.

Sur quels piliers s’appuyer pour sécuriser un réseau industriel ?

Ressources humaines, procédures et résilience

Les forces et les faiblesses dans les SI industriels et dans les SI de gestions sont différents. Pour mettre en place des mesures de cybersécurité efficaces dans un SI industriel, il faut d’abord comprendre les leviers déjà présents dans les SI Industriels qui peuvent être utiles dans une démarche de sécurisation cyber.

Tout d’abord, les opérateurs dans les réseaux de production industriels connaissent très bien les procédés et le fonctionnement habituel du système de production. De plus, les procédures en cas d’incident sont beaucoup plus développées que dans le cas des SI de gestion. L’un dans l’autre, ces éléments permettent de détecter efficacement les dysfonctionnements et de réagir de manière appropriée. Une mesure intéressante à mettre en place est donc de développer cette capacité de résilience en ajoutant des procédures de détection d’incidents cyber en se basant sur les connaissances actuelles des équipes.

Connaissance du réseau

Connaitre son réseau facilite la sécurisation du SI, permet le maintien en conditions de sécurité en permettant l’analyse des risques, la segmentation du réseau, la gestion des vulnérabilités et des patchs, la conformité règlementaire, etc.

Il est possible de réaliser cet inventaire exhaustif à la main sur un base régulière, notamment en se basant sur les outils de maintenance industrielle. Pour aller plus loin, il est possible d’automatiser la tâche grâce à des outils de cartographie gratuits (Dragos CyberLens, GrassMarlin). Enfin, des sondes (Nozomi, Claroty, Dragos, etc.) permettent d’aller beaucoup plus loin en automatisant la détection d’anomalies sur le réseau voire en aidant à la réponse à incident.

Sauvegarde et restauration

La meilleur arme de résilience contre les ransomwares est la sauvegarde systématique et si possible hors ligne des données critiques pour le système de production. C’est d’ailleurs une pratique de plus en plus courante dans les SI Industriels.

Toutefois, des conditions supplémentaires sont nécessaires pour que les sauvegardes soient vraiment utiles. Premièrement, il faut cerner toutes les données nécessaires au fonctionnement du système. Ces données peuvent être des données techniques (configuration des machines par exemple) ou des données métier et peuvent être identifiées avec le métier notamment lors d’une analyse de risques. Enfin, il faut s’assurer de sa capacité à restaurer un système fonctionnel à partir des sauvegardes effectuées, notamment pour les systèmes certifiés.

Quelles sont les opportunités en 2021 ?

Notre étude nous a permis de mettre en évidence des mesures efficaces pour augmenter le niveau de sécurité d’un SI industriel.

Segmenter son réseau

Bien que ce sujet soit présent depuis plusieurs années, la segmentation réseau est une étape importante à passer pour sécuriser un réseau industriel. Elle permet de prévenir très efficacement la propagation d’une attaque et donc son impact.

Outre l’utilisation de pare-feu adaptés, un projet de segmentation du réseau repose sur des équipes d’architecture et d’intégration compétentes et disposant de temps et de moyens suffisants. La segmentation d’un réseau est un équilibre à trouver entre la sécurité et les besoins métiers. L’utilisation des nouvelles technologies réseau « Software Defined » peut permettre la mise en œuvre de cette segmentation de manière plus agile.

Séparer le réseau de gestion et le réseau industriel

L’ouverture des SI industriels aux SI de gestion est aujourd’hui nécessaire mais est également un vecteur de risques.

Les solutions à mettre en œuvre dépendent de la criticité du réseau industriel et des flux nécessaires entre les deux réseaux. Il faut privilégier un unique point de passage entre les deux réseaux afin de pouvoir garder le contrôle sur cette interface particulièrement critique.

Un éventail complet de produits existe, du pare-feu à la diode de données. Le mieux étant d’assembler plusieurs de ces solutions au sein d’une DMZ, pour bien maitriser les services qui peuvent communiquer entre les deux réseaux.

La séparation IT/OT va bien au-delà de la question du réseau, abordée ci-dessus. Sur le plan de l’identité, il faut également aborder la séparation de l’Active Directory (AD) entre le réseau de gestion et le réseau industriel. D’un point de vue sécurité, le mieux est de séparer ces deux AD pour éviter la propagation des attaques si les ressources sont disponibles. Toutefois, les AD peuvent également être reliés en contrôlant de très près les flux autorisés et/ou en prévoyant des solutions de remédiation en cas de compromission d’un des deux AD.

Identifier les utilisateurs du réseau

Une particularité de la gestion de l’identité dans un SI industriel est la présence marquée de postes partagés. Dans cette situation, une solution adaptée doit permettre à plusieurs utilisateurs de travailler sur la même machine de manière authentifiée permettant ainsi d’identifier les actions de chacun.

Dans ce cas, le modèle où chaque utilisateur dispose de sa propre session Windows n’est pas adapté. Une solution possible est de mettre en place une session Windows générique sur laquelle l’utilisateur s’authentifie de manière simple et rapide grâce à un badge et un logiciel de Fast Switching.

Quels sont les prochains grand chantiers de la cybersécurité des SI industriels ?

SOC

Les Security Operation Centers (SOC) spécialisés dans les SI industriels sont en train d’émerger chez plusieurs Managed Security Services Providers (MSSP). Toutefois, il ne faut pas considérer ces SOC comme des solutions miracles : c’est avant tout en connaissant votre métier et toutes ses particularités que le SOC pourra être efficace.

Un aspect capital lors de la mise en place d’un SOC industriel est de bien cerner un périmètre à la mesure de la maturité cyber du SI. Dans un SOC cyber industriel, seuls les incidents cyber doivent être traités, sans considération pour les événements purement opérationnels classiques, qui sont déjà pris en charge par le système de supervision métier.

Sécurité des tiers

La gestion de la Supply Chain, en IT comme en OT, est en train de devenir un des sujets cyber les plus importants. L’attaque de REvil contre Kayesa et ses clients en juillet 2021 donne une idée des possibilités offertes par une attaque de la Supply Chain : l’attaque change d’échelle et peut toucher des centaines voire des milliers d’organisations d’un coup. Evidemment, les SI industriels font également appel à des tiers et ne sont donc pas à l’abri. On pourrait imaginer la compromission d’un fournisseur d’automate par exemple.

Les attaques sur les tiers peuvent prendre différentes formes, dont voici quelques exemples :

• Accès au SI suite à la mise à jour d’un logiciel ;
• Pillage des données stockées chez un tiers ;
• Accès au SI via un accès distant, par exemple utilisé par le tiers pour faire de la maintenance

Afin de se protéger de ces attaques, il convient de connaitre ses fournisseurs et le risque lié à chacun d’entre eux. Les tiers à risques peuvent ensuite faire l’objet de mesures pour réduire les chances de compromission comme un Plan Assurance Sécurité (PAS) ou des audits réguliers.

Les accès distants au SI peuvent être contrôlés par des solutions de bastion ou de gestion des accès privilégiés (PAM), qui permettent de surveiller toutes les actions faites par le tiers et de gérer finement ses droits. Toutefois, cette solution peut être contraignante et il convient de prendre en compte le besoin de l’utilisateur pour proposer la solution la plus pertinente.

Cloud

Encore principalement cantonné à des fonctions annexes telles que la gestion des stocks et de l’approvisionnement, le cloud fait petit à petit son arrivée dans les SI industriels avec le développement de l’industrie 4.0, en permettant par exemple d’avoir une gestion plus globale des terminaux IoT dans les sites de production ou d’optimiser le dimensionnement des serveurs.

Mais cette arrivée pose aussi des problèmes de sécurité. Certaines de ces problématiques ont déjà été traitées avec la démocratisation du cloud dans les SI de gestion, mais d’autres sont encore à résoudre. Comment gérer la sécurité des terminaux IoT ? Comment intégrer des systèmes cloud dans des environnements critiques, très réglementés ? A qui sont confiées les données et quelle règlementation s’applique ?

Cet article Quelles sont les tendances et les enjeux en cybersécurité industrielle en 2021 ? est apparu en premier sur RiskInsight.

Notre méthodologie d’audit

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

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

Rappel de l’état de la menace

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

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

Spécificité du secteur industriel

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

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

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

Il apparait donc que :

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

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

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

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

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

Impliquer les équipes industrielles

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

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

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

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

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

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

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

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

Il est notamment possible de citer :

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

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

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

Lister ses flux internes

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

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

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

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

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

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

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

Evaluer le réel besoin de ses flux

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

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

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

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

Préparer ses postures de repli

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Que faut-il sauvegarder pour pouvoir restaurer ses automates ?

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

Posséder une copie à jour de ses programmes automates

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

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

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

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

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

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

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

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

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

Identifier ce qui est vraiment nécessaire

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

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

Sauvegarder intelligemment

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

Ne pas négliger la documentation et l’entrainement

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

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

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

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

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

Conclusion

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

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

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

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

Eléments clés

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

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

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

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

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

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

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

Notre vision du produit : une solution aux multiples fonctionnalités

Description

Une sonde OT est un équipement, virtuel ou physique, connecté au système d’information afin de le cartographier et de le surveiller. Elle se compose de capteurs répartis dans le réseau pour collecter les données et d’un équipement central pour corréler ces données.

Une sonde se caractérise par :

• Son mode de fonctionnement ;
• Le positionnement de ses composants ;
• Ses méthodes de détection d’attaque ;
• Son bouquet de fonctionnalités.

L’illustration ci-dessous fournit plus de détails sur chacun de ces items :

Figure 1 : Caractéristiques principales d’une sonde OT

Fonctionnalités principales

Les fonctionnalités de ces sondes OT sont essentielles pour leurs utilisateurs. L’illustration ci-dessous présente un résumé des principales fonctionnalités identifiées :

Figure 2 : Fonctionnalités principales d’une sonde OT

Des fonctionnalités plus avancées apparaissent également sur certains produits telles que le management centralisé de plusieurs sites, la fourniture de guides d’investigation, la recherche de vulnérabilité… D’après nos observations, les solutions du marché tendent vers les mêmes objectifs en termes structurels et fonctionnels. Les différences apparaissent plutôt au niveau de l’intégration globale de la sonde aux offres des fournisseurs.

Notre vision du marché : un marché en cours de consolidation

Des acteurs nombreux et variés

Nos études nous ont permis de mettre en avant un peu plus d’une vingtaine d’acteurs aux profils divers sur le marché des sondes OT. Sur les cinq dernières années, des acteurs sont apparus, d’autres ont disparu, des partenariats se sont construits et les solutions ont continué d’évoluer. Tous ces éléments indiquent un marché encore en cours de consolidation.

Figure 3 : Notre connaissance du marché

Des acteurs qui adoptent des approches différentes

Comme on peut s’y attendre d’un marché si varié, différentes approches se dégagent concernant le modèle de vente. Certains acteurs mettent plus l’accent sur leur produit en tant que tel, tandis que d’autres soulignent son intégration dans leurs catalogues de services (threat intelligence, SOC, CSIRT…) ou de produits complémentaires. Ces approches influent naturellement sur le contact entre les acteurs et leurs clients : plus l’offre mettra en avant un service plus l’acteur cherchera à avoir un contact direct avec son client.

Notre vision du terrain : un besoin de maturité

Nos retours

Au départ au moins, nous recommandons de se focaliser sur les sites et process critiques pour des raisons d’économies de temps, de finances et de compétences. De plus, afin de proposer une détection comportementale pertinente, les sondes nécessitent un temps d’apprentissage non négligeable dépendant du site sur lequel elles sont déployées (identification des faux-positifs, faux-négatifs, accumulation de données pour l’apprentissage…). A ce temps s’ajoutent d’importants besoins en ressources humaines, lors de cette phase d’apprentissage, mais aussi plus tard lors de l’utilisation quotidienne du produit (gestion des alertes essentiellement). Il sera aussi important de mettre en lien les équipes de gestion de la sonde et les équipes de réponses aux incidents afin de traiter les incidents avérés détectés par la sonde.

En amont du déploiement, le positionnement des sondes est à étudier. En effet, il sera à la fois la clef d’une cartographie complète et d’une surface de détection optimale. Ces premières réflexions doivent adresser des points importants tels que la compatibilité matérielle (des switches par exemple) avec les sondes et l’architecture du site (dont peut dépendre le nombre de sondes). En plus de fournir un inventaire en temps réel, la cartographie peut aider à implémenter ou à revoir la segmentation du réseau, étape indispensable à un projet de sécurisation. La phase de qualification doit aussi permettre de vérifier que la sonde choisie comprendra l’intégralité des protocoles industriels utilisés et de discuter du traitement des flux chiffrés, s’il y en a.

Enfin, bien sûr, ce genre de projet ne peut pas être mené sans l’intégration, dès le début, des équipes OT.

Un certain nombre de nos clients s’arrêtent à la phase de tests, mais d’autres ont commencé à déployer des sondes sur leurs sites critiques voire sur l’ensemble de leur système d’information industriel. Les raisons avancées en cas de non-déploiement sont notamment liées aux : coûts, charges et compétences nécessaires. La souveraineté d’une sonde de détection peut aussi être une question importante dans certains environnements.

Des limites identifiées

En plus des points précédents, des limites techniques peuvent elles-aussi apparaître. Des enjeux de bande passante et de surcharge réseau, induits par la collecte de logs, peuvent être anticipés. De plus, une sonde OT est par nature limitée aux échanges réseaux, ses résultats (menaces détectées, évaluation du niveau de sécurité…) sont donc à relativiser par rapport aux ressources à sa disposition.

Enfin, les sondes assurent la détection. En revanche, la réaction doit être portée par d’autres moyens, humains ou technologiques. Plus généralement, avec leurs nombreuses fonctionnalités intéressantes, les sondes sont complémentaires des bonnes pratiques de sécurité telles que : la mise en place d’antivirus et de pare-feu, l’implémentation d’un puit de logs et des configurations de collecte adéquates, la construction d’une documentation réseau, l’instauration d’équipes dédiées SOC et CSIRT… Toutes ces pratiques restent de vigueur et permettront d’exploiter pleinement les capacités des sondes.

Figure 4 : Nos principaux retours sur le déploiement d’une sonde OT

Conclusion

Les sondes offrent un panel de fonctionnalités qui répond à des besoins réels. Nos rencontres nous indiquent que les acteurs du marché continuent de prendre en considération les besoins qui leur sont remontés afin d’améliorer leur produit. Malgré un marché en cours de consolidation, les acteurs semblent techniquement converger vers des produits finaux extrêmement semblables. Les différences se joueront sur des détails d’ergonomie, sur les approches adoptées par chacun et sur les coûts.

Nos premiers retours montrent l’importance de la charge et des compétences nécessaires pour l’utilisation d’une sonde. Si elles peuvent avoir une utilité dans un contexte peu mature, afin d’aider à la connaissance du système et à la mise en place d’une bonne hygiène réseau, elles ne révèlent vraiment leur potentiel qu’une fois qu’elles s’intègrent pleinement dans l’arsenal des équipes de détection et de réponse aux incidents, ce qui correspond à un contexte fortement mature. Ainsi, il semble plus prioritaire de suivre les bonnes pratiques énoncées précédemment afin de gagner en maturité puis de songer au déploiement d’une sonde dans un second temps.

1 : Voir https://en.wikipedia.org/wiki/Purdue_Enterprise_Reference_Architecture

2 : Voir https://fr.wikipedia.org/wiki/Miroir_de_port

3 : Voir https://fr.wikipedia.org/wiki/TAP_r%C3%A9seau

Cet article Les sondes de détection en milieu industriel, notre vision du marché est apparu en premier sur RiskInsight.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Résumons de manière un peu simpliste :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[4] Maintien en Conditions de Sécurité

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

La couverture des risques dans la durée

Le durcissement des équipements

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

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

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

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

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

Le maintien en conditions de sécurité

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

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

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

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

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

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

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

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

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

La mise en place de la détection

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

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

L’anticipation de risques spécifiques

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

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

Se préparer à la remédiation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La prise en compte des mainteneurs externes

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

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

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

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

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

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

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

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

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

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

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

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

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

[9] SSH i.e. Secure Shell

[10] RDP i.e. Remote Desktop Protocol

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La particularité des SI de sureté   

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

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

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

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

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

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

[3] DMZ i.e. Demilitarized Zone.

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

Le développement rapide du véhicule autonome et connectée indique qu’il est urgent de mettre en œuvre des mesures pour réduire le risque cyber.

Dans un premier temps, ces mesures consistent à adapter des concepts de cybersécurité connus et maitrisés tout en s’adaptant à un environnement nouveau, dans un contexte marché ultra-concurrentiel et confronté à des usagers de plus en plus exigeants.

Dans un second temps, il s’agit de mettre sous contrôle des systèmes critiques intelligents, interactifs, et ce en temps réel afin de se prémunir d’attaques évolutives, de plus en plus sophistiquées et difficiles à anticiper.

Des concepts de cybersécurité connus… mais qui doivent tenir compte des contraintes propres aux systèmes embarqués

La course à l’innovation autour du véhicule connecté conduit à la mise en œuvre de plus en plus de services, ce qui augmente le niveau d’exposition du véhicule à de nombreuses menaces – adeptes du car tuning, hacktivistes, organisations criminelles, gouvernements etc.

La mise sur le marché de nouveaux modèles de véhicules pourrait être conditionnée par sa capacité à se protéger des cybermenaces. En effet cette protection pourra s’appuyer sur des incontournables de la cybersécurité tels que : la gestion des identités et des accès (authentification forte, infrastructure PKI…), la segmentation des réseaux et le regroupement par actifs critiques (Firewall, Gateway…), le chiffrement des données et des communications (via un réseau Ethernet, des environnements d’exécution protégés), la détection et la supervision des composants critiques (SIEM embarqué, sonde de sécurité IPS/IDS…).

Contrairement à un système d’information d’entreprise, un véhicule connecté est un produit contenant un système pouvant s’apparenter à un système d’information à espace fini, à prix fixe et en mouvement. Autant de contraintes différentes de celles d’un SI classique qui complexifient sa sécurisation. Celle-ci doivent être prises en compte au plus tôt, dès la phase de conception du véhicule :

• Le coût du véhicule – Des solutions cybersécurité connues certes, mais qui doivent néanmoins s’intégrer dans un système initialement mécanique/électronique où le coût de chaque pièce doit être justifié afin de ne pas trop augmenter le Prix de Revient à la Fabrication (PRF). L’important étant de maintenir un équilibre coût/risques acceptable pour garantir la sécurité de l’usager.

• La dimension et le poids du véhicule – L’encombrement et le poids sont les deux principaux ennemis des solutions de transport. L’intégration de composants embarqués et de modules de cybersécurité supplémentaires peut amener à une modification des architectures physiques des véhicules. Mais l’évolution d’un véhicule n’est pas aussi aisée que celle d’un système d’information classique ; au vu du contexte une approche modulaire permettant l’ajout de capacité hardware dès la phase de conception pourrait être envisagée.

• La capacité de calcul en temps réel – Selon la criticité des composants du véhicule, il pourra être décidé d’y sécuriser certaines communications (via chiffrement, signature). Une analyse fine et une priorisation des échanges à protéger sont préconisées, les mécanismes de cryptographie étant très consommateurs en ressources et puissance de calculs.

• L’expérience utilisateur – Les constructeurs automobiles ont toujours cherché à développer le concept de confort et de plaisir de la conduite. L’intégration de la cybersécurité dans le véhicule ne doit pas aller à l’encontre de ce principe et nombre d’utilisateurs ne sont probablement pas prêts à accepter la cybersécurité au détriment de leur expérience de conduite. Ainsi, il paraît difficilement envisageable de demander à un conducteur d’entrer un mot de passe à chaque démarrage du véhicule, encore moins de configurer un nouvel utilisateur pendant plusieurs minutes à chaque fois qu’il prête son véhicule. Les problématiques de cybersécurité permettent d’identifier de nouveaux usages et de se positionner au service de l’expérience utilisateur. Cela peut conduire au développement de solutions innovantes comme l’authentification de l’usager via smartphone ou la délégation de droits d’accès au véhicule via une application.

• La mobilité et la connectivité – La détection d’incidents et la supervision des composants critiques du véhicule nécessitent une disponibilité et une remontée des logs en continue.  Sachant qu’un véhicule en mouvement peut être amené à se retrouver dans une zone à couverture réseau limitée (voir nulle), ces problématiques de connectivité amènent à concevoir des systèmes de supervision et détection directement intégrés au véhicule. De manière générale, face à la perte de connectivité, la résilience doit être généralisée à l’ensemble des fonctions (cyber ou non) du véhicule.

• Le cycle de vie – La durée de vie peut varier d’un véhicule à l’autre, historiquement basée sur l’usure mécanique que subissent les voitures. Désormais le véhicule c’est aussi un ensemble de composants électroniques et de services qui doivent s’adapter à un cycle de vie long. Chaque système et solution informatique incorporés au véhicule doivent être conçus pour fonctionner et être supportés dans la durée. Le défi que devront relever les constructeurs est de contrôler l’obsolescence et maintenir en condition opérationnelle leur parc automobile. Le développement des systèmes de mise à jour Over-The-Air (OTA) deviendra une nécessité pour le déploiement des patchs et correctifs de sécurité.

Les principaux enjeux de cybersécurité

La (cyber)sécurité des véhicules n’est pas qu’une affaire de solutions techniques

Convergence de l’ingénierie automobile et du digital

Le croisement des univers de l’ingénierie et du service devient un sujet prioritaire chez les constructeurs automobiles, provoquant certains changements dans leur cœur de métier. La gouvernance doit évoluer en prenant en compte un certain nombre d’actions indispensables à la sécurisation de leurs véhicules et plateformes de services.

Il est important de s’assurer que la cybersécurité soit pensée et intégrée dans l’ensemble des étapes du projet tout en disposant des ressources et compétences nécessaires.

La mise en circulation d’un véhicule impose aussi de gérer lors de cette phase des problématiques de maintien en condition opérationnelle et de sécurité des systèmes développés, qu’ils soient embarqués ou débarqués (plateforme de services connectés). Ainsi les constructeurs opèrent dans un environnement qui les positionne, à la fois, en fournisseur de produit mais aussi de services automobiles.

On constate que le temps moyen de développement et d’intégration d’un véhicule est d’environ 3 à 5 ans, là où il faut quelques mois pour développer et mettre en production un nouveau service (connecté).

De fait, pour faire face à un marché toujours plus concurrentiel ; les architectures développées du véhicule doivent être en capacité de supporter l’approvisionnement régulier de nouveaux services tout au long du cycle de vie. Il sera nécessaire de garantir un maintien du niveau de sécurité, de sureté et de qualité du véhicule.

Ainsi, on peut logiquement s’attendre à une transformation des scénarios de développement et d’intégration, avec un véhicule qui voit sa plateforme devenir plus modulaire, plus évolutive pour réduire ce fameux « time-to-market ». Les services quant-à-eux se verront soumis à un développement Agile avec un temps de mise en production plus flexible afin que les mondes de l’ingénierie et du service soient de nouveau « synchronisés » et puissent travailler en synergie.

Le ruissellement de la cybersécurité des constructeurs aux fournisseurs

La question de la responsabilité en cas d’accident lié à une cyber attaque ou à un incident système devient également un sujet urgent à adresser. En effet, par défaut la responsabilité de l’accident serait attribuée au système assurant le déplacement sécurisé de la voiture. Le constructeur automobile, créateur du système, devrait en assumer la défectuosité (conformément à la partie responsabilité du fait des produits défectueux issu de la loi n°98-389 du 19 mai 1998). C’est pourquoi les constructeurs (ou OEMs – Original Equipment Manufacturer) auront la responsabilité de s’assurer que les fournisseurs de rang 1 (Tiers-1) et plus, s’engagent eux aussi dans une démarche d’intégration de la cybersécurité dans les produits fournis. La sécurité de bout-en-bout du véhicule ne pourra être assurée que par la déclinaison d’exigences de sécurité sur l’ensemble de la chaine fournisseur., intégrées dans les cahiers des charges, renforcées au sein des contrats et vérifiées à la livraison.

La problématique de la cybersécurité dans l’écosystème automobile est prise très au sérieux par les instances internationales et plus particulièrement par la Commission Economique pour l’Europe des Nations Unies qui entend faire de la nouvelle norme, l’ISO/SAE 21434, une base commune de référence que l’ensemble des acteurs de cet écosystème devront respecter. Cette norme encore en cours d’élaboration fera l’objet d’un prochain article.

Cet article Saga 3/3 : La sécurité des véhicules connectés, les réponses pour une transformation nécessaire ! 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.

De ce fait, la surface d’attaque des véhicules s’élargie, ceci les exposant à de nouveaux risques qui peuvent compromettre la sécurité des passagers mais aussi des personnes aux alentours du véhicule qui subirait une cyberattaque. En effet, de nombreux chercheurs ont déjà réussi à faire aboutir différentes attaques sur des véhicules récents du marché et ont même pu en prendre totalement contrôle.

Dans le monde de l’automobile connectée, quels types d’attaques ont pu aboutir à ce jour ? Quels sont les vecteurs de ces attaques ? Et quels sont les motifs de ceux qui les réalisent ?

Un large panel de cyberattaques déjà réalisées sur les voitures connectées et autonomes…

Au cours des dernières années, des vulnérabilités aussi nombreuses que variées ont été découvertes par des chercheurs sur les véhicules connectés. En 2015, deux études particulières ont généré une large couverture médiatique, amenant le sujet de la sécurité des véhicules connecté sous les feux des projecteurs.

La première a été réalisé par les chercheurs Américains Charlie Miller et Chris Valasek, qui ont réussi, à distance, à compromettre la plateforme embarquée du groupe Fiat Chrysler leur permettant de prendre le contrôle de nombreuses fonctions telles que le réglage du volume de la radio et même la possibilité d’actionner les freins. La porte d’entrée de leur attaque était le point d’accès à internet Uconnect  qui est utilisé pour contrôler le système de navigation et de divertissement des voitures. En compromettant l’accès internet, ils ont pu rebondir sur la carte à puce d’un boitier de contrôle du système de divertissement et réécrire le code source en y intégrant leurs fonctions malveillantes sans être détectés. A l’aide de ce composant corrompu, ils ont été capables d’envoyer des commandes via le réseau interne du véhicule (le CAN-bus) à différents éléments physiques tels que le moteur ou les roues. Suite à la présentation de la vulnérabilité et des scenarios d’attaque par les chercheurs, Fiat Chrysler a du patcher 1,4 millions de véhicules en envoyant des clés USB à tous les clients concernés pour qu’ils puissent corriger eux même le défaut de conception de leur véhicule.

© ANDY GREENBERG/WIRED

La seconde a concerné une Tesla Model S. Outre les cyberattaques rendues possible grâce à un accès physique ou une connexion distante, d’autres ont elles visé les capteurs utilisés dans de nombreux véhicules pour détecter d’éventuels obstacle et analyser leur environnement². En effet, en 2016, des chercheurs Chinois ont montré comment attaquer la Tesla Model S via ses différents capteurs : Radars à ondes millimétriques (Radars MMW), cameras LiDAR, , capteurs ultrasons, etc. Ils ont présenté les scenarios d’attaque suivants :

• Brouillage de signal des radars MMW : utilisation d’un transmetteur réglé sur la même fréquence que celle du récepteur du véhicule et avec le même type de modulation permettant de neutraliser tous les signaux envoyés au récepteur. Durant cette attaque (« évaporation d’obstacle »), le véhicule est incapable de détecter les obstacles présents sur sa route et donc de les éviter.

A travers le monde, les équipes de chercheurs ont donc réussi à faire aboutir des cyberattaques variées sur des véhicules modernes de différents constructeurs, qui sont résumées sur la frise chronologique ci-dessous.

Il y a 6 vecteurs d’attaque principaux pour les véhicules connectés et autonomes :

Les véhicules récents peuvent se connecter aux réseaux 3G/4G et fournissent des accès Wi-Fi et Bluetooth aux passagers. Ces technologies sont des standards qui présentent des vulnérabilités : de nombreuses attaques sur ces réseaux de communication sont belles et bien connues. Il est facilement possible d’imaginer un attaquant qui pénètre à distance le réseau local du véhicule, ceci en utilisant ces canaux de communication ou en réalisant une attaque “Man-In-The-Middle”, afin de dérober des données personnelles, altérer des services voire même prendre le contrôle de certaines commandes comme vu précédemment.

De plus, il est possible de se connecter directement au véhicule. En effet, toutes les voitures ont un port ODB utilisé à des fin de diagnostique lors de l’entretien et les plus modernes équipées de systèmes de divertissement dernière génération offrent des ports USB. Ces accès physiques représentent une porte ouverte pour les attaquants leur permettant de mener à bien des actions malveillantes aux conséquences lourdes : Blocage d’une partie ou de l’ensemble des systèmes dû à un ransomware, fausses informations envoyées via le réseau interne, altération de l’unité de commande électronique par un malware, etc.

A l’avènement des véhicules autonomes, de nouvelles techniques d’attaque sont à considérer. La conduite autonome repose sur de nombreux capteurs en interaction continue avec leur environnement, dans le but de collecter les informations relatives à la route, au trafic, etc. Les attaques visant ces capteurs peuvent avoir des impacts dramatiques. En effet, le détournement des fonctions primaires des capteurs ou des infrastructures routières par des personnes malintentionnées, peut mener à des accidents. Par le passé, des accidents mortels ont eu lieu, dus à des défauts d’interprétation des capteurs : dans le cas le plus récent, la caméra de la voiture n’a pas pu détecter un camion blanc, éblouie par le soleil rasant.

Nous le constatons, les voitures deviennent un point de connexion central avec l’internet des objets. Les services fournis par les Smartphones (Apple Car, Android Auto)  et autres appareils, deviendront à leur tour vecteurs d’attaques. Par exemple, une authentification compromise gérée par le Smartphone connecté au véhicule, pourrait donner un accès illimité à des fonctionnalités physiques (déverrouillage des portes, ouverture du coffre, etc.).

En fonction du vecteur utilisé, les attaques peuvent être catégorisées et :

• Peuvent affecter un seul véhicule ou une flotte entière, ce qui en augmenterait l’impact ;
• Peuvent être réalisées à proximité du véhicule mais également à distance, ceci changeant les possibilités des attaquants et contribuant à augmenter la complexité de l’attaque.

Capteurs, IoT, réseaux publics et privés, les véhicules connectés et autonomes sont un concentré de technologies.  Ils constituent donc un large terrain de jeu pour les attaquants déjà aux aguets ! Mais quelles sont les motivations qui les poussent à perpétrer ces attaques ?

Quelles peuvent être les motivations derrière de telles cyberattaques ?

Les motivations sont en effet diverses et variées, nous les représentons ci-dessous suivant 5 catégories :

• Idéologie : De nombreuses organisations militent contre l’industrie automobile, ce qui pourrait les amener à lancer des attaques contre les véhicules connectés et autonomes. Par exemple, une organisation de protection de l’environnement qui détournerait le système de divertissement pour passer des messages militants ou perturber le fonctionnement des véhicules pour les immobiliser.
• Financières : Des hackers peuvent perpétrer des attaques basiques comme voler des données du véhicule dans le but de les revendre ou de les utiliser. Par exemple pour avoir un accès gratuit à un service de streaming de musique en piratant le système de divertissement.
• Déstabilisation : Des attaques peuvent être lancées sur de nombreux véhicules afin de perturber leur fonctionnement ou de les immobiliser. Par exemple, le cas d’un état qui ferait une tentative de déstabilisation d’un ennemi ou un concurrent qui voudrait dégrader l’image d’un constructeur.
• Meurtre : La possibilité de prendre un contrôle total sur un ou plusieurs véhicules pour mettre en danger la vie de personnes en les utilisant comme des armes peut être considérée par des organisations criminelles et terroristes.
• Obtention de moyen d’attaque : Les véhicules vont devenir des systèmes informatiques très sophistiqués avec une très grande puissance de calcul. Si des vulnérabilités sont exploitées, les voitures pourront être utilisées pour espionner les utilisateurs ; leur puissance de calcul peut aussi servir lors d’attaques brut force ou comme botnet lors d’attaques DDOS.

Les véhicules modernes disposent de nombreuses façons de se connecter via des systèmes externes vulnérables : Bluetooth, Wi-Fi, USB, etc. Avec le développement des véhicules autonomes, des plateformes de service et les infrastructures routières connectées, la surface d’attaque des véhicules va considérablement augmenter de la même manière que les impacts associés qui vont devenir très sérieux et dangereux pour les utilisateurs. De ce fait le piratage des véhicules va attirer de plus en plus d’attaquants, se généraliser et se sophistiquer.

Il est devenu urgent d’adopter une approche détaillée pour sécuriser les fonctions vitales du véhicule assurant la sécurité des passagers. Les mesures de sécurité et l’organisation de la cybersécurité déployées s’inspirent du monde de l’IT mais doivent être adaptés au secteur de l’automobile. Dans ce contexte, des start-ups sont en mesure d’apporter des solutions aux challenges techniques et réglementations telle que l’ISO21434, en cours de développement, posant un cadre global pour augmenter le niveau de sécurité des véhicules connectés. Mais concrètement, quelles sont ces solutions et comment protègent-elles les véhicules des cyberattaques ? Patience, nous vous le présenterons très prochainement !

Cet article Saga 2/3 : La voiture connectée, route semée d’embûches (…et de failles de sécurité) est apparu en premier sur RiskInsight.

Cette saga se propose de vous présenter dans un premier temps le véhicule connecté et les défis cybersécurité associés ; les principales sources de menace et les risques seront abordés lors d’une prochaine publication. Enfin, un troisième article vous présentera nos convictions et premiers éléments de réponse pour y faire face.

La voiture connectée : un objet au cœur d’interactions multiples

Divertissement, extension du smartphone, mobilité partagée, gestion de vie de la voiture … Les utilisateurs sont demandeurs de nouvelles expériences et ces services et applications engendrent de multiples interactions. On peut ainsi imaginer une voiture communicante capable de trouver une place de parking libre, planifier automatiquement un rendez-vous pour sa maintenance ou déclencher un feu au vert à son passage. Depuis le 1^er avril 2018, tous les nouveaux modèles de véhicules doivent d’ailleurs posséder un système d’appel d’urgence et de géolocalisation pour contacter les secours en cas d’accident. A ce titre, ils sont déjà « connectés ».

Les constructeurs et autres acteurs se saisissent déjà de cette opportunité de maintenir une relation étroite avec les clients tout au long du cycle de vie du véhicule. Ils deviennent ainsi des « fournisseurs de services et de solutions mobilités », s’appuyant entre autres sur les données collectées. D’autant plus que cette connectivité constitue une étape vers l’autonomie, le véhicule ayant besoin de pouvoir communiquer avec ses homologues et avec l’environnement. Le mouvement est en marche et va s’amplifier progressivement.

Cependant, le constat est aujourd’hui sans appel : la problématique de cybersécurité n’est pas ou peu prise en compte, alors qu’elle doit être partie intégrante de la solution connectée, dès sa phase conception et jusqu’à la fin du cycle de vie. Cette réflexion est essentielle pour réussir à préserver l’intégrité du véhicule, la vie des passagers et respecter les réglementations en vigueur et à venir.

Le premier prérequis consiste à correctement appréhender les technologies et l’écosystème du véhicule connecté.

Comment le véhicule interagit-il avec son environnement ?

Un véhicule connecté est un véhicule qui possède la particularité d’être en interaction avec son écosystème, à courte ou à longue portée, via des flux de données mobiles.

• Connexion courte portée: Le véhicule interagit directement avec un objet (smartphone, infrastructure, etc.), sans intermédiaire. Il utilise des technologies avec un rayon d’action limité (WAVE, Wifi on board, bluetooth, etc.) avec des échanges en local.
• Connexion longue portée: Le véhicule utilise un accès distant pour interagir avec des éléments externes via une plateforme cloud. Les connections 4G et bientôt 5G sont les technologies de prédilection pour raccorder le véhicule à internet.

Ce concept de véhicule connecté englobe également les échanges avec l’environnement direct du véhicule sous le terme de «Vehicle-To-Everything » (ou V2X). Enfin, la norme ISO 20077 décrit l’« Extended Vehicle » (ou ExVe) comme étant un ensemble composé du véhicule physique ainsi que toutes les plateformes et infrastructures qui sont sous la responsabilité du constructeur automobile.

De nombreux écosystèmes et acteurs devront cohabiter

La voiture était autrefois un système très fermé ; à l’exception d’une prise diagnostique pour les garagistes et d’un peu de connectivité pour diffuser du contenu multimédia, le risque était jusque-là contenu. Aujourd’hui, la multiplication des éléments de connectivité et l’accès à internet ouvrent de nouvelles opportunités pour les constructeurs et fournisseurs de services, mais aussi pour une personne malveillante.

Le premier écosystème à considérer est celui du véhicule embarqué. Les systèmes électroniques et de communication doivent pouvoir communiquer entre eux sans que les données transmises ou les secrets stockés ne soient altérés ou dérobés. Parmi ces systèmes, on retrouve les ECU, ces mini « ordinateurs embarqués » qui pilotent des fonctions clés du véhicule telles que le système de freinage, la climatisation, l’éclairage, etc.

Au-delà de la sécurité embarquée, on retrouve les utilisateurs et le propriétaire (qui n’est pas forcément un particulier) bénéficiant de droits afin de donner des ordres au véhicule selon les règles prédéfinies. Dans le futur, leur authentification sera certainement primordiale pour des questions de responsabilités ainsi que la vérification de la légitimité des ordres qu’ils émettent.

Un autre aspect très important concerne les services connectés qui utilisent des plateformes centralisées, voire dans le cloud, mises en œuvre par les constructeurs ou par des partenaires. Ces plateformes représentent une menace importante car elles peuvent déclencher des commandes sur une flotte entière de véhicules, et donc avoir un impact démultiplié. Les constructeurs devront mettre en place des solutions sécurisées adéquates pour autoriser ces services, en combinant leur propre plateforme, celle des partenaires et les API sur le véhicule, et s’assurer du niveau de confiance de l’environnement.

Enfin, à moyen terme, les objets extérieurs et l’environnement proche (autres véhicules, garage, parking, infrastructure routière, etc.) devront communiquer et partager des informations. Les enjeux de sécurisation en temps réel (disponibilité, intégrité, etc.) seront alors des challenges complexes à relever.

Des enjeux cybersécurité : du monde virtuel à la réalité

La sécurité des hommes à l’intérieur et à l’extérieur du véhicule est une préoccupation de tout premier plan pour le secteur automobile. Il serait donc logique de penser que les problématiques de cybersécurité soulevées par le véhicule connecté seront traitées avec la même rigueur, dans le but de garantir les fonctions de safety et d’intégrité de la voiture.

Le premier enjeu est un défi organisationnel à relever pour tous les acteurs et notamment les constructeurs, car l’avènement de ce nouveau modèle provoque la réunion de deux mondes opposés : d’un côté, celui des services et de l’autre celui de l’ingénierie. Le premier est tout en agilité et rapidité, avec de très nombreux projets à court terme. Le second, avec un cycle de développement plus long, doit répondre à des exigences en matière de safety et de qualité afin de permettre l’homologation du véhicule. Cette dichotomie a des impacts sur la cybersécurité et notamment son intégration dans les projets, ou encore la couverture du risque end-to-end. Par exemple, le backend devient, de par sa position, un point névralgique à sanctuariser pour éviter tout risque d’attaque systémique avec des répercussions sur l’ensemble de la flotte. Malheureusement sa sécurité n’est aujourd’hui pas appréciée à sa juste valeur, principalement pour des exigences de time-to-market très court.

En ce qui concerne les autres enjeux, force est de constater que les thématiques de cybersécurité pour le véhicule connecté ne diffèrent pas beaucoup de celles que l’on connait dans le monde SI : gestion des identités et des accès, détection et réponse, sécurité des infrastructures, cryptographie, gestion des parties tierces ou encore patch management… Un véhicule connecté est un SI « mobile », et les différentes normes de sécurité (ISO2700x, NIST 800, etc.) sont déjà déclinées sous forme de bonnes pratiques dans différents guides et référentiels (SAE J3061, AUTOISAC, NHST, etc.) et seront prochainement l’objet de la norme ISO/SAE 21434.
Cependant, un certain nombre de contraintes inhérentes au véhicule et aux systèmes embarqués impliquent de considérer ces sujets sous des angles spécifiques et originaux.

La mobilité et la connectivité du véhicule complexifient sa sécurisation : il faut prévoir la sécurité dans un contexte de connexion limité ou inexistante, avec un environnement changeant. L’aspect réglementaire n’est pas en reste, le véhicule étant amené à se déplacer à l’international.

Le monde de l’embarqué pose également des restrictions sur le matériel, en termes de coût, de puissance de calcul et d’encombrement.

La question de la mise à jour des composants et des services se pose vis-à-vis d’un système devant fonctionner à tout moment mais pouvant aussi être arrêté sur de longues périodes.

Enfin, le véhicule est promis à un cycle de vie long, ce qui implique de penser dès le début sa sécurité notamment par rapport à la gestion des identités et des accès. Cette durée de vie impose aussi de réfléchir à des standards évolutifs dans le temps, ainsi qu’à un modèle de mises à jour garantissant la sécurisation du véhicule de manière durable et soutenable pour les constructeurs.

La route est longue et la cybersécurité s’invite à un carrefour où on ne l’attendait pas il y a une dizaine d’années encore. Il est urgent que chaque acteur réalise l’importance de l’effort demandé et commence à prendre le virage dès maintenant, avant qu’il ne soit trop tard.

Cet article Saga 1/3 : La voiture connectée, entre cybersécurité et safety 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.