Dans la série « cybersécurité » de l’ISA (préfixe 99), pour l’instant trois documents sont publiés, avec un contenu de qualité variable. Deux nouveaux documents, respectivement en version brouillon (‘draft’) et en cours de validation, sont très prometteurs : il s’agit de la mise en œuvre pratique des notions de zone et conduite dans les exigences.

Cet article rappelle la structure d’ISA 99  (aussi connue à présent comme IEC 62443), et fait une présentation critique des deux chapitres 99.03 en gestation.

Ceci est un article de fond – donc assez long – n’hésitez pas à sauter aux paragraphes de conclusion si vous êtes déjà familier avec toutes les notions présentées. L’article fait d’abord un rappel sur la norme ISA 99, puis détaille et commente les nouveaux documents : le premier permettant de définir les niveaux de sécurité requis (99.03.02), et le second définissant les mesures à mettre en œuvre suivant ce niveau (99.03.03).

La structure de la norme ISA 99

Pour rappel, les trois documents publiés jusqu’à présent, dans la série cybersécurité ISA 99, sont :

• ISA 99.01.01 : bases de vocabulaire et concepts (2007), avec notions intéressantes de zones et conduites
• ISA 99.02.01 (2009) : établissement d’un SMSI dédié à la cybersécurité industrielle, dont j’ai fait une critique dans cet autre article
• ISA TR99.03.01 : concepts de sécurité (2007), pertinent, mais n’apportant rien à un professionnel de la sécurité, utile sans doute pour le public visé des automaticiens désireux d’avoir un référentiel technique sur les pare-feux etc…

Je ne reviendrai pas dans la suite de l’article sur le fait que la norme ISA 99 est à présent également supportée par l’IEC sous le préfixe IEC 62443, avec les mêmes suffixes (99.03.03 = 62443-03.03). J’utilise le terme « ISA » pour des raisons historiques, de respect pour l’ISA, et pratique (c’est plus court !).

Ces documents sont disponibles à l’achat en anglais sur le site de l’ISA (sélectionner ’99′ dans la liste déroulante sous ‘Search Standards by number’). Ils peuvent aussi être consultés gratuitement par les membres de l’ISA.

La ‘newsletter’ « ISA Flash » N°43 inclut une excellente revue de la structure de la norme ISA 99, et notamment de l’état de ISA 99.03 : je m’en suis inspiré dans cette partie de l’article (avec l’accord de l’ISA), et vous invite à le récupérer en téléchargement gratuit sur la section « Téléchargement » du site ISA France.

On y trouve notamment une reprise du synoptique ci-dessous (cliquer pour agrandir) :

(Source : KB Intelligence, Jean-Pierre Hauet, ISA France)

On voit ainsi que :

• ISA 99.01.01 et 99.02.01 sont en cours de mise à jour, ce qui est heureux : en effet ISA 99.01.01 date un peu, et je ne reviens pas sur les problèmes de 99.02 explicités dans un autre article
• ISA 99.03.03 est en cours de validation – il est encore tout juste temps d’envoyer un commentaire car la date limite est (ou plutôt était lorsque vous lirez cet article) le 27 octobre 2011. Le document est en circulation et consultable sur le site de l’ISA, le lien étant valide jusqu’à approbation je suppose.
• A noter qu’il y a confusion sur certains numéros, ainsi on peut acheter (ou consulter en ligne) 2 des 3 standards publiés sous d’autres numéros :
  • 99.01.01 (ci-dessus) est en fait disponible sous le numéro 99.00.01 (sur isa.org)
  • TR99.03.01 est en fait disponible sous le numéro 99.00.01 – je confirme qu’il s’agit bien de la même chose !

Enfin le flash ISA nous apprend que la notion de SAL (cf ci-dessous) introduite par l’ISA a été adoptée par le NIST américain, qui produit de nombreux et excellents référentiels, par exemple NIST 800-82.

