EBIOS RM : analyse de risque et limites pratiques

EBIOS RM (Expression des Besoins et Identification des Objectifs de Sécurité, Risk Manager) permet de relier des événements redoutés, des sources de risque et des scénarios d’attaque à des mesures de traitement. Sa valeur dépend moins des ateliers que de la capacité à traduire leurs résultats en exigences d’architecture, contrôles vérifiables et décisions budgétaires.

→ Lire l’explication complète de la marmotte

EBIOS RM : un cadre de décision, pas une machine à produire du risque

La méthode publiée par l’ANSSI (Agence nationale de la sécurité des systèmes d’information) organise l’analyse autour de cinq ateliers : cadrage et socle de sécurité, sources de risque, scénarios stratégiques, scénarios opérationnels, puis traitement du risque. L’enchaînement a une logique : partir de ce qui doit être protégé, identifier qui peut vouloir l’atteindre, puis déterminer comment l’attaque devient techniquement plausible.

Le compromis central est brutal : EBIOS RM gagne en traçabilité, en langage commun et en capacité de justification auprès de la gouvernance, mais paie cette qualité par une forte dépendance à la qualité des hypothèses. Une analyse très détaillée fondée sur un inventaire faux reste une fiction très bien mise en page. Les slides de risque ont cette propriété remarquable : elles peuvent survivre à la disparition complète de l’actif qu’elles décrivent.

La recommandation est de réserver EBIOS RM aux décisions qui modifient réellement l’architecture, le modèle opérationnel ou l’acceptation du risque. C’est pertinent pour un service exposé, une fédération d’identité, une interconnexion partenaire, une plateforme de données sensibles ou une migration cloud. Ce n’est pas l’outil à sortir pour choisir entre deux versions mineures d’un agent de supervision. Dans ce cas, une revue de changement et une analyse de vulnérabilité suffisent.

Le premier atelier doit produire des éléments vérifiables : périmètre technique, missions métier, biens essentiels, biens supports, dépendances externes, exigences réglementaires et critères de gravité. Un bien essentiel n’est pas un serveur, un cluster Kubernetes ou un annuaire. C’est une capacité métier ou une information dont l’altération, l’indisponibilité ou la divulgation produit un effet mesurable. Confondre actif métier et composant technique transforme l’analyse en inventaire de matériel, ce qui est une manière coûteuse de ne rien décider.

Les critères de gravité doivent être définis avant l’examen des scénarios. Par exemple : interruption d’un service critique au-delà de quatre heures, divulgation de données à caractère personnel, altération d’une décision métier, perte d’une preuve opposable. Sans seuil, les participants classent selon l’intensité de leur dernier incident. Ce n’est pas une métrique, c’est de la météorologie émotionnelle.

La page gouvernance fixe le cadre de décision, mais EBIOS RM doit aussi s’appuyer sur une architecture cyber documentée. Sans flux, dépendances, identités techniques et frontières de confiance, les scénarios opérationnels se réduisent à des verbes inquiétants : compromettre, exfiltrer, rebondir. Très dramatique, très inutilisable.

Sources de risque et scénarios : éviter le théâtre des menaces

Une source de risque associe un acteur, une intention, des capacités et un accès potentiel. « Le pirate » n’est pas une source de risque exploitable. Un groupe criminel visant l’extorsion, un prestataire disposant d’accès d’administration, un concurrent cherchant une information stratégique ou un agent interne abusant d’un privilège le sont davantage.

Le scénario stratégique décrit la rencontre entre une source de risque et un objectif : obtenir des données, interrompre un service, modifier une transaction, contourner une obligation de contrôle. Il doit rester au niveau de l’objectif et du chemin général. Le scénario opérationnel descend ensuite dans le système réel : hameçonnage d’un administrateur, vol d’un jeton d’accès, exploitation d’une interface d’administration exposée, mouvement latéral via un compte de service, export de sauvegardes.

Cette séparation est indispensable. Mélanger les deux niveaux produit soit un récit vague, soit un catalogue de vulnérabilités sans adversaire ni conséquence métier. Le scénario stratégique répond à « pourquoi cet acteur agirait-il ? ». Le scénario opérationnel répond à « par quelle chaîne technique cela peut-il fonctionner ? ».

Chaque scénario opérationnel doit contenir au minimum :

le point d’entrée et la précondition d’accès ;
les actifs traversés ;
les mécanismes de sécurité à contourner ;
les identités, secrets ou clés visés ;
l’action redoutée sur le bien essentiel ;
les preuves attendues pour détecter l’attaque ;
les contre-mesures préventives, détectives et de reprise.

Un scénario qui ne précise pas la précondition est généralement impossible à arbitrer. « Compromission de l’annuaire » n’indique ni comment l’attaquant obtient un premier accès, ni quels privilèges permettent l’escalade, ni quel contrôle casse la chaîne. Il faut nommer LDAP (Lightweight Directory Access Protocol), Kerberos, l’authentification multifacteur ou les comptes de service si ces éléments conditionnent réellement l’attaque. Le détail technique n’est pas décoratif, il porte la décision.

