Mettre en place une gestion récurrente des vulnérabilités

Mettre en place une gestion récurrente des vulnérabilités

Un programme de gestion des vulnérabilités ne consiste pas à produire un rapport de scan mensuel et à le déposer dans un répertoire où il mourra dignement. Il relie un inventaire exploitable, une détection récurrente, une priorisation fondée sur l’exposition réelle et un cycle de correction capable de revenir en arrière.

Explication de la marmotte

Cela ressemble à l’entretien d’un immeuble : avant de réparer les fuites, il faut savoir quelles pièces existent, lesquelles donnent sur la rue et lesquelles risquent réellement d’être forcées. Le but est d’éviter que des défauts connus restent ouverts juste parce qu’ils sont cachés dans une liste interminable.

→ Lire l’explication complète de la marmotte

Le compromis central est brutal : scanner et corriger vite réduit la fenêtre d’exploitation, mais augmente le risque de panne causée par un changement insuffisamment testé. La bonne réponse n’est pas de choisir entre sécurité et stabilité, vieux duel de slides commerciales. Il faut séparer un cycle normal, prévisible et réversible, d’une voie accélérée réservée aux vulnérabilités exploitées activement.

La gestion des vulnérabilités ne remplace ni le durcissement, ni la segmentation réseau, ni le contrôle des identités. Une machine non corrigée derrière un filtrage strict reste vulnérable dès qu’un accès interne est compromis. Une machine corrigée exposée sans authentification reste une cible parfaitement fonctionnelle. Consulter aussi les principes de défense réseau et de gouvernance de la sécurité avant de transformer un scanner en oracle.

Inventaire des actifs et des logiciels exposés

1. Définir l’unité d’inventaire

Inventorier une adresse IP ne suffit pas. Une adresse peut être réattribuée, un service peut vivre derrière un répartiteur de charge et un conteneur peut disparaître avant la fin du scan. L’unité minimale doit associer un actif technique à un propriétaire, une criticité métier, un environnement, une zone réseau, une exposition et une méthode de mise à jour.

Pour chaque actif, conserver au minimum :

• identifiant stable ;
• nom de domaine et adresses réseau ;
• système d’exploitation, version et niveau de correctif ;
• logiciels installés et versions ;
• services ouverts et ports publiés ;
• propriétaire technique et propriétaire métier ;
• environnement : développement, test, production ;
• exposition : Internet, partenaire, interne, administration ;
• groupe de maintenance et procédure de retour arrière.

Un inventaire sans propriétaire transforme chaque vulnérabilité en objet trouvé. Vingt ans de métier apprennent que l’objet trouvé finit toujours par être celui qui répond au téléphone en pleine nuit.

2. Croiser les sources plutôt que croire une base unique

Construire l’inventaire à partir de plusieurs sources : outil de gestion de parc, gestionnaire de configuration, annuaire des machines, inventaire cloud, dépôts d’images de conteneurs, journaux du pare-feu et découverte réseau. Chaque source ment différemment, ce qui devient une qualité lorsqu’on compare leurs écarts.

Un actif détecté sur le réseau mais absent de l’inventaire déclaré doit créer une alerte de gouvernance. Inversement, un actif déclaré mais invisible depuis plusieurs cycles doit être qualifié : retiré, éteint, isolé ou simplement mal scanné. Ne pas supprimer automatiquement ces entrées. Un pare-feu qui bloque le scanner n’est pas une preuve de disparition, seulement une preuve que le pare-feu fait son travail.

Pour les applications web, inventorier les noms de domaine, les points d’entrée, les certificats et les dépendances exposées. Les certificats Transport Layer Security (TLS), protocoles de chiffrement des communications réseau, fournissent une bonne source de découverte : un nouveau nom public apparaît souvent là avant d’arriver dans un tableur supposé officiel.

3. Classer l’exposition avant le premier scan

L’exposition doit être une donnée contrôlée, pas une appréciation laissée dans un commentaire libre. Attribuer des classes explicites :