Curieusement, 99.03.02 qui devrait logiquement précéder 99.03.03, n’est pas encore soumis à commentaire/vote. Une raison en est sans doute la nature encore un peu « brouillonne » (qui fait penser à 99.02.01), comme je le décris ci-dessous.

Le SAL de ISA 99 faisant écho au SIL de IEC 61508 ?

Je n’entre pas en détail dans la norme de sûreté de fonctionnement IEC 61508 car c’est un vaste sujet d’une part, et que je ne maîtrise pas d’autre part. En quelques mots cependant : la norme s’applique aux dispositifs de sécurité des installations industrielles (« safety » – d’où SIL « safety integrity level »), et permet d’une part de définir la sûreté de fonctionnement dont on a besoin, et d’autre part comment l’obtenir.

Par exemple : suivant l’impact potentiel d’un dysfonctionnement (réacteur nucléaire qui s’emballe), on définit l’objectif de sûreté de fonctionnement de l’arrêt d’urgence « automatic shutdown » (par exemple, 99,99% – i.e. SIL level 4 – max), que l’on applique à la boucle automatique de contrôle de la fonction de sécurité (fiabilité des capteurs de températures, de pression, des automates et des vannes à contrôler), ce qui permet grâce au modèle SIL de définir le niveau de qualité des composants et éventuellement leur redondance (par exemple 3 automates et décision de « shut down » si 2 parmi les 3 le décident).

N.B. en réalité d’autres critères que SIL sont en France sur les réacteurs (IPS pour la génération en fonctionnement), mais je conserve l’exemple qui est plus frappant !

A noter que cet exemple hypothétique ne l’est pas tant que ça : ces automatismes ont très bien fonctionné à Fukushima par exemple (détection de tremblement de terre), et durant le tremblement de terre en Virginie (USA) ce mois d’août, mais il arrive aussi qu’ils soient déclenchés suite à des incidents de cybersécurité, causant par exemple l’arrêt d’urgence du réacteur 2 dans la centrale nucléaire « Hatch » de Southern Nuclear Operating Company (USA – le 7 mars 2008 – source RISI).

On voit ainsi qu’il y a un intérêt à traiter des deux aspects (sûreté de fonctionnement et cybersécurité) de manière cohérente, et si possible avec des méthodologies pas trop éloignées.

La promesse d’ISA 99.03

La promesse explicite d’ISA 99.03 est de définir un concept aussi simple et efficace que SIL, nommé SAL pour « security assurance level », et permettre via les différents chapitres de 99.03 de définir le niveau requis de SAL pour une « zone » donnée (la notion de zone étant celle définie par 99.01), et d’indiquer les mesures à mettre en œuvre selon ce niveau de SAL. Implicitement, on peut aussi y voir une tentative de convergence des approches de gestion des risques, en utilisant des référentiels « compatibles » entre sûreté et cybersécurité – en tous cas, c’est la perspective qui me semble la plus intéressante. C’est d’ailleurs à mon avis ce qui manque cruellement en sécurité des SI de gestion, dont les approches méthodologiques restent déconnectées des autres démarches « qualité ».

Pour reprendre l’exemple des réacteurs nucléaires, on peut définir comme « zone » le sous-réseau des automatismes d’arrêt d’urgence en cas de séisme. Avec une analyse d’impact adaptée comme définie en annexe de 99.02 (qui inclut pertes humaines, destructions, dégâts environnementaux et – spécificité de la cybersécurité – perte d’exploitation), on définit le niveau de SAL requis (mettons 4 – car SAL utilise aussi une échelle de 1 à 4 comme SIL), et enfin 99.03 nous indique les mesures à mettre en place (par exemple déconnexion totale du sous-réseau Ethernet de cette zone du reste du réseau contrôle-commande, sauf éventuellement via data-diode).

L’objet de cet article est de voir si les deux documents 99.03, semblent, en l’état, en mesure de tenir cette promesse.

