Il était annoncé, donc attendu, et il est arrivé avec l’été : un guide de l’ANSSI intitulé « Maîtriser la SSI pour les systèmes industriels », accompagné d’un « Cas pratique ».

Sa seule existence est déjà utile pour « officialiser » le sujet, voyons en détail ce qu’il contient et comment l’utiliser au mieux.

La première remarque que j’ai entendue de tous les lecteurs, est son excellente qualité rédactionnelle : « ça se lit très bien », et c’est important pour être accepté dans les équipes de direction des industries françaises !   C’est d’ailleurs en filigrane la cible visée : trop précis pour être une simple « plaquette » qui ne ferait pas sérieux, et pas assez développé pour être un vrai équivalent du document qui s’en rapprocherait le plus (le NIST 800-82 américain), c’est avant tout un outil de communication intelligent, et il faut vraiment le mettre entre toutes les mains.

Ainsi par exemple les auteurs évitent-ils intelligemment le jargon de la « SSI », à l’exception de l’incontournable « C,I,D » mais qui est bien présenté. (C,I,D sont les initiales de confidentialité, intégrité, et disponibilité, et donc, pour en savoir plus, le mieux est de consulter le document de l’ANSSI qui explique ces concepts mieux que je ne saurais le faire…).

Certains mythes qui ont la peau dure sont dénoncés efficacement : NON, un réseau industriel isolé n’en est pas protégé pour autant, au contraire. Tout les professionnels le savaient, d’expérience malheureusement quelquefois, mais ça aide d’avoir un doc. officiel qui explique pourquoi. Dans une version « non officielle », on pourra relire l’article de ce blog sur le sujet.

L’importance du risque lié aux actions non intentionnelles, non malveillantes, est bien expliqué (clés USB qui se promènent, PCs de maintenance…).

Le panorama est bien fait sur les différentes mesures et aspects de la sécurité :

• défense en profondeur,
• importance de la prévention mais aussi de la détection et de la réaction,
• la sécurité durant les projets et les bonnes pratiques : si on conçoit un système avec une architecture de sécurité de course, mais que les plans sont dans la nature et que certaines portions de codes sont livrées avec des modifications non commandées… on n’a rien gagné !
• prise en compte de la sécurité dans le MCO (maintien en conditions opérationnelle – maintenance en résumé) et au niveau achats : quelques bonnes consignes

Des annexes… étonnantes…

• une annexe A intéressante, qui donne une liste d’une douzaine de vulnérabilités majeures, ce qui ressemble un peu à la démarche du DHS américain. On regrettera que les sources ne sont pas indiquées (est-ce statistique par rapport à des incidents ? Par rapport à des audits ANSSI ? Le « feeling » des experts ANSSI ?), et on peut aussi regretter une absence d’indication de l’utilité de ce type de liste, à commencer justement par des analyses de risques travaillant sur la base de ces vulnérabilités majeures. Bref une bonne liste mais un peu « cheveu sur la soupe » dans le document, et qui mériterait un meilleur traitement.
• même problème pour l’annexe B qui est une liste de bonnes pratiques. Pour le coup, si le document s’adresse aux professionnels, il ne leur apprend rien (enfin j’espère !), et si le document s’adresse aux dirigeants : l’absence (normale) de priorité ne leur apporte rien. Cela peut tout de même rassurer le lecteur sur l’existence de solutions en termes de mesures de sécurité. A noter quand même une « bonne pratique » BP12 « protection des automates » un peu décalée par rapport à la réalité de la vulnérabilité des automates, les mesures suggérées ne permettant pas d’atteindre un degré de sécurité correct.

Les regrets :

Formations

