EBIOS Risk Manager¶

L'analyse de risques organisationnelle en 5 ateliers — méthode de référence de l'ANSSI.

Pourquoi EBIOS¶

EBIOS Risk Manager (EBIOS RM) est la méthode d'analyse de risques de l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information). Elle est conçue pour des systèmes d'information complexes ou les risques ne sont pas uniquement techniques mais aussi organisationnels, humains et strategiques.

Contrairement a STRIDE qui se concentre sur les menaces techniques composant par composant, EBIOS prend du recul. On identifie d'abord les sources de risques (qui pourrait attaquer et pourquoi), puis on construit des scenarios d'attaque strategiques avant de descendre au niveau technique. Cette approche top-down garantit que l'analyse couvre les menaces réelles — pas seulement les vulnérabilités théoriques.

EBIOS RM est alignee avec ISO 27005 (gestion des risques de sécurité de l'information) et s'intégré dans un SMSI (Système de Management de la Sécurité de l'Information) ISO 27001. Elle est recommandee par l'ANSSI pour les opérateurs d'importance vitale (OIV) et les opérateurs de services essentiels (OSE), mais sa structure convient à tout système critique.

Les 5 ateliers¶

EBIOS RM se decompose en 5 ateliers séquentiels. Chaque atelier produit des livrables qui alimentent le suivant. L'ensemble forme un processus structure qui part du périmètre métier pour aboutir a un plan de traitement des risques.

graph LR
    A1["Atelier 1\nSocle de securite"] --text--> A2["Atelier 2\nSources de risques"]
    A2 --text--> A3["Atelier 3\nScenarios strategiques"]
    A3 --text--> A4["Atelier 4\nScenarios operationnels"]
    A4 --text--> A5["Atelier 5\nTraitement du risque"]
    A5 --retour--> A1

Le retour de l'atelier 5 vers l'atelier 1 materialise le cycle d'amélioration continue. Les mesures de traitement modifient le socle de sécurité, ce qui peut révéler de nouvelles sources de risques ou modifier les scenarios existants.

Atelier 1 — Socle de sécurité¶

L'atelier 1 définit le périmètre de l'étude et etablit le socle de sécurité existant. On identifie ce qu'on protégé, avec quoi, et quel est le niveau de protection actuel.

Activités¶

Définir le périmètre — quels systèmes, quelles données, quels processus métier sont couverts par l'analyse. Un périmètre trop large rend l'analyse ingerable. Un périmètre trop étroit laisse des angles morts.

Identifier les valeurs métier — les processus métier critiques et les données essentielles. Ce sont les cibles finales des attaquants. Exemples : processus de paiement, données clients, secrets industriels, disponibilité du service.

Cartographier les biens supports — les composants techniques qui supportent les valeurs métier : serveurs, bases de données, réseaux, applications, services cloud. Chaque bien support est un vecteur potentiel d'attaque.

Évaluer le socle de sécurité — les mesures de sécurité déjà en place. On s'appuie sur des référentiels (ISO 27002, guide ANSSI) pour évaluer la maturité actuelle. Les ecarts identifiés sont des vulnérabilités a traiter.

Livrables¶

Atelier 2 — Sources de risques¶

L'atelier 2 identifié qui pourrait attaquer le système et pourquoi. On raisonne en termes de sources de risques (l'attaquant) et d'objectifs vises (ce qu'il cherche à obtenir).

Types de sources de risques¶

Couples source/objectif¶

On construit des couples (source de risque, objectif vise) qui représentent les scenarios de menace plausibles. Chaque couple est évalué en termes de motivation, de ressources disponibles et de pertinence par rapport au périmètre.

Exemple pour une plateforme e-commerce :

Les couples de pertinence faible sont documentes mais ne passent pas aux ateliers suivants. On concentre l'effort sur les menaces reellement plausibles.

Atelier 3 — Scenarios strategiques¶

L'atelier 3 construit des chemins d'attaque haut niveau. On raisonne en termes d'écosystème : par ou l'attaquant peut-il entrer et comment atteint-il son objectif ?

Écosystème et parties prenantes¶

On identifie les parties prenantes de l'écosystème (fournisseurs, partenaires, clients, sous-traitants, hebergeurs) et on évalué leur niveau d'exposition. Un fournisseur avec un VPN permanent vers le SI est un vecteur d'entree potentiel.

