Calculateur CVSS

Qu'est-ce qu'un score CVSS ?

Le CVSS (Common Vulnerability Scoring System) est une méthode standardisée pour évaluer la sévérité des vulnérabilités logicielles. Il produit un score de 0,0 à 10,0 basé sur plusieurs facteurs d'impact et d'exploitabilité.

Fonctionnement

1. Sélectionnez des valeurs pour chaque vecteur (par exemple AV, AC, PR).

2. Le score de base et la chaîne vectorielle sont calculés automatiquement.

3. Copiez et utilisez dans vos rapports ou audits de sécurité.

Interaction utilisateur (UI)

La métrique d'interaction utilisateur mesure si une vulnérabilité peut être exploitée de façon autonome ou si elle nécessite qu'un utilisateur joue un rôle actif.

• Aucune : si ce champ est défini sur "Aucune", cela signifie que l'attaquant n'a besoin de l'aide de personne, la vulnérabilité peut être déclenchée sans aucune intervention de l'utilisateur, ce qui tend à augmenter le risque.

• Requise : si "Requise" est sélectionné, l'exploitation n'est possible que si un utilisateur légitime effectue une action spécifique au préalable, comme cliquer sur un lien, ouvrir une pièce jointe ou effectuer une installation système. Cette dépendance à l'utilisateur peut parfois réduire la probabilité d'une attaque réussie.

En évaluant cette métrique, CVSS v3.1 vous aide à comprendre dans quelle mesure une attaque repose sur l'interaction humaine par opposition à une automatisation complète.

Disponibilité (A)

Lors de l'évaluation de la disponibilité dans CVSS v3.1, vous choisissez parmi trois niveaux, chacun capturant un degré différent d'impact sur la disponibilité du système et l'accès aux ressources :

• Élevée (pire cas) : l'attaquant peut complètement bloquer l'accès aux ressources du composant ciblé. Cela peut se manifester par une interruption totale du service, où les utilisateurs ne peuvent plus accéder aux systèmes critiques, soit pendant toute la durée de l'attaque, soit durablement après. Dans certains cas, la vulnérabilité peut nécessiter plusieurs exploitations, mais le résultat est un blocage total pour les utilisateurs légitimes.

• Faible (mauvais) : dans ce scénario, les performances peuvent baisser ou des interruptions intermittentes de disponibilité des ressources peuvent survenir. Bien que le service ne soit pas complètement hors ligne, l'impact est tangible : les utilisateurs peuvent ressentir des lenteurs, des pannes partielles ou des interruptions intermittentes, mais sans conséquence directe catastrophique.

• Aucune (bon) : aucun impact. La vulnérabilité ne touche pas le temps de fonctionnement du système ni la capacité des utilisateurs à accéder à ses ressources.

Chaque évaluation aide à définir clairement à quel point un problème peut affecter votre capacité à maintenir les services opérationnels, facilitant ainsi la priorisation des corrections là où c'est le plus important.

Intégrité

Lors de l'évaluation de la métrique "Intégrité" dans CVSS v3.1, nous examinons dans quelle mesure un attaquant pourrait altérer des données protégées ou des ressources système :

• Élevée : pire cas. Un attaquant peut modifier librement toutes les données, ou effectuer des changements aux conséquences directes graves, comme modifier des fichiers système vitaux ou des bases de données sensibles.

• Faible : l'attaquant peut effectuer certaines modifications non autorisées, mais leur portée est limitée ou sans effets immédiats graves sur le système.

• Aucune : aucune opportunité pour un attaquant d'altérer des données ; l'intégrité reste intacte.

Exemples pour chaque vecteur d'attaque et exigence de privilège

Vecteurs d'attaque (AV)

Le vecteur d'attaque décrit comment un attaquant peut exploiter une vulnérabilité :

• Réseau : exploit à distance classique, par exemple l'envoi de paquets spécialement forgés via Internet pour compromettre un serveur web. Ces attaques peuvent se produire depuis n'importe où, ne nécessitant qu'un accès réseau. Pensez au ransomware WannaCry qui a exploité des vulnérabilités SMB à l'échelle mondiale.

• Adjacent : l'attaquant doit être sur le même réseau local ou dans un domaine administratif limité. Par exemple, une attaque Wi-Fi où quelqu'un inonde un réseau local de requêtes ARP, ou un exploit qui se propage via un VPN partagé sans dépasser Internet.

• Local : ces attaques nécessitent que l'auteur ait déjà accès au système, directement au clavier ou à distance via une connexion SSH. Exemple classique : inciter un utilisateur connecté à ouvrir un fichier malveillant par ingénierie sociale.

• Physique : l'attaquant doit avoir un accès direct au matériel, comme extraire des clés de chiffrement en se connectant brièvement aux puces mémoire, ou brancher un périphérique USB malveillant pour exploiter l'accès direct à la mémoire.

Choisissez le vecteur d'attaque le plus approprié pour la vulnérabilité en question, car cela influencera l'évaluation globale du risque.

Privilèges requis (PR)

La métrique des privilèges requis (PR) décrit le niveau d'accès qu'un attaquant doit avoir sur un système vulnérable pour exploiter une vulnérabilité donnée :

• Aucun : l'attaquant n'a pas besoin d'être authentifié. Par exemple, exploiter une vulnérabilité d'application web publique accessible à n'importe qui sur Internet sans permissions particulières.

