Comme nous l’avons déjà mentionné, si notre approche est davantage orientée menaces parce que leur nombre est fini et les informations sont le reflet exact des vulnérabilités qu’elles exploitent, certaines analyses de risque nécessitent l’évaluation des faiblesses ou des vulnérabilités. C’est le cas par exemple si on nous mandate une analyse de risque à partir d’une ou plusieurs vulnérabilités découvertes dans un système. S’il est préférable de les évaluer seulement sous l’angle de la sévérité d’impact, dans un processus séparé.

Un petit mot sur une différence fréquemment ignorée entre une mitigation et une remédiation (ou correction). Il faut souligner que ce sont deux notions distinctes. La première fait référence à un risque dont on sait qu’il n’est jamais nul ou presque, si bien que le but est de le réduire à un niveau jugé acceptable pour l’organisation. La seconde constitue une anomalie qu’on doit supprimer ou corriger de sorte qu’elle n’existe plus. Un défaut dans un système n’est jamais acceptable, le but est d’y remédier et non de mitiger.
Une fois qu’on comprend cela, il apparaît improbable de mêler deux activités dont la finalité est différente. ce qui peut se produire en revanche, est qu’on doive évaluer certains facteurs de risque associés à une vulnérabilité afin d’en prioriser la remédiation (et non la mitigation). On tente d’ordonnancer des tâches qui auront lieu de toute manière, mais dont on sait que parce que les vulnérabilités sont détectées en trop grand nombre (nous parlons souvent de densité de vulnérabilités dans un seul système), il est très difficile de trouver le temps et les ressources. C’est ainsi que les organisations accumulent un arriéré de vulnérabilités non corrigées durant des années, et de toute sévérité. Mais ce type d’évaluation n’en constitue pas pour autant une analyse de risque …

Alors que fait-on des vulnérabilités ? On les considère, quand on en a une connaissance suffisante, pour identifier dans le détail un scénario de menace (qui deviendra de risque). Dans beaucoup de référentiels, et c’est le cas de CAPEC (menaces) et CWE (faiblesses) par exemple, chaque entrée pour une menace est reliée aux faiblesses qui favorisent la réussite d’une attaque. Imaginons une menace hypothétique d’un mur qui s’écroule, il serait utile de pouvoir identifier tous les trous visibles afin de les colmater et rendre la structure stable. Il en est de même avec les vulnérabilités. Ce n’est pas une priorité, lors d’une analyse de risque, d’évaluer aussi les vulnérabilités. Nous disons souvent que menaces et vulnérabilités sont les deux faces d’une même pièce. Il deviendrait très fastidieux et cela ferait en quelque sorte double emploi, d’évaluer dans le détail les deux successivement. Mais il est important d’en avoir connaissance et de savoir quelle est la fiabilité de l’information que nous en avons. Le fait même que certaines vulnérabilités sont non seulement observées, mais surtout confirmées voire formellement vérifiées et de manière indépendante (comme lors d’un audit technique ou lors d’un test d’intrusion), cela rend un scénario possible et cela déterminera le plan d’action. D’abord on doit supprimer les vulnérabilités, puis on doit appliquer des mesures de sécurité efficaces. Il ne servirait à rien d’implémenter des mesures de sécurité additionnelles pour se rendre compte que les vulnérabilités sont toujours présentes dans le système … si les mesures sont contournées (cf. l’étape d’évasion des défenses), le système est directement exposé.

Il faut aussi rappeler la distinction entre deux types de vulnérabilités : les vulnérabilités intrinsèques et les vulnérabilités extrinsèques. Les premières sont constitutives d’un système tel qu’il a été conçu et configuré, les secondes dépendent de l’architecture globale, de l’infrastructure et l’environnement où le système opère. Les deux types de vulnérabilités doivent être corrigées, et certains référentiels comme CWE décrivent en détail les phases durant lesquelles les vulnérabilités ont été introduites dans le système :

• Architecture
• Conception
• Implémentation

En revanche, MITRE parle de mitigation, ce qui est erroné car « mitiger » signifie bien « rendre plus doux, moins rigoureux » et non « supprimer ». Parfois, s’il n’est pas possible de corriger immédiatement une vulnérabilité, il sera recommandé de mettre en œuvre une mesure compensatoire (et transitoire), seulement dans ce cas on parlerait de mitigation à juste titre.

Enfin rappelons la distinction, légère certes, entre une faiblesse (weakness) et une vulnérabilité :

• Faiblesse : une condition dans un logiciel, microgiciel, matériel ou composant qui, sous certaines circonstances, pourrait contribuer à l’introduction de vulnérabilités.
• Vulnérabilité : un défaut dans un logiciel, microgiciel, matériel ou composant résultant d’une faiblesse qui peut être exploitée pour causer un impact négatif sur la confidentialité, l’intégrité ou la disponibilité d’un composant ou ensemble de composants impactés. .

Dans beaucoup d’autres référentiels, il n’existe aucune distinction, donc il ne faut pas y attacher une importance excessive. Disons que les faiblesses sont souvent génériques et indépendantes de technologies spécifiques, tandis que les vulnérabilités sont de nature plus technique et rattachée plus souvent à des technologies particulières. Dans tous les cas, on reconnaît le libellé d’une faiblesse ou d’une vulnérabilité parce qu’il commence par les mots-clés suivants :

• Insuffisance de
• Absence de
• Faiblesse de
• Susceptibilité à
• Sensibilité à

Et nous finirons par émettre des doutes sur la tendance nord-américaine à considérer l’absence ou l’inefficacité des mesures de sécurité comme des vulnérabilités (le plus souvent extrinsèques). Les vulnérabilités concernent directement le système étudié, tel qu’il est conçu ou implémenté. Certaines mesures de sécurité peuvent venir compenser des vulnérabilités toujours existantes qu’il est impossible de corriger. On ne peut donc mélanger ces deux notions. Si l’objet de l’étude est la mesure de sécurité elle-même, en tant qu’actif organisationnel, comme par exemple un pare-feu ou une solution de chiffrement dont on voudrait évaluer le risque avant son implémentation, alors dans ce cas son inefficacité à rendre le service de sécurité attendu constituerait vraisemblablement une faiblesse du système. Dans le cas contraire, les mesures de sécurité défaillantes ne doivent pas être confondues avec des vulnérabilités mais elles détermineront, bien évidemment, le niveau de risque.

Nous allons maintenant énumérer différents référentiels de faiblesses ou de vulnérabilités dans les sections suivantes.