ma présentation au workshop cybersécurité du M.I.T. – les métriques de sécurité

Ce post est la suite d'un premier article publié ici.

Avouons-le tout de suite, je n’aime pas les « standards de sécurité reconnus ». Ils sont trop souvent rédigés par des filières académiques coupées de la réalité du terrain ou par des techniciens coupés de la réalité business. Au sujet des métriques, les exemples ne manquent pas.

Dans le contexte des métriques, il est bon de rappeler ce que je pense être l’objectif principal des métriques : apporter des informations pertinentes aux preneurs de décisions, afin qu'ils fassent des choix adéquats. Il me semble que (trop) souvent, le but initial s’est perdu.

de quoi parle-t-on ?

Vu l’audience du workshop, je me suis focalisé sur les standards américains. Le NIST – National Institute of Standards and Technology publie une liste de standards très intéressants, dans les technologies de l’information, la série SP800 est mondialement reconnue. En toute logique, j’ai commencé par parler du standard SP 800 – 55 Rev1 Performance Measurement Guide for Information Security.

Si le responsable du MIT m’avait demandé d’épargner la NSA (c.f. post précédent), il n’avait rien précisé à propos du NIST. Je vais donc pouvoir dire ce que je pense de ce standard, sans retenue. En fait, j’ai pris les premiers métriques recommandées par le NIST (Annexe A du standard) et je les ai démontés une par une. Extraits :

mesure 1: budget sécurité

La formule pour calculer le budget sécurité : faire le pourcentage du budget IT dévolu à la sécurité des informations.

Mon commentaire : pour avoir un bon résultat « sécurité » il me suffit juste d’être moins efficace que le reste de l’informatique. Ou que le niveau de sécurité de base de l’IT soit si mauvais qu'il faille dépenser des fortunes pour rattraper la situation.

Ma suggestion : et si on mesurait le budget par rapport à l’exposition des risques ?

mesure 2 : gestion des vulnérabilités

La formule pour calculer la gestion des vulnérabilités : faire le pourcentage des vulnérabilités présentant un risque élevé qui ont été remédiées dans le délai défini.

Mon commentaire : pour avoir un bon résultat, je n’ai qu’à réduire l’évaluation du danger dans le contexte de l’entreprise, ou mieux, de définir un délai de déploiement des correctifs suffisamment long pour qu’il me soit aisé d’y remédier. C’est exactement ce qu’avaient fait les compagnies aériennes lorsque la Commission Européenne les avait forcées à ce que les vols soient à l’heure : ils ont augmenté la durée de tous les vols !

Ma suggestion : et si on définissait le délai sur la base de l’exposition aux risques (est-ce qu’il y a un malware exploitant cette faille ? est-ce qu’il y a un exploit dans Metasploit ? est-ce que dans le contexte de l’entreprise la faille pourrait être exploitée ou pas ? etc.) Et si on ne parvient pas à déployer dans le délai souhaité, cela montre que l’on a besoin d’autres outils, de davantage de personnel, de procédures différentes, que le business montre plus de flexibilité par rapport à la fenêtre de maintenance, etc.

mesure 3 : contrôle des accès

La formule pour calculer le contrôle des accès : faire le pourcentage des points d’accès à distance utilisé pour obtenir un accès non-autorisé.

Mon commentaire : pour avoir un bon résultat, il me suffit d’avoir un système insuffisamment protégé et ainsi toutes les attaques réussies ne l’auront été que par un unique point d’accès.

Ma suggestion : l’exemple type d'une métrique privée de bon sens. Il est déjà considéré comme « normal » d’avoir des accès non autorisés. Sachant qu’une multinationale a facilement plus de 10 000 composants réseaux, plus les stations de travail, plus les « smartphones », vous imaginez le pourcentage que représentent d’avoir 5 systèmes non sécurisés et exposés à Internet… Les chiffres de cette métrique apparaîtront comme très bons alors que le niveau de sécurité est catastrophique.

Même si l’audience riait tout en regardant le représentant du NIST, j’ai souligné que le NIST n’avait pas le monopole des métriques non pertinentes. J’ai continué avec le Consensus Information Security Metrics du Center for Internet Security. Comme le nombre de métriques proposées est très élevé, j’ai sélectionné celui que je considère comme un candidat au pire métrique :

mesure 22 : le temps moyen pour remédier à une vulnérabilité

La formule pour calculer ce temps moyen : somme (date de la remédiation – date de détection) / nombre de vulnérabilités remédiées.

Mon commentaire : il me suffit de ne pas remédier à une vulnérabilité pour qu’elle ne soit pas incluse dans le calcul. Ensuite, comme si cela n’était pas suffisant, on en fait une moyenne. Pour résumer, l’objectif de cette métrique est clairement d’avoir des résultats positifs et en aucun cas de dresser un bilan fidèle de la situation.

ma conclusion : comment approcher les métriques sécurité

Il est tout de même effarant de constater le nombre de métriques ou de rapports qui donnent des informations conduisant à avoir une image erronée par rapport à la situation réelle. D’un côté, j’entends souvent des gens IT ou sécurité se plaindre du manque de moyens, mais de l’autre, toutes les métriques fournies donnent des indications que tout va bien dans le meilleur des mondes...

Je suis toujours étonné que les gens de la sécurité s’intéressent aux 99.9% de systèmes en conformité. Personnellement, ce qui m’intéresse, c’est ce qui ne va pas, ce qui représente un risque potentiel, le 0.1%. Combien de systèmes ? Quelles sont les conséquences potentielles ? Que peut-on faire pour y remédier ? (s’il y a besoin d’ailleurs, car peut-être que ces systèmes sont vulnérables à une attaque SQL mais qu’ils n’ont pas de bases de données)

Je pense que les métriques sécurité devraient être définies pour identifier les risques et mettre des priorités. Donc, mon conseil est simple : fini les moyennes (average, mean-time, etc.), on reporte sur les pires cas, les plus grands risques. On arrête avec les pourcentages, on analyse le nombre d’exceptions, de non-conformité. Et on explique pourquoi on ne parvient pas à atteindre l’objectif. Cela peut être pour des raisons justifiées, avec des coûts disproportionnés par rapport à une solution. Mais on le met en avant, on en parle et les dirigeants acceptent les risques liés (ou donne un budget). Mais au moins ils sont mis au courant.

Je n’oublie pas que certains en sont toujours à fournir des métriques inutiles pour le management : par exemple le nombre de virus bloqués… On s’en fout ! Combien sont passés et pourquoi seraient-ils plus pertinents ? Mais comme on ne sait pas le reporter, on reporte les virus bloqués. Pour ceux-là, il serait judicieux de revoir leur reporting très vite et de s’aligner sur le métier (enfin).

La semaine prochaine, je publierai le 3e et dernier post au sujet de ce workshop, le social engineering. N’hésitez pas à commenter, à publier vos expérience (positives et négatives) et/ou me contacter !

Johny

Photo credit: © adam121 - Fotolia.com