On ne peut pas faire de cybersécurité industrielle sans prendre en compte la sûreté de fonctionnement : c’est le sujet de cet article avec également quelques illustrations, un point sur le vocabulaire et une annonce de séminaire pour faire l’état de lieux si vous voulez tout savoir sur le sujet !

Le vocabulaire…

… serait un sujet en soi. On parle ici de sûreté au sens « Sûreté de fonctionnement » (SDF), qui recouvre différentes propriétés des systèmes de conduite et de sécurité. On s’intéressera dans cet article à la SDF mais aussi plus spécifiquement à la « Sécurité fonctionnelle », qui concerne seulement certaines propriétés SDF des systèmes de sécurité (safety). Comme on le voit, le vocabulaire est compliqué : on utilisera indifféremment les termes « sûreté », « sûreté de fonctionnement » ou « sécurité fonctionnelle » dans cet article, selon qu’on parle de l’ensemble des propriétés de systèmes ou plus spécifiquement de celles de systèmes (ou automates) des sécurité.

Pour une explication exacte des termes, des variations par secteur (entre industrie, chimie, énergie, nucléaire…), et les liens avec les termes anglais équivalents, vous pouvez consulter l’article sur le sujet paru dans le Flash ISA-France #57, téléchargeable sur le site de l’ISA-France.

Voir aussi cette excellente présentation sur le même sujet, très complémentaire avec cet article, et réalisée presque simultanément (je connais l’auteur mais on ne s’est pas du tout concertés !)

Annonce de séminaire ISA-France

« Sûreté et cybersécurité : comment concilier deux objectifs essentiels de la sécurité industrielle »

Un séminaire est organisé par l’ISA-France le 18 octobre 2016, le sujet sera alors amplement exploré et développé, avec peut-être quelques retours d’expérience. Si vous avez, ou connaissez des gens ayant une expérience ou même juste de bonnes idées sur le sujet, un appel à communication (date limite 15 avril) est lancé !

Les grands principes : FDMS, MTBF, redondance, indépendance

En environnement de bureautique, les pannes sont pénibles mais causent au maximum des pertes de données ou de temps, avec des risques de plus en plus réduit du fait du cloud (virtualisation) et de la démocratisation des solutions de sauvegarde (cloud aussi !)

En environnement industriel, des pannes ou des erreurs peuvent conduire à des accidents ou a minima des pertes de production. Les systèmes en prise directe avec le processus industriel (moteurs, pompes, vannes etc…) ne peuvent être virtualisés et la sauvegarde est compliquée (automates…) :  il faut donc modéliser et traiter le risque en cas de panne. La modélisation des besoins en sûreté se fait par les paramètres FDMS (fiabilité, disponibilité, maintenabilité et sécurité), comparables aux paramètres DICP de la sécurité de l’information, sachant que l’on parle de contrôle de procédé pour FDMS, et non d’information comme pour DICP.

Lorsque le besoin de disponibilité, fiabilité ou sécurité est particulièrement élevé, différentes approches permettent de l’atteindre :

1. choisir des équipements particulièrement fiables (il y a toutes les gammes de MTBF – mean time between failure – dans les catalogues constructeurs)
2. dupliquer les équipements c’est à dire utiliser la redondance simple (courante pour réseaux et serveurs SNCC et SCADA) – permet d’augmenter disponibilité et maintenabilité (il est usuel de faire des mise à jour sur un système puis l’autre, sans interrompre le pilotage, si le risque associé est raisonnable)
3. augmenter le niveau de redondance et rajouter des fonctions de vote (par exemple 2oo3 pour « 2 out of 3″: un composant peut dysfonctionner, du moment que les deux autres continuent de fonctionner correctement la fonction est assurée),
4. rendre indépendants les différentes redondances pour augmenter la résistance aux causes communes de défaillance : alimentation électrique différente, diverses localisations physique, logiciel ou matériel différents…
5. mettre en œuvre un système intégralement dédié à la sécurité fonctionnelle, fonctionnant en parallèle des systèmes de conduite. Ces systèmes assurent avant tout la sécurité via un haut niveau d’intégrité : en cas de défaillance des systèmes de contrôle ils assurent le plus souvent une mise à l’arrêt sûre, éventuellement avec fonctionnement minimal ou dégradé.

