ANSSI – classification et mesures de cybersécurité pour l’industrie
Ca y est, on dispose en France d’une règlementation de cybersécurité industrielle !
Suite à la publication en 2012 d’un premier guide de la sécurité des sites industriels (voir l’article sur ce blog), l’ANSSI publie deux documents normatifs, après un an de travail réalisé avec des représentants d’industries, de sociétés de sécurité des SIs et d’équipementiers.
Et on ne plaisante plus, car après la « LPM » (Loi de programmation militaire) en décembre, des décrets d’application (avec ajustements sectoriels) vont décliner ces normes en exigences fin 2014. Les exigences sont claires et assez ambitieuses et cela va nous placer à la pointe des pays « cybersécurisés » – si elles sont vraiment mises en œuvre – c’est donc une bonne idée de les comprendre et les anticiper.
Je vais donner les points clés et mes surprises, sans détailler le contenu des documents car le premier se lit très bien « Méthodes de classification et mesures principales », le second étant une version détaillée des exigences et s’appelle d’ailleurs « Mesures détaillées » (un peu comme ISO 27002 détaille l’annexe A d’ISO 27001). Les documents sont en téléchargement libre sur le site de l’ANSSI.
On aurait aimé un titre un peu plus court ou un acronyme permettant de faire référence à ces documents, car « La cybersécurité pour les systèmes industriels » / « Méthodes de classification et mesures principales » n’est pas très pratique. Un peu de marketing ne nuirait pas !
Les points clés de la règlementation ANSSI
Classes de sécurité
A l’instar des « Security Levels » de l’ISA ou des « degrés de sécurités » dans le domaine nucléaire, l’ANSSI définit trois classes de sécurité, correspondant à trois niveaux de risques très globaux.
- une fabrique de clous de cercueils (exemple que j’emprunte au président de l’ISA France) avec un réseau industriel déconnecté de l’internet sera probablement de classe 1,
- une usine de fabrication de pièces mécaniques pour l’automobile utilisant des processus chimiques, de l’emboutissage automatique, avec de la maintenance à distance sera probablement de classe 2,
- et les usines chimiques classées Seveso, les INBs (installations nucléaires de base), les centrales nucléaires seront assurément de classe 3.
Comme dans les normes ISA, AIEA, NRC et les normes IEC, les classes peuvent s’appliquer à tout ou à des parties d’une installation. Par exemple pour notre sous-traitant de pièces auto de classe 2, la plus grande partie de l’installation pourrait être de classe 1 et seules les parties dangereuses pour la sécurité des personnes seraient éventuellement de classe 2.
L’ANSSI dans son document indique qu’on trouve la notion de « zone » dans « la littérature » : en effet ce concept est largement défini par l’ISA et l’IEC. Il permet de segmenter les parties des installations en zones avec des besoins de sécurité différents. On peut donc l’employer sans crainte que ce soit de la théorie uniquement.
Cette classification est très importante car suivant la classe de l’installation ou de la zone, il y a des exigences différentes en termes de cybersécurité, d’autant plus poussées que la classe est élevée. C’est logique et on trouve la même approche dans les autres normes citées.
Selon la classification, l’exploitant n’a pas les mêmes obligations générales vis à vis des autorités :
- classe 1 : le guide ANSSI formule des recommandations. En gros, si vous fabriquez des clous de cercueil, vous sécurisez si vous voulez, si vous êtes piratés et que votre production est H/S cela n’embêtera pas grand monde,
- classe 2 : vous êtes tenu de mettre en œuvre au moins toutes les « Directives » (dans les mesures détaillées il y a des « Directives » et des « Recommandations »), et vous pouvez êtes contrôlés,
- classe 3 : idem classe 2 mais en plus vous êtes tenus de faire certifier votre installation par un prestataire labellisé (un programme de labellisation pour les sociétés d’audit existe déjà pour la sécurité de l’information, et devrait s’étendre pour certifier des auditeurs).
Mesures détaillées de sécurité
Une quinzaine de catégories de mesures « organisationnelles » et autant de mesures « techniques » sont définies, avec des exigences variant suivant la classe. La couverture est bonne, les mesures font du sens en général pour l’environnement industriel, avec quelques soucis tout de même détaillés plus bas.
Les mesures sont accompagnées de commentaires et précisions claires : les documents sont vraiment utilisables !
On peut tout de même s’étonner qu’alors même que la plupart des normes travaillent à aligner l’organisation des mesures sur ISO 27001/2, y compris industrielles (ISA) ou nucléaires (IEC), l’ANSSI ait préféré créer son propre chapitrage. L’organisation du référentiel sur une base ISO 2700x aurait permis aux professionnels de la cybersécurité de s’y retrouver plus facilement.
Les points originaux et leurs conséquences
Le corpus d’exigences est ambitieux, ce qui est une bonne nouvelle. Mais dans une conjoncture économique où l’industrie en France se porte comme elle peut quand elle ne met pas la clé sous la porte, avec un niveau de sensibilisation des dirigeants faibles (et je suis optimiste), l’accueil de ces documents risque d’être assez peu enthousiaste et on peut se demander ce qu’il va rester de ces ambitions après « discussions » avec les lobbies et au niveau politique en général.
Pour la classe 3, qui concerne notamment les infrastructures critiques, on peut espérer que cela se concrétise. Pour la classe 2, les industries avec risques moyens sur les personnes et l’environnement, je suis curieux de voir si les budgets suivront… Peut-être les assureurs, qui commencent à savoir modéliser les risques de cyber-attaques, auront le bon argument : le montant des primes !
Évidemment, même si seule une partie des recommandations sont mises en œuvre (celles relatives à la sensibilisation, à la séparation des réseaux, aux contrôle d’accès pour citer les plus importantes à mon avis), on ira dans le bon sens. Mais seule une vraie responsabilisation et mise en œuvre d’un SMSI (management de la sécurité) digne de ce nom permettra de maintenir le niveau de sécurité à long terme.
L’approche probabiliste et ses conséquences
Pour classer une installation, deux paramètres sont pris en compte : l’impact en cas de cyber-attaque, et la vraisemblance que cela arrive – avec un tableau permettant de définir la classe en fonction de ces deux paramètres.
Sur le premier point, pas de soucis, l’ANSSI propose une grille d’impact orientée « société », c’est à dire ne prend pas en compte les impacts économiques pour l’opérateur (après tout, c’est son problème), mais uniquement ceux pour les personnes, l’environnement, et le service rendu à la population. Au niveau des détails des échelles qui comportent 5 niveaux, on trouve sur le même plan « un décès » et la « perturbation de l’économie nationale », cela semble curieux, enfin tant mieux pour les employés.
Par contre l’utilisation d’un paramètre « vraisemblance », qui est calculé entre autres sur la base du « niveau de l’attaquant » (au sens le niveau nécessaire pour réussir une attaque), est originale dans une approche d’étude d’impact. J’ai eu l’occasion au printemps 2013 d’animer un séminaire entre industriels qui avaient différentes approches d’impact, dont l’un avait utilisé une notion « d’effort » nécessaire à réussir une attaque, pour définir ses zones de sécurité. Après débats nous sommes convenus que cette approche n’était pas souhaitable, pour la raison suivante:
Le niveau de l’attaquant qui souhaitait pirater un automate industriel en 2010 était sans doute « Organisation privée » (niveau 4/5 selon l’ANSSI), car il fallait se procurer un automate, avoir des moyens d’études etc… D’ailleurs, à ce moment, il n’y avait aucune faille publiquement connue sur les automates. En 2014, le niveau de l’attaquant serait plutôt 2 (« hobbyiste » selon l’ANSSI), voire 1 (attaque non ciblée), car des codes d’attaques (« exploit ») sont librement disponibles sur internet par exemple sur exploit-db. N’importe qui peut faire on/off d’un automate, et assez facilement injecter du code.
L’un des paramètres permettant de définir la « classe » a donc fortement évolué en 4 ans. Vous pouviez avoir une installation de classe 1 en 2010, et vous retrouver avec des parties en classe 2 en 2014.
L’impact de l’approche de l’ANSSI est donc que la classe d’une installation, ou une partie d’installation, peut évoluer sans que celle-ci ne change en quoi que ce soit. Il y a deux conséquences à cela :
- les exigences concernant l’architecture des réseaux et les flux autorisés peuvent évoluer puisque la classe peut changer – ce qui n’est pas très pratique à gérer dans une installation industrielle, et c’est la raison pour laquelle dans le groupe de travail auquel je faisais allusion nous avons retiré le paramètre « effort »,
- il est nécessaire de ré-actualiser régulièrement l’étude de « classification », en plus de ré-évaluer régulièrement les mesures mises en place.
Alors pourquoi pas, c’est même une dynamique intéressante, mais cela va encore un peu augmenter les factures de conseil en sécurité pour les industriels.
Note rajoutée en juin 2014 : je suis obligé de corriger le point ci-dessous concernant la vraisemblance, après avoir mis en œuvre la méthodologie ANSSI pour un OIV. L’ANSSI a de fait soigneusement évité de prendre en compte des éléments évolutifs (type vulnérabilités, ou effort requis) dans le calcul de la vraisemblance, qui prend en compte trois types de facteurs :
- caractéristiques fixes des systèmes : connectivité, complexité,
- type d’authentification, traçabilité et contrôle d’accès aux systèmes,
- sources de menaces qui visent l’installation – avec systématiquement pour les OIV le niveau 5/5 (états étrangers).
Il s’agit donc de données factuelles fixes, à partir desquelles est calculée une valeur de « vraisemblance d’attaque ». Celle-ci se distingue donc d’une « probabilité de réussite », qui nécessiterait d’autres paramètres type vulnérabilité, niveau d’effort etc… L’approche reste assez complexe mais ne présente donc pas le défaut de définir des classes évoluant rapidement avec le temps. A noter que l’industriel peut cependant faire évoluer la classe en décidant de modifier certains paramètres pour baisser la vraisemblance ou l’impact, et tant mieux.
Autres particularités du référentiel
Une grille d’impact parcellaire à compléter dans l’intérêt de l’opérateur
L’ANSSI indique que parmi les critères DICP (voir cet article pour l’explication de l’acronyme), le plus souvent seuls la disponibilité et l’intégrité sont pertinents (document « classes » chapitre 3.2). C’est exact, et cela permet d’accélérer un peu les études d’impacts. Attention à ne cependant pas complètement oublier la confidentialité qui peut être un paramètre pertinent du point de vue économique pour l’exploitant (procédés sous licences etc…). Comme vu ci-dessous,, l’ANSSI ne se préoccupe que de l’impact sociétal : l’industriel doit penser également à son impact économique et devrait intégrer ce paramètre dans son évaluation d’impact, en plus des paramètres exigés par l’ANSSI.
Des règles draconiennes de flux entre SI de gestion et SI industriels
Le chapitre 2.2.10 (document « classes »), applicable aux installations de classe 3 uniquement, indique que l’interconnexion entre le système d’information de gestion et le systèmes de production doit être unidirectionnelle, via une data-diode par exemple (du réseau indus. vers la gestion). C’est une exigence qui a des impacts forts : le paramétrage ou les ordres de production doivent donc soit transiter sur papier pour saisie manuelle, soit via des medias ou PCs amovibles.
Or à notre époque, on considère qu’il vaut mieux établir un réseau sécurisé entre les SI de gestion et industriel (voir deux data-diodes « tête-bêche » – non ce n’est pas idiot…) , plutôt que d’entériner l’usage de media amovibles. De plus certaines industries, où le pilotage de la production est très réactif, ne supportent pas ce type d’exigence (ex : commandes arrivant dans SAP se traduisent en ordres de fabrication, réglages réguliers par grands nombres de paramètres, voir par exemple cet article qui propose plutôt la mise en place d’une « vraie » DMZ entre SI de gestion et SI industriel).
Ainsi dans le domaine nucléaire, les nouvelles normes (IEC 62645, règlementations anglaises 2012, allemandes 2014) suppriment l’ancienne option d’utiliser des medias amovibles, pour exiger des réseaux sécurisés « par couches » (plusieurs séparations entre le SI de gestion et l’industriel « sensible »).
Sans doute on atteint ici les limites d’un document générique, et que ce type de problème se résoudra par des approches adaptées aux différents secteurs industriels, comme annoncé par l’ANSSI.
Un seul oubli : la primauté des fonctions de sûreté sur la cybersécurité
En général dans les normes industrielles (ISA, IEC, AIEA, NRC) il est indiqué clairement que les mesures de cybersécurité ne doivent pas mettre à risque les mesures de sûreté – par exemple un pare-feu ne doit pas faire courir le risque qu’une alarme ne soit pas remontée à la supervision (SCADA). Ceci permet d’opposer aux exigences de cybersécurité une obligation de sûreté, et donc permet de ne pas mettre en œuvre telle ou telle mesure, à condition bien sûr d’expliquer comment on obtient le résultat équivalent.
Il y a à ce sujet une indication dans l’introduction du document « mesures détaillées » : « dans certaines situations des mesures ne peuvent s’appliquer sans adaptation ». Cependant si l’on consulte par exemple le paragraphe 4.2.7 « Sécurité des protocoles », on découvre pour la classe 3 une directive de chiffrement des communications (a minima pour authentification), avec comme alternative, si c’est impossible, de mettre en œuvre des VPNs et équipements périphériques… Tout cela n’est guère réaliste sur des réseaux terrain de sûreté !
Évidemment on espère bien qu’en audit on ne va pas refuser un plan de sécurité si une mesure contre-productive n’est pas mise en œuvre – mais c’est toujours utile de le formuler explicitement, pour éviter tout débat avec des auditeurs un peu trop près de la lettre et pas assez de l’esprit du texte.
On voit la nécessité d’adapter la règlementation aux différents domaines industriels, comme c’est d’ailleurs annoncé par l’ANSSI.
Conclusion
La France semble être bien partie pour rattraper son retard en termes de cybersécurité – retard qui avait été constaté par le sénateur Bockel dans son rapport de l’été 2012, lequel appelait à la définition et mise en œuvre de mesures ambitieuses en cyber-défense.
Reste à voir si l’ambition affichée dans les documents ANSSI va se traduire dans la loi et les décrets d’applications, et combien de temps sera octroyé aux industriels pour se mettre en conformité : aux USA et en Allemagne les installations nucléaires ont eu respectivement 2 et 3 ans pour se mettre en conformité avec les nouvelles exigences (2011 – USA, et 2014 – Allemagne).
Tags: ANSSI, Automates, France, Industriel, Normes, Réseau, SCADA
Avec son autorisation, je reprends ce commentaire fait par Hervé Schauer dans l’édition de mars de la newsletter HSC (www.hsc-news.fr) :
Pour moi la France seule dans cette voie va s’auto-flageller en réduisant la compétitivité de ses industries par des lois difficilement applicables qui ne profiteront qu’aux industriels dits de la « cybersécurité », qui ont profité dans le passé des marchés de la Défense. De même que les médicaments sont moins fabriqués en France pour éviter une législation contraignante, nous allons faire pareil sur l’industrie, et celle qui ne peut se délocaliser comme l’eau ou l’électricité répercutera le surcoût sur le consommateur.
Je pense qu’il faudrait rechercher l’avantage compétitif de nos industriels, en développant des certifications internationales, et accompagner la France vers celles-ci.
Pour résumer ma pensée, exprimée ci-dessous de manière plus argumentée je dirais,
Bravo !
MAIS,
- les mesures proposées manquent d’ambition (par rapport à une ISO/IEC 27k ou une IEC 62443)
- la méthode de classification est trop perméable (son niveau d’application fait fi des détails).
db
1] L’exposition
Compresser la pyramide CIM en 3 niveaux est une excellente chose [*] car les frontières entre niveaux s’estompent. Et rapidement s’il vous plaît.
Heureusement que « L’ensemble des mesures présentées ont été pensées pour des nouveaux systèmes industriels. » (§1.2, page 6 des mesures détaillées).
En effet, dès aujourd’hui nous avons des automates équipés de fonctions de gestion PC industriels de chez Beckhoff) et je suis convaincu que ce type d’automate assurera des fonctions de supervision, même déléguées (sonde agrégateur OPC-UA pour un groupe d’automates par exemple), d’ici 3 ans. C’est un PC sous x86 et Linux et ça peut donc tout faire y compris (trans)porter des infections. De même que les actionneurs intelligents existent déjà (ils communiquent directement avec le SCADA et comporte des services d’automatisation).
Tout cela rend, sur les nouvelles implantations (pas les anciennes), la segmentation fonctionnelle légèrement plus compliquée qu’elle n’est présentée.
L’exposition est un facteur pertinent ça ne se discute pas (on l’a retrouve dans EBIOS) mais ses composantes manquent, de mon point de vue, de définition.
Parler de fonctionnalités me dérange.
Plutôt que de parler de fonctionnalités il vaudrait mieux, j’en suis convaincu, parler de susceptibilité/sensibilité à la manipulation (infection) d’un équipement et ce, indépendamment de sa qualification.
Un actionneur à l’ancienne a ainsi une telle susceptibilité quasi-nulle, un automate en possède une plus importante selon son âge (surtout s’il s’agit d’un PC), un SCADA, historian, un serveur OPC-UA c’est pire. Un capteur intelligent est excessivement fragile, surtout s’il est sans fil, sans authentification et non confiné et il dispose donc d’un d’une sensibilité équivalente voire supérieure à celui d’un automate. Et pour autant pour des fonctionnalités somme toute réduites.
Pour la connectivité ce n’est pas mieux.
En effet, identifier la connectivité de la manière proposée va conduire systématiquement à une sous-exposition et à de sérieuses déconvenues. C’est peut-être l’objectif recherché …
2 exemples pris au hasard de l’expérience :
– lecteur de badge de portail isolé connecté en sans-fil (WiFi) pour des raisons de coût (comme toujours), au système de gestion des badges (1 serveur sur réseau de gestion), il n’y a pas de sans-fil au sein du système de production mais au sein du système de gestion. Dans quelle catégorie sommes-nous ?
– sous-traitant intervenant par rebond sur une machine du réseau industriel (modem sur concentrateur de terminaux via liaison privée) : a priori connectivité 4 sauf que le sous-traitant s’est fait piraté le réseau local (via plusieurs postes de travail ayant récupéré un PDF forgé de telle manière à installer un cheval de Troie établissant une relation permanente avec un serveur CC). Le réseau industriel du client est donc accessible par rebonds multiples et est, de fait, connecté en entrée à Internet. Nous sommes donc en connectivité de niveau 5 (réelle) et non de niveau 4 (supposée).
Ensuite il y a le cas des liaisons sans-fil utilisées en tant que backbones privés (WiMax) et le cas de la liaison VPN sur réseau public.
Cette dernière est-elle vue comme une liaison privée ? Bien configurée c’est le cas. Mal configurée (PKI insuffisante) c’est de l’Internet.
Je pense qu’il était bien plus simple de commencer par envisager 2 cas uniquement (comme d’autres référentiels le pratiquent, la notion de conduits de l’IEC 62443 me semblant nécessiter pas mal de maturité pour l’appliquer) :
– aucune connectivité (vraiment, pas même une paire téléphonique ni l’ombre d’une antenne) ;
– présence d’une connectivité quel qu’en soit le support et quelle que soit la pile protocolaire concernée (avec un PC on fait ce qu’on veut, IP ou pas).
En effet, à partir du moment où il y a connectivité avérée personne ne peut prétendre à l’absence d’entrée depuis Internet là-bas dans un pays lointain.
–
db
Bonsoir,
Mes remarques sont découpées en 2 parties : les remarques à proprement parler (14k) et les notes (8k).
En résumé je trouve là un bel effort.
Mais :
– les 2 documents principaux (classification et mesures détaillées) sont présentés de manière incorrecte,
– la méthode de classification me semble trop perméable
– et les mesures proposées sont largement insuffisantes.
Une mauvaise présentation fait perdre du temps dans l’assimilation des informations, l’imprécision de la classification risque de conduire à des manipulations/falsifications et l’insuffisance des mesures ne permettra pas à un RSSI ou à un coordinateur de travailler correctement.
Cependant, l’intérêt de ces documents qui constituent ce que nous pouvons appeler le « standard de la cybersécurité française » (et non norme s’il vous plait) ne se dément pas.
Ils ont vocation à avoir la même valeur qu’un PCI-DSS pour le secteur des marchands (paiements CB) ou encore … IEC 62443 pour le secteur de la cybersécurité internationale.
Mais j’aimerais en être convaincu.
Quoi qu’il en soit les défauts listés sont embarrassant (temporairement ?) car je pense que bon nombre « d’entités » voire des conseils vont utiliser ces documents en l’état, quasi-religieusement par crainte d’une non-certification ou par recul devant l’ampleur de la tâche réelle.
Et je subodore de grosses déceptions ce qui est dommage pour des documents censés guider les orientations de tout un secteur.
Bon, ok, c’est un « premier jet », les cibles sont immatures de toute façon et, in fine, si je le compare avec les premières versions de PCI-DSS ce n’est, au final, pas si mal que cela.
Mais ce travail DOIT être poursuivi en, en vrac, développant des métriques, des règles d’application de ces derniers, des indicateurs d’entrée pour les évaluations (niveau de menaces ambiant délivré par une cellule spécialisée, un CERT), une liste de points de contrôle en vue de reboucler sur l’analyse etc, etc.
Parlons un peu de forme à présent.
Je ne vais pas détailler les questions de couleurs mal choisies, une sorte de refus de ne pas embrayer sur des notions pourtant affirmées et canoniques comme
la gestion du changement, la gestion des configurations, la gestion de la conformité, le cycle PDCA, une approche par les processus ; toutes choses qu’un équivalent documentaire comme le « NIST framework for cybersecurity » ne renie pas.
1. le document de classification DOIT rester un document dédié à la méthode de classification. Le « rappel » des mesures ne fait que troubler la lecture.
2. Le document des mesures détaillées aurait largement gagné à ne pas être rédigé d’une manière littéraire (comme un bouquin) mais DEVRAIT être organisé :
– par thème (pris dans ISO27k c’est le plus simple, cf IEC 62443 et cela permet de ne pas oublier des mesures),
– puis par classe,
– puis enfin par type de travaux à réaliser :
. organisation,
. technique [configuration, investissement],
. documentaire et
. règlementaire voire, également,
. par catégorie EBIOS si je suis EBIOS : prévention/protection/récupération ;
. par acteur (entité, fournisseurs, sous-traitant, accompagnant, etc).
À cela s’ajoute une méthode préconisée pour valider la bonne implantation de l’exigence (points de contrôle).
Ou prévoir accessoirement un document supplémentaire listant ces points de contrôle (à la CoBiT ou plutôt à la NIST SP-800 53).
On obtient, ainsi, une vision globale des actions et des moyens à engager et, surtout, établir des plannings.
Et il est alors bien plus aisé de suivre l’avancement du projet et d’en dégager des priorités.
Par exemple, la gestion des vulnérabilités incorpore de la technique (outillage), c’est vrai. Mais c’est avant tout une mesure organisationnelle !
Même chose pour la gestion (il y a « gestion » ce n’est donc pas pour rien) des comptes, de l’authentification : il y a pour tous ces thèmes une grande partie organisationnelle.
Du reste le terme processus y est évoqué.
Si je prends le sujet des sauvegardes j’ai du technique, de l’organisation, du documentaire parfois du réglementaire (régime de la preuve) et des conséquences sur d’autres thèmes.
Venons-en à présent au fond.
Les mesures
Au hasard : des notions pourtant essentielles comme la longueur de clés, le recrutement, l’étiquetage des medias, etc mériteraient d’appartenir au référentiel.
La méthode de classification
Les mesures s’appuient sur cette gradation, il ne faut pas se louper : passer d’une classe 2 à une classe 3, ce n’est pas le même investissement !
Le résultat d’une telle classification, si jamais il s’avère négociable manquera pas de devenir un sujet politique voire d’activer du lobbying (en vue de réduire le niveau) le cas échéant. Avec des conséquences potentiellement houleuses pour le « classifieur ».
Et, pour le coup, je suis loin d’être convaincu de la facilité de détermination de la classe cultivée par les exemples joints.
N’était-il pas envisageable de trouver un déterminant simple comme celui issu d’un autre classement (Séveso ?).
Ceci à la manière d’un PCI-DSS qui évalue la classe en fonction du nombre d’opérations CB par an. Au moins, là c’est indiscutable.
Mais, quitte à disposer d’une méthode raffinée de calcul, je suis contre l’approche globale (les intervenants et les attaquants au sens large), qui prévaut ici : elle conduira inéluctablement à des effets de bord (par omission volontaire ou non, par raccourci [ah, le budget !], etc).
Les méthodes d’études de risques parlent du reste de sélection des scénarios pertinents. Tout n’est donc pas à prendre en compte (compétence d’un attaquant, habilitation d’un intervenant) selon le périmètre envisagé.
Et l’approche individuelle (dispositif par dispositif) de l’IEC 62443 avec une règle de composition afin de calculer le SL au niveau de la zone (et/ou des conduits) me semble une bien meilleure option, bien plus « fail-proof » (mais pas forcément plus « political-proof ») et, de surcroît, évolutive.
La sécurité est dans les détails, souvent.
Ensuite, et les détails de ma réflexion sont en [1], parler de fonctionnalités me dérange de même que de connectivité car il s’agit, dans ces « guides », de notions envisagées encore une fois d’un point de vue global (le site).
Je pense, encore une fois, que la stratégie du particulier au général (bottom-up) est ici préférable (quitte à conduire à un surcroît de travail) en privilégiant le niveau de sécurité d’un dispositif individuel (dans sa sensibilité à la manipulation et dans son niveau de connectivité) ; dispositif que l’on peut suivre tout au long de sa vie (grâce à l’inventaire) et qui transporte alors avec lui sa propre exposition et donc son propre niveau de sécurité.
Car, enfin, c’est bien LUI que l’on cherche à protéger, lui en tant que membre critique du réseau industriel !
La durée d’indisponibilité
Dans les différentes échelles de gravité décrites dans les « guides » je n’ai pas aperçu la notion de durée d’arrêt de service afin d’estimer l’impact consécutif à celui-ci.
L’ANSSI prévient bien que la méthodologie doit être adaptée selon le contexte (§3.3.2 page 27).
Mais je pense que ne pas faire apparaître cette variable, dans cette version des « guides », est une erreur.
Elle intervient dans le calcul de la vraisemblance souvent avec sa consœur, l’heure de survenance.
Il s’agit donc, d’une composante majeure du calcul de la gravité (ou du risque de manière générale).
Cette variable apparaît bien dans EBIOS sous la forme d’un besoin en sécurité et elle est, bien entendu, détaillée dans l’IEC 62443-3-2.
III. Conclusion
Quiconque voudra s’atteler à un audit, appliquer des mesures de sécurité cohérentes et établir des points de contrôle chez un client industriel DOIT d’ores et déjà construire son propre référentiel basé sur son expérience, l’ISO/IEC 27k et l’IEC 62443 surtout. Et ce, tout en accusant le différentiel d’avec ces mesures « ANSSI ».
L’exercice est classique et on ne s’en sort pas à moins de 400 recommandations (en 2013) dont certaines sont en plus des directives selon la classe ciblée.
Mais ces recommandations seront-elles certifiables ?
Là encore, quid pour le cabinet qui élabore sa propre méthode de détermination de la classe ? Pourra-t-elle être certifiée ?
Est-il entendu que le travail accompli dans ce « premier jet » de l’ANSSI constitue un cœur de mesures que l’on doit absolument retrouver dans les référentiels privés sous peine de non-accréditation et non-certification ?
« Reste à voir si l’ambition affichée dans les documents ANSSI va se traduire dans la loi et les décrets d’applications »
En France, comme dans la plupart des pays latins, je pense qu’il n’y a que la sanction qui vaille. Pas de sanction en vue, on ne bouge pas. Surtout en temps de crise.
Et puis il y a la gouvernance. Et pour elle la SSI c’est souvent très bien … sur le papier et dans les salons. Et, surtout, tant que ça ne coûte rien.
Mais dès qu’un VIP veut utiliser le dernier iPad pour frimer ou que la direction du marketing ou de la comm souhaitent utiliser les réseaux sociaux ou encore que la DSI souhaite économiser 3 francs et 6 sous sur l’hébergement de courriel et bien, on oublie très vite les belles promesses.
Bref, comme pour tout système de management, sans adhésion franche, comprise et pérenne d’une DG, AUCUN espoir.
Et là j’ai de véritables doutes.
Attendons donc les décrets à présent.
—
db