CVE Watch : prioriser les findings selon votre exposition réelle

Le catalogue mondial des CVE est trop vaste pour devenir directement une file de remédiation. Une équipe sécurité doit savoir quelles vulnérabilités touchent ses produits, lesquelles sont utilisées par les attaquants et quel finding peut produire le plus grand dommage dans son environnement.

CVE Watch d’isMalicious transforme ce catalogue global en findings propres à l’organisation. Vous définissez des périmètres produits avec des entrées CPE, puis examinez les CVE correspondantes avec leur contexte d’exploitation, de sévérité, de produit, de ransomware et de remédiation.

La distinction essentielle est l’exposition. Un score CVSS critique sur un produit absent de votre parc n’est pas votre premier patch. Une vulnérabilité moins sévère mais exploitée sur un système exposé à Internet peut l’être.

Construire les périmètres autour des décisions

Un périmètre est un ensemble nommé de produits représentés par des données CPE. Créez des périmètres qui correspondent à la manière dont l’organisation attribue le travail, par exemple :

• services exposés à Internet ;
• postes des collaborateurs ;
• systèmes d’identité et d’accès distant ;
• infrastructure cloud de production ;
• systèmes de paiement ou de données clients ;
• fournisseur ou entité métier critique.

Ouvrez les Périmètres CVE Watch, créez un périmètre clair et ajoutez les entrées CPE pertinentes. Le catalogue CPE du NVD fournit le modèle de nommage standardisé utilisé pour identifier les plateformes. Validez le fournisseur, le produit et la version avec votre inventaire avant de conclure à une correspondance.

Un périmètre nommé « Production » reste trop large si plusieurs équipes possèdent des systèmes sans rapport. « VPN public et frontière d’identité » indique ce que le finding protège et qui doit le recevoir.

Lire chaque signal comme une question différente

CVE Watch réunit plusieurs signaux de priorisation. Ils se complètent sans être interchangeables.

• Exploitation active ou SSVC : existe-t-il une preuve que les attaquants utilisent la vulnérabilité ?
• CISA KEV : la CVE figure-t-elle dans le catalogue officiel des vulnérabilités exploitées ?
• EPSS : quelle est la probabilité d’exploitation dans les 30 prochains jours selon le modèle de FIRST ?
• CVSS : quelle serait la sévérité selon les hypothèses du score ?
• Usage ransomware : un contexte relie-t-il la vulnérabilité à une activité ransomware ?
• Correspondance produit : quel fournisseur et produit du périmètre sont touchés ?
• Statut : quelle décision ou action l’organisation a-t-elle déjà prise ?

FIRST décrit EPSS comme une probabilité quotidienne de 0 à 1 d’exploitation d’une CVE publiée pendant les 30 prochains jours. Ce signal aide à ordonner le travail probable à court terme. Il ne prouve pas une exploitation dans votre environnement.

Utiliser une pile de priorités, pas un score unique

CVE Watch met en avant l’exploitation active et le contexte KEV, puis soutient la décision avec CVSS et d’autres signaux. Ajoutez le contexte de l’organisation avant d’attribuer la priorité finale :

1. Le produit touché est-il réellement présent et vulnérable ?
2. Est-il exposé à Internet ou accessible depuis un chemin d’attaque probable ?
3. Protège-t-il l’identité, des privilèges, des données sensibles ou une activité critique ?
4. L’exploitation est-elle confirmée, listée dans KEV ou fortement probable selon EPSS ?
5. Les exploits publics, l’usage ransomware ou les campagnes actives sont-ils pertinents ?
6. Des contrôles compensatoires réduisent-ils le risque pratique ?
7. L’équipe peut-elle corriger sans danger ou faut-il d’abord atténuer ?

Cette pile évite deux erreurs fréquentes : corriger selon CVSS seul et traiter EPSS comme une mesure d’impact métier.

Transformer un finding en travail attribué

Pour chaque finding important, consignez :

• le périmètre et le produit touchés ;
• les preuves qui fixent sa priorité ;
• le responsable de l’actif ou du service ;
• le patch, l’atténuation ou l’acceptation choisis ;
• l’échéance et le statut actuel ;
• la méthode de validation de la clôture.

Si le finding révèle une infrastructure suspecte ou un indicateur lié, validez-le avec la Recherche intelligente. Envoyez les changements urgents vers les Alertes et le Centre d’actions, puis ouvrez un Dossier lorsque plusieurs équipes ou artefacts sont nécessaires.

L’analyse de réponse BlueHammer montre comment une vulnérabilité endpoint déjà corrigée peut rester urgente lorsque le déploiement est irrégulier et que l’attaquant possède un premier accès.

Maintenir l’exactitude du périmètre

La qualité du finding dépend de celle de la correspondance produit. Actualisez les CPE lorsqu’un produit est introduit ou retiré, qu’une version majeure change, qu’un service devient exposé, que la responsabilité change d’équipe, qu’une relation fournisseur débute ou se termine, ou qu’une correction d’inventaire révèle une fausse correspondance.

Planifiez une revue périodique avec les responsables d’actifs. Une file CVE propre construite sur un inventaire obsolète reste fausse.

Séparer catalogue, finding et incident

Ces trois objets répondent à des questions différentes :

• Une CVE du catalogue décrit une vulnérabilité connue mondialement.
• Un finding relie cette CVE à un produit de l’un de vos périmètres.
• Un incident conserve les preuves qu’une exploitation ou compromission a touché l’environnement.

Ne transformez pas chaque finding en incident. Validez d’abord l’exposition et cherchez les preuves de compromission. À l’inverse, n’attendez pas un incident pour corriger une vulnérabilité KEV sur un système critique accessible.

Utilisez le tableau des menaces pour examiner les campagnes actives et le guide des sources pour évaluer les preuves associées.

Installer une cadence de revue ciblée

À chaque revue :

1. Examinez les nouveaux findings avec exploitation active ou contexte KEV.
2. Revoyez les EPSS élevés sur les produits exposés et critiques.
3. Rapprochez les correspondances produits de l’inventaire actuel.
4. Actualisez responsables, échéances et statut de remédiation.
5. Escaladez toute preuve de compromission dans le workflow d’incident.
6. Clôturez uniquement après validation du patch ou de l’atténuation.

CVE Watch rend le renseignement sur les vulnérabilités plus petit et plus pertinent. Le périmètre définit ce qui appartient à l’organisation. Les signaux d’exploitation montrent ce qui bouge. Le contexte métier et les actifs décident de ce que l’équipe traite en premier.