Vulnerability Assessment
Identifier les failles avant que les attaquants ne le fassent. Découvre le processus complet d'évaluation des vulnérabilités, du scan à la remédiation.
- Comprendre le cycle de vie d'une vulnérabilité (CVE, CWE, NVD)
- Maîtriser le système de scoring CVSS
- Connaître les outils et processus de scan de vulnérabilités
- Savoir analyser et prioriser les résultats d'un scan
- Comprendre le processus de patch management
🐛 23.1 — Les vulnérabilités
Une vulnérabilité est une faiblesse dans un système, un logiciel ou un processus qui peut être exploitée par un attaquant pour compromettre la sécurité.
Imagine une maison. Une vulnérabilité, c'est une fissure dans le mur, une serrure défaillante ou une fenêtre qui ne ferme pas bien. Même si personne ne l'exploite aujourd'hui, le risque est là. L'évaluation des vulnérabilités, c'est l'inspection minutieuse de ta maison pour trouver et réparer toutes ces faiblesses.
Terminologie clé
CVE — Common Vulnerabilities and Exposures
Un identifiant unique attribué à chaque vulnérabilité connue :
- Format :
CVE-YYYY-NNNNN(ex : CVE-2021-44228 = Log4Shell) - Géré par MITRE Corporation
- Permet de référencer la même vulnérabilité de manière universelle
- Tout le monde parle le même langage : éditeurs, chercheurs, SOC
CWE — Common Weakness Enumeration
Catalogue des types de faiblesses logicielles (pas les instances spécifiques) :
- CWE-79 : Cross-Site Scripting (XSS)
- CWE-89 : SQL Injection
- CWE-287 : Improper Authentication
- CWE-798 : Use of Hard-coded Credentials
- CWE-22 : Path Traversal
Différence avec CVE : CWE décrit le type de faiblesse, CVE identifie une instance spécifique de cette faiblesse dans un produit donné.
NVD — National Vulnerability Database
Base de données du NIST qui enrichit les CVE avec des informations supplémentaires :
- Score CVSS calculé pour chaque vulnérabilité
- Liens vers les patches et correctifs
- Produits et versions affectés (CPE)
- Références techniques et advisories
La NVD est la référence pour les analystes de sécurité et les scanners de vulnérabilités.
Cycle de vie d'une vulnérabilité
La vulnérabilité est introduite (bug dans le code, mauvaise configuration). Personne ne le sait encore.
Un chercheur en sécurité, un attaquant ou un scanner la découvre. Si l'attaquant la découvre en premier, c'est un zero-day.
La vulnérabilité est signalée au vendor (responsible disclosure) ou publiée. Un CVE est attribué.
L'éditeur publie un correctif. La course commence : appliquer le patch avant que les attaquants n'exploitent la faille.
Les organisations appliquent le patch. Les systèmes non patchés restent vulnérables (N-day).
Zero-day vs N-day
| Type | Définition | Danger |
|---|---|---|
| Zero-day | Vulnérabilité exploitée avant qu'un patch ne soit disponible (0 jours de correction) | ⛔ Critique — aucune défense directe possible |
| N-day | Vulnérabilité pour laquelle un patch existe depuis N jours mais n'a pas encore été appliqué | ⚠️ Danger élevé — les exploits sont souvent publics |
📊 23.2 — CVSS (Common Vulnerability Scoring System)
Le CVSS est un système standardisé de notation des vulnérabilités sur une échelle de 0 à 10. Il permet de prioriser les vulnérabilités de manière objective.
Le CVSS, c'est comme l'échelle de Richter pour les séismes. Un score de 2, ce n'est pas grave. Un score de 9, c'est une catastrophe. Le CVSS mesure la "magnitude" d'une vulnérabilité.
Les 3 groupes de métriques CVSS
Caractéristiques intrinsèques de la vulnérabilité, constantes dans le temps :
- Attack Vector (AV) : Network, Adjacent, Local, Physical
- Attack Complexity (AC) : Low, High
- Privileges Required (PR) : None, Low, High
- User Interaction (UI) : None, Required
- Scope (S) : Unchanged, Changed
- Impact : Confidentiality, Integrity, Availability (None/Low/High)
Caractéristiques qui évoluent dans le temps :
- Exploit Code Maturity : l'exploit est-il public ? fonctionnel ?
- Remediation Level : un patch officiel est-il disponible ?
- Report Confidence : la vulnérabilité est-elle confirmée ?
Personnalisation selon le contexte de l'organisation :
- Importance des actifs affectés pour l'entreprise
- Mesures de mitigation déjà en place
- Exigences de confidentialité/intégrité/disponibilité spécifiques
Interprétation du score CVSS
| Score | Sévérité | Action recommandée | Exemple |
|---|---|---|---|
| 0.0 | None | Aucune action requise | — |
| 0.1 — 3.9 | Low | Corriger lors du prochain cycle de maintenance | Information disclosure mineure |
| 4.0 — 6.9 | Medium | Planifier la correction dans les 30 jours | XSS reflected |
| 7.0 — 8.9 | High | Corriger dans les 7 jours | SQL Injection authentifiée |
| 9.0 — 10.0 | Critical | Corriger immédiatement | RCE non authentifiée (Log4Shell) |
🔍 23.3 — Scanners de vulnérabilités
Un scanner de vulnérabilités est un outil automatisé qui identifie les failles de sécurité dans les systèmes, les réseaux et les applications.
Un scanner de vulnérabilités, c'est comme un inspecteur en bâtiment. Il examine chaque mur, chaque tuyau, chaque câble pour trouver les défauts. Il ne répare rien, mais il te donne un rapport détaillé de tout ce qu'il faut corriger.
Types de scans
Network Vulnerability Scan
Scanne les systèmes via le réseau :
- Découverte des hôtes actifs et des ports ouverts
- Identification des services et versions (banner grabbing)
- Comparaison avec la base de vulnérabilités connues (CVE/NVD)
- Détection des configurations par défaut et des protocoles obsolètes
Limites : vision externe uniquement, ne voit pas les vulnérabilités internes au système.
Web Application Scan
Spécialisé dans les applications web :
- Détection de XSS, SQL Injection, CSRF, path traversal
- Test des formulaires, paramètres URL, cookies, headers
- Crawling automatique de l'application
- Vérification de la configuration du serveur web
Outils : OWASP ZAP (gratuit), Burp Suite, Nikto, Acunetix.
Credentialed Scan (scan authentifié)
Le scanner se connecte au système avec des identifiants pour un scan en profondeur :
- Inventaire complet des logiciels installés et de leurs versions
- Vérification des patches manquants
- Analyse de la configuration interne (registre, fichiers de config)
- Vérification des politiques de mots de passe et des comptes
Avantage : beaucoup plus précis, moins de faux positifs.
Inconvénient : nécessite des credentials sur chaque système.
Outils populaires
- Le scanner de vulnérabilités le plus utilisé au monde
- Plus de 200 000 plugins de détection
- Scans réseau, web, credentialed, compliance
- Version Essentials gratuite (16 IPs max) pour l'apprentissage
- Version professionnelle : Nessus Professional, Tenable.io (cloud)
- Scanner open source (fork de Nessus v2)
- Gratuit et communautaire
- Interface web (Greenbone Security Assistant)
- Bonne couverture de vulnérabilités, mise à jour régulière
- Idéal pour l'apprentissage et les petites organisations
- Solution cloud-native de gestion des vulnérabilités
- Agent léger déployé sur les endpoints
- Scans continus (pas seulement périodiques)
- Module VMDR (Vulnerability Management, Detection and Response)
- Très utilisé dans les grandes entreprises
- Scanner web open source en ligne de commande
- Vérifie les configurations dangereuses des serveurs web
- Détecte les fichiers et répertoires par défaut ou sensibles
- Identifie les versions de serveurs et logiciels obsolètes
- Simple mais efficace pour un premier scan rapide
📋 23.4 — Processus d'évaluation des vulnérabilités
L'évaluation des vulnérabilités est un processus structuré et cyclique. Ce n'est pas un événement ponctuel mais une activité continue.
Définir le périmètre (quels systèmes ?), obtenir les autorisations, planifier le calendrier, identifier les credentials pour les scans authentifiés.
Exécuter les scans avec les outils appropriés (Nessus, OpenVAS, Qualys). Scans réseau et/ou authentifiés selon le périmètre défini.
Examiner les résultats, éliminer les faux positifs, valider les vulnérabilités réelles. Comprendre le contexte de chaque vulnérabilité.
Classer les vulnérabilités par risque : CVSS + criticité de l'actif + existence d'un exploit public + exposition (internet vs interne).
Appliquer les correctifs : patches, reconfigurations, mises à jour, workarounds temporaires. Documenter chaque action.
Re-scanner pour vérifier que les vulnérabilités ont bien été corrigées. Boucler le cycle et recommencer.
- Faux positif : le scanner signale une vulnérabilité qui n'existe pas en réalité. Cause du travail inutile.
- Faux négatif : le scanner ne détecte pas une vulnérabilité qui existe réellement. Plus dangereux car on croit être protégé.
📄 23.5 — Rapports de vulnérabilité
Le rapport de vulnérabilité est le livrable principal de l'évaluation. Il doit être clair, actionnable et adapté à son audience.
Contenu d'un bon rapport
Destiné à la direction (non technique) :
- Nombre total de vulnérabilités trouvées par sévérité
- Tendance par rapport au scan précédent (amélioration ou dégradation ?)
- Risques principaux en langage business
- Recommandations prioritaires
Destiné à l'équipe technique (sysadmins, devs, SOC) :
- Liste complète des vulnérabilités avec CVE, CVSS, description
- Systèmes et services affectés (IP, port, version)
- Preuves (evidence) : captures d'écran, output du scanner
- Instructions de remédiation spécifiques
- Références : liens vers les advisories et patches
- MTTR (Mean Time To Remediate) : temps moyen pour corriger une vulnérabilité
- Taux de couverture : pourcentage des actifs scannés
- Patch compliance : pourcentage des systèmes à jour
- Aging : nombre de vulnérabilités ouvertes depuis plus de 30/60/90 jours
- Tendance : évolution du nombre de vulnérabilités dans le temps
Priorisation par risque
Le score CVSS seul ne suffit pas. Il faut croiser plusieurs facteurs :
| Facteur | Question à se poser | Impact sur la priorité |
|---|---|---|
| CVSS Score | Quelle est la sévérité intrinsèque ? | Score 9+ = priorité maximale |
| Criticité de l'actif | S'agit-il d'un serveur critique ou d'un poste de test ? | Serveur de production > poste de dev |
| Exploit disponible | Un exploit public existe-t-il (Exploit-DB, Metasploit) ? | Exploit public = priorité augmentée |
| Exposition | Le système est-il accessible depuis Internet ? | Internet-facing = priorité maximale |
| Données sensibles | Le système contient-il des PII, des données financières ? | Données sensibles = priorité augmentée |
🔄 23.6 — Patch Management
Le patch management est le processus de gestion des mises à jour et correctifs de sécurité sur l'ensemble des systèmes de l'organisation.
Le patch management, c'est comme l'entretien d'une flotte de véhicules. Chaque véhicule (système) a besoin de révisions régulières (patches). Si tu négliges l'entretien, un véhicule tombe en panne (est compromis) et peut bloquer toute la flotte (le réseau).
Processus de patch management
1. Inventaire des actifs
- Maintenir un inventaire à jour de tous les systèmes (OS, applications, versions)
- Identifier les systèmes critiques et leur classification
- Utiliser des outils de discovery (SCCM, Qualys, Nessus)
- On ne peut pas patcher ce qu'on ne connaît pas !
2. Évaluation des patches
- Surveiller les advisories des éditeurs (Microsoft Patch Tuesday, Red Hat, etc.)
- Évaluer la sévérité de chaque patch (CVSS, criticité des systèmes)
- Déterminer les patches à appliquer en priorité
- Planifier le calendrier de déploiement
3. Test en staging
- Déployer les patches sur un environnement de test d'abord
- Vérifier la compatibilité avec les applications critiques
- Tester les fonctionnalités après application du patch
- Préparer un plan de rollback en cas de problème
4. Déploiement en production
- Déployer pendant les fenêtres de maintenance planifiées
- Commencer par les systèmes les moins critiques
- Automatiser le déploiement (WSUS, SCCM, Ansible, Puppet)
- Surveiller le processus et être prêt pour le rollback
5. Vérification
- Vérifier que les patches ont été appliqués avec succès
- Re-scanner les systèmes pour confirmer la correction
- Documenter les résultats et mettre à jour l'inventaire
- Rapporter les métriques de compliance aux patchs
Outils de patch management
| Outil | Plateforme | Usage |
|---|---|---|
| WSUS | Windows | Windows Server Update Services — gratuit, intégré à Windows Server, déploie les mises à jour Microsoft |
| SCCM / MECM | Windows | Microsoft Endpoint Configuration Manager — gestion complète des endpoints (patches, inventaire, déploiement) |
| Ansible | Multi-OS | Automatisation open source — agentless, idéal pour Linux et infrastructure as code |
| Puppet / Chef | Multi-OS | Configuration management — maintient les systèmes dans un état souhaité (desired state) |
Politique de patches recommandée
| Sévérité | Délai de correction | Action |
|---|---|---|
| Critical (CVSS 9.0-10.0) | 24-72 heures | Patch d'urgence hors cycle si nécessaire |
| High (CVSS 7.0-8.9) | 7 jours | Prioriser dans le prochain cycle de patch |
| Medium (CVSS 4.0-6.9) | 30 jours | Planifier lors de la maintenance régulière |
| Low (CVSS 0.1-3.9) | 90 jours | Inclure dans le cycle trimestriel |
🔬 23.7 — Exercice : Analyser et prioriser des vulnérabilités
Tu es analyste SOC et tu viens de recevoir les résultats d'un scan de vulnérabilités. Classe chaque vulnérabilité dans la bonne catégorie de priorité :
🔴 Critical — Immédiat
🟠 High — 7 jours
🟡 Medium — 30 jours
📊 23.8 — Frameworks, profils reseau et gestion des risques
Fonctions du NIST Cybersecurity Framework (CSF)
Le NIST CSF definit 5 fonctions fondamentales. Chaque fonction produit des resultats (outcomes) specifiques :
| Fonction | Objectif | Exemples de resultats (outcomes) |
|---|---|---|
| Identify | Developper la comprehension organisationnelle pour gerer les risques | Asset Management, Risk Assessment, Governance, Business Environment |
| Protect | Implementer les mesures de protection appropriees | Information Protection Processes, Access Control, Training, Data Security |
| Detect | Implementer les activites pour identifier les evenements de cybersecurite | Anomalies and Events, Security Continuous Monitoring, Detection Processes |
| Respond | Prendre des mesures concernant un incident detecte | Response Planning, Communications, Analysis, Mitigation |
| Recover | Maintenir les plans de resilience et restaurer les capacites | Recovery Planning, Improvements, Communications |
Cycle de vie de la gestion des vulnerabilites
Le cycle de vie complet suit cet ordre precis en 6 etapes :
- Discover (Decouvrir) — identifier tous les actifs du reseau (inventaire)
- Prioritize Assets (Prioriser les actifs) — classer les actifs par criticite metier
- Assess (Evaluer) — scanner et identifier les vulnerabilites
- Remediate (Remedier) — appliquer les correctifs et mesures de mitigation
- Report (Rapporter) — documenter les resultats et le statut pour le management
- Verify (Verifier) — confirmer que les vulnerabilites ont ete corrigees
Strategies de gestion des risques
| Strategie | Description | Exemple |
|---|---|---|
| Risk Avoidance | Mettre fin a toutes les activites qui generent le risque | Ne plus utiliser un logiciel obsolete et vulnerable |
| Risk Retention (Acceptance) | Accepter le risque quand l'impact est faible mais le cout de mitigation est eleve | Accepter le risque d'une vulnerabilite sur un serveur de test isole |
| Risk Reduction | Implementer des controles pour reduire l'impact ou la probabilite | Installer un WAF devant une application web vulnerable |
| Risk Sharing (Transfer) | Transferer le risque a un tiers | Souscrire une cyber-assurance |
Profils reseau et serveur
Un profil reseau documente les caracteristiques normales du reseau pour etablir une baseline et detecter les anomalies :
| Element du profil | Description |
|---|---|
| Ports used (Ports utilises) | Liste des processus TCP et UDP actifs sur le reseau |
| Critical address space | Emplacements IP critiques (serveurs, passerelles, infrastructure) |
| Session duration | Duree des flux de donnees (timing des sessions reseau) |
| Total throughput | Volume de donnees transitant sur le reseau |
Un profil serveur decrit les caracteristiques normales d'un serveur :
| Element | Description |
|---|---|
| Listening ports | Ports TCP/UDP ouverts et daemons (services) en ecoute sur le serveur |
| Service accounts | Comptes de service utilises par les applications |
| Software environment | Applications et versions installees |
| Critical address space | IPs et sous-reseaux du serveur |
Baseline reseau et phase de detection
Lors de la phase de detection des vulnerabilites, une mesure essentielle est de developper une baseline reseau (reference de comportement normal). Cette baseline permet de :
- Detecter les deviations par rapport au comportement normal
- Identifier les nouveaux services ou ports ouverts non autorises
- Reperer les flux inhabituels (exfiltration, lateral movement)
Asset Management dans le plan de securite
L'asset management (gestion des actifs) est le composant du plan de securite responsable du suivi et de l'inventaire de tous les actifs de l'organisation. Il repond a la question : "Que devons-nous proteger ?" C'est un prerequis a toute evaluation de vulnerabilite efficace.
📋 23.9 — NIST Risk Management Framework (RMF)
Le NIST RMF (SP 800-37) est un cadre structuré en 7 étapes pour intégrer la gestion des risques dans le cycle de vie des systèmes d'information.
| Étape | Nom | Description |
|---|---|---|
| 1 | Prepare | Établir le contexte et les priorités pour gérer les risques de sécurité |
| 2 | Categorize | Catégoriser le système et les informations selon leur impact (FIPS 199 : Low/Moderate/High) |
| 3 | Select | Sélectionner les contrôles de sécurité appropriés (NIST SP 800-53) |
| 4 | Implement | Implémenter les contrôles sélectionnés |
| 5 | Assess | Évaluer l'efficacité des contrôles implémentés |
| 6 | Authorize | L'autorité désignée accepte le risque résiduel et autorise le système |
| 7 | Monitor | Surveiller en continu les contrôles et le niveau de risque |
Analyse de risque : Quantitative vs Qualitative
| Approche | Méthode | Avantage | Inconvénient |
|---|---|---|---|
| Quantitative | Valeurs monétaires : SLE × ARO = ALE | Résultats objectifs et comparables | Difficile d'estimer les valeurs précisément |
| Qualitative | Échelles relatives : Faible/Moyen/Élevé/Critique | Plus rapide et plus simple | Résultats subjectifs |
- SLE (Single Loss Expectancy) = Valeur de l'actif × Facteur d'exposition
- ARO (Annualized Rate of Occurrence) = Fréquence annuelle estimée
- ALE (Annualized Loss Expectancy) = SLE × ARO
Risque résiduel
Le risque résiduel est le risque qui subsiste après l'application de tous les contrôles de sécurité. Il n'est jamais possible d'éliminer 100% du risque — l'objectif est de le réduire à un niveau acceptable pour l'organisation. L'autorité désignée (Authorizing Official) doit formellement accepter ce risque résiduel.
📝 23.10 — Quiz de revision
🔬 23.7 — Lab : Scan et evaluation de vulnerabilites
Utilise les outils de scan de vulnerabilites pour identifier et evaluer les failles de securite sur un reseau cible.
Exercice : classe chaque vulnerabilite par severite CVSS
Points clés du Module 23
- Un CVE identifie une vulnérabilité spécifique, un CWE décrit un type de faiblesse
- Le NVD enrichit les CVE avec des scores CVSS et des références
- Un zero-day n'a pas de patch disponible ; un N-day a un patch non appliqué
- Le CVSS score de 0 à 10 avec trois groupes de métriques : Base, Temporal, Environmental
- Les scans authentifiés (credentialed) sont plus précis que les scans réseau simples
- Les principaux scanners sont Nessus, OpenVAS, Qualys et Nikto (web)
- Le processus d'évaluation est cyclique : préparation, scan, analyse, priorisation, remédiation, re-scan
- La priorisation croise le CVSS avec la criticité de l'actif, l'exposition et l'existence d'exploits publics
- Le patch management est un processus continu : inventaire, évaluation, test, déploiement, vérification
- Les patches critiques doivent être appliqués sous 24-72 heures
- Le NIST RMF comporte 7 étapes : Prepare → Categorize → Select → Implement → Assess → Authorize → Monitor
- L'analyse quantitative utilise SLE × ARO = ALE, l'analyse qualitative utilise des échelles relatives
- Le risque résiduel doit être formellement accepté par l'autorité désignée