Infrastructures critiques : le framework du NIST reçoit un accueil mitigé

Le développement d’un cadre pour la sécurité informatique des infrastructures critiques a été initialement demandé par le président américain Barack Obama il y a un an, au NIST, l’organisme chargé de la définition des standards technologiques outre-Atlantique. Pour Barack Obama, un tel cadre était devenu nécessaire du fait de la multiplication des menaces informatiques visant les actifs des infrastructures critiques, et pouvant potentiellement affecter la sécurité des Etats-Unis, tant physique qu’économique. Pour lui, ce framework « marque un tournant » : « il est clair qu’un travail bien plus important doit être conduit pour améliorer notre cybersécurité. Nos infrastructures critiques continuent d’être menacées dans le cyberespace et notre économie est affectées par le vol de notre propriété intellectuelle »  ainsi expliqué le président américain.

Une version préliminaire du framework NIST avait été présentée en octobre dernier. Elle a ensuite fait l’objet d’un examen durant 45 jours, par les parties concernées, afin d’intégrer leurs commentaires à la version finale. Il semble que peu de choses aient finalement changé entre les deux versions, hormis la suppression d’une bonne partie des détails initialement fournis pour la protection de la vie privée et des informations personnelles identifiables.

Trois sections

Le framework du NIST s’organise in fine autour de trois sections. La première, le coeur du document, vise à guider les organisations vers d’autres standards déjà validés, tels que le NIST 800-53, lorsqu’elles doivent déterminer la manière de gérer certains risques informatiques. Si, par exemple, une organisation décide qu’elle a besoin de protéger les identifiants d’un utilisateur, le framework renvoie directement à des sections spécifiques de Cobit 5, d’Iso 27001, et d’autres standards.

Pour l’évaluation de la maturité des programmes de sécurité informatique, le framework compte quatre niveaux d’auto-évaluation. En bas de l’échelle, les organisations de tier-1, décrites comme n’ayant pas formalisé de pratiques et de processus de gestion du risque, et n’ayant que peu conscience des menaces informatiques. A l’opposé de l’échelle, les organisations de tier-4 sont connues pour adapter « leurs pratiques de cybersécurité en fonction des leçons apprises et des indicateurs prédictifs dérivés des activités passées et actuelles de cybersécurité », sont bien conscientes des menaces, et ont mis en place les processus nécessaires pour y faire face.

Le framework encourage en outre les opérateurs d’infrastructures critiques à créer des « profils » - pour l’essentiel un résumé des informations de son programme de sécurité informatique - conçus pour établir une roadmap de réduction du risque en fonction des besoins métiers, de la tolérance au risque, et des ressources sécurité spécifiques à l’organisation. Le profil d’une entreprise vise ainsi à fournir une idée générale de l’état de son programme actuel de cybersécurité ainsi que l’objectif vers lequel elle tend. Le framework encourage les entreprises à comparer leurs profils entre elles afin d’identifier les décalages potentiels dans leurs stratégies de gestion du risque. Toutefois, le framework ne fournit pas de modèle pour la création de ces profils.

Comment implémenter ce framework

Michael Assante, chef de projet ICS et Scada de l’institut SANS, estime que le framework arrive à temps. Hélas, selon lui, il échoue à tenir compte de la nature ciblée des menaces. Pour Assante, les recommandations du framework du NIST sont trop « vagues ». Et d’affirmer que lui-même ne saurait pas comment les implémenter. En particulier, le coeur du framework fournit aux organisations toute une série de contrôles basés sur des situations généralistes sans, selon lui, tenir compte des menaces spécifiques à certaines industries et organisations.

Par exemple, Assante relève que les attaquants visant les systèmes de contrôle industriel (ICS) misent sur l’établissement de connexions avec les infrastructures de commande et de contrôle pour accéder à des informations sensibles. Pour gérer ce risque, les organisations devraient s’appuyer sur le filtrage des communications sortantes et les surveiller pour stopper toute exfiltration de données. Las, les professionnels de la sécurité des ICS ne trouveront pas un tel conseil dans le framework du NIST. Et si Assante estime que l’approche généraliste du NIST pourrait être positive pour provoquer la discussion, il s’inquiète du risque que les organisations l’adoptant ne cherchent à mettre en place trop de contrôle. « Le langage employé est important dans n’importe quel standard. Et là, il y a de l’incertitude dans le langage utilisé, » estime ainsi Assante, ajoutant que « c’est là que l’implémentation devient difficile. Trop de choses sont laissées à l’interprétation, ce qui signifie que l’on dit aux gens de faire des choses, mais l’on ne sait pas s’ils les font vraiment, ou s’ils les font d’une façon qui marque une réelle différence. »

Chris Coleman, Pdg de Lookingglass Cyber Solutions, estime également que le framework a peut-être été un peu « dilué ». De sorte à atteindre un consensus, il pense que le NIST pourrait avoir élargi le framework en raison de sa douloureuse expérience avec le document 800-53, qui présente les lignes directrice de cybersécurité pour le gouvernement fédéral. Alors qu’il occupait les fonctions de directeur en charge de la cybersécurité chez Cisco, Coleman a fait partie de l’équipe qui a cherché à appliquer ce document à l’offre de l’équipementier pour ses clients gouvernementaux. Et s’il en souligne les bons côtés, il relève qu’il contient aussi trop de contrôles de sécurité - détaillés sur plus de 130 pages… - pour être aisément applicable au secteur privé.

