Gouvernance et facteur humain

Nous voici au bout du parcours, et à l'endroit qui n'avait aucun sens au début. Une analyse de risque présentée au premier cours aurait été un exercice de vocabulaire ; présentée ici, après que vous avez exploité de vos mains une injection SQL et un dépassement de tampon, après avoir monté un homme du milieu et analysé un incident, elle range enfin quelque chose de concret. C'est la raison pour laquelle ce bloc ferme le semestre.

Le changement de perspective est complet. Les neuf chapitres précédents raisonnaient technique : une faille, un correctif. Celui-ci raisonne organisation : des moyens finis, des risques innombrables, et des décisions qui appartiennent au métier, pas à l'équipe de sécurité. Deux idées le traversent, et ce sont les plus importantes du cours :

La sécurité est un processus, pas un produit — et pas un état qu'on atteindrait une fois. Et son maillon décisif est presque toujours humain.

Analyser le risque : EBIOS, ISO 27005

Le chapitre 1 a posé la grille — actif, vulnérabilité, menace, risque — et la formule risque ≈ vraisemblance × gravité. Les méthodes d'analyse de risque organisent cette estimation pour qu'elle soit reproductible et défendable, plutôt que laissée à l'intuition.

EBIOS Risk Manager (ANSSI) et ISO 27005 partagent la même démarche : recenser les actifs et leur valeur, identifier les menaces et les scénarios qui les réalisent, estimer vraisemblance et gravité sur des échelles à quatre niveaux, en déduire un niveau de risque, puis décider d'un traitement. EBIOS insiste particulièrement sur les scénarios stratégiques — qui vous en veut, avec quels moyens, pour atteindre quoi — ce qui reconnecte l'analyse aux profils d'attaquants du chapitre 1.

Le point à retenir n'est pas la méthode mais son produit : un registre des risques priorisé, et pour chacun l'un de quatre traitements possibles :

Trois nuances décident de tout, et elles sont l'objet de l'exercice de ce chapitre.

On priorise par le risque, jamais par la gravité technique. Une injection SQL sur un site vitrine sans données passe après le départ mal géré d'un administrateur — même si la première a un « score » plus impressionnant. Le contexte commande, exactement comme au chapitre 1.

Le transfert ne transfère pas tout. Une assurance couvre l'impact financier, pas l'atteinte à la réputation ni la responsabilité juridique. On reste responsable de ses données.

Accepter est une décision légitime — l'ignorer ne l'est pas. Le risque zéro n'existe pas ; après traitement, il reste toujours un risque résiduel. L'accepter en connaissance de cause, par une décision signée de la direction, est du bon management. Ne pas le voir est une faute. Le rôle du responsable sécurité est d'éclairer cette décision, pas de la prendre seul — la sécurité arbitre entre des propriétés qui s'opposent (chapitre 1), et cet arbitrage appartient au métier.

Piloter : ISO 27001 et la politique de sécurité

Là où EBIOS analyse, ISO 27001 organise. C'est la norme internationale du système de management de la sécurité de l'information (SMSI), et sa logique tient dans une boucle d'amélioration continue — planifier, déployer, contrôler, corriger — la même que le cycle de réponse à incident du chapitre 9, appliquée à toute la sécurité.