On notera pour commencer que l’ISA considère que la cybersécurité est trop complexe pour être ramenée à un seul chiffre par zone (SAL = 3 par exemple), et définit en fait 7 (sept) dimensions d’exigence SAL pour chaque zone. On parle ainsi qu’un « vecteur SAL », là où SIL est un « scalaire ». Ce qui rend d’emblée l’approche a priori plus complexe à utiliser (il y a potentiellement de nombreuses zones dans une installation). Cependant, il y a en principe beaucoup moins de zones où appliquer SAL que de boucles où appliquer SIL : en effet une « zone » regroupe potentiellement de nombreuses boucles de contrôle. Mais en revanche SAL est supposé s’appliquer sur toutes les parties du contrôle-commande, là où SIL s’applique uniquement aux équipements de sûreté…

ISA 99.03.02 : définition des SAL pour les zones et conduits

Pour rappel, et de manière synthétique : une zone au sens ISA est un ensemble physique et logique de systèmes de même « criticité », au sens cybersécurité. Même si au sein d’une zone on peut installer des équipements de cybersécurité (détection d’intrusion, protection des serveurs, etc. suivant le principe de « defense in depth »), on va a priori surtout veiller à la sécurité des liaisons « inter zones », les « conduits ». Les conduits seront donc en nombre minimal, pour éviter des flux réseau complexes à administrer et surveiller, et permettre la mise en œuvre, par exemple, de règles de pare-feu efficaces et auditables.

A noter que les documents font la distinction encore niveau SAL « actuel », « exigence », « cible » etc. Ce niveau de détail n’est pas nécessaire pour le présent article je n’y reviendrai donc pas.

On attend donc de ISA 99.03.02 :

• une méthode pour définir les zones et conduits
• une méthode pour calculer le niveau de SAL cible d’une zone donnée

Qu’en est-il en réalité ?

Le contenu d’ISA 99.03.02

J’ai étudié le draft 3 (Juillet 2009, 38 pages) fourni par ISA France. La structure du document correspond visiblement aux deux objectifs ci-dessus, avec, après des introductions terminologiques et définition du cadre, deux chapitres essentiels :

• chapitre 5 : procédure pour établir les zones et conduits (6 pages)
• chapitre 6 : procédure pour calculer le niveau SAL (8 pages)

Suivent quelques annexes donnant des exemples de mise en œuvre, une correspondance pour FIPS 199 (norme US s’appliquant aux organismes fédéraux) et une discussion sur une nouvelle notion : la ‘trustworthiness’ (niveau de confiance). A noter que je ferai prochainement un zoom sur FIPS 199, car j’ai été alerté sur le fait qu’elle conciliait les approches DIC et criticité (au sens 61508) – à ré-examiner donc dans un futur article.

Note rajoutée après commentaire N°1 ci-dessous  : ce draft 3 est en cours de refonte, et si le contenu devrait peu évoluer, la forme et présentation devraient donc grandement s’améliorer.

La définition des ‘zones’ et des ‘conduits’ (chapitre 5)

Je m’attendais à une espèce de méthode MERISE pour découper son installation en zones et conduites avec des règles procédant par étape : je suis déçu. En lieu et place : 3 chapitres (5.1 à 5.3) listant 13 règles à respecter (par exemple, comment définir le niveau de sécurité de deux zones connectées, à quoi rattacher un pare-feu : à la zone ou au conduit, et le besoin de considérer les systèmes de sûreté comme une zone séparée, car en général plus critique). Pas toujours limpides (notamment du fait des erreurs), on les comprend cependant avec relecture et c’est plutôt du bon sens.

Le document se positionnerait du coup plutôt comme norme que comme méthode, pourtant c’est bien présenté comme un « process ».

La section suivante (chapitre 5.4) propose un exemple relativement parlant avec des considérations pratiques, par exemple si un point d’accès Wifi existe, il est indispensable de l’isoler dans une zone à part :