Surtout, pour Coleman, l’effort de simplification du NIST avec son nouveau framework pourrait s’avérer contre-productif, ce document pouvant être considéré comme trop « basique » par les organisations ayant déjà atteint un certain niveau de maturité. Selon lui, les organisations choisissant d’adopter le framework vont soit trouver qu’elles n’ont aucun moyen de s’évaluer par rapport à lui, ou se retrouver perdues dans un déluge de contrôles et d’informations liés aux standards auxquels se réfère le framework. « Le défi est que le NIST devait simplifier. Mais la question est de savoir s’il est allé trop loin. Adopter ce framework représente encore beaucoup de travail, notamment pour comprendre ce à quoi correspondent toutes ces références, » explique Coleman.

Mais pour Dave Burg, patron de la practice conseil en cybersécurité de PwC, qui a participé au développement du framework du NIST, ces critiques passent à côté des intentions de l’organisme. Et d’expliquer que le but final du document est de fournir une base à partir de laquelle tous les opérateurs d’infrastructures critiques peuvent s’évaluer, mais en tout cas pas « partir de zéro », ni renoncer aux standards existants. Et selon lui, le framework n’est pas pensé comme seul mécanisme d’évaluation, mais plutôt comme référence pour évaluation objective des programmes de sécurité existants et de leurs failles.

Par exemple, dans l’édition 2014 de l’étude de PwC sur l’état mondial de la sécurité de l’information, Burg a relevé que 26 % des répondants n’ont pas réalisé d’évaluation initiale de sécurité pour déterminer quels actifs doivent être protégés, faisant ainsi l’impasse sur l’une des bases de la construction effective d’une cybersécurité en entreprise. « A chaque fois qu’une organisation veut se critiquer, s’évaluer, et utiliser pour cela une référence, je pense que c’est très important, » estime-t-il ainsi. « Et trouvera-t-on à partir de là des failles jusqu’ici non identifiées dans des programmes de sécurité matures et efficaces? Peut-être pas. Mais je pense que l’objectif est ici de simplifier l’environnement d’évaluation. »

Bâtons et carottes

Aussi surprenant que cela puisse paraître, aucun des experts interrogés ne s’est préoccupé de la nature exclusivement volontaire du framework, l’un des points pourtant les plus critiqués avant sa publication. De fait, le framework ne fournit pas d’élément de motivation concret, et les opérateurs d’infrastructures critiques qui ne souhaitent pas l’adopter ne seront pas sanctionnés. Burg répond à cela que le processus de création du framework aurait été « ralenti » s’il avait revêtu un caractère obligatoire et qu’il est préférable que les organisations pilotent elles-mêmes leurs activités dans ce domaine.

Pour Assante, la nature même du décret présidentiel a éliminé tout « bâton » pour potentiellement sanctionner les organisations qui n’adoptent pas le framework, laissant au NIST et aux officiels du gouvernement la charge de proposer des « carottes. » Il a ainsi entendu parler de taux d’assurance susceptibles d’être modulés en fonction du niveau de maturité des organisations, tel qu’évalué dans le cadre du framework. Toutefois, selon lui, de véritables indicateurs sont nécessaires avant que de telles propositions ne voient véritablement le jour.

De son côté, Coleman s’inquiète du risque de faire de créer une culture « checkbox » de la sécurité associé au fait de rendre obligatoire l’adhésion à des standards. En outre, selon lui, le framework n’est pas prêt, en l’état, pour une telle chose. « Je ne pense pas qu’il soit suffisamment mature pour pousser qui que ce soit à l’adopter, » estime-t-il ainsi. « Si Lookingglass voulait l’adopter aujourd’hui, je ne suis pas vraiment sûr de ce que l’on adopterait. »

Quel avenir pour ce framework ?

Au côté de cette version 1.0 de son framework, le NIST a également présenté un calendrier qui fournit quelques indications quant aux domaines sur lesquels l’institut entend travailler à l’avenir pour le faire évoluer. Le NIST entend ainsi développer des recommandations autour des différentes formes d’authentification, du partage automatisé d’indicateurs, et de la gestion du risque tout au long de la chaîne logistique.

Pour Burg, la mention d’un renforcement du partage d’informations est prometteuse, même si elle intrigue nombre des clients de PwC. Coleman relève également qu’un nombre croissant d’organisation commencent à reconnaître le besoin d' un partage d’informations plus grand. Mais il souligne avec prudence les freins naturels à la mise en oeuvre et à l’adoption : « le défi du partage en général, c’est que les personnes ne partagent que si elles estiment qu’elles ont quelque chose à gagner des informations qu’elles sont susceptibles de recevoir en retour. C’est peut-être simplement dans la nature humaine, mais cela n’en constitue pas moins un important défi culturel. »

Assante a appelé le NIST à compléter le standard avec plus d’indicateurs de sécurité et à offrir aux organisations plus de conseils techniques pour contrer les attaques ciblées. Toutefois, son expérience des approches orientées NIST, notamment lors de travaux sur les standards liés aux smartgrids, lui permet de comprendre à quel point il peut être difficile d’impliquer les experts « très occupés » qui seraient capables de fournir les apports nécessaires à un effort « orienté processus. » Et de se demander : « est-ce que le NIST dispose d’un processus qui lui permettrait de tenir compte de la nature dynamique de la menace informatique et d’avancer vers quelque chose de mieux qu’un simple point de départ ? J’ai bien peur que le NIST doive composer avec un processus de consensus et que c’est cela, plus qu’autre chose, qui va présider à la destinée du framework. »

Adapté de l'anglais par la rédaction.