Menace, vulnérabilité, risque et impact : quatre notions distinctes

Ce contenu est destiné aux débutants et aux personnes qui doivent lire un audit, participer à une analyse de risque ou prioriser des mesures de sécurité. Aucun outil n’est requis. Il suffit de savoir décrire un actif, c’est-à-dire une ressource qui a de la valeur pour une activité : données, service, appareil, réputation, temps ou capacité de travail.

Les définitions varient légèrement selon les référentiels. Le glossaire du NIST agrège d’ailleurs plusieurs formulations issues de publications différentes. L’objectif n’est donc pas d’imposer une phrase universelle, mais de conserver des distinctions stables pour raisonner sans ambiguïté.

Une analyse utile ne commence pas par une liste abstraite de failles. Elle relie plusieurs éléments :

actif et objectif -> menace -> vulnérabilité ou condition -> événement -> conséquences -> impact

Prenons une petite association qui conserve les coordonnées de ses membres dans un service cloud. Son objectif est de pouvoir gérer les adhésions sans divulguer ces données.

• Actif : le fichier des adhérents et le service qui l’héberge.
• Menace : une personne malveillante cherche à obtenir des accès.
• Vulnérabilité : un compte administrateur utilise un mot de passe réemployé et aucune MFA.
• Événement redouté : l’attaquant se connecte et exporte le fichier.
• Impact : divulgation de données, temps d’enquête, notifications éventuelles et perte de confiance.
• Risque : possibilité que ce scénario affecte les objectifs de l’association, évaluée selon sa vraisemblance et la gravité de ses conséquences.

Cette chaîne montre pourquoi corriger une vulnérabilité réduit un risque sans faire disparaître toutes les menaces. Activer une MFA peut compliquer l’utilisation d’un mot de passe volé, mais ne protège pas forcément contre un administrateur légitime malveillant, un partage public accidentel ou un terminal déjà compromis.

Dans les publications du NIST, une menace est une circonstance ou un événement susceptible d’avoir un effet défavorable sur les opérations, les actifs, les personnes ou d’autres organisations. Elle peut être intentionnelle, accidentelle, technique ou environnementale.

Un cybercriminel est une source de menace. Une campagne de phishing est un mode d’action. Une panne électrique, une erreur humaine ou une inondation peuvent aussi menacer la disponibilité d’un service. Réduire la notion de menace à « un pirate » fait oublier une grande partie des scénarios réels.

Lorsqu'elle provient d'un acteur, la menace peut être décrite par sa capacité, son intention et les occasions d'agir. Pour une menace accidentelle ou environnementale, on examine plutôt les conditions de survenue et l'exposition. Ces attributs influencent la vraisemblance, mais ne suffisent pas à décrire le risque complet. Sans actif exposé ni conséquence pour l’organisation, une menace générale peut rester peu pertinente pour la décision étudiée.

Le terme peut être vérifié dans le glossaire Threat du NIST.

Une vulnérabilité est une faiblesse dans un système, une procédure, un contrôle ou une mise en œuvre, qui peut être exploitée ou déclenchée par une source de menace. Elle peut être technique, comme un logiciel non corrigé, mais aussi organisationnelle : droits non révisés, sauvegardes jamais testées, procédure de départ incomplète ou absence de séparation des rôles.

Une vulnérabilité n’est pas synonyme d’exploitation. La présence d’une version vulnérable ne prouve pas qu’un attaquant a réussi. Elle ne donne pas non plus automatiquement la priorité de correction. Il faut examiner l’exposition, les contrôles compensatoires, la valeur des actifs et les conséquences possibles.

À l’inverse, l’absence de CVE connue ne démontre pas l’absence de faiblesse. Une mauvaise configuration, une logique métier fragile ou une erreur de processus peut créer un scénario de risque sans vulnérabilité logicielle référencée.

Cette définition suit le glossaire Vulnerability du NIST.

Le NIST définit le risque comme une mesure de la manière dont une entité est menacée par une circonstance ou un événement potentiel, généralement fonction des impacts défavorables et de la vraisemblance. Dans un cadre plus large, le risque est lié à l’incertitude qui affecte les objectifs.

En pratique, il faut nommer le scénario. Écrire « risque : ransomware » reste trop vague. Une formulation exploitable serait : « un opérateur de rançongiciel exploite un accès distant insuffisamment protégé, chiffre les serveurs et interrompt la facturation pendant plusieurs jours ».