La vraisemblance ne doit pas être confondue avec la fréquence statistique. Pour une architecture particulière, elle dépend de l’exposition, de l’attractivité, de la maturité de l’attaquant et des barrières présentes. Un accès d’administration protégé par une authentification forte et un poste dédié n’a pas la même plausibilité qu’un portail d’administration accessible depuis Internet avec un mot de passe local. Les deux peuvent finir dans un tableau rouge, mais l’un mérite une refonte et l’autre une surveillance ciblée.

Traitement du risque : traduire les scénarios en contraintes d’architecture

Le traitement consiste à réduire, transférer, éviter ou accepter un risque. Dans une architecture de sécurité, « transférer » signifie généralement déplacer une partie de la responsabilité contractuelle, pas faire disparaître le mécanisme d’attaque. Une assurance ne bloque pas une exfiltration. Un contrat non plus. Les juristes apprécieront peut-être la distinction, les attaquants beaucoup moins.

La réduction doit être formulée sous forme d’exigences testables. « Renforcer l’authentification » ne se teste pas. « Interdire les protocoles d’authentification en clair, imposer une authentification multifacteur aux accès d’administration et journaliser les élévations de privilèges » se teste. Le durcissement de l’annuaire peut s’appuyer sur la désactivation des binds LDAP anonymes et en clair, mais cette mesure ne protège ni les comptes compromis ni les délégations excessives.

Le plan de traitement doit distinguer trois familles de mesures :

Prévention : segmentation réseau, authentification forte, moindre privilège, chiffrement, suppression des services exposés, signatures de code.
Détection : journaux centralisés, alertes sur élévation de privilèges, détection d’exports anormaux, corrélation des accès d’administration.
Résilience : sauvegardes hors ligne, procédures de restauration, comptes de secours, exercices de reprise, révocation de secrets.

Une mesure sans propriétaire, date cible, preuve de vérification et risque résiduel associé n’est pas une mesure de traitement. C’est un souhait avec une mise en forme de tableur. La gouvernance doit accepter explicitement les risques résiduels dont le traitement dépasse le coût, le délai ou la capacité technique disponible. L’acceptation ne doit jamais servir à masquer une absence de décision.

Les scénarios impliquant des certificats, des clés ou des jetons doivent inclure la rotation et la révocation. Une clé stockée dans un HSM (Hardware Security Module) peut réduire le risque d’extraction, mais ne protège pas contre un opérateur ou une application autorisée à l’utiliser. Un HSM ne sécurise pas une architecture entière, il impose une frontière sur l’usage ou l’export d’une clé. Cela se vend moins bien qu’un slogan, mais cela résiste mieux à un dump mémoire.

Exemple reproductible : contrôler la couverture des scénarios EBIOS RM

Un registre de scénarios peut être versionné avec l’architecture et contrôlé en intégration continue. YAML (YAML Ain’t Markup Language) reste approprié pour des données lisibles, à condition de valider sa structure. Le fichier suivant impose qu’un scénario possède un propriétaire, une mesure, une détection et une reprise.

scenarios:
  - id: SR-01
    nom: Vol d'un jeton d'administration via hameçonnage
    bien_essentiel: Administration de la plateforme
    precondition: Accès à la messagerie d'un administrateur
    proprietaire: Responsable IAM
    vraisemblance: elevee
    gravite: majeure
    mesures:
      prevention:
        - Authentification multifacteur résistante au hameçonnage
        - Poste d'administration dédié
      detection:
        - Alerte sur connexion d'administration inhabituelle
      reprise:
        - Révocation du jeton et rotation des secrets associés

# Exécuter : python3 verifier_risques.py risques.yaml
import sys
import yaml

with open(sys.argv[1], encoding="utf-8") as fichier:
    registre = yaml.safe_load(fichier)

for scenario in registre.get("scenarios", []):
    champs = ["id", "bien_essentiel", "proprietaire", "vraisemblance", "gravite"]
    manquants = [champ for champ in champs if not scenario.get(champ)]
    mesures = scenario.get("mesures", {})
    for type_mesure in ("prevention", "detection", "reprise"):
        if not mesures.get(type_mesure):
            manquants.append(f"mesures.{type_mesure}")
    if manquants:
        raise SystemExit(f"{scenario.get('id', 'sans-id')} incomplet : {', '.join(manquants)}")

print("Registre EBIOS RM cohérent")

Installer la dépendance avec python3 -m pip install pyyaml, puis exécuter le contrôle dans la chaîne d’intégration. Ce contrôle ne calcule pas la pertinence d’un scénario, heureusement : automatiser un mauvais jugement produit seulement un mauvais jugement plus vite. Il force en revanche la présence des éléments nécessaires à une revue d’architecture.

Limites pratiques d’EBIOS RM et conditions d’exploitation

