Le risque zéro n'existe pas
Imagine un centre commercial, appelons-le Les Arcades. Dedans : des rayons pleins, des caisses qui tournent, un fichier clients dans le bureau de la direction. Autour : des vigiles à l'entrée, des portiques antivol, un rideau de fer sur chaque boutique la nuit, des caméras, des issues de secours balisées.
Ce centre n'est pas inviolable. Et personne ne lui demande de l'être.
Un centre parfaitement sûr, ce serait un bunker sans porte : zéro vol, mais zéro client. La direction ne vise pas le risque zéro. Elle vise un risque acceptable, compatible avec son métier : vendre.
La cybersécurité, c'est le même calcul. Un système d'information totalement sécurisé est un système éteint, débranché, enfermé dans un coffre. Donc inutile.
Sécuriser, ce n'est pas supprimer le risque. C'est l'amener à un niveau acceptable, puis l'assumer en connaissance de cause.
Trois questions, trois fondations
Avant d'entrer dans les détails, posons le décor. Toute démarche de sécurité répond à trois questions, et trois notions y répondent. Garde Les Arcades en tête : on éclairera chacune avec le même centre commercial.
Disponibilité, intégrité, confidentialité, preuve : le besoin de sécurité de chaque donnée et chaque service.
Menace, vulnérabilité, impact : ce qui permet de prioriser au lieu de tout protéger pareil.
Des couches de protection complémentaires, conçues en supposant que la précédente a cédé.
Zero Trust, threat modeling, SOC, conformité : tout le reste décline ces trois idées. Voyons-les une à une, du principe général vers la pratique.
DICP : ce qu'on protège
Avant de poser un cadenas, il faut savoir ce qu'on garde. Le modèle de référence s'appelle la triade CIA en anglais (Confidentiality, Integrity, Availability), reprise par presque tous les référentiels dont le NIST Cybersecurity Framework. En France, on lui ajoute un quatrième pilier, la preuve. Ça donne DICP.
Disponibilité, Intégrité, Confidentialité, Preuve. Quatre questions à poser sur chaque donnée et chaque service.
Reprenons Les Arcades, pilier par pilier.
- Disponibilité : c'est accessible quand on en a besoin. Une boutique fermée un samedi de soldes perd de l'argent, même si rien n'a été volé.
- Intégrité : les données sont justes, pas trafiquées. Un prix modifié en caisse ou une compta maquillée, c'est l'intégrité qui tombe, pas la confidentialité.
- Confidentialité : seules les personnes autorisées voient l'information. Le fichier clients n'a rien à faire affiché dans la galerie.
- Preuve : on peut montrer qui a fait quoi, et quand. Vidéo, journaux, horodatage. Celui qui agit ne peut pas nier l'avoir fait.
| Pilier | En clair | Aux Arcades | En IT | Contrôles types |
|---|---|---|---|---|
| Disponibilité | Le service répond quand on en a besoin | Groupe électrogène, réouverture rapide après sinistre | Un site qui tient le pic des soldes malgré une panne | Redondance, sauvegardes, PRA, anti-DDoS |
| Intégrité | Les données ne sont ni altérées ni falsifiées | Les prix en caisse collent aux étiquettes | Un virement qui n'est pas modifié en transit | Hachage, signature, droits en écriture, versionnage |
| Confidentialité | Seuls les habilités accèdent à l'info | Le fichier clients reste sous clé dans le bureau | Des données de santé lisibles par le seul soignant | Chiffrement, IAM, cloisonnement |
| Preuve | On peut tracer et démontrer | Vidéosurveillance, registre des livraisons | Des journaux horodatés liés à un compte | Journalisation centralisée, horodatage, SIEM |
Le piège serait de traiter ces quatre besoins à égalité. Ils ne pèsent jamais pareil.
Le site vitrine des Arcades a surtout besoin de disponibilité et d'intégrité ; sa page d'accueil est publique, la confidentialité n'y change rien. Le fichier de paie, lui, réclame d'abord de la confidentialité. Mettre un poids sur chaque pilier, actif par actif : c'est déjà le début d'une analyse de risque.
Le risque : par quoi commencer
« Risque » sert souvent de synonyme à « danger ». C'est une erreur qui coûte cher, parce qu'elle empêche de prioriser.
Un risque, c'est la rencontre de trois ingrédients :
- une menace : quelqu'un ou quelque chose capable de nuire (cambrioleur, ransomware, incendie, employé distrait) ;
- une vulnérabilité : une faille exploitable (porte mal fermée, serveur pas à jour, mot de passe partagé) ;
- un impact : ce qu'on perd si la menace passe (argent, activité, réputation, amende).
Retire un seul des trois ingrédients, le risque s'effondre. Une faille critique sur un serveur vide ne menace rien. Une menace féroce contre un système sans faille ne fait rien non plus.
On résume ça par une formule : risque = menace × vulnérabilité × impact. Sur le terrain, on la ramène à deux axes : la vraisemblance (quelle probabilité ?) et la gravité (quels dégâts ?). C'est le langage d'EBIOS Risk Manager, la méthode de l'ANSSI pour apprécier les risques numériques.
Ces deux axes ouvrent deux leviers, et seulement deux. Aux Arcades, on baisse la vraisemblance avec des vigiles, des portiques, des caméras qui dissuadent ; en IT, avec les correctifs, le MFA, la segmentation. On baisse la gravité avec un coffre, des vitrines blindées, une assurance ; en IT, en chiffrant un disque ou en testant ses sauvegardes, pour qu'un vol devienne un simple incident matériel. Tout l'art consiste à savoir, pour chaque risque, sur quel levier appuyer.
Place les menaces sur ces deux axes, et la priorité saute aux yeux :
| Plan de secours, transférer Braquage de la bijouterie, incendie : rares mais lourds. |
Traiter en priorité Ransomware massif : fréquent et dévastateur. |
| Surveiller, accepter Incidents rares et bénins : un coup d'œil suffit. |
Réduire au fil de l'eau Vol à l'étalage : fréquent mais peu grave à l'unité. |
La protection suit toujours le produit vraisemblance × gravité, jamais un seul des deux. Une fois les risques classés, quatre réponses sont possibles :
| Option | Principe | Aux Arcades | En IT |
|---|---|---|---|
| Réduire | Baisser la vraisemblance ou la gravité | Un vigile de plus, des vitrines blindées | Correctifs, MFA, segmentation réseau |
| Éviter | Renoncer à l'activité qui porte le risque | Ne pas exposer les pièces hors de prix | Ne pas collecter une donnée inutile |
| Transférer | Faire porter le risque par un tiers | Assurance vol et incendie | Cyber-assurance, infogérance |
| Accepter | Assumer le risque sciemment | Tolérer une démarque marginale | Une faille mineure sur un service isolé |
Quoi qu'on fasse, il reste toujours un risque résiduel.
Un risque résiduel que personne n'a validé par écrit n'est pas un risque accepté. C'est un risque ignoré.
La défense en profondeur : des couches qui se rattrapent
Le terme vient de l'armée : plutôt que tout miser sur une seule muraille, on aligne des lignes successives qui ralentissent et fatiguent l'assaillant. L'idée est formalisée depuis longtemps, par l'ANSSI dans son mémento sur le sujet (voir son catalogue de publications) et par le NIST, jusqu'aux travaux d'ingénierie de NIST SP 800-160.
Le principe tient en une phrase :
Chaque contrôle de sécurité, pris seul, finit par céder. C'est leur empilement qui protège.
Aux Arcades, le portique se contourne, le vigile se distrait, le rideau se force, le coffre se perce. Aucun ne suffit. Mais pour réussir son casse, le voleur doit tous les franchir sans déclencher la moindre alarme, alors qu'une seule détection suffit au défenseur. L'asymétrie penche enfin du bon côté.
Dans un système d'information, l'empilement ressemble à ça : chaque couche une nouvelle ligne de défense, la supervision qui les traverse toutes.
Trois règles séparent un vrai empilement d'un simple tas d'outils.
- Chaque couche suppose la précédente tombée. La segmentation interne part du principe que le pare-feu a sauté. Le chiffrement part du principe que le serveur est déjà compromis.
- Les couches se complètent, elles ne se répètent pas. Deux pare-feu identiques tombent sur la même technique. On mélange des contrôles qui bloquent, qui voient et qui réparent, de natures différentes : technique, organisationnelle, physique.
- La supervision traverse tout. Une défense sans détection, c'est un labyrinthe sans gardien : l'attaquant patient finit par sortir. La traçabilité (le P de DICP) transforme un simple ralentissement en alerte exploitable.
Attention au contresens : empiler n'est pas accumuler. Chaque couche doit répondre à un risque réel. Sinon elle n'ajoute que de la complexité, et la complexité non maîtrisée est elle-même une faille.
Cas réel : NotPetya paralyse Maersk
Le 27 juin 2017, le malware NotPetya se répand via une mise à jour piégée de M.E.Doc, un logiciel de comptabilité ukrainien très utilisé. Déguisé en ransomware, il ne déchiffre rien : il détruit. Parmi les victimes collatérales, le géant maritime A.P. Møller-Maersk, qui n'était pas visé mais utilisait M.E.Doc dans sa filiale ukrainienne.
La suite est racontée en détail par Andy Greenberg pour Wired : en quelques heures, le ver se propage dans tout le réseau mondial du groupe, chiffre postes et serveurs, et bloque des terminaux portuaires sur plusieurs continents. Maersk reconstruira environ 4 000 serveurs et 45 000 postes en une dizaine de jours, pour un coût estimé entre 250 et 300 millions de dollars.
Relis l'incident avec nos trois fondations.
- DICP : l'attaque vise la disponibilité (tout s'arrête) et l'intégrité (données détruites), sans toucher à la confidentialité. Croire que « sécurité = secrets volés » fait rater toute une famille d'attaques.
- Risque : Maersk n'était pas la cible. La probabilité d'être touché par ricochet, via un fournisseur de logiciel, avait été sous-estimée. C'est le prestataire habituel des Arcades dont personne ne fouille jamais le camion.
- Défense en profondeur : une fois entré, presque rien n'a freiné le ver. Réseau peu segmenté, Active Directory interconnecté à l'échelle mondiale, comptes à privilèges réutilisables d'une machine à l'autre. Périmètre franchi, il n'y avait plus de couche derrière.
Le seul contrôleur de domaine qui a survécu était au Ghana, hors ligne par hasard à cause d'une coupure de courant. La sauvegarde providentielle que personne n'avait prévue.
Un désastre pareil n'a rien d'une fatalité technique. C'est la facture d'un arbitrage de risque que personne n'avait posé sur la table : « et si la compromission venait d'un éditeur tiers, sans rien pour l'arrêter ? »
Les couches qu'on oublie : résilience et facteur humain
La défense en profondeur s'arrête trop souvent à la prévention et à la détection. Deux couches de plus méritent autant d'attention.
La résilience d'abord : accepter qu'un incident finira par passer, et préparer le retour à la normale. Le NIST CSF en fait un pilier à part entière, avec des fonctions qui vont de la gouvernance au rétablissement, en passant par la détection et la réponse. La protection n'est qu'une fonction sur six. Aux Arcades, les issues de secours n'empêchent pas l'incendie : elles garantissent que le centre y survit. En IT, ça s'appelle sauvegardes hors ligne testées, plan de reprise documenté, et procédures de réponse répétées avant l'incident, pas pendant.
Le facteur humain ensuite, qu'on surnomme la couche 8. La plupart des protections techniques sautent avec un coup de fil convaincant ou un faux livreur en uniforme crédible. Une porte coupe-feu calée avec un extincteur « pour ne pas faire le détour » annule à elle seule des mois d'ingénierie. Former, vérifier, et cultiver un climat où signaler son erreur est valorisé : c'est une couche de défense à part entière. Le sujet est assez large pour son propre billet, plus loin dans cette série.
Ces fondations ne servent pas qu'aux équipes sécurité. Intégrées au cycle de développement, elles deviennent la base du DevSecOps, déjà abordé dans Qu'est-ce que le DevSecOps ?.
Points clés
- Le risque zéro n'existe pas : sécuriser, c'est ramener le risque à un niveau acceptable et l'assumer.
- DICP (Disponibilité, Intégrité, Confidentialité, Preuve) sert à exprimer le besoin de sécurité de chaque actif, avec des poids différents.
- Un risque naît de menace × vulnérabilité × impact ; on le priorise par vraisemblance et gravité, et tout risque résiduel se valide par écrit.
- La défense en profondeur empile des contrôles imparfaits mais complémentaires, chacun conçu en supposant le précédent tombé.
- La prévention ne suffit pas : la résilience et le facteur humain sont des couches de défense, pas des options.
Dans la série
Palier 1 : Connaître les lieux. Domaine : Fondations.
- Précédent : premier billet de la série.
- Suivant : Zero Trust, moindre privilège et surface d'attaque
- Vue d'ensemble : Par où commencer dans Les Arcades
Pour aller plus loin
- NIST Cybersecurity Framework : le cadre qui structure la sécurité en fonctions, de la gouvernance au rétablissement.
- EBIOS Risk Manager (ANSSI) : la méthode française d'appréciation du risque numérique.
- NIST SP 800-160 Vol. 1 : l'ingénierie des systèmes dignes de confiance.
- The Untold Story of NotPetya (Wired) : le récit complet de l'incident Maersk.
- Qu'est-ce que le DevSecOps ? : comment ces principes entrent dans le cycle de vie logiciel.
