CVSS de niveau 10 : de quoi parle-t-on exactement ?

Les vulnérabilités cyber d’à peu près tout ce qui existe sont qualifiées par le Nist (https://www.nist.gov/) qui utilise une échelle normalisée (https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator). Il y a eu quelques évolutions entre la v2 et la v3, la v4 (sortie en novembre dernier) apportant elle aussi quelques modifications, notamment sur l’échelle des critères de connexion.

Le score de la vulnérabilité ira de 0 à 10 selon une équation un peu complexe qui tient compte de cinq paramètres :

– le vecteur d’attaque : il va du mécanisme le plus difficile à utiliser (accès physique à la ressource) au plus facile (accès par un réseau distant) ;
– la complexité technique de l’attaque : simple ou élevée ;
– les privilèges nécessaires sur l’équipement impacté : d’élevés (difficile) à aucuns (facile) ;
– la nécessité d’une action de l’utilisateur légitime de l’équipement (par exemple, un clic sur un lien contenu dans un mail de phishing) : aucune ou requise ;
– l’étendue de l’attaque : contingentée à l’équipement concerné ou susceptible de s’étendre.

S’ensuit une échelle de l’impact de l’attaque sur les axes habituels DIC (Disponibilité/Intégrité/Confidentialité), avec trois valeurs(None/Low/High). Du classique.

Quand on joue cinq minutes avec le calculateur fourni par le Nist (la v3, je n’ai pas testé la v4), outre le fait que l’équation qui permet de calculer la note globale est assez alambiquée, on cherche assez rapidement à trouver la combinaison qui permet d’obtenir le score maximal de 10. J’ai fait l’exercice, et je vous livre le résultat : dès lors qu’il y a un impact DIC (s’il n’y a pas pas de vulnérabilité DIC, normal que l’on ne soit pas à 10), il faut absolument que les cinq paramètres ci-dessus soient au niveau maximal pour obtenir ce high score – ou dit autrement, si un seul de ces cinq paramètres n’est pas au taquet, on n’obtient pas 10.

Pour un firewall qui a obtenu 10, il a donc fallu :

– que la vulnérabilité ait pu être exploitée depuis Internet, et pas simplement depuis une DMZ ou le LAN ;
– que cette exploitation n’ait pas posé de difficulté (je n’ai pas plus de détails) ;
– qu’aucun privilège spécifique d’accès à la machine n’ait été nécessaire ; j’en déduis qu’une authentification même simple n’était pas indispensable – on parle d’une machine accessible sur Internet tout de même !
– qu’aucune action des utilisateurs légitimes n’ait été requise ;
– et que la vulnérabilité, une fois exploitée, ait donné accès à un large panel de ressources à l’attaquant.

Nous n’aurons bien évidemment jamais le détail des erreurs de codage qui ont mené à une telle paire de cyberbaffes pour le constructeur, mais vous conviendrez que cela pique un peu. Venant d’équipes de développement d’un logiciel métier hors du champ de la cyber, ce serait déjà anormal, mais on comprendrait un peu mieux, par contre venant d’une boîte de cyber, où est le problème (au sens Itil : root cause) ?

On me dit dans l’oreillette droite qu’il n’y aurait là rien d’exceptionnel et que les équipements les plus répandus seraient impactés – donc les plus testés/attaqués par les vilains en capuche. Non seulement il n’existe (à ma connaissance) aucune statistique officielle qui confirme cette idée, mais il y a tellement de contre-exemples de solutions cyber quasi confidentielles qui se sont fait trouer que cette idée ne tient pas deux minutes.

On me dit dans l’oreillette gauche que c’est la désastreuse ambiance cyber mondiale qui mène à ce constat. OK, je veux bien, mais qui est le premier de la poule ou de l’œuf ? On trouve davantage de CVSS 10 parce qu’il y a plus de monde qui les cherche, ou il y en a toujours autant et juste plus de monde pour les débusquer ? Parce que si la seconde hypothèse est la bonne, ça veut juste dire que le produit est développé avec les pieds et que personne ne s’en était rendu compte avant.

Les équipes cyber en sont donc réduites à mettre en œuvre la seule action qui relève de leur périmètre : patcher dare-dare toutes ces cochonneries, pour autant qu’elles en aient connaissance à temps, pour autant que l’attaque ne se produise pas un week-end de pont, pour autant que le constructeur communique rapidement sur le sujet, etc.

Je propose sans rire d’introduire dans les contrats plusieurs pénalités :

– CVSS > 7 : pénalité ;
– quand la vulnérabilité n’est pas signalée dans les 4 heures : pénalité ;
– quand le patch n’est pas disponible dans les 4 heures : pénalité ;
– le temps d’indisponibilité du SI consécutif au déploiement des patchs : refacturé ;
– les heures sup des équipes cyber pour réparer l’incurie des fournisseurs : refacturé.

Avec de telles mesures, peut-être que les fournisseurs muscleraient un peu plus leurs équipes de dev et surtout de contrôle, parce que là (et pas que pour la question des CVSS), dans la majorité des cas, on en est à la préhistoire. Et mettraient un peu moins de sous dans des plaquettes marketing brillantes ou les buffets de petits fours des séminaires clients dans des hôtels gastronomiques.

L'auteur

Responsable Sécurité des systèmes d’information et correspondant Informatique et Libertés au CHU de Nantes, Cédric Cartau est également chargé de cours à l’École des hautes études en santé publique (EHESP). On lui doit aussi plusieurs ouvrages spécialisés publiés par les Presses de l’EHESP, dont La Sécurité du système d’information des établissements de santé.