Chapitre 5 — Analyse de Vulnérabilités
⏱ ~30 min autonome · ~45 min encadré
Une fois les services énumérés, il faut évaluer méthodiquement quelles faiblesses ils présentent réellement. Ce chapitre couvre les systèmes de référence de l'industrie (CVE, CVSS, CWE) et une méthode de modélisation des menaces — STRIDE — qui structure la réflexion au-delà d'une simple liste d'outils.
- Distinguer un scan de vulnérabilités d'un test d'intrusion complet.
- Interpréter un identifiant CVE et un score CVSS.
- Appliquer les six catégories STRIDE à un scénario de modélisation des menaces.
Un scan de vulnérabilités compare automatiquement un système à une base de faiblesses connues et produit une liste de correspondances potentielles. Un test d'intrusion va plus loin : il cherche à confirmer, en les exploitant réellement (dans les limites convenues), que ces vulnérabilités sont effectivement exploitables — un scan produit des candidats, le test d'intrusion produit des preuves.
Le cycle de gestion des vulnérabilités suit généralement trois grandes étapes : identification (scan), correction (application de correctifs ou de contrôles compensatoires), puis vérification que la correction a bien éliminé la faille — un cycle continu plutôt qu'un exercice ponctuel.
| Système | Rôle |
|---|---|
| CVE (Common Vulnerabilities and Exposures) | Identifiant unique standardisé pour chaque vulnérabilité publiquement connue, au format CVE-ANNÉE-NUMÉRO. Sert de référence commune entre chercheurs, éditeurs et outils de scan. |
| CVSS (Common Vulnerability Scoring System) | Score de sévérité de 0 à 10, calculé à partir de plusieurs vecteurs (facilité d'exploitation, impact, portée). Un score de 9-10 signifie critique ; 7-8,9 élevé ; 4-6,9 moyen ; 0,1-3,9 faible. |
| CWE (Common Weakness Enumeration) | Catalogue de catégories de faiblesses génériques (par exemple « validation d'entrée insuffisante ») — alors qu'une CVE désigne une instance précise, une CWE désigne le type de faille sous-jacente que plusieurs CVE peuvent partager. |
Les scores CVSS et les catalogues CVE sont utiles mais réactifs : ils décrivent des failles déjà découvertes dans des logiciels existants. La modélisation des menaces adopte une posture différente, proactive : plutôt que de chercher des failles connues, elle pousse à se demander systématiquement, dès la conception d'un système, « qu'est-ce qui pourrait mal tourner ici ? ». STRIDE, développé chez Microsoft, est le cadre le plus répandu pour structurer cette réflexion.
| Lettre | Catégorie | Question posée |
|---|---|---|
| S | Spoofing (usurpation) | Un attaquant peut-il se faire passer pour quelqu'un ou quelque chose d'autre ? |
| T | Tampering (altération) | Les données peuvent-elles être modifiées sans autorisation ? |
| R | Repudiation (répudiation) | Un utilisateur peut-il nier avoir effectué une action, faute de preuve ? |
| I | Information disclosure (divulgation) | De l'information sensible peut-elle être exposée à qui ne devrait pas y avoir accès ? |
| D | Denial of Service (déni de service) | Le système peut-il être rendu indisponible pour ses utilisateurs légitimes ? |
| E | Elevation of Privilege (élévation de privilège) | Un utilisateur peut-il obtenir plus de droits que ceux qui lui ont été accordés ? |
La force de STRIDE n'est pas de fournir des réponses toutes faites, mais de garantir qu'aucune catégorie de risque n'est oubliée par simple omission. C'est une méthode de pensée, réutilisable sur n'importe quel système, contrairement à une checklist d'outils qui devient obsolète dès qu'un nouvel outil apparaît.
Sans dépendre d'un produit commercial précis, les outils de scan de vulnérabilités se répartissent généralement en deux familles : les scanners réseau (qui interrogent les services exposés à distance) et les scanners d'application web (qui testent spécifiquement les faiblesses côté application, voir Chapitre 8).
Faux positifs et validation manuelle
Un scan automatisé signale des correspondances probables, pas des certitudes. Un faux positif — une faille signalée qui n'existe pas réellement, ou qui n'est pas exploitable dans ce contexte précis — est fréquent, et seule une validation manuelle (souvent via une tentative d'exploitation contrôlée) permet de distinguer le signal du bruit avant de submerger une équipe de correctifs inutiles.
Priorisation des correctifs selon le risque métier
Un score CVSS élevé ne dit pas tout : une vulnérabilité critique sur un serveur de test isolé du reste du réseau représente objectivement moins de risque métier qu'une vulnérabilité moyenne sur un système de production traitant des données sensibles. La priorisation finale doit toujours combiner la sévérité technique et le contexte métier réel de l'actif concerné.