NOTE : Cet article ne concerne pas uniquement les organisations qui ont déjà été piratées... La norme IEC 62443 est une norme générique reconnue comme applicable dans des secteurs critiques tels que la fabrication, l'énergie, le transport, les soins de santé et bien d'autres.
Cet article est le cinquième épisode d'une série de 8, couvrant certaines des meilleures pratiques à mettre en œuvre par toute organisation visant à répondre à l'état de l'art en matière de cybersécurité pour les systèmes de contrôle industriels et d'automatisation. Dans ce contexte, le renforcement de la sécurité est considéré comme un sujet clé pour prouver que la stratégie de défense en profondeur est suivie et mise en œuvre par les intégrateurs. Les activités incluses dans ce thème sont principalement abordées par les huitièmes pratiques de la norme ISA/IEC6244-4-1 consacrée aux directives de sécurité, ainsi que par la partie ISA/IEC62443-2-4 décrivant les exigences pour les fournisseurs de services d'intégration et de maintenance.
Du point de vue de la norme ISA/IEC62443, les pratiques de durcissement de sécurité comprennent toutes les activités liées au durcissement d'un produit pendant les phases de post-développement (par exemple, l'installation, la maintenance...). Des exceptions sont faites sur l'exploitation sécurisée et l'élimination sécurisée qui sont décrites par des pratiques spécifiques, respectivement SG-5 (ISA/IEC62443-4-1, section 12.6) et SG-4 (ISA/IEC62443-4-1, section 12.5). Un cycle de développement sécurisé conforme de la part d'une organisation devrait donc intégrer ces aspects par la création d'une documentation pertinente pour les utilisateurs/intégrateurs de produits sur la manière d'intégrer, d'utiliser et de manipuler un produit en toute sécurité.
Cette exigence reconnaît que les politiques et les exigences de sécurité des sites des clients sont souvent différentes et que, par conséquent, il est nécessaire de fournir des instructions pour intégrer le produit de manière sécurisée sur le site du client, le configurer de manière appropriée et maintenir sa sécurité. Formellement, une exigence spécifique décrit ces activités comme suit :
Comme nous l'avons déjà mentionné dans les épisodes précédents de cette série de blogs, la stratégie de défense en profondeur est essentielle pour gérer la cybersécurité et réduire les cyberrisques. Il n'existe pas de solutions à l'épreuve des balles, c'est pourquoi la multiplication des techniques et des barrières défensives est considérée comme la meilleure approche pour minimiser les cybermenaces tout au long de la chaîne d'approvisionnement, depuis le développement sécurisé de composants individuels jusqu'au fonctionnement sécurisé de solutions et de systèmes complets et plus complexes. Dans ce contexte, les directives de renforcement de la sécurité représentent l'un des principaux ensembles de documents à fournir par les fournisseurs de composants/systèmes pour garantir une intégration et une maintenance sûres des produits.
Le renforcement de la sécurité, un sujet commun à l'OT et à l'IT
En effet, le renforcement de la sécurité est un sujet connu pour les systèmes informatiques mais considéré comme encore plus important pour les cibles OT où les conséquences potentielles des cyber-attaques sont généralement plus critiques. La mise en œuvre des techniques de renforcement de la sécurité peut différer selon qu'il s'agit de systèmes informatiques ou de systèmes d'exploitation, mais les approches sont similaires et l'objectif final est le même : exploiter les capacités de sécurité d'une cible, dans un environnement donné, de la manière la plus efficace possible pour réduire la surface d'attaque restante et atteindre une posture raisonnablement sûre.
Les techniques de renforcement de la sécurité doivent être envisagées pour tout composant/sous-système d'un "système" ou d'une solution complète. Sur la base de ces considérations provenant de sources multiples, il est de la responsabilité des intégrateurs et/ou des utilisateurs de suivre les meilleures pratiques décrites par les fournisseurs de produits dans un environnement spécifique. Ce principe est la raison pour laquelle la SG-3 de la norme ISA/IEC62443 exige des fournisseurs de produits qu'ils fournissent une documentation comprenant des directives à cet effet.
Généralement, ces directives spécifient les processus à suivre par les intégrateurs et/ou les utilisateurs pour intégrer une cible spécifique dans un environnement en prenant soin de plusieurs aspects critiques, tels que :
- Interfaces avec d'autres sous-systèmes ou composants
- Configuration des produits
- Utilisation d'outils liés à la sécurité pour interagir avec le produit
- Activités de maintenance de la sécurité (par exemple, traitement des mises à jour et des correctifs)
- Notifications d'incidents
Prenons un exemple...
Si nous pensons à la fabrication d'un contrôleur industriel considéré comme un PLC (Programmable Logic Controllers), que signifie la directive de renforcement de la sécurité dans le contexte de ce produit ?
En ce qui concerne le composant lui-même, il serait considéré comme un dispositif embarqué selon la terminologie ISA/IEC62443-4-2. Un PLC est un dispositif qui réside généralement aux niveaux inférieurs du système d'automatisation (tels que les niveaux 1 et 2 de l'architecture de référence de l'entreprise Purdue décrite dans la norme ANSI/ISA-95.00. voir la figure ci-dessous). Les PLC utilisent généralement du matériel robuste pour permettre un fonctionnement dans des environnements industriels et sont généralement basés sur des systèmes d'exploitation en temps réel (RTOS) commerciaux. De plus en plus, les capteurs et actionneurs intelligents reçoivent également des formes de capacité de contrôle de processus. Les PLC et les capteurs/actionneurs intelligents sont programmés pour exécuter une logique de contrôle basée sur les entrées du processus (obtenues à partir d'instruments tels que les capteurs de température traditionnels, les capteurs de pression, les capteurs de vibration). La sortie de la logique de contrôle est utilisée pour contrôler le processus industriel (par le biais d'actionneurs tels que des vannes, des pompes). La programmation est généralement effectuée à l'aide d'un logiciel d'ingénierie fonctionnant sur des dispositifs hôtes (par exemple, des ordinateurs portables ou des stations de travail PC).
vous trouverez ci-dessous quelques exemples de sujets à fournir par les fabricants d'automates pour permettre aux intégrateurs et/ou aux utilisateurs de durcir le produit dans un environnement spécifique, sur la base des aspects de haut niveau mentionnés précédemment :
- Interfaces avec d'autres sous-systèmes ou composants
- Comment intégrer en toute sécurité le produit dans un système complet, en utilisant les API et les protocoles appropriés ?
- Quelles sont les exigences/hypothèses formulées par le fournisseur du produit concernant les autres sous-systèmes dépendants (par exemple, les serveurs d'authentification à déployer et à référencer pour gérer les fonctions AAA sur les produits) ?
- Configuration des produits
- Quelles sont les fonctionnalités permettant de prendre en charge l'identification et l'inventaire des actifs au niveau du système ?
- Quelles sont les hypothèses sur les protections physiques ?
- Quelles sont les contributions générales à la stratégie de défense en profondeur du produit ?
- Utilisation d'outils liés à la sécurité pour interagir avec le produit
- Quelles sont les recommandations d'instructions des fournisseurs du produit concernant l'utilisation d'outils pour l'administration, le suivi et d'autres activités connexes ?
- Activités de maintenance de la sécurité (par exemple, traitement des mises à jour et des correctifs)
- Quels sont les processus à suivre par les utilisateurs finaux / intégrateurs pour être informés des mises à jour / correctifs ?
- Comment déployer en toute sécurité une mise à jour/un correctif ?
- En cas d'erreur de déploiement, comment exécuter des fonctions de retour en arrière sécurisées ?
- Notifications d'incidents
- Le canal de communication avec les fournisseurs (par exemple, les points de contact, les outils, les modèles), pourrait être considéré comme hors du champ d'application des techniques de durcissement mais traité par d'autres exigences de la norme ISA/IEC62443-4-1 ?
- Processus de notification et de rapport des incidents/problèmes liés à la sécurité ?
La liste ci-dessus n'est pas exhaustive mais devrait vous aider à réfléchir à l'importance d'une telle documentation, dans la perspective de la gestion de la cybersécurité d'un produit tout au long de sa vie.
Qu'en est-il des certifications ?
Il est important d'être conscient du fait que, si un produit sécurisé est intégré dans une solution sans aucune directive spécifique de renforcement de la sécurité, les capacités de sécurité du produit ne seront pas correctement exploitées et pourraient donc conduire à des faiblesses au niveau du système. Cette considération est la raison principale pour laquelle la certification de produit selon ISA/IEC62443-4-2 exige également des preuves de l'établissement du SDLC, et donc de la conformité à ISA/IEC62443-4-1. Une certification SDLC complète selon la norme CEI 62443-4-1 n'est pas nécessaire avant toute certification de produit selon la norme CEI 62443-4-2, mais un sous-ensemble de pratiques SDLC doit être audité dans le cadre de la certification de produit.
Elle est cristallisée dans la norme CEI 62443-4-2 par le biais de ce que l'on appelle les contraintes communes de cybersécurité (CEI 62443-4-2, section 4.5, CCSC-4), qui exigent que "tout composant sécurisé soit développé et pris en charge conformément aux processus de développement de produits sécurisés décrits dans la norme CEI 62443-4-1".
Actuellement, la meilleure approche qui pourrait être adoptée par les organisations sur la voie de la certification IEC62443 serait la suivante :
- Évaluer votre position actuelle par rapport aux exigences normalisées par le biais d'une analyse des écarts.
- Certification SDLC selon la norme IEC 62443-4-1 pour obtenir une reconnaissance organisationnelle de l'état de l'art en matière de développement sécurisé.
- Certifications de produits selon la norme CEI 62443-4-2 pour proposer en définitive des produits répondant à l'état de l'art en matière de capacités techniques de sécurité.
Cette approche vous permettrait de réduire les coûts des certifications de produits en certifiant d'abord vos processus de développement et en obtenant une reconnaissance au niveau de l'organisation, puis en devenant déjà conforme aux exigences initiales du produit.
Conclusion
Même si la conformité à la norme 62443 n'est pas un objectif ultime, les pratiques liées au renforcement de la sécurité doivent être considérées comme l'une des principales activités et la documentation à fournir aux utilisateurs de produits et aux intégrateurs pour garantir des boucles de cybersécurité complètes à tous les niveaux des écosystèmes SIGC (y compris les propriétaires d'actifs, les fournisseurs de services, les fournisseurs de systèmes et les fournisseurs de composants).
Si vous avez des questions sur les pratiques de renforcement de la sécurité, les documentations et/ou tout autre critère de certification, n'hésitez pas à contacter notre spécialiste en cybersécurité : Kilian Marty