J’ai consacré un article précédent à expliquer pourquoi EBIOS Risk Manager devait être industrialisé sur un cycle mensuel plutôt que conduit comme un exercice annuel statique. Cet article complète le précédent en décrivant la structure de matrice qui permet cette industrialisation. Le point clé : sans une structure de données adaptée, l’industrialisation est techniquement impossible. Avec elle, le cycle mensuel se conduit à coût marginal.
Voici la structure de référence que j’utilise pour mes propres travaux, applicable à toute organisation de taille moyenne soumise à NIS2.
Architecture en trois niveaux articulés
La matrice s’organise en trois niveaux qui correspondent aux ateliers 2, 3 et 4 d’EBIOS RM.
- Niveau 1 : les sources de risque (acteurs potentiels).
- Niveau 2 : les scénarios stratégiques (objectifs de l’acteur appliqués à l’organisation).
- Niveau 3 : les scénarios opérationnels (séquences techniques d’attaque).
Chaque niveau hérite et précise le niveau précédent. Cette architecture est calquée sur la doctrine EBIOS RM mais elle introduit une discipline supplémentaire : chaque élément à chaque niveau est typé selon une nomenclature stable, ce qui permet l’automatisation des relations entre niveaux.
Niveau 1 — Typage des sources de risque par archétype
Les sources de risque cyber se rangent en un nombre limité d’archétypes structurels. La typologie que je retiens distingue six archétypes principaux : opportuniste automatisé (scan massif, exploitation de vulnérabilités connues), ransomware-as-a-service (acteur affilié à une plateforme commerciale, motivation financière), étatique espionnage (APT collectant du renseignement, persistance longue), étatique sabotage (APT préparant des opérations destructrices), hacktiviste (motivation idéologique, communication publique), interne malveillant (acteur disposant d’accès légitime).
Chaque archétype porte des paramètres structurels stables : Probability of Action moyenne, Threat Capability typique, modus operandi standard, types de cibles privilégiées. Ces paramètres sont documentés dans la littérature publique (rapports ENISA, rapports Mandiant, rapports CrowdStrike, rapports CERT-FR) et peuvent être considérés comme des constantes méthodologiques sur des horizons de 12 à 24 mois.
Pour une organisation cliente, on active ou désactive les archétypes selon son profil. Une PME industrielle sans activité internationale activera typiquement les archétypes opportuniste automatisé, ransomware-as-a-service et interne malveillant, sans activer les archétypes étatiques. Une entreprise de défense ou de souveraineté activera les six archétypes.
Niveau 2 — Scénarios stratégiques paramétriques
À chaque source de risque activée correspond un ensemble de scénarios stratégiques pertinents pour l’organisation. Un scénario stratégique est la formulation, du point de vue de l’acteur, d’un objectif appliqué à l’organisation : « le groupe ransomware Z chiffre les SI de l’entreprise pour extorquer une rançon », « l’acteur étatique X exfiltre les données R&D de l’entreprise ».
La logique de croisement entre sources de risque et scénarios stratégiques peut être codifiée. À chaque archétype correspond une bibliothèque de scénarios stratégiques typiques. Pour l’organisation cliente, on active les scénarios pertinents en fonction de ses valeurs métier identifiées en atelier 1.
Cette codification permet l’automatisation partielle de l’atelier 3 : quand un nouvel acteur apparaît dans la veille mensuelle, son archétype détermine quels scénarios stratégiques sont automatiquement activés. La validation humaine intervient sur la pertinence du croisement, pas sur la construction des scénarios depuis zéro.
Niveau 3 — Descente vers les scénarios opérationnels via MITRE ATT&CK
Le passage du scénario stratégique au scénario opérationnel consiste à descendre du « pourquoi » au « comment ». La matrice MITRE ATT&CK fournit le vocabulaire commun pour décrire les séquences techniques d’attaque.
La descente s’opère par chaîne de TTPs. Pour chaque archétype, on dispose de l’inventaire des techniques observées dans ses incidents passés. Ces techniques se composent en kill chains plausibles : initial access via phishing, persistence via planificateur de tâches, privilege escalation via exploitation de vulnérabilité, lateral movement via SMB, exfiltration via canal C2.
Pour une organisation cliente, la matrice indique quelles techniques MITRE ATT&CK la concernent pour chaque scénario opérationnel, et quels contrôles de sécurité couvrent chaque technique. Cette traçabilité permet de répondre à la question opérationnelle clé : « si tel acteur attaquait selon tel modus operandi, mes contrôles actuels résisteraient-ils ? ».
Pondération des contrôles — la couche de défense
La quatrième dimension de la matrice est la couverture des contrôles. Chaque technique MITRE ATT&CK est mappée à un ou plusieurs contrôles de sécurité (par exemple, MFA contre les techniques de credential access, EDR contre les techniques d’execution). Pour chaque contrôle, l’organisation déclare son niveau de maturité (absent, partiel, configuré, monitoré).
La couverture effective d’une technique se calcule par agrégation des contrôles qui la traitent, pondérée par leur maturité. Cette couverture peut être objectivée par observation externe : Censys peut vérifier la présence d’un firewall périmétrique, l’utilisation de Microsoft 365 implique certaines configurations MFA par défaut, etc.
Le Community Defense Model du Center for Internet Security publie des matrices détaillées de couverture contrôles × TTPs qu’on peut reprendre comme base de calibration. Cette matrice publique évite de réinventer la roue et garantit que les pondérations utilisées sont défendables face à un évaluateur tiers.
Quantification financière via Open FAIR
Une fois la matrice descendue jusqu’aux scénarios opérationnels avec leur couverture de contrôles, le passage à la quantification financière par Open FAIR devient mécanique. Pour chaque scénario opérationnel, on calcule la Loss Event Frequency (fonction de la Contact Frequency des acteurs concernés, de leur Probability of Action, et de la Vulnerability calculée à partir de la couverture des contrôles), puis on multiplie par la Loss Magnitude (Primary Loss Magnitude + Secondary Loss Magnitude pondérée par sa probabilité).
L’agrégation au niveau de l’organisation produit la distribution de l’Annual Loss Expectancy attendue. Cette distribution est l’input principal pour les arbitrages budgétaires : sur quels contrôles investir en priorité, où réside le risque résiduel acceptable, quelle est l’exposition à transférer en assurance.
Priorisation par retour sur investissement sécurité
La matrice permet aussi de calculer un retour sur investissement sécurité (ROSI) par action de traitement envisagée. Pour chaque contrôle envisagé, on simule deux fois la matrice : avec et sans le contrôle. La différence d’Annual Loss Expectancy entre les deux simulations donne la valeur attendue du contrôle. Divisée par le coût d’implémentation et de maintien du contrôle, elle donne le ROSI.
Cette priorisation transforme une discussion budgétaire qualitative (« il faut investir en cybersécurité ») en une discussion quantitative (« investir 50 k€ dans tel contrôle réduit l’Annual Loss Expectancy de 320 k€ avec un horizon de retour de 18 mois »). Le langage parle à la direction financière.
Mise en œuvre dans une organisation existante
Constituer cette matrice pour une organisation qui démarre représente typiquement un travail initial de quinze à vingt-cinq jours répartis sur trois à six mois : cinq jours pour l’atelier 1 (cadrage et valeurs métier), trois jours pour la qualification du contexte (archétypes activés, scénarios pertinents), cinq jours pour la cartographie des contrôles, cinq jours pour la calibration des paramètres FAIR, deux à sept jours selon la complexité pour le paramétrage de l’outillage qui automatisera le cycle mensuel.
Une fois la matrice constituée, la cadence mensuelle se conduit à coût marginal. Une à deux journées par mois pour la mise à jour des paramètres dérivés de la CTI, la revue des nouveaux scénarios à activer, et la validation humaine des évolutions significatives. Une journée trimestrielle pour la revue de fond avec dirigeant et RSSI.
Limites et précautions
Cette industrialisation n’est pas une panacée. Trois limites doivent être nommées.
Première limite : la qualité de la matrice dépend de la qualité de l’atelier 1 initial. Si les valeurs métier sont mal identifiées, ou si le contexte est mal cadré, tout l’édifice s’effondre. L’investissement dans l’atelier 1 mérite d’être préservé.
Deuxième limite : la matrice ne dispense pas du jugement humain. La validation mensuelle par le RSSI et la validation trimestrielle par le dirigeant restent nécessaires. L’industrialisation supprime le travail répétitif, pas le jugement.
Troisième limite : la matrice doit elle-même être maintenue. La typologie d’archétypes, la bibliothèque de scénarios, la nomenclature des contrôles évoluent avec le paysage de la menace. Une révision annuelle de la matrice elle-même est nécessaire.
En conclusion
Une matrice EBIOS RM bien structurée est l’outil qui rend l’industrialisation possible. Sans elle, l’analyse de risque mensuelle reste un exercice artisanal qui ne tient pas à l’échelle. Avec elle, la démarche devient reproductible, auditable, et économiquement soutenable pour des organisations de taille moyenne.
Pour les RSSI qui veulent professionnaliser leur démarche d’analyse de risque en 2026, l’investissement dans la constitution de cette matrice est probablement le projet le plus structurant qu’ils puissent mener. Il transforme la fonction analyse de risque d’une charge ponctuelle en un actif vivant.
Découvrez nos formations et services.
Sources : méthode EBIOS Risk Manager publiée par l’ANSSI ; Open FAIR Risk Taxonomy, The Open Group ; matrice MITRE ATT&CK ; Community Defense Model du Center for Internet Security ; rapports publics ENISA, Mandiant, CrowdStrike, CERT-FR sur les archétypes d’acteurs.
Commentaires récents