Construis un registre de risques et choisis un traitement justifié

L’idée reçue

« Risque = probabilité × impact, donc le score décide automatiquement. »

Le score simplifie la comparaison. La décision exige contexte, propriétaire, contrôles existants, obligations, dépendances et preuve.

01Assemble le registre

ID du risque
actif et mission
menace
vulnérabilité
vraisemblance
impacts CIA
contrôles existants
propriétaire
traitement
échéance
preuve
risque résiduel

Un registre sans propriétaire ou sans action devient une liste d’inquiétudes.

02Utilise une matrice simple avec prudence

Le lab transforme les niveaux en valeurs :

vraisemblance : rare 1 → presque certain 5
impact maximal CIA : low 1 → critical 5
score pédagogique : vraisemblance × impact

Puis :

15–25  CRITICAL
9–14   HIGH
4–8    MEDIUM
1–3    LOW

Cette matrice est locale au lab. Elle ne constitue pas une norme universelle.

03Observe le registre généré

lab=/tmp/soria-cyber-risk-$USER
bash module1-cyber-risk-foundations.sh setup "$lab"
bash module1-cyber-risk-foundations.sh run "$lab"
column -s, -t "$lab/output/risk-register.csv"

Deux résultats attendus :

RISK-001  score 20  CRITICAL  REDUCE_NOW
RISK-002  score 12  HIGH      PLAN_PRIORITY_CONTROL

Le premier scénario combine rançongiciel, ERP, administration distante insuffisamment restreinte et impact critique sur la disponibilité.

04Choisis un traitement

Traitement

Décision

Exemple

Réduire

ajouter ou améliorer des contrôles

MFA, segmentation, backup isolé

Éviter

supprimer l’activité ou l’exposition

retirer un service inutile d’Internet

Transférer

partager une conséquence contractuellement

service de protection ou assurance, sans supprimer la responsabilité

Accepter

assumer explicitement le risque résiduel

impact limité, coût disproportionné, approbation habilitée

Transférer un coût ne transfère pas toujours les obligations, l’image ou l’interruption métier.

05Bloque les décisions incomplètes

Le lab conserve deux erreurs intentionnelles :

RISK-007
traitement = ACCEPT
approval = no
→ BLOCK_ACCEPTANCE_APPROVAL

RISK-008
owner = vide
→ BLOCK_NEEDS_OWNER

Une acceptation implicite n’est pas une stratégie. Un risque sans propriétaire ne peut pas être suivi.

06Transforme le traitement en plan

Risque : RISK-002
Priorité : HIGH
Propriétaire : Responsable IT
Traitement : REDUCE
Action : généraliser MFA et surveiller les connexions anormales
Échéance : date approuvée
Preuve : couverture MFA + test d'alerte + procédure de signalement
Risque résiduel : réévalué après preuve

La preuve vient après l’action. « Configuration appliquée » ne suffit pas si aucun test n’est défini.

07Analyse la couverture du cycle

column -s, -t "$lab/output/csf-coverage.csv"

Le lab exige les six fonctions :

GOVERN IDENTIFY PROTECT DETECT RESPOND RECOVER

Une couverture ne signifie pas que les contrôles sont suffisants. Elle montre seulement que le registre ne regarde pas exclusivement la prévention.

08Gère le risque résiduel

Risque initial
→ contrôles existants
→ traitement
→ vérification
→ risque résiduel
→ accepter, renforcer ou éviter

La réévaluation doit utiliser de nouvelles preuves, pas simplement diminuer le score parce qu’un projet est annoncé.

09Présente la décision à la direction

Ce qui peut arriver
Pourquoi c'est possible
Conséquence métier
Mesures déjà présentes
Options et coût
Recommandation
Décideur
Délai et preuve

Évite le vocabulaire inutilement technique lorsque la décision porte sur une mission, un budget ou une acceptation.

Projet du lot 1

Défends le registre de SORIA Distribution

Exécute le lab, examine les huit scénarios, justifie le risque critique, corrige les deux blockers de gouvernance dans une copie de travail et présente trois traitements prioritaires avec propriétaire, échéance et preuve.

✓Lot 1 terminé

Tu sais relier missions, actifs, menaces, vulnérabilités, CIA, contrôles et décisions. Le registre de risques devient un outil de gouvernance, pas une feuille de scores automatique.