Concrètement, elle exige une politique de sécurité : un ensemble de règles écrites, approuvées par la direction, qui disent ce qui est attendu — usage acceptable, gestion des accès (chapitre 3), classification des données, réponse à incident (chapitre 9), relations avec les tiers (chaîne d'approvisionnement, chapitre 8). Une politique n'a de valeur que si elle est vécue : appliquée, contrôlée, révisée. Un classeur de politiques que personne ne lit est un risque de plus, pas une mesure — il donne l'illusion de la maîtrise.

Le SBOM du chapitre 8 et la revue des habilitations du chapitre 3 trouvent ici leur place : ce sont des instruments de gouvernance autant que des mesures techniques. La sécurité à l'échelle, c'est d'abord savoir ce qu'on a — inventaire des actifs, des composants, des accès — avant de savoir le protéger.

RGPD et obligations de notification

La sécurité rencontre le droit dès qu'il y a des données personnelles. Le RGPD — et, dans plusieurs États africains, des lois nationales de protection des données inspirées des mêmes principes et de la convention de Malabo (chapitre 1) — impose des obligations qui changent la manière de concevoir un système.

Les principes structurants pour un informaticien :

• minimisation : ne collecter que le nécessaire — c'est aussi de la réduction de surface d'attaque (chapitre 1) : la donnée qu'on n'a pas collectée ne peut pas fuir ;
• finalité : n'utiliser la donnée que pour l'usage annoncé ;
• sécurité : protéger par des mesures appropriées — tout ce cours ;
• protection dès la conception et par défaut : la sécurité et la vie privée pensées au départ, pas ajoutées après.

L'obligation qui a le plus d'effet opérationnel est la notification de violation de données. En cas de fuite touchant des données personnelles, le responsable de traitement doit notifier l'autorité de contrôle dans les 72 heures, et informer les personnes concernées si le risque pour elles est élevé. Cette horloge de 72 heures fait le lien direct avec le chapitre 9 : sans détection ni capacité d'analyse, on ne peut ni qualifier la violation, ni tenir le délai. C'est une contrainte de gouvernance qui exige une capacité technique — et l'un des meilleurs arguments pour financer la détection.

Continuité et reprise d'activité

Toutes les mesures précédentes visent à empêcher ou à limiter. La continuité d'activité répond à une autre question : comment continue-t-on à fonctionner quand un sinistre survient malgré tout — rançongiciel, incendie, panne majeure, indisponibilité d'un fournisseur ?

Deux notions se mesurent et se décident à l'avance, avec le métier :

• le RTO (Recovery Time Objective) : en combien de temps le service doit être rétabli ;
• le RPO (Recovery Point Objective) : quelle quantité de données on accepte de perdre — ce qui dicte la fréquence des sauvegardes.

Le rançongiciel — menace dominante, croisée à chaque bloc — a fait de la sauvegarde la mesure de survie par excellence. Mais une sauvegarde n'est utile que si elle est hors ligne ou immuable (un rançongiciel chiffre aussi les sauvegardes accessibles depuis le réseau) et surtout testée : d'innombrables organisations ont découvert le jour du sinistre que leurs sauvegardes étaient incomplètes, corrompues ou irrestaurables. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie — c'est le prolongement direct de la « préparation » du chapitre 9.

Le facteur humain

On arrive au maillon décisif, et il n'est pas technique. La grande majorité des incidents commencent par une action humaine : un lien cliqué, une pièce jointe ouverte, un mot de passe réutilisé, une clé USB ramassée sur un parking. Colonial Pipeline (chapitre 3), c'était un mot de passe. Le rançongiciel type commence par un hameçonnage.

L'ingénierie sociale exploite non pas la technique mais la psychologie : l'autorité (« le directeur exige un virement immédiat »), l'urgence (« votre compte sera fermé dans l'heure »), la confiance, la peur, la serviabilité. Ses formes : l'hameçonnage de masse, le harponnage ciblé sur une personne précise, la fraude au président qui a coûté des millions à de grandes entreprises, l'appât physique. Aucune de ces attaques ne casse un chiffrement ou n'exploite une faille logicielle — elles contournent toute la technique en s'adressant à la personne.

La défense se construit à deux niveaux, et l'ordre importe :

1. Technique d'abord. On ne demande pas aux gens d'être parfaits, on rend l'erreur moins grave. Le MFA résistant au hameçonnage (chapitre 3) neutralise la réutilisation et le vol de mot de passe. Le filtrage de la messagerie arrête l'essentiel du volume. Le moindre privilège (chapitre 3) limite ce qu'un compte hameçonné peut faire.
2. Humain ensuite. La sensibilisation régulière et concrète — exercices d'hameçonnage, consignes claires — élève le niveau, à condition d'être bienveillante. Une culture qui punit celui qui a cliqué obtient l'inverse de ce qu'elle cherche : les gens cachent leurs erreurs, et l'incident est détecté trop tard. Ce qu'on veut, c'est qu'un employé qui a cliqué par erreur le signale dans la minute — c'est ce signalement qui sauve, pas la culpabilité. C'est le même principe que le retour d'expérience sans blâme du chapitre 9.