graph TD
    ATT["Attaquant\n(source de risque)"]
    ATT --text--> PP1["Fournisseur SaaS\n(partie prenante)"]
    ATT --text--> PP2["Prestataire infra\n(partie prenante)"]
    ATT --text--> PP3["Employe\n(partie prenante)"]
    PP1 --text--> SI["Systeme cible\n(valeurs metier)"]
    PP2 --text--> SI
    PP3 --text--> SI
    ATT --text--> SI

Construction des scenarios¶

Un scenario strategique décrit le chemin d'attaque au niveau macro :

1. L'attaquant identifie une cible dans l'écosystème
2. Il compromet une partie prenante ou exploite un vecteur d'entree
3. Il progresse vers les valeurs métier
4. Il atteint son objectif (exfiltration, sabotage, chiffrement)

Exemple : "Un groupe de ransomware compromet le prestataire de maintenance qui dispose d'un accès VPN permanent. Via ce VPN, il se déplacé lateralement vers le serveur de bases de données et chiffre les données de production."

Évaluation de la gravite¶

Chaque scenario strategique est évalué en termes de gravite pour l'organisation :

Atelier 4 — Scenarios opérationnels¶

L'atelier 4 traduit les scenarios strategiques en chemins d'attaque techniques. C'est ici que STRIDE peut intervenir comme outil complementaire pour identifier les menaces technique par technique sur chaque composant du chemin.

Du strategique à l'opérationnel¶

Chaque scenario strategique de l'atelier 3 est decompose en étapes techniques concrètes. On utilise la cartographie des biens supports de l'atelier 1 et les connaissances techniques de l'équipe.

Exemple — decomposition du scenario "ransomware via prestataire" :

Évaluation de la vraisemblance¶

Chaque scenario opérationnel est évalué en termes de vraisemblance :

Articulation EBIOS / STRIDE¶

À l'atelier 4, STRIDE devient un outil precieux pour systematiser l'identification des menaces techniques sur chaque composant du chemin d'attaque. Les deux méthodes ne sont pas en compétition — elles opèrent a des niveaux différents.

Atelier 5 — Traitement du risque¶

L'atelier 5 définit les mesures de traitement pour chaque risque identifié. C'est le passage de l'analyse à l'action.

Stratégies de traitement¶

Pour chaque risque, quatre stratégies sont possibles :

Plan de traitement¶

Le plan de traitement formalise les mesures decidees, les responsables, les délais et les indicateurs de suivi.

Risques residuels¶

Après traitement, il reste toujours un risque residuel. La direction doit valider formellement que ce risque residuel est acceptable. Cette validation est tracee et revisitee périodiquement.

graph LR
    RI["Risque initial\nVraisemblance x Gravite"] --mesures de traitement--> RR["Risque residuel"]
    RR --acceptable ?--> ACC["Accepte\nValide par la direction"]
    RR --inacceptable ?--> RET["Retour atelier 4\nMesures supplementaires"]

ISO 27005 et EBIOS RM¶

ISO 27005 définit le cadre générique de gestion des risques de sécurité de l'information. EBIOS RM est une implémentation concrète de ce cadre, avec une méthodologie structurée et des ateliers définis.

L'avantage d'EBIOS RM sur une application générique d'ISO 27005 est la structuration en ateliers avec des livrables concrets à chaque étape. Cela rend la méthode praticable par des équipes qui ne sont pas specialistes de la gestion des risques.

Mise en pratique¶

Quand lancer une analyse EBIOS¶

• Nouveau projet ou nouveau système à forte criticite
• Évolution majeure de l'architecture (migration cloud, ouverture d'APIs)
• Audit de conformité (ISO 27001, reglementations sectorielles)
• Incident de sécurité significatif (retour d'expérience)
• Périodiquement (annuel) pour les systèmes critiques en production

Participants¶

L'analyse EBIOS n'est pas un exercice purement technique. Elle implique :

• Direction / métier — définition des valeurs métier, validation des risques residuels
• RSSI — pilotage de l'analyse, expertise sécurité
• Architectes — cartographie des biens supports, scenarios techniques
• Équipes opérationnelles — connaissance du terrain, faisabilite des mesures
• Parties prenantes externes — fournisseurs, hebergeurs (pour l'écosystème)

Pieges courants¶

Chapitre suivant : Threat modeling — STRIDE — identifier les menaces techniques composant par composant.