La méthode EBIOS Risk Manager continue son déploiement et son adoption s’accélère. Il n’en reste pas moins qu’un large capital d’analyses EBIOS 2010 est toujours en place et valide. Peut-on les migrer sous EBIOS RM et pour quels gains ?
Un peu d’histoire
La méthode EBIOS est une méthode d’analyse et d’évaluation des risques qui a aujourd’hui près de 25 ans. Elle a initialement été définie par la DCSSI, qui est devenue l’ANSSI en 2009.
D’abord imaginée pour répondre au besoin de rédaction de fiche FEROS à destination du monde de la défense, elle a connu de nombreuses mises à jour au fil de son intégration dans le monde industriel et de son exploitation par les acteurs terrain. Elle est intrinsèquement compatible (vocabulaire, démarche) avec les normes les plus répandues, et notamment l’ISO 27005.
L’histoire de cette méthode est marquée par 4 grandes étapes
- La première version officielle (1995)
- Une actualisation de la méthode (2004)
- Une évolution significative en 2010 (EBIOS 2010)
- Une autre évolution significative en 2018 (EBIOS RM)
Portée par un contexte cyber en pleine expansion, la méthode EBIOS 2010 s’est solidement implantée, à la fois auprès des acteurs publics et institutionnels mais aussi dans le monde privé.
Elle avait néanmoins pour défaut de proposer une démarche d’assez bas niveau, pilotée par une approche unitaire des vulnérabilités et de la remédiation associée.
La mise à jour EBIOS RM a pour objectif d’accélérer ce déploiement et l’utilisation de la méthode, en fournissant un nouveau cadre plus agile, centré sur l’utilisateur et l’écosystème. Les deux versions de la méthode n’ayant pas pour vocation de cohabiter, comment migrer de l’une à l’autre ?
Faut-il passer à EBIOS Risk Manager ?
EBIOS 2010 parle de Module, EBIOS RM parle d’Atelier. Ce changement de vocabulaire n’est pas anodin, et vient réellement appuyer la volonté de communication et d’échange portée par cette nouvelle itération de la méthode.
L’idée « d’Atelier » implique de travailler à plusieurs, de manière directe, et d’y intégrer au maximum des acteurs qui restaient par le passé en marge de l’analyse. Chaque Atelier va imposer d’identifier et prioriser des éléments, et cela nécessite d’avoir une vision juste à travers les métiers, et la capacité à décider à travers les responsables.
De plus, et contrairement à ce que proposait EBIOS 2010, chaque Atelier va pouvoir produire des éléments directement exploitables pour améliorer la posture cyber globale.
A la sortie de l’atelier 1, on pourra par exemple considérer le périmètre du socle de sécurité non appliqué, à la sortie de l’atelier 3 identifier les mesures associées à l’écosystème, etc.
Le passage d’EBIOS 2010 à EBIOS Risk Manager impose donc avant tout un changement de posture : l’agilité et l’amélioration continue deviennent centrales dans cette nouvelle démarche.
Une construction et une approche différentes
EBIOS 2010 demandait une approche d’identification des vulnérabilités et des biens supports très larges, avec comme corollaire le risque d’intégrer au périmètre de nombreux éléments périphériques, et la nécessité d’une exhaustivité réelle.
Ce travail minutieux et souvent conséquent permettait facilement l’industrialisation. Cet inventaire a été partiellement abandonné par EBIOS RM.
La construction du contexte se fait à partir des missions (et non pas vers les missions), et l’identification des vulnérabilités poursuit maintenant un autre but : permettre de définir les actions élémentaires possibles et assurer la pertinence des scénarios opérationnels de l’atelier 4.
Des éléments ré-exploitables
De manière directe, une grande partie des données des analyses EBIOS 2010 existantes peuvent directement être réexploitées dans EBIOS RM : les biens supports (attention au périmètre néanmoins), les biens essentiels (sous la forme de valeurs métiers).
Le référentiel de sécurité pourra venir alimenter le socle de sécurité assez simplement. Les échelles sont aussi globalement réexploitables (gravité, vraisemblance, etc.) ainsi que la base de connaissance des impacts.
Il y a ensuite les éléments pour lesquels la corrélation est possible, mais moins directe :
Les sources de menaces EBIOS 2010 (Module 1) sont partiellement couvertes par les sources de risques EBIOS RM. En effet, toute la partie non intentionnelle n’est plus explicitée, car normalement absorbée par le socle de sécurité (Atelier 1). A la marge, on peut aussi réutiliser certaines sources de menaces pour la définition des parties prenantes de l’écosystème.
Les évènements redoutés définis en EBIOS 2010 sont construits assez mécaniquement à partir de critères et besoins de sécurité. Si ces notions n’ont pas disparu en EBIOS RM, elles sont néanmoins moins explicitées. L’objectif est de rendre les évènements redoutés moins génériques et plus spécifiques au métier/périmètre traité par l’analyse. Il faudra donc être attentif à leur reformulation.
Les menaces au sens EBIOS 2010 sont des actions globales, de très haut niveau, associables à une source de risque pour permettre de construire des scénarios de menace de haut niveau.
Ce type d’approche n’a plus d’équivalent direct en EBIOS RM. Néanmoins, en fonction du niveau de détails des analyses existantes, une partie des données peut être utilisée pour alimenter la base des évènements intermédiaires (Atelier 3), au sein des scénarios stratégiques dans le cadre d’une analyse EBIOS RM.
Des différences notables
Les différences entre les deux démarches sont suffisamment significatives pour inciter à la prudence lors de la reprise des autres éléments. Les risques identifiés seront par nature très différents : EBIOS 2010 permet d’identifier des risques simples, précis, alors qu’EBIOS RM se concentre sur des scénarios et des risques beaucoup plus riches et complexes.
Il ne faut donc pas chercher à identifier la même chose, ou la même volumétrie de risques, mais changer son approche en visant la construction d’une stratégie itérative de réduction du risque.
Une remise en cause obligatoire pour des gains tangibles
Les différences et les points communs abordés dans cet article permettent de construire une première approche structurée d’une migration : récupération et élagage des données, re-découpage de certaines bases, puis un nouveau cycle de définition des risques et leur évaluation.
Cette approche doit être adaptée (une analyse EBIOS 2010 d’un système informatique en univers hospitalier n’offre pas le même contexte que celle d’un système de défense militaire), et il ne faut pas faire l’économie d’une remise en cause significative des résultats des analyses précédentes : le gain et la pertinence de la migration seront au rendez-vous.