EBIOS RM ne garantit pas l’exhaustivité. Une analyse couvre des hypothèses, pas l’ensemble des attaques futures. Elle ne remplace ni un inventaire de vulnérabilités, ni des tests d’intrusion, ni la supervision, ni la gestion des correctifs. Elle ne prouve pas davantage qu’une mesure fonctionne en production. Une exigence d’authentification forte peut coexister avec un compte local oublié, une API sans contrôle ou un canal de secours non journalisé.

La méthode souffre particulièrement de quatre dérives :

surcharger les ateliers avec des scénarios trop nombreux et non priorisés ;
attribuer une gravité maximale à chaque actif afin d’obtenir du budget ;
confondre conformité documentaire et réduction effective de la surface d’attaque ;
laisser l’analyse figée après une migration, une acquisition, un changement de fournisseur ou une exposition Internet nouvelle.

Le seuil pratique est de conserver les scénarios qui entraînent une décision différente. Si deux scénarios conduisent exactement aux mêmes contrôles, à la même priorité et au même propriétaire, ils peuvent être regroupés. La granularité doit servir le traitement, pas l’archivage. Une bibliothèque de deux cents scénarios non reliés aux tickets, contrôles ou journaux est un musée de la menace.

L’exploitation impose une revue déclenchée par événement : changement d’architecture, nouveau flux sensible, incident, vulnérabilité critique exploitable, modification des privilèges d’administration ou changement d’hébergeur. Une revue périodique seule rate les changements rapides ; une revue à chaque micro-changement paralyse les équipes. Le bon compromis est une analyse complète sur les périmètres structurants, puis des mises à jour ciblées reliées à la gestion des changements.

Enfin, chaque mesure critique doit avoir une preuve opérationnelle : journal consultable, règle de détection testée, sauvegarde restaurée, révocation vérifiée, secret tourné, accès supprimé. Sans cette boucle, EBIOS RM reste une méthode de raisonnement correcte posée sur une réalité non vérifiée. La sécurité adore ce genre de vide, elle y range volontiers les incidents.

🐝 Ce qui arrive si on s’en passe

Sans registre de scénarios relié à l’architecture, aucune trace ne relie une décision d’exposition à son arbitrage : lors d’un incident, l’ordre de restauration se décide dans l’urgence, faute de biens essentiels hiérarchisés et de seuils de gravité établis à l’avance. Les demandes de budget perdent leur justification opposable, et les risques acceptés ne sont plus distinguables de ceux simplement oubliés. Les dépendances externes (prestataires disposant d’accès d’administration, interconnexions partenaires) restent hors du champ des contrôles, donc hors des règles de détection. Chaque migration, acquisition ou changement d’hébergeur s’effectue sans réévaluation des préconditions d’accès, ce qui laisse des chemins d’escalade fonctionnels après la bascule. Enfin, l’absence de propriétaire nommé par mesure rend la vérification impossible : plus personne ne constate qu’une révocation, une rotation de secret ou une suppression d’accès n’a jamais été appliquée.

🦫 Explication de la marmotte 🍫

Cette méthode sert à examiner un système avant qu’un incident grave ne se produise. Elle commence par définir ce qui doit être protégé : un service, des informations, une capacité de travail ou une décision. Il faut ensuite préciser ce qui arriverait si cet élément était rendu inaccessible, modifié ou divulgué.

L’analyse identifie ensuite les personnes ou groupes susceptibles de causer le problème. Il ne suffit pas de dire qu’un attaquant existe : il faut décrire son objectif, ses moyens possibles et la façon dont il peut atteindre le système. On écrit alors une suite d’actions réaliste, par exemple obtenir un accès, voler une identité, atteindre un serveur, puis exporter des données.

Pour chaque risque, une décision est prise. Il est possible de supprimer la cause du risque, de réduire les chances de réussite, de mieux détecter l’attaque, de préparer le retour à la normale ou d’accepter le risque restant. Chaque décision doit avoir un responsable et une preuve qu’elle fonctionne.

La méthode échoue si les informations de départ sont fausses, si les mesures restent dans un document ou si le système change sans mettre l’analyse à jour. Elle ne bloque aucune attaque par elle-même. La protection réelle dépend des réglages techniques, des accès, des sauvegardes, de la surveillance et de la capacité à réagir lorsque les contrôles ne suffisent plus.

Pages voisines

La citent

EBIOS RM : analyse de risque et limites pratiques

Elle cite

EBIOS RM : analyse de risque et limites pratiques

EBIOS RM : analyse de risque et limites pratiques

EBIOS RM : un cadre de décision, pas une machine à produire du risque

Sources de risque et scénarios : éviter le théâtre des menaces

Traitement du risque : traduire les scénarios en contraintes d’architecture

Exemple reproductible : contrôler la couverture des scénarios EBIOS RM

Limites pratiques d’EBIOS RM et conditions d’exploitation

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines