Gains :
- Capacité à établir des priorités avec précision en combinant CVSS (gravité), EPSS (probabilité d'abus) et KEV (abus réel) avec le contexte institutionnel (exposition, criticité, contrôle compensatoire)
- Possibilité de vérifier les numéros et scores CVE que l'intelligence artificielle peut créer dans les sources NVD/EPSS/KEV et de transmettre le plan de correctifs via la porte de gestion des modifications
- Comprenez qu'un CVSS élevé ne signifie pas à lui seul une priorité, mais que le risque réel est déterminé par le contexte.
Il existe des milliers de vulnérabilités dans chaque organisation : une vulnérabilité dans un logiciel, une mauvaise configuration ou un composant obsolète qu'un attaquant peut exploiter. Un scanner de vulnérabilités (un outil qui analyse les systèmes et répertorie les vulnérabilités connues) produit facilement entre 10 000 et 50 000 résultats dans une organisation de taille moyenne. Le problème n’est pas de les trouver ; Dans cette pile où il est impossible de tous les fermer en même temps, il est important de décider lequel patcher en premier. Une mauvaise hiérarchisation cause des dommages de deux manières : vous retardez ce qui est vraiment dangereux, ou vous épuisez l'équipe et la continuité des activités sur des milliers de découvertes sans importance.
L’intelligence artificielle est une aide puissante dans cette priorisation. Il peut regrouper des milliers de lignes de résultats d'analyse, combiner des doublons, traduire chaque résultat en langage humain, expliquer « pourquoi est-ce important » et fournir un aperçu de la priorisation. Mais l’IA ne sait pas quel serveur de votre organisation est ouvert à Internet et lequel contient des données critiques ; Et le plus dangereux, c'est qu'il peut fabriquer une identité de vulnérabilité (CVE) qui n'existe pas. Ainsi, l'IA génère et explique le schéma du classement, mais la décision finale de priorité est prise par l'analyste avec le contexte institutionnel et les données validées.
Concepts de base de la priorisation
Clarifions quelques termes. CVE (Common Vulnerabilities and Exposures) est l'identifiant unique attribué à chaque vulnérabilité connue (par exemple CVE-2021-44228, le tristement célèbre Log4Shell). CVSS (Common Vulnerability Scoring System) est la norme qui note la gravité technique d'une vulnérabilité de 0 à 10 ; 9.0+ est considéré comme « critique ». Mais le CVSS à lui seul ne suffit pas, car il indique « quelle est la gravité de la situation », et non « quelle est la probabilité qu'elle soit effectivement utilisée de manière abusive ». C’est là qu’intervient l’EPSS (Exploit Prediction Scoring System) : il prédit la probabilité qu’une vulnérabilité soit effectivement exploitée dans les 30 prochains jours. Il existe également la liste KEV (Known Exploited Vulnerabilities) : vulnérabilités dont il a été prouvé qu'elles étaient utilisées dans des attaques réelles ; Ce sont des priorités absolues.
Une hiérarchisation appropriée combine ces trois éléments et le contexte de l'entreprise : CVSS élevé + EPSS élevé + sur la liste KEV + serveur critique ouvert à Internet = correctif immédiat. CVSS élevé mais EPSS faible + sur le réseau interne + accès restreint = correctifs programmés.
Tableau des facteurs de priorisation
facteur
qu'est-ce que ça dit
Source
Est-ce suffisant seul ?
Score CVSS
Sérieux technique (0-10)
NVD / fournisseur
Non, ça ne dit pas probabilité
Score EPSS
Probabilité d'être exploité (%)
FIRST.org
Non, le contexte ne le dit pas
Liste KEV
Est-il réellement exploité ?
LPCC KEV
Signal fort, pas le seul
Criticité des actifs
Quelle est la valeur du serveur ?
Inventaire institutionnel
Fournit du contexte
exposition
Est-il ouvert à Internet ou isolé ?
architecture réseau
Fournit du contexte
contrôle compensatoire
WAF, y a-t-il une segmentation ?
Informations sur l'établissement
Réduit le risque
L’IA s’empresse de remplir ce tableau ; Mais il est de votre responsabilité de confirmer les valeurs CVSS/EPSS/KEV auprès de la source officielle et d'ajouter la criticité et l'exposition de l'actif avec les connaissances institutionnelles.
Étapes de priorisation des vulnérabilités
- Collectez et anonymisez les résultats de l'analyse. Masquez les noms d’hôtes et les adresses IP internes.
- Regroupez et réduisez les répétitions. Laissez l'IA combiner les répétitions de la même vulnérabilité sur différentes machines et créer une liste CVE unique.
- Enrichir. Incluez les statuts CVSS, EPSS et KEV pour chaque CVE, mais vérifiez-les auprès de la source officielle.
- Ajoutez du contexte. Quel système est ouvert à Internet, qui contient des données critiques, quel contrôle compensatoire existe – vous l’additionnez.
- Trier par. Faites établir une liste de priorités alliant sérieux + probabilité + contexte.
- Vérifiez et décidez. Confirmez que les CVE des résultats ci-dessus sont authentiques et que les versions existent réellement dans votre établissement ; Approuvez le plan de correctifs en tant qu’analyste.
trois mini-cases
Cas 1 — 12 000 constats, 40 vraies priorités. Un analyste donne à l’IA un résultat d’analyse anonymisé de 12 000 lignes. L'IA combine les répétitions et les réduit à 380 CVE uniques, les enrichit avec des données EPSS et KEV et met en évidence « 40 vulnérabilités qui figurent sur la liste KEV et situées sur le serveur ouvert à Internet ». L'analyste confirme ces 40 CVE dans le catalogue NVD et KEV, corrigeant les 3 vulnérabilités critiques qui existent réellement en 24 heures. La pile est passée de 12 000 à un chiffre gérable de 40 ; L'analyste a pris la décision.
Cas 2 – Faux CVE. Un autre analyste donne la priorité à l’IA ; L'IA indique "CVE-2023-88888, CVSS 9.8, patch maintenant". L'analyste recherche ce numéro dans NVD — aucun enregistrement, modèle inventé. Si cela n'avait pas été confirmé, l'équipe aurait recherché un patch qui n'existait pas. Leçon : tous les numéros CVE ne sont pas prioritaires tant qu'ils ne sont pas vérifiés dans le registre NVD/fournisseur.
Cas 3 — Le CVSS est élevé mais le risque est faible. Un scanner trouve une vulnérabilité CVSS 9.1 sur un serveur de test du réseau interne. L’IA met cela en premier. Mais l'analyste ajoute du contexte : le serveur est fermé à Internet, il n'y a pas de données critiques, il y a une segmentation du réseau devant lui, et le score EPSS est de 0,4 %. Dans la même liste, il existe une autre vulnérabilité qui est CVSS 7.5 mais qui est ouverte sur Internet et est en KEV. L'analyste corrige le classement : la vulnérabilité dans KEV, avec un faible CVSS mais effectivement exploitée, vient en premier. Leçon : CVSS seul n’est pas une priorité ; le contexte détermine.
Invite faible/Invite forte
Invite faible :
Classez ces vulnérabilités de la plus dangereuse à la plus dangereuse et notez leurs scores CVSS. [sortie de numérisation]
Cette affirmation repose uniquement sur CVSS (en ignorant la probabilité et le contexte), laisse la porte ouverte à l’IA pour s’adapter aux valeurs CVSS/CVE et ne prend pas en compte l’exposition de l’agence.
Invite puissante :
Votre rôle : priorisation PROJET assistant à l'analyste sécurité. Prise de décision; Ne commandez pas de correctifs. Traitez la sortie d'analyse anonyme suivante : (1) fusionnez les doublons, affichez une liste CVE unique, (2) renseignez les statuts CVSS, EPSS et KEV pour chaque CVE MAIS marquez chaque valeur comme "[Doit être vérifié à partir de NVD/EPSS/KEV]" ; N'inventez aucune valeur, écrivez "[inconnu]" en cas de doute, (3) écrivez-moi 3 questions que je devrais poser pour le contexte institutionnel (exposition, criticité des actifs, contrôle compensatoire), (4) fournissez un classement PRÉLIMINAIRE basé sur des données techniques uniquement, précisez que je le corrigerai avec le contexte de l'entreprise. Résultat : [résultat de l'analyse anonyme]
L'invite puissante demande le trio CVSS/EPSS/KEV, laisse chaque valeur à vérifier, vous prend le contexte institutionnel et vous donne la décision finale.
Modèles d'invite copiables
MODÈLE DE GROUPEMENT DE VULNÉRABILITÉS Traitez le résultat d'analyse anonyme suivant : (1) combinez les occurrences du même CVE sur différentes machines, (2) extrayez le CVE unique et le nombre de machines affectées, (3) regroupez par produit/composant. N'inventez aucun numéro CVE ; n'ajoutez pas quelque chose qui ne figure pas dans la source. Résultat : [coller]
MODÈLE D'ENRICHISSEMENT TRIPLE Pour la liste CVE, ajoutez le score de base CVSS, la probabilité EPSS et s'il figure sur la liste KEV dans chaque ligne. exporter CHAQUE valeur avec l'indicateur "[verify: source]" ; Présentation de données précises, fabrication. Tapez "[confirmer dans NVD]" pour le CVE dont vous n'êtes pas sûr. CVE : [coller]
MODÈLE DE QUESTIONS CONTEXTEPour les vulnérabilités prioritaires suivantes, générez les questions que vous devez me poser sur le contexte de l'organisation afin que je puisse les classer correctement : exposition (est-elle ouverte à Internet), criticité des actifs, sensibilité des données, contrôles compensatoires, fenêtre de correctifs. Je vais donner les réponses; Vous ne mettez à jour le classement qu’après cela. Vulnérabilités : [coller]
MODÈLE DE PROJET DE PLAN DE PATCH Ébauche d'un plan de correctif basé sur la liste de priorités validée et le contexte que je fournis : seaux immédiats (24h), à court terme (7j), planifiés (30j) ; justification de chaque vulnérabilité et impact potentiel sur l’activité/risque de panne. Ceci est une ébauche ; l’approbation et la mise en œuvre appartiennent à l’analyste et à la gestion du changement. Données : [coller]
Erreurs courantes
- Je regarde simplement CVSS. Un CVSS élevé peut indiquer un risque réel faible ; Considérez ensemble l’EPSS (probabilité), le KEV (exploitation réelle) et le contexte.
- Ne pas vérifier CVE. Les non-IA peuvent constituer des numéros et des scores CVE ; confirmez chacun avec l’enregistrement NVD/revendeur.
- Contourner le contexte institutionnel. Est-ce qu’il est ouvert à Internet, existe-t-il des données critiques, existe-t-il un contrôle compensatoire – tout cela change complètement le classement.
- En supposant que la version corresponde. Le navigateur lit parfois la mauvaise version ; Vérifiez que la vulnérabilité existe réellement dans votre organisation (analyse des faux positifs).
- Implémenter le plan de correctifs seul sans impact commercial. Un correctif critique peut entraîner une interruption des activités ; La gestion du changement et les tests sont essentiels.
Astuce : La combinaison idéale en matière de priorisation est "listé KEV + ouvert à Internet + EPSS élevé". Si ces trois éléments se croisent, cette vulnérabilité apparaît en haut de la liste, quel que soit le CVSS.
Attention : Déclarer une vulnérabilité comme « critique » et la corriger immédiatement peut également être risqué ; Un correctif non testé peut faire planter la production. Le plan produit par l’IA est un modèle ; la mise en œuvre passe par le processus de gestion du changement et la porte de test.
En résumé
La partie difficile de la gestion des vulnérabilités n’est pas de la trouver, mais de mettre en évidence la bonne parmi des milliers de découvertes. L'IA regroupe le résultat de l'analyse, réduit les répétitions, le traduit en langage humain et fournit un aperçu du classement. Mais la véritable priorité ne vient pas d’un seul chiffre : CVSS (gravité), EPSS (probabilité), KEV (exploitation réelle) et contexte institutionnel (exposition, criticité, contrôle compensatoire) sont évalués ensemble. L’erreur la plus dangereuse de l’IA est la non-CVE et la fabrication de scores ; Ainsi, chaque valeur est validée dans NVD/EPSS/KEV, le contexte d'entreprise est ajouté par vous et le plan d'application de correctifs passe par la porte de gestion des modifications.
Tâche de candidature
Obtenez un exemple de résultat d’analyse (anonymisé de vous-même ou à partir d’échantillons de données). Extrayez la liste CVE unique et le contour CVSS/EPSS/KEV de l'IA avec les modèles « Regroupement de vulnérabilités » et « Triple Enrichissement ». Vérifiez vous-même les 5 meilleurs CVE dans le catalogue NVD et CISA KEV ; Essayez de détecter au moins une valeur fictive ou fausse. Répondez ensuite aux questions du modèle « Question contextuelle » pour votre environnement et notez comment l'ordre change.
liste de contrôle
- [ ] J'ai anonymisé le résultat de l'analyse ; l'hôte et l'IP sont masqués.
- [ ] J'ai combiné les doublons pour obtenir une liste de CVE uniques.
- [ ] J'ai vérifié chaque valeur CVE et CVSS/EPSS/KEV dans la source officielle.
- [ ] Sachant qu'il pourrait s'agir d'un faux CVE/score, je l'ai confirmé.
- [ ] J'ai inclus le contexte institutionnel (exposition, criticité, contrôle compensatoire) dans le classement.
- [ ] Pas seulement CVSS ; J'ai également regardé EPSS et KEV.
- [ ] J'ai traité le plan de correctif comme un brouillon ; J'ai ajouté la porte de test et de gestion des changements.