Si les deux premières approches sont assez standards et financièrement raisonnables, les autres solutions sont très coûteuses et réservées à des processus sensibles : chimie avec risque d’accident (énergie – gaz, pétrole, sites Seveso…), nucléaire, ou équipements de production très coûteux (certains process industriels – par exemple les presses des ailes d’avions gros porteur – nécessitent un investissement de dizaines de millions d’euros et sont quelquefois uniques et difficilement remplaçables).

Les systèmes instrumentés de sûreté (SIS)

C’est l’aspect le plus simple à comprendre et à illustrer de l’approche 5) ci-dessus : l’idée est de dédier des systèmes à la sécurité fonctionnelle, le plus souvent des automates avec supervision locale. On choisit alors des modèles spéciaux dont l’intégrité est maîtrisée du fait d’une conception particulière, d’auto-tests et en général de tests fonctionnels approfondis, quelquefois de matériels plus fiables, et surtout d’un retour d’expérience : historique de fiabilité et de pannes sur plusieurs années d’exploitation. Les SIS surveillent le processus industriel sans aucune action sur le processus la plupart du temps, et prennent le contrôle en cas de détection de déviation importante du processus, quand les équipements standards de conduite sont dépassés (BPCS – basic process control systems en anglais).

Schéma de principe d’un SIS base: le processus piloté est en vert, le contrôle de processus (BPCS) est en bleu, avec ses propres capteurs et actionneurs, et on représente un SIS qui est complètement indépendant avec ses propres capteurs et actionneurs dans ce cas (ce n’est pas toujours le cas).

Il y a des référentiels et des standards dédiés au sujet (initialement ISA 84 puis IEC 61508 et ses dérivés 61511 pour processus continus comme dans la chimie, 61513 pour le nucléaire, etc…). Les standards développent un vocabulaire et des approches quantitatives permettant, via un bon choix d’équipements, d’architecture, et démonstration mathématique, d’atteindre un niveau cible de fiabilité du processus. On trouve par exemple la quantification SIL (safety integrity level) pour l’intégrité d’une fonction de sécurité dans IEC 61511.

Autre exemple : les normes de sécurité nucléaire imposent de concevoir le contrôle commande des réacteurs nucléaires avec un niveau de fiabilité tel qu’il y ait moins de 10^-5 chances par siècle de fusion du coeur à cause d’une défaillance du contrôle commande. Dans ce cas précis, il y a non seulement des systèmes 2oo3 voire 2oo4, mais des SIS à plusieurs niveaux, chacun rattrapant les défaillances des précédents, jusqu’à un niveau résiduel correspondant à cette cible. L’ANS (autorité de sûreté nucléaire) vérifie la démonstration avant d’autoriser la mise en exploitation d’un réacteur.

Le point important ici est la possibilité de démontrer mathématiquement, à partir des données statistiques de panne des équipements et des occurrences de défaillances humaines, de bugs logiciels, de risques environnementaux etc… qu’on atteint bien l’objectif de fiabilité. Les études AMDEC (HAZOP dans le monde anglo-saxon) et les variantes permettent de constituer des dossiers de sûreté, permettant l’homologation des systèmes.

Et la cybersécurité dans tout ça ?

Des approches incompatibles

Les dernières versions des normes de sûreté citées ci-dessus (61508, 511, 513…) font état du besoin de cybersécurité, et quelquefois (61513) listent quelques exigences. Ces documents semblent suggérer une solution simple : considérer les cyber-attaques comme un type de menace additionnel, à ajouter aux pannes, erreurs, et autres aléas déjà prises en compte.

Mais cette approche ne marche pas car la nature des menaces est trop différente :

• accidentelles, aléatoires et statistiquement prévisibles pour la sûreté,
• malveillantes, ciblées et imprévisibles dans le cas des cyber-attaques.

Ainsi par exemple un système industriel va résister à du « bruit » sur le réseau, mais tomber en panne suite à une seule trame volontairement mal formée, qui n’a aucune chance de se produire aléatoirement.