1. Internet : accessible depuis tout Internet.
2. Partenaire : accessible depuis des réseaux tiers identifiés.
3. Interne : accessible depuis le réseau d’entreprise ou un réseau d’administration.
4. Isolé : accessible seulement localement ou dans un segment sans chemin entrant connu.

Cette classification pilote la priorité et la fréquence des scans. Une interface d’administration accessible depuis Internet n’a pas besoin d’un score sophistiqué pour mériter une attention immédiate. Le risque est déjà dans la pièce, il regarde les meubles.

Déployer OpenVAS et planifier les scans récurrents

4. Préparer la plateforme de scan

OpenVAS, composant de détection de vulnérabilités aujourd’hui distribué dans Greenbone Community Edition, nécessite une machine dédiée, une connectivité contrôlée vers les cibles et des ressources adaptées au nombre d’hôtes scannés. Prévoir du stockage pour les résultats historiques, car supprimer les anciens rapports supprime la seule preuve qu’une régression a eu lieu.

Le scanner doit disposer de flux réseau explicites vers les ports à évaluer. Éviter de lui donner un accès d’administration universel sans justification. Les scans authentifiés demandent des comptes techniques à privilèges limités : lecture des versions, des correctifs et des paramètres de sécurité, sans droit de modification ni ouverture de session interactive lorsque cela est évitable.

Protéger ces identifiants dans un coffre de secrets. Leur rotation doit être testée contre le scanner : un mot de passe modifié sans mise à jour de la configuration fait basculer silencieusement les scans authentifiés vers des scans externes incomplets. Le rapport reste vert, ce qui est une forme très efficace de mensonge.

5. Segmenter les politiques de scan

Créer des politiques distinctes pour les actifs Internet, internes, critiques et fragiles. Un scan complet avec tests intrusifs peut saturer un équipement ancien, déclencher des mécanismes de défense ou perturber une application industrielle. Désactiver les tests dangereux n’est acceptable que si le risque est documenté et compensé par une vérification de version ou un contrôle manuel.

Planifier les scans selon l’exposition :

• actifs Internet : découverte hebdomadaire, plus scan après tout changement de publication ;
• serveurs internes standards : scan mensuel authentifié ;
• actifs critiques : scan authentifié hebdomadaire, pendant une plage validée ;
• postes de travail : inventaire et contrôle de correctifs via l’outil de gestion de parc, complété par des scans par échantillonnage ;
• équipements réseau et appliances : scan adapté au constructeur, sans tests destructifs.

Un scan ponctuel mesure un instant. Un programme mesure une dérive. La différence paraît sémantique jusqu’au jour où une image vulnérable est redéployée chaque semaine par la chaîne de livraison continue.

Exemple de découverte et de contrôle d’exposition

6. Vérifier une cible avant intégration au scanner

Avant d’ajouter une plage entière, valider la surface visible depuis le réseau du scanner. La commande suivante utilise Nmap, outil de découverte réseau, pour identifier les ports ouverts et les services déclarés. Exécuter cette opération seulement sur des actifs autorisés et depuis un segment approuvé.

# Scanner les services TCP les plus fréquents d'une cible autorisée.
# -sV demande l'identification de version, -Pn évite la découverte ICMP.
# Le résultat alimente l'inventaire, il ne remplace pas un scan authentifié.
nmap -sV -Pn --top-ports 1000 \
  --reason \
  --output-normal inventaire/serveur-app-01.nmap \
  serveur-app-01.exemple.interne

Comparer la sortie avec l’inventaire déclaré. Un port d’administration inattendu, une base de données exposée ou un service dont la version ne correspond pas à la configuration attendue doit être traité comme un écart de configuration avant même de chercher un identifiant de vulnérabilité.

Les identifiants Common Vulnerabilities and Exposures (CVE) désignent publiquement des failles connues. Ils permettent de corréler une version détectée avec une vulnérabilité, mais ne prouvent ni qu’un exploit fonctionne, ni que l’actif est atteignable. L’outil est une sonde, pas un détecteur de destin.