• Faibles : l'attaquant a besoin de permissions utilisateur de base, comme un compte normal sans droits d'administration. Exemple : exploiter un bug d'élévation de privilèges locale pour passer d'utilisateur standard à administrateur.

• Élevés : des privilèges système significatifs sont requis avant que l'attaque puisse se produire. Cas classique : exploiter une vulnérabilité accessible uniquement à un administrateur ou root.

Cette répartition aide à clarifier le risque : moins un attaquant a besoin de privilèges, plus la vulnérabilité est sévère.

Complexité de l'attaque (AC)

Faible : l'attaque nécessite un effort minimal. L'attaquant peut s'attendre à un succès répétable lorsqu'il cible le composant vulnérable.

Élevée : une attaque réussie n'est pas simple. Elle dépend de facteurs hors du contrôle direct de l'attaquant, nécessitant une préparation supplémentaire ou des circonstances spécifiques. L'attaquant doit investir un effort mesurable avant de réussir.

Comment CVSS v3.1 classe l'impact sur la confidentialité

CVSS v3.1 catégorise l'impact sur la confidentialité en trois niveaux :

• Élevé : pire cas, quand des données sensibles sont entièrement exposées à un attaquant. Pensez aux mots de passe d'administrateur ou aux clés de chiffrement privées tombant entre de mauvaises mains.

• Faible : l'attaquant obtient un certain accès à des informations confidentielles, mais c'est limité. Il ne peut pas choisir ce qui est révélé, ou les données divulguées n'entraînent pas de conséquences immédiates graves.

• Aucun : idéal, aucune information confidentielle n'est compromise.

Conséquences directes et indirectes dans CVSS v3.1

CVSS v3.1 distingue également les conséquences directes et indirectes sous chaque catégorie.

• Conséquences directes : se produisent quand les actions d'un attaquant impactent immédiatement et sérieusement le composant. Pour la confidentialité, cela pourrait signifier que l'attaquant obtient des informations sensibles comme des mots de passe ou des clés de chiffrement. Pour l'intégrité, l'attaquant peut délibérément et significativement altérer des fichiers protégés. Pour la disponibilité, une conséquence directe pourrait être un déni de service total.

• Conséquences indirectes : l'impact est moins immédiat ou grave. Si l'accès de l'attaquant est limité, ou si les changements peuvent survenir mais sans résultat critique évident, les conséquences sont considérées comme indirectes.

Qu'est-ce que la portée (Scope) dans CVSS v3.1 et quel est l'impact des options "Changed" et "Unchanged" sur le score ?

La portée décrit si une vulnérabilité, une fois exploitée, n'impacte que ce que l'autorité de sécurité initiale contrôle ou si elle s'étend au-delà de ses limites.

• Unchanged : une vulnérabilité exploitée ne peut affecter que les ressources gérées par la même autorité de sécurité. Le composant vulnérable et le composant impacté sont soit identiques, soit sous un même domaine d'autorité.

• Changed : la portée change. Une vulnérabilité exploitée peut affecter des ressources en dehors de la portée de sécurité initialement gérée. Le composant vulnérable et le composant impacté sont différents et peuvent être gérés par des autorités entièrement distinctes.

Comprendre la portée est crucial pour évaluer le rayon d'explosion potentiel d'une vulnérabilité.

Fonctionnalités principales

• Prise en charge du scoring CVSS v3.1

• Génération dynamique de la chaîne vectorielle

• Mise à jour du score en temps réel

• Interface simple pour des évaluations de sécurité rapides

• Idéal pour la conformité, DevSecOps et les soumissions de bug bounty

Exemple de sortie

Score de sévérité, vecteur :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Score : 9,8 - Critique

Comprendre "Pire", "Mauvais" et "Bon" dans CVSS v3.1

Dans le cadre CVSS v3.1, ces termes décrivent la sévérité relative ou la favorabilité des options possibles pour chaque métrique, comme des indicateurs rapides le long d'un spectre allant de l'impact le plus critique au moins grave.

• Pire (Worst) : indique l'option la plus sévère pour une métrique donnée. Par exemple, une vulnérabilité accessible via Internet représente le risque le plus élevé.

• Plus grave (Worse) : juste en dessous de "Pire" en sévérité. Encore assez dangereux, peut-être limité aux voisins réseau, mais pas aussi étendu que le scénario "Pire".

• Mauvais (Bad) : impact négatif significatif mais moins grave. Par exemple, l'exploitation peut nécessiter un accès local ou des privilèges spéciaux.

• Bon (Good) : scénario le plus favorable pour cette métrique, risque ou impact minimal. Si l'intégrité ou la confidentialité est "Bon", cela signifie généralement que ces qualités ne sont pas affectées.

En bref : "Pire" est votre alerte rouge, "Plus grave" est un avertissement sérieux, "Mauvais" est une mise en garde, et "Bon" signifie que vous êtes à l'abri.

Cas d'utilisation courants

• Tests de pénétration et red teaming

• Gates de sécurité DevSecOps

• Priorisation des correctifs logiciels

• Conformité sécurité (ISO 27001, SOC 2)

• Soumissions de bug bounty

Outils complémentaires recommandés

• Générateur de mots de passe : pour sécuriser les endpoints

• Générateur de tokens : pour les simulations API

• Générateur d'UUID : pour la génération d'identifiants uniques dans le suivi de bugs

• Générateur d'adresses IP : pour la simulation réseau