Ces quatre termes reviennent constamment en cybersécurité, souvent utilisés de façon interchangeable. Pourtant, ils désignent des concepts distincts. Confondre une vulnérabilité avec un risque, ou une menace avec une attaque, mène à des décisions de sécurité incohérentes. Ce guide pose les définitions et montre comment ces notions s’articulent dans la pratique.
Les quatre concepts fondamentaux
Section intitulée « Les quatre concepts fondamentaux »Avant de plonger dans les détails, comprenons comment ces quatre concepts s’emboîtent. Imaginez une maison : une fenêtre mal fermée est une vulnérabilité. Un cambrioleur dans le quartier est une menace. Le moment où il entre par cette fenêtre est une attaque. Le risque évalue la probabilité que cela arrive et les conséquences si cela se produit.
Une faiblesse exploitable
Section intitulée « Une faiblesse exploitable »Une vulnérabilité est une faiblesse dans un système, un processus ou une organisation. Elle existe indépendamment de toute intention malveillante. C’est une porte ouverte — le problème survient quand quelqu’un décide de la franchir.
Les vulnérabilités peuvent être techniques (un serveur web sans authentification, un mot de passe stocké en clair), humaines (un employé non formé au phishing), ou organisationnelles (pas de processus de revue de code).
Ce qui caractérise une vulnérabilité, c’est qu’elle existe même sans attaquant. Elle persiste jusqu’à sa correction ou son atténuation. Sa gravité dépend de ce qu’elle permet : simple lecture de données, modification, ou prise de contrôle complète.
Un danger potentiel
Section intitulée « Un danger potentiel »Une menace est un acteur ou un événement susceptible d’exploiter une vulnérabilité. Elle représente le qui ou le quoi qui pourrait causer un dommage.
Les menaces se répartissent en plusieurs catégories. Les acteurs humains incluent les cybercriminels, les employés malveillants, les hacktivistes et les États-nations. Les événements naturels comme les incendies, inondations ou coupures électriques constituent aussi des menaces. Les défaillances techniques (pannes matérielles, corruption de données) et les erreurs humaines (suppression accidentelle, mauvaise configuration) complètent le tableau.
Une menace existe indépendamment de la présence d’une vulnérabilité. Un attaquant motivé reste une menace même si aucune faille n’est actuellement connue dans votre système. Il attend simplement l’opportunité.
L’exploitation en action
Section intitulée « L’exploitation en action »Une attaque est la réalisation concrète d’une menace qui exploite une vulnérabilité. C’est le passage à l’acte — le moment où les conditions se réunissent pour causer un dommage réel.
L’attaque nécessite trois éléments simultanés : une vulnérabilité exploitable, une menace capable et motivée, et une opportunité (accès au système, fenêtre de temps). Sans vulnérabilité, pas d’exploitation possible. Sans menace active, pas d’attaque. Sans opportunité, l’attaquant ne peut pas agir.
Vulnérabilité : Application web sans validation d'entrées +Menace : Attaquant externe avec connaissances SQL +Opportunité : Application exposée sur Internet =Attaque : Injection SQL permettant l'extraction de donnéesLa combinaison des facteurs
Section intitulée « La combinaison des facteurs »Le risque est le concept central de la gestion de sécurité. C’est ce qu’on évalue, ce qu’on priorise, et ce qu’on gère au quotidien. Formellement, le risque combine la probabilité qu’une menace exploite une vulnérabilité, multipliée par l’impact que cela causerait.
Risque = Probabilité × Impact
Le risque n’est pas binaire. Il se mesure, se compare, et surtout se gère. On ne peut pas éliminer tous les risques, mais on peut les réduire à un niveau acceptable pour l’organisation.
Pour évaluer un risque, posez-vous quatre questions : Quelle faiblesse existe (vulnérabilité) ? Qui pourrait l’exploiter (menace) ? Quelle chance que cela arrive (probabilité) ? Quelles conséquences en cas d’exploitation (impact) ?
Apprendre par l’exemple : deux scénarios concrets
Section intitulée « Apprendre par l’exemple : deux scénarios concrets »La théorie prend tout son sens quand on l’applique à des situations réelles. Ces deux scénarios illustrent comment les concepts de vulnérabilité, menace, attaque et risque s’articulent dans la pratique — et comment des décisions différentes mènent à des résultats opposés.
Scénario 1 : quand le risque est sous-évalué
Section intitulée « Scénario 1 : quand le risque est sous-évalué »Une équipe découvre une vulnérabilité dans une bibliothèque utilisée par l’application principale. La correction nécessite une mise à jour majeure qui casserait des fonctionnalités existantes. L’équipe décide de reporter la correction « après la release ».
Trois semaines plus tard, un attaquant exploite cette même vulnérabilité sur des milliers de systèmes dans le monde. L’application est compromise.
Analyse de la situation :
La vulnérabilité existait et était connue de l’équipe. La menace (attaquants exploitant cette faille) était réelle et active — d’autres organisations étaient déjà ciblées. Le risque a été sous-évalué car l’impact métier de la mise à jour semblait plus concret que le risque d’attaque. L’attaque est survenue car la fenêtre d’opportunité était ouverte.
Scénario 2 : quand le risque est géré consciemment
Section intitulée « Scénario 2 : quand le risque est géré consciemment »Une organisation utilise un système legacy critique pour la comptabilité. Ce système présente des vulnérabilités connues mais ne peut pas être mis à jour sans un projet de migration de 18 mois.
Plutôt que d’ignorer le problème ou de paniquer, l’équipe prend des décisions structurées : isoler le système sur un segment réseau dédié, restreindre l’accès aux seuls utilisateurs nécessaires, monitorer toute activité anormale, et planifier la migration avec un budget alloué.
Analyse de la situation :
La vulnérabilité persiste — elle n’a pas disparu. La menace reste présente — des attaquants pourraient toujours cibler ce système. Mais le risque est significativement réduit par les mesures compensatoires. Le risque résiduel est accepté en connaissance de cause, documenté, et suivi.
Comment ces notions s’articulent
Section intitulée « Comment ces notions s’articulent »Le schéma ci-dessous montre la relation entre ces quatre concepts. La menace ne peut causer de dommage que si elle trouve une vulnérabilité à exploiter. Cette exploitation constitue l’attaque. Le risque évalue la probabilité de cette chaîne d’événements et ses conséquences.
Threat Modeling : anticiper plutôt que réagir
Section intitulée « Threat Modeling : anticiper plutôt que réagir »Plutôt que de réagir aux attaques, les équipes matures anticipent les menaces par une analyse systématique. Le Threat Modeling (modélisation des menaces) répond à trois questions fondamentales : Qu’est-ce qu’on protège ?, Contre qui ?, et Comment pourraient-ils attaquer ?
Plusieurs méthodologies existent, chacune adaptée à un contexte différent. Le choix dépend de la complexité du système, des compétences de l’équipe, et des objectifs de l’analyse.
La méthode Microsoft
Section intitulée « La méthode Microsoft »STRIDE catégorise les menaces selon six types, formant un acronyme facile à mémoriser. Cette approche systématique permet de ne rien oublier lors de l’analyse d’un système.
Pour chaque composant de votre architecture, posez-vous la question : « Quelles menaces STRIDE s’appliquent ici ? » Un serveur d’authentification sera particulièrement concerné par le Spoofing (usurpation d’identité). Une API publique par le Denial of Service. Une base de données par l’Information Disclosure.
| Type | Signification | Exemple | Contrôle |
|---|---|---|---|
| Spoofing | Usurpation d’identité | Faux token JWT | Authentification forte |
| Tampering | Altération de données | Modification de logs | Intégrité, signatures |
| Repudiation | Déni d’action | « Je n’ai pas fait ça » | Journalisation non-répudiable |
| Information Disclosure | Fuite d’information | Données en clair interceptées | Chiffrement, contrôle d’accès |
| Denial of Service | Déni de service | Saturation de ressources | Rate limiting, scaling |
| Elevation of Privilege | Élévation de privilèges | Utilisateur → admin | Moindre privilège, séparation |
Quand l’utiliser : Idéal pour des systèmes avec des flux de données clairs, ou pour initier une équipe au threat modeling.
L’approche orientée business
Section intitulée « L’approche orientée business »PASTA (Process for Attack Simulation and Threat Analysis) est une méthodologie en 7 étapes qui aligne la sécurité sur les objectifs métier. Contrairement à STRIDE qui se concentre sur les aspects techniques, PASTA commence par comprendre ce qui a de la valeur pour l’organisation.
-
Définir les objectifs — Aligner sécurité et objectifs métier : que cherche-t-on à protéger et pourquoi ?
-
Définir le périmètre technique — Cartographier l’infrastructure concernée
-
Décomposer l’application — Identifier les flux de données et les frontières de confiance (trust boundaries)
-
Analyser les menaces — Identifier les menaces spécifiques au contexte de l’organisation
-
Analyser les vulnérabilités — Scanner et corréler avec les menaces identifiées
-
Modéliser les attaques — Construire des arbres d’attaque montrant les chemins possibles
-
Analyser les risques et impacts — Prioriser selon l’impact business, pas seulement technique
Quand l’utiliser : Pour des projets complexes où l’impact business doit guider la priorisation des efforts de sécurité.
Les techniques réelles des attaquants
Section intitulée « Les techniques réelles des attaquants »Le framework MITRE ATT&CK ne propose pas une méthodologie de threat modeling à proprement parler, mais catalogue les techniques réellement utilisées par les attaquants. C’est une base de connaissances précieuse pour valider que vos contrôles couvrent les menaces réelles.
Les techniques sont organisées par tactique (l’objectif de l’attaquant à chaque étape) :
| Tactique | Description | Exemples de techniques |
|---|---|---|
| Initial Access | Accès initial au système | Phishing, exploitation de services exposés |
| Execution | Exécuter du code malveillant | PowerShell, scripts, conteneurs |
| Persistence | Maintenir l’accès | Tâches planifiées, comptes créés |
| Privilege Escalation | Obtenir plus de droits | Exploitation de vulnérabilités locales |
| Defense Evasion | Éviter la détection | Désactivation d’antivirus, obfuscation |
| Credential Access | Voler des credentials | Dump de mémoire, keylogger |
| Lateral Movement | Se déplacer dans le réseau | Pass-the-hash, RDP |
| Exfiltration | Extraire des données | Chiffrement, canaux alternatifs |
Usage pratique : Lors d’un threat modeling avec STRIDE ou PASTA, utilisez ATT&CK pour vérifier que vos contrôles couvrent les techniques réelles pertinentes pour votre environnement.
Ce qu’il faut retenir
Section intitulée « Ce qu’il faut retenir »Ces quatre concepts forment le vocabulaire de base de la gestion de sécurité. Les maîtriser permet de raisonner correctement sur les priorités, de communiquer efficacement avec les équipes sécurité, et de prendre des décisions éclairées.
Vulnérabilité
Faiblesse technique, humaine ou organisationnelle qui existe indépendamment de toute attaque. C’est la porte ouverte.
Menace
Acteur ou événement capable d’exploiter une vulnérabilité, qu’il soit intentionnel (attaquant) ou non (incendie, erreur).
Attaque
Action concrète où une menace exploite une vulnérabilité pour causer un dommage réel. C’est le passage à l’acte.
Risque
Combinaison de la probabilité d’une attaque et de son impact potentiel. C’est ce qu’on évalue et gère au quotidien.