Priorisation CVSS, exposition et exploitation active

7. Refuser la file d’attente triée par score brut

Le Common Vulnerability Scoring System (CVSS) décrit la gravité théorique d’une vulnérabilité. Il ne connaît ni l’architecture locale, ni le chemin réseau, ni la valeur de l’actif. Trier uniquement par CVSS produit une liste propre, défendable en comité et souvent mauvaise pour réduire le risque réel.

Construire une priorité à partir de quatre facteurs :

1. gravité technique, notamment le score CVSS ;
2. exposition effective de l’actif ;
3. existence d’un exploit public fiable ou d’une exploitation active documentée ;
4. valeur de l’actif et capacité de rebond de l’attaquant.

Une vulnérabilité de gravité élevée sur un serveur isolé, sans exploit public et sans chemin utilisateur, peut attendre une fenêtre normale après validation. Une vulnérabilité de gravité moyenne sur une passerelle Internet exploitée activement mérite une correction immédiate. La base de données des vulnérabilités exploitées connues de la Cybersecurity and Infrastructure Security Agency (CISA) est une source de priorisation pratique, à recouper avec les avis éditeurs et la télémétrie interne.

Conserver la décision et son motif. Une dérogation doit contenir une date d’expiration, un propriétaire, une mesure compensatoire et un risque résiduel accepté. Une dérogation sans échéance est un abandon avec une police plus élégante.

8. Définir des objectifs de correction réalistes

Fixer des délais par classe, puis mesurer le respect de ces délais :

• critique, Internet ou exploitation active : voie accélérée, correction ou mitigation sous 24 à 72 heures ;
• critique sans exploitation connue : correction dans la prochaine fenêtre, au plus tard sous 14 jours ;
• élevée : correction sous 30 jours ;
• moyenne : correction sous 90 jours ;
• faible : traiter lors des montées de version ou selon l’analyse de risque.

Ces délais ne sont pas des garanties de sécurité. Ils rendent visible la dette de correction et forcent l’arbitrage. Le reste vient de la segmentation, de la surveillance, du contrôle d’accès et de la capacité à restaurer.

Cycle de patch management et reprise après échec

9. Industrialiser la fenêtre normale

Définir une fenêtre de maintenance récurrente par famille technique. Préparer les correctifs dans un environnement représentatif, vérifier les dépendances applicatives, sauvegarder les données nécessaires et valider les contrôles de santé après redémarrage.

La procédure de changement doit préciser : version cible, prérequis, ordre de mise à jour, durée estimée, tests de validation, seuil d’abandon et procédure de retour arrière. Pour un système d’exploitation, le rollback peut être une restauration d’instantané ou une réinstallation automatisée. Pour une base de données, restaurer un instantané sans vérifier la cohérence transactionnelle est une méthode de destruction de données qui porte une cravate.

Tester réellement le retour arrière. Une sauvegarde non restaurée est une théorie. Une image de machine virtuelle dont les secrets expirent pendant la restauration est une théorie avec des certificats cassés.

10. Ouvrir une voie accélérée séparée

La voie accélérée s’active lorsqu’une vulnérabilité est exploitée activement, touche un service exposé ou permet un accès direct à une fonction sensible. Elle doit autoriser une mitigation avant le correctif : désactivation d’une fonction, filtrage réseau, retrait d’une publication, règle de proxy ou rotation d’identifiants potentiellement compromis.

Documenter l’état temporaire et sa date d’expiration. Une mitigation d’urgence devient vite une règle permanente que personne n’ose retirer, puis un archéologue la découvre trois ans plus tard entre deux entrées de pare-feu.

Après chaque cycle, mesurer le taux de couverture des scans authentifiés, le délai médian de correction, le nombre d’actifs inconnus, les échecs de déploiement et les vulnérabilités réouvertes. Relier ces métriques aux procédures de gestion des failles et aux fondations d’architecture pour éviter que le patch management devienne une activité isolée.