La partie « sensibilisation » (formation) est très légère, 4 lignes… Or la formation large du personnel offre sans doute le meilleur retour sur investissement des différentes mesures possibles : cela ne coûte pas cher, et vue l’importance du comportement notamment pour les incidents non intentionnels (ils insistent pourtant bien là-dessus), un peu plus de messages sur le sujet serait bienvenu. Ce n’est peut-être pas du domaine d’expertise de l’ANSSI ? Les principales normes de sécurité des SIs industriels développent largement le sujet en général (ISA 99, NIST, DHS, AIEA NSS #17…)

Analyse de risques

Le document précise que les principes de l’analyse de risques ne diffèrent pas de la sûreté de fonctionnement. Ça c’est très surprenant : on peut utiliser une échelle des conséquences proche (échelle de conséquences type telle le modèle proposé par l’ISA), mais il y a déjà à ce niveau de vraies différences, par exemple les échelles de conséquence de la sûreté de fonctionnement ne considèrent pas le risque d’interruption de production ! Par ailleurs, les autres paramètres de l’analyse de risque sont eux très différents (source de menaces, menaces, vulnérabilités). L’ANSSI rappelle l’existence d’EBIOS sans trop insister pour que ce soit la méthode à utiliser, mais on peut regretter qu’il ne soit pas fait référence :

• en termes de principe plutôt à ceux d’ISO 27005, disponible en français, et qui se lit très bien et permet d’acquérir le vocabulaire courant de l’analyse de risques,
• en termes d’échelle de conséquence et de méthode, à l’ISA 99, qui devient d’autant plus légitime que la CEI a adopté et transcrit en norme internationale sous la référence IEC 62443.02 le document correspondant

Ce n’est pas très important car le document de l’ANSSI ne s’adresse pas aux professionnels qui mettront en œuvre ces outils, mais aux managers qui doivent prendre conscience du besoin, cependant cette annexe amène plus de confusion que de clarté.

La veille

Rappelée à juste titre comme « une mesure fondamentale », on reste un peu sur sa faim, faute d’indications de source pratiques d’information. Le CERTA ANSSI est mentionné, mais il traite peu des vulnérabilités industrielles. Il est conseillé de se rapprocher des constructeurs, mais ceux-ci sont encore peu matures sur le sujet, quand ils ne cherchent pas simplement à vendre plus grâce au nouveau créneau « cybersécurité.

Evidemment il ne serait peut-être pas très « politiquement correct » dans un document du gouvernement français de rappeler l’existence du CERT ICS américain, mais c’est tout de même de loin la meilleure et plus exhaustive des sources d’information, bien qu’en Anglais seulement. Ne pas donner cette information clé est dommage, tous les professionnels de la sécurité des SIs industriels utilisant largement cette source.

Les autres normes et standards

De manière générale, le peu de référence aux normes existantes, même si elles ne sont pas encore bien abouties, et aux sources d’informations utiles en cybersécurité industrielle, même en Anglais, me semble regrettable. Les seules références sont celles aux autres publications de l’ANSSI et au CERTA, qui restent très limitées. Il existe pourtant un certain nombre de sources utiles en français, répertoriées dans un article de ce blog.

Le cas pratique

Concernant le cas pratique (document disponible sur la même page web) une première partie verbeuse narre une visite d’un « coordinateur » sur un site industriel et qui découvre un certain nombre de problème (clés USB etc…), on pourra passer cette section, d’autant plus qu’il est noté, à propos d’un poste Windows « Il peut être utile de réaliser des tests d’intrusion depuis ce type d’équipement » : étonnant que l’ANSSI prône encore des tests d’intrusion sur une installation en production, avec les possibles dégâts que cela peut causer. Rappelons que le document du NIST américain (800-82 ayant fait l’objet d’un article) rappelle pourquoi il est totalement exclu de réaliser des tests d’intrusions en environnement actif, avec comme argument à l’appui deux incidents causés par ce type d’action.

La suite (chapitre 4 – le bilan) est plus intéressante surtout par des exemples de représentation graphique de l’installation, du découpage fonctionnel, des flux etc… ce qui permet de donner de bonnes idées sur la manière de réellement « traiter » l’installation.

L’annexe B illustre bien les différentes approches de connexion sécurisée entre les réseaux « bureautiques » et industriels (« DMZ »), sur ce point l’ANSSI a de bonnes sources…

Deux autres annexes sont très intéressantes, et mériteraient de figurer dans le document principal :

• annexe D sur les 10 règles pour l’utilisation des SCADA
• plus anecdotique mais il est rare de trouver ces recommandations claires : l’annexe C sur les astuces pour limiter l’usage des clés USB sur les systèmes Windows antérieurs à Windows 7. Dommage quil ne soit pas clairement indiqué que les consignes concernent uniquement Windows XP, et que Windows 7 apporte de manière native des mécanismes de contrôle des médias USB, pilotable via des « GPO » (règle de sécurité groupe) par ActiveDirectory. Pourquoi ne pas plus directement recommander d’essayer de migrer vers des versions plus récentes de Windows ? Enfin, il est vraiment étrange de ne pas rappeler la fin de la période de support de XP en Avril 2014 : après, plus de patchs de sécurité !

Conclusion

Le document est indiscutablement utile et bien conçu. Il faut le diffuser largement, notamment aux directions industrielles. Le « tampon » officiel ANSSI permet de porter un message avec plus de légitimité que tel ou tel blog ou publication américaine. C’est donc une contribution attendue, et bienvenue.

Les manques de pistes pratiques vers les sources d’informations, d’assistance etc… reflètent en partie la réalité (peu de choses en France), et est en partie un choix de ne pas faire la publicité de sources d’informations et acteurs privés ou étrangers. On peut le comprendre mais cela limite l’utilité pratique du document, au delà de la prise de conscience : de mon expérience les professionnels de la sécurité des SIs ne connaissent pas si bien que ça les sources d’information disponibles dans le domaine industriel.

Tags: ANSSI, Industriel, NIST, Risques