On peut ensuite estimer la vraisemblance et l’impact sur des échelles simples, par exemple faible, moyen et élevé. Le produit de deux notes n’est pas une vérité mathématique. Une matrice aide à comparer, mais elle dépend des échelles, des informations disponibles et de l’appétence au risque. Les hypothèses doivent rester visibles.

Le risque brut désigne souvent le niveau avant certains contrôles. Le risque résiduel est celui qui demeure après les mesures prises. Il existe aussi un risque introduit par le traitement lui-même : complexité, indisponibilité, coût ou dépendance à un fournisseur.

Le glossaire Risk du NIST fournit la définition courte, et le guide NIST SP 800-30 Rev. 1 détaille la conduite d’une évaluation de risque.

L’impact est la conséquence d’un événement sur les opérations, les actifs, les personnes, les finances, les obligations ou la réputation. Il ne se limite pas à une somme d’argent. Une indisponibilité de deux heures peut être tolérable pour un site vitrine et critique pour un service de soins.

Pour éviter les qualificatifs vagues, décris l’impact avec des unités ou des seuils : durée maximale d’interruption, nombre de personnes concernées, volume de données, coût de reconstitution, délai réglementaire, perte de capacité ou atteinte à la sécurité physique.

Distingue impact direct et indirect. Le coût de restauration est direct. La perte future de contrats peut constituer un impact indirect, plus difficile à estimer. Ne présente pas une hypothèse réputationnelle comme un fait certain.

Première erreur : appeler « risque » toute vulnérabilité détectée par un scanner. Le rapport technique fournit une faiblesse et parfois une sévérité, pas le contexte métier complet.

Deuxième erreur : confondre impact et vraisemblance. Un événement très grave mais rare doit être discuté autrement qu’un incident fréquent mais limité. Les deux dimensions comptent.

Troisième erreur : utiliser le score CVSS comme score de risque. CVSS décrit la sévérité technique d’une vulnérabilité selon des métriques définies. Il ne remplace pas la valeur de l’actif, l’exposition réelle ni les conséquences propres à l’organisation.

Quatrième erreur : chercher le « risque zéro ». Aucun contrôle raisonnable ne supprime toute incertitude. La décision consiste à éviter, réduire, transférer ou accepter un risque avec une justification, un responsable et une date de réexamen.

Cadre : travaille sur un scénario fictif ou sur un service que tu es autorisé à administrer. Ne teste aucun compte tiers et n’essaie pas d’exploiter une faiblesse.

Scénario : une équipe partage un tableur contenant des coordonnées clients. Le lien est accessible à toute personne qui le possède, et il a été envoyé dans plusieurs conversations.

1. Décris l’objectif métier en une phrase.
2. Nomme l’actif principal et deux actifs secondaires.
3. Identifie une source de menace intentionnelle et une cause accidentelle.
4. Formule la vulnérabilité sans employer le mot « risque ».
5. Écris un événement redouté en précisant la source ou la cause, l'action ou l'événement, puis l'actif touché.
6. Décris trois impacts observables : confidentialité, activité et temps de traitement.
7. Estime vraisemblance et impact sur une échelle de trois niveaux, avec une justification par note.
8. Propose un contrôle préventif et un contrôle de détection.
9. Réévalue le risque résiduel et note ce qui reste incertain.

Durée indicative : 30 à 40 minutes. Une page suffit.

L’exercice est réussi si une autre personne peut distinguer clairement la menace, la vulnérabilité, l’événement, l’impact et le risque sans demander ce que chaque ligne signifie. Il n'existe pas nécessairement une note unique. L'essentiel est de rendre le raisonnement traçable : chaque estimation doit reposer sur une hypothèse explicite et chaque contrôle doit agir sur une partie identifiable du scénario.

• Évaluer sans périmètre : un même incident n’a pas le même sens selon l’actif et l’objectif.
• Employer des catégories trop générales : « humain », « cyberattaque » ou « données perdues » ne décrivent pas un scénario.
• Inventer des probabilités précises : sans historique ni données adaptées, « 73 % » donne une fausse impression de mesure.
• Oublier les contrôles existants : sauvegarde, journalisation, segmentation et procédures changent la vraisemblance ou l’impact.
• Confondre conformité et risque : respecter une exigence peut être nécessaire sans couvrir tous les scénarios.
• Additionner des scores incompatibles : une note qualitative locale et un score technique ne partagent pas forcément la même échelle.
• Figer l’analyse : menaces, actifs et dépendances évoluent. Une revue est nécessaire après un changement significatif ou un incident.

Une analyse courte peut guider une décision locale. Pour un système critique, une méthode formelle, des parties prenantes métier et des données plus solides sont nécessaires.