🐝 Ce qui arrive si on s’en passe

Sans cycle récurrent, l’écart se creuse au rythme des publications : un identifiant de faille rendu public reste exploitable tant qu’aucune détection ne le relie à une version installée, et un attaquant qui balaie en continu les plages publiques dispose du même catalogue, sans en attendre la validation en comité. L’absence d’historique de scans supprime la ligne de temps : impossible d’établir depuis quand un service exposé portait le défaut, donc impossible de délimiter la période à examiner lors d’une investigation, ni de distinguer une machine jamais corrigée d’une machine redevenue vulnérable après un redéploiement. Sans mesure de couverture, un hôte que le scanner n’atteint plus se confond avec un hôte sain. Les dérogations, faute d’échéance suivie, cessent d’être des décisions et deviennent l’état par défaut du parc.

🦫 Explication de la marmotte 🍫

Le programme commence par une liste des machines, applications et services existants. Pour chaque élément, il faut connaître son responsable, son rôle, les logiciels installés, son accès depuis Internet ou depuis le réseau interne, et la manière de le remettre en état. Sans cette liste, des systèmes oubliés restent sans correction.

Un outil de recherche examine ensuite régulièrement les systèmes autorisés. Il compare leurs versions de logiciels avec des défauts publiés. Certains contrôles utilisent un compte technique pour voir les correctifs réellement installés. Ce compte doit être protégé et renouvelé, sinon les résultats deviennent incomplets.

Chaque défaut détecté ne reçoit pas la même urgence. Il faut vérifier si le système est visible depuis Internet, si des attaquants utilisent déjà le défaut et si le système donne accès à des données ou à d’autres machines. Un défaut grave sur un service accessible publiquement peut exiger une action en quelques heures. Un défaut moins exposé peut attendre la prochaine maintenance.

La maintenance normale installe les corrections à des dates prévues. Avant le changement, il faut tester, sauvegarder et préparer un retour arrière. Après le changement, il faut vérifier que le service fonctionne et refaire un contrôle. Si une correction casse le service, la procédure de retour arrière remet une version connue en état. Pour les défauts activement exploités, une voie urgente permet aussi de couper temporairement un accès ou une fonction avant d’installer la correction.

À lire aussi

• CISARéférence opérationnelle américaine pour la sécurisation, les alertes, les vulnérabilités exploitées et les guides de terrain.
• WannaCry et MS17-010 : fenêtre d'exposition et correctifsWannaCry, EternalBlue et MS17-010 montrent comment les deux mois entre un correctif publié et un correctif déployé deviennent la fenêtre d'exposition d'un parc Windows.
• Comment écrire un rapport de vulnérabilité corrigéMéthode pour écrire un rapport de vulnérabilité qui déclenche une correction vérifiable, exploitable et suivie.
• Comment les attaquants utilisent l'IA : de la CVE au zero-dayCe que l'intelligence artificielle apporte réellement aux attaquants d'après les rapports publiés par OpenAI, Anthropic, Google et Microsoft, l'accélération de l'exploitation des vulnérabilités publiées, la recherche de zero-days assistée par IA et ce que les défenseurs doivent changer.

Pages voisines

La citent

• Écrire un Dockerfile durci avec condensé, multi-étapes et non root
• CERT-FR alertes et avis de sécurité
• Comment les attaquants utilisent l'IA : de la CVE au zero-day
• Nmap pour cartographier un réseau, des hôtes aux services exposés
• PSIRT et divulgation coordonnée des vulnérabilités produit sous CRA

Mettre en place une gestion récurrente des vulnérabilités

Elle cite

• ⇄Lien dans les deux sens :Prioriser les vulnérabilités avec CVSS 4.0, EPSS, KEV et exposition
• Patch management d’un parc de postes hétérogène
• Pourquoi la dette technique de sécurité reste non chiffrée

⇄ : les deux pages se citent l’une l’autre.