À vous

Le dernier exercice du cours vous met dans le fauteuil du responsable sécurité. Budget fini, cinq risques issus d'un atelier EBIOS. Calculez le niveau de chacun, priorisez, allouez le budget, et nommez le traitement retenu pour chaque risque.

Observez lequel offre le meilleur rapport — et de quelle nature il est. Ce n'est pas un hasard si la mesure la plus rentable du registre n'est pas technique : c'est là toute la leçon du bloc V, et la conclusion de ce cours.

// Vous êtes RSSI d'une PME. Votre budget de sécurité annuel est de 30 k€.
// Cinq risques identifiés lors de l'atelier EBIOS. À vous de décider où il va.
//
// Échelles à 4 niveaux (pas d'euros à la décimale : c'est une grille de
// discussion, pas un calcul comptable — cf. chapitre 1).
//   vraisemblance : 1 improbable ... 4 quasi certain
//   gravité       : 1 mineure    ... 4 catastrophique

const RISQUES = [
  { id: "R1", nom: "Rançongiciel via hameçonnage",       v: 4, g: 4, cout: 8,  mesure: "MFA + sensibilisation + sauvegardes hors ligne testées" },
  { id: "R2", nom: "Vol du portable d'un commercial",     v: 3, g: 2, cout: 2,  mesure: "chiffrement de disque (BitLocker/LUKS)" },
  { id: "R3", nom: "Injection SQL sur le site vitrine",   v: 2, g: 1, cout: 6,  mesure: "réécriture en requêtes préparées + WAF" },
  { id: "R4", nom: "Panne du serveur de paie (matériel)", v: 2, g: 3, cout: 5,  mesure: "redondance + plan de reprise" },
  { id: "R5", nom: "Départ d'un admin avec ses accès",    v: 3, g: 4, cout: 1,  mesure: "revue des habilitations + procédure de départ" },
];

// ── À VOUS ──────────────────────────────────────────────────────────────────
// 1. niveau() : le niveau de risque = vraisemblance × gravité (1 à 16).
// 2. Triez les risques du plus élevé au plus faible.
// 3. Choisissez les mesures à financer sans dépasser 30 k€, et pour chaque
//    risque NON financé, nommez le traitement retenu :
//       éviter / réduire / transférer (assurance) / accepter.

function niveau(r) {
  return 0; // à compléter
}

const BUDGET = 30;
// à compléter : tri, sélection, décision de traitement.

// ── Affichage ────────────────────────────────────────────────────────────────
for (const r of RISQUES) {
  console.log(r.id + " " + r.nom.padEnd(38) + " niveau=" + niveau(r) + " coût=" + r.cout + "k€");
}

Ce que ce cours vous laisse

Vous avez traversé la discipline une fois en entier : des menaces à la cryptographie appliquée, des systèmes aux réseaux, des applications à la mémoire, de la réponse à incident à la gouvernance. C'était l'objectif — une première exposition complète, où chaque chapitre s'est arrêté là où commencerait un cours dédié.

Trois idées survivent à l'oubli des détails, et méritent de rester :

• La sécurité se raisonne par le risque, pas par la gravité technique. Le contexte commande toujours la priorité.
• La défense se pense en profondeur. Aucune barrière n'est parfaite ; l'attaquant doit réussir toutes les étapes, le défenseur n'a qu'à en casser une. On multiplie les couches, on suppose que chacune cédera.
• Le maillon décisif est humain, et la sécurité est un processus continu, jamais un état acquis.

Le master approfondira, chapitre par chapitre, ce que vous n'avez ici que traversé — la cryptographie du chapitre 2 y devient deux UE entières. Mais la grille de lecture, elle, ne changera plus : c'est celle que ce cours vous a donnée.

À retenir