Un autre exemple d’antagonisme est celui des automates de « sûreté » évoqués plus haut. Comme il faut des équipements bien connus, avec retour d’expérience du taux de panne sur une longue durée, éventuellement certifiés… les automates de sûreté sont particulièrement vulnérables ! En effet, leur conception date, et il n’est pas question de mettre à jour leur firmware, sans parler de leurs équipements de communication, sous peine de perdre la garantie de fiabilité !

Les méthodes (HAZOP, AMDEC etc…) ignorent d’ailleurs largement le sujet de la sécurité, pour une bonne raison : l’approche d’analyse de risques de cybersécurité, par nature qualitative, est difficilement compatible avec la démonstration mathématique des méthodes de sûreté – et de plus, le domaine est en constante évolution (découvertes de vulnérabilités, augmentation de la menace, nouvelles méthodes d’attaque informatique…).

Le besoin de rapprochement

A l’exception du domaine de la sûreté nucléaire, qui a initié les travaux sur une norme « sûreté et cybersécurité » (IEC 62859), et d’un groupe de travail à l’ISA (travail entre groupes ISA 84 et ISA 99), il y a peu de travaux sur le sujet. A noter que l’étude de l’ISA a été commentée par DigitalBond, qui note l’échec de la tentative de rapprocher les niveaux de sûreté SIL (ISA 84 – IEC 61511) avec les niveaux de sécurité ISA 99 (SL – security level, expliqués dans un précédent article de ce blog).

Or le besoin est apparu explicitement il y a quelques années, à commencer par le nucléaire et l’avionique : diverses autorités (et clients) ont demandé à ce que les systèmes de sûreté soient aussi « cybersecure ». En effet dans la mesure où on investit des sommes importantes dans des équipements pour assurer la fiabilité de processus critiques, il est légitime de s’assurer que le premier hacker-amateur venu ne puisse pas mettre en panne le réacteur ou l’avion !

Il fallait donc faire quelque chose… alors on a commencé par bricoler : analyse de risques en essayant de coller aux objets traités par les analyses de sécurité (safety), analyse des redondances et indépendantes utiles à la sûreté avec le prisme cybersécurité (mettre deux fois le même automate ça sert à la sécurité (safety) mais pas à la cybersécurité s’ils sont connectés sur le même réseau, par contre c’est utile à la fois à la sûreté et sécurité si les modèles sont différents et non interconnectés…), et quelques approches plus fines pour adapter les modèles « zones et conduits » aux fonctions de sécurité : on a décrété qu’il fallait une zone dédiée à la sécurité fonctionnelle, que les redondances devaient idéalement être dans des zones différentes et quelques autres astuces…

Approches collaboratives et formation

Depuis quelques temps les approches se font plus professionnelles, essentiellement en profitant du retour d’expérience : on sait à présent ce qui ne marche pas (par exemple faire une analyse EBIOS standard une fois l’analyse de sûreté bouclée), on sait à peu près quel serait l’approche idéale (les experts sûreté et cybersécurité qui se rencontrent régulièrement et échangent avec un formalisme adapté aux différents stades du cycle de vie : expression de besoin, exigences, design global, désign détaillé etc…), et on essaie de se rapprocher de cet idéal.

Cette approche collaborative semble d’autant plus adaptée que le nombre des vrais experts sûreté d’une part, et cybersécurité des SI industriels d’autre part, reste réduit. Il est irréaliste d’espérer disposer d’experts des deux domaines simultanément (il en existe à peine une poignée dans le monde, et ils uniquement dans le domaine nucléaire) : il faut donc trouver des moyens de faire dialoguer les experts qu’on a !

En conclusion, si on trouve naturel d’organiser des sensibilisations et des formations de cybersécurité pour les acteurs industriels (automaticiens, mainteneurs, intégrateurs etc…), il faut donc aussi dès à présent commencer les sensibilisations et formations de sûreté (et sécurité fonctionnelle) pour les consultants en cybersécurité industrielle, sinon la collaboration ne fonctionnera pas !

Tags: Menaces, Safety