Modèle de calcul du niveau SAL (chapitre 6)

Un peu comme le chapitre précédent, ici on donne plutôt des règles qu’une méthode. Il reste donc à imaginer la méthode. On y confirme le « découpage » de SAL en 7 exigences distinctes:

• AC: contrôle d’accès
• UC: contrôle d’usage (opérations autorisées)
• DI: intégrité des données (sur une liaison)
• DC: confidentialité des données
• RDF: restriction des flux de données
• TRE: temps de réponse aux événements
• NRA: disponibilité des réseaux

C’est donc un ‘DIC’ décliné de manière encore plus fine. Et la complexité ne s’arrête pas là, en effet, plusieurs contraintes sont rajoutées, notamment l’obligation d’utiliser les « catégories de sécurité » qui sont définies dans 99.01.03 (qui est encore en développement). Il s’agit en fait de métriques, en % d’une cible, par exemple « % des comptes utilisateurs dont les accès ont été vérifiés durant une période de temps ».

Suivent ensuite la définition des niveaux SAL eux-mêmes, qui contrairement à ce qu’on pourrait penser, n’est pas 4,3,2,1 mais… 4, 4R, 3, 3R, et pas de différence entre 2 et 1 dans la norme : au choix de l’organisation.  Le R se référant à un système redondant…

Un exemple est ensuite fourni dans le document. J’ai relu plusieurs fois et j’avoue que ces notions restent confuses. A noter que 99.03.03, présenté ci-dessous, est plus synthétique, voire un peu critique envers 99.03.02.

99.03.03 rappelle en effet les quatre niveaux SAL (sans ‘R’), suggère un niveau 0  (correspondant à pas d’exigence, pour pouvoir plus facilement utiliser des logiciels d’expression d’exigence…), et donne des définitions synthétiques de ce à quoi correspondent, synthétiquement, les niveaux SAL. On verra que cela rend presque caduc 99.03.02 dans sa forme actuelle.

Conclusion sur 99.03.02

D’une complexité inouïe, on arrive ainsi à un système encore plus « usine à gaz » que les méthodologies de sécurité du SI de gestion. L’utilisation de ce modèle me semble extrêmement irréaliste dans des installations complexes – et à l’inverse, dans des installations plus simples, une telle débauche de formalisation ne s’impose pas forcément (voir pour mémoire le « rappel aux basiques » de l’ANSSI, évoqué dans l’article sur les assises de la sécurité 2011).

La promesse d’un modèle SAL aussi pratique que SIL n’est à mon avis donc pas du tout tenue dans la version « brouillonne » de 99.03.02 datant de 2009. Un gros travail de rationalisation / simplification est à faire. En théorie la distinction en 7 dimensions (voir plus haut) se tient, mais en pratique, cette distinction semble vraiment exagérée – surtout si l’on considère la réalité, par exemple, des systèmes de contrôle d’accès aux automates existants : mettre des exigences fines sur les différents types d’accès exclurait de fait tous les fournisseurs, ou alors il faut rajouter dans chaque zone des systèmes de contrôle d’accès complexes, ce qui reviendrait à avoir un budget pour la sécurité comparable au budget pour les automates ! (une « data-diode » est en effet d’un coût sensiblement similaire à un API moyen, de l’ordre de 5k$).

ISA 99.03.03 : définition des mesures en fonction du niveau SAL

Après un paragraphe sur 99.03.02 un peu long ci-dessus, celui-ci sera beaucoup plus court (première bonne nouvelle), pour la bonne raison que ISA 99.03.03 est beaucoup plus clair car de construction très logique. Le document comporte trois parties, après les introductions habituelles :

• environ 30 pages décrivant, pour chaque critère (en moyenne 10 critères pour chaque dimension), les mesures à mettre en oeuvre suivant le niveau SAL. Par exemple en page 32 on trouve une description de l’exigence UC SR 2.9 ‘timestamps’ : en fonction du niveau SAL (dimension ‘UC’ du vecteur SAL), on trouve les mesures à appliquer :
  • niveau 1 : rien
  • niveau 2 : obligation pour l’équipement de fournir une information « date et heure », non altérable, idéalement synchronisée globalement, pour dater les entrées de logs.
  • niveaux 3 et 4 : idem 2 + obligation de synchronisation régulière des équipements
  • tout ça est très clair, chaque exigence respecte dans sa forme les bonnes pratiques d’ingénierie des exigences
• annexe A : définition du vecteur SAL, en fait reprise des notions de ‘zones’, ‘conduits’, vecteur SAL, et quelques définitions et clarifications supplémentaires : c’est un excellent digest beaucoup plus clair que ces autres documents, à lire à mon avis en lieu de place de 99.01 et 99.03.02 !
• annexe B : tableau récapitulatif des mesures applicables pour chaque SAL, telles que détaillées dans la première partie

C’est donc un document impeccable dans la forme, et qui semble utilisable en pratique… mais avec le paradoxe que les documents supportant l’étape précédente (définition du niveau SAL) sont dans un état loin d’être publiable…

Conclusion sur ISA 99.03

Le document 99.03.03, pas encore publié mais sans doute à présent approuvé, est prometteur et utilisable – en tous cas c’est une bonne base pour exprimer des exigences de cybersécurité en environnement industriel. Il demeure deux soucis majeurs :

• la manière de définir le niveau SAL, qui sert de base aux exigences, n’est pas encore précisée – cela n’empêche pas cependant d’exiger un niveau SAL donné : à comparer au SIL, où en pratique on devrait utiliser une méthodologie fine pour définir le niveau SIL nécessaire, et en pratique, c’est souvent plus ou moins décrété « je veux SIL 4 pour cette boucle », et à l’arrivée d’ailleurs il arrive que cela soit revu à la baisse « bon ok, vu le coût,  SIL 3 sera suffisant ici »…
• il demeure la complexité d’avoir un vecteur de dimension 7 ce qui semble exagéré. Par exemple, faire la différence entre les deux premières dimensions : « contrôle d’accès » et « contrôle d’usage » n’est pas forcément aisé. Il semble, si la norme est publiée en l’état, qu’on rate l’objectif de rationalisation. Au prix de quelques compromis, il semblerait logique – par exemple – de définir un seul niveau d’exigence pour le contrôle d’accès (1ère dimension), le contrôle d’usage (2e) voire même la confidentialité des données (4e), puisqu’il s’agit en fait à peu près du même besoin qui s’exprime d’une part sur les équipements, et de l’autre sur le réseau de communication

En ayant voulu respecter l’esprit des précédents documents de la norme, ISA 99.03.03 est à mi-chemin de ce qui aurait réellement pu être un modèle limpide et utilisable en pratique. On dispose cependant d’un document couvrant l’ensemble des exigences de sécurité, avec des définitions claires, c’est déjà ça.

En particulier, ISA 99.03.03 donne une définition synthétique de ce à quoi correspond un niveau SAL, ce qui est (à mon avis) une manière de suggérer que l’on peut tout à faire définir un niveau SAL sans pour autant construire une usine à gaz type ISA 99.03.02.

Par exemple pour le niveau SAL 2 il est indiqué que cela vise à la : ‘Protection against intentional violation using simple means with low resources, generic skills and low motivation’, en français « Protection contre les attaques volontaires utilisant des moyens simples avec peu de ressources, des compétences moyennes et une faible motivation ». On voit donc que ce type de définition n’a pas besoin de 7 dimensions !

Néanmoins le vecteur « SAL », s’il est effectivement approuvé dans sa forme actuelle par le NIST étatsunien, ne sera donc probablement pas remis en cause dans sa complexité – on va donc devoir faire avec, mais de toute façon, ce sera mieux que de faire sans !

Tags: Exigences, ISA, Normes