Distingue menace, vulnérabilité, événement, incident et contrôle

L’idée reçue

« Le phishing est une vulnérabilité et un antivirus est un risque. »

Un registre exploitable sépare la source ou l’événement menaçant, la faiblesse, la conséquence et le contrôle. Sinon les décisions deviennent impossibles à vérifier.

01Utilise un vocabulaire stable

Notion

Question

Exemple

Menace

Qu’est-ce qui peut provoquer un dommage ?

hameçonnage, rançongiciel, erreur, perte

Vulnérabilité

Quelle faiblesse rend le scénario possible ou plus grave ?

MFA absent, sauvegarde dans le même domaine de confiance

Événement

Qu’avons-nous observé ?

connexion inhabituelle, fichier modifié, service indisponible

Incident

Quel événement compromet ou menace réellement les objectifs ?

compte compromis utilisé pour accéder à la messagerie

Contrôle

Quelle mesure réduit vraisemblance, impact ou délai de réaction ?

MFA, sauvegarde isolée, alerte, procédure

02Formule un scénario complet

Une campagne de phishing
exploite l'absence de MFA sur la messagerie
pour obtenir une session utilisateur
et peut entraîner divulgation de messages,
fraude et interruption du compte.

Le scénario indique :

actif + menace + vulnérabilité + conséquences + contrôles

03Ne confonds pas menace et acteur

Acteur possible : groupe criminel, fraudeur, initié, fournisseur compromis
Événement menaçant : phishing, abus de compte, exfiltration, sabotage
Motivation ou contexte : gain financier, erreur, conflit, automatisation opportuniste

L’acteur n’est pas toujours connu et une erreur sans intention peut produire un impact majeur.

04Observe les fixtures du lab

lab=/tmp/soria-cyber-risk-$USER
bash module1-cyber-risk-foundations.sh setup "$lab"
column -s, -t "$lab/input/threats.csv"
column -s, -t "$lab/input/vulnerabilities.csv"

Exemple :

THR-002  Hameçonnage
VUL-002  MFA non généralisée
AST-003  Messagerie collaborative

Le lab vérifie que VUL-002 appartient bien à AST-003 avant d’accepter le scénario.

05Positionne l’événement et l’incident

Événement
→ un utilisateur reçoit un message suspect

Alerte
→ un filtre ou un utilisateur signale le message

Incident potentiel
→ l'utilisateur a saisi ses informations et une connexion inhabituelle apparaît

Incident confirmé
→ la session compromise est utilisée ou des données sont accédées

La qualification nécessite des preuves. Ne transforme pas automatiquement toute anomalie en incident majeur.

06Choisis des contrôles complémentaires

Pour le même scénario :

GOVERN   politique et propriétaire du risque
IDENTIFY comptes sensibles et dépendances
PROTECT  MFA et filtrage du message
DETECT   alerte de connexion anormale
RESPOND  révocation et procédure de signalement
RECOVER  restauration de la confiance et retour d'expérience

Un contrôle préventif peut échouer. La défense doit aussi détecter, répondre et récupérer.

07Évite les contrôles non prouvés

Déclaré : « MFA activée »
Preuve possible : rapport de couverture des comptes sensibles

Déclaré : « sauvegarde quotidienne »
Preuve possible : job, checksum et test de restauration

Déclaré : « surveillance active »
Preuve possible : source, règle, test et délai de qualification

Le lab utilise des références de preuve synthétiques. Il ne confirme pas qu’elles existent dans une organisation réelle.

08Corrige les formulations faibles

Faible : risque de virus
Mieux : un code malveillant exploite un poste non corrigé et interrompt l'ERP

Faible : vulnérabilité phishing
Mieux : une sollicitation trompeuse exploite l'absence de vérification et de MFA

Faible : contrôle sécurité
Mieux : MFA obligatoire sur les comptes sensibles avec couverture mesurée

Mission

Écris six scénarios vérifiables

Pour six actifs de la PME, formule menace, vulnérabilité, conséquence CIA, contrôles existants, preuve et événement qui déclencherait une qualification.

✓À retenir

La menace décrit ce qui peut arriver, la vulnérabilité explique pourquoi le scénario est possible, l’événement est observé, l’incident est qualifié et le contrôle réduit ou maîtrise le risque.