Face à la multiplication et à la diversité des supports, à la délocalisation de nos applications dans le Cloud, aux exigences nouvelles du RGPD, la Sécurité ne peut plus être aujourd’hui considérée comme une option. On peut s’alarmer néanmoins devant l’ampleur de la tâche.
Une première réponse consiste à « cartographier » ces exigences en déterminant d’une part le niveau général de sécurité auquel on prétend et en recensant d’autre part les règles « applicables » dans le cadre de notre projet. Plusieurs méthodes existent à ce sujet ^[1] : EBIOS, MEHARI, ISAMM, OCTAVE… Destinées aux entreprises, voire aux grandes administrations, elles peuvent néanmoins se révéler utiles dans le cadre d’un projet de développement, comme nous allons le voir avec la méthode EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité).

Méthode EBIOS

Elaborée en 1995 par ce qui s’appelait alors la DCSSI (Direction centrale de la Sécurité des Systèmes d’Information) la méthode EBIOS a connu depuis trois mises à jour principales. Contrairement à la version 2010, « centrée sur la notion de menaces unitaires » ^[2], celle de 2018 prend désormais en compte la possibilité de menaces complexes, tirant parti d’une chaîne de vulnérabilités et plus représentatives des réalités du moment.
Bien que la mouture de 2018, appelée EBIOS RM (EBIOS Risk Manager), soit appelée à remplacer à plus ou moins longue échéance les anciennes spécifications, nous nous pencherons sur la version 2010, encore aujourd’hui très répandue.

Ses trois objectifs sont définis par l’ANSSI de la manière suivante :

• mettre en place ou renforcer un processus de management du risque numérique au sein d’une organisation.
• apprécier et traiter les risques relatifs à un projet numérique, notamment dans l’objectif d’une homologation de sécurité.
• définir le niveau de sécurité à atteindre pour un produit ou un service selon ses cas d’usage envisagés et les risques à contrer, dans la perspective d’une certification ou d’un agrément par exemple.

Les deux derniers auront toute leur pertinence dans le cadre d’un projet de développement et bien que cela soit mis en exergue, l’obtention d’une certification n’est pas le seul but visé.

EBIOS 2010 se définit comme une « Une démarche itérative en cinq modules » :

Module 1

Chaque module se décompose en plusieurs étapes, appelées « actions ». Pour le premier, par exemple, on aura les actions suivantes :

1. Définir le cadre de la gestion des risques
2. Préparer les métriques
3. Identifier les biens

Attardons-nous ici sur les métriques car c’est un aspect essentiel dans le cycle de vie du développement logiciel (SDLC). Comme le souligne Tom Marco ^[3], « You can’t control what you can’t measure » (On ne peut pas contrôler ce qu’on ne peut pas mesurer).

C’est à ce stade en effet qu’on décidera du niveau de criticité des quatre critères fondamentaux de la sécurité (DICT) :

• Disponibilité : une ressource doit être accessible et utilisable par son destinataire autorisé à l’endroit et à l’heure prévue.
• Intégrité : les données sont bien celles que l’on croit être.
• Confidentialité : une ressource n’est accessible qu’aux seules personnes autorisées.
• Traçabilité : garantie que les accès et tentatives d’accès aux ressources sont tracés et que ces traces sont conservées et exploitables.

Ces métriques peuvent être définies en choisissant une option parmi un ensemble de postulats, comme dans l’exemple suivant pour la disponibilité :

• La ressource peut subir une indisponibilité de plus d’une journée mais limitée dans le temps
• La ressource ne peut être indisponible plus d’une journée
• La ressource ne peut être indisponible plus de 4h
• La ressource ne doit pas être indisponible plus d’une heure

Les options sont ici présentées par niveau, de la plus libre à la plus contraignante. Les niveaux agrégés de l’ensemble des métriques permettront d’évaluer le projet de manière globale et d’envisager les prochaines actions à mener.
Les graphiques ci-dessous nous en donnent une représentation synthétique :

Les impacts ont été ici répartis sur 4 niveaux et 5 grandes catégories : perte de données, impacts juridiques, impacts financiers, perte de service Entreprises, fuite ou violation de données à caractère personnel. Il a fallu par exemple déterminer quel était le plus probable des impacts juridiques suivants :

• Pas de conséquence
• Des pénalités contractuelles peuvent être demandées
• La responsabilité civile de l’entreprise ou d’une personne physique peut être engagée
• La responsabilité pénale de l’entreprise ou d’une personne physique peut être engagée

L’identification des risques et la définition des métriques dépendront bien entendu du projet sur lequel on travaille. EBIOS facilite la gestion de la sécurité en proposant des parcours types mais n’impose rien quant aux détails d’implémentation.

Modules 2 et 3

Les modules 2 et 3 sont complémentaires et permettent pour le premier de dresser une liste des événements redoutés et pour le second d’analyser « les modes opératoires portant atteinte à la sécurité dans le cadre de l’étude », les scénarios. Les sources de menaces y sont plus détaillées que dans le premier module. Les échanges entre les participants ou la consultation d’une base de connaissances permettront d’identifier les plus plausibles d’entre elles. L’idée est d’obtenir un consensus afin de bien s’entendre sur les risques encourus et les impacts qu’ils engendrent.
Les événements redoutés correspondent à ce que l’organisme craint et les scénarios à ce à quoi il est exposé.

On pourra par exemple cataloguer l’événement redouté Indisponibilité du site Internet de la manière suivante :

Parallèlement, le scénario Menaces sur le système de l’hébergeur causant une indisponibilité pourra être décrit comme suit :

A la lecture de ces deux tableaux, on peut avoir une impression de redondance. Ils diffèrent cependant en un point : les événements redoutés portent sur des biens essentiels alors que les scénarios se focalisent sur les biens de type « support ». Les scénarios peuvent être envisagés d’autre part de manière narrative afin qu’ils soient mieux compris par les protagonistes. Ils apparaissent ainsi comme un ensemble cohérent de situations, analogues aux « personas » et aux « stories » des méthodes agiles.

Module 4

Le module 4, intitulé Etude des risques, en corrélant les événements redoutés avec les scénarios de menaces a pour but « [… d’identifier les seuls scénarios réellement pertinents vis-à-vis du périmètre de l’étude.] ». C’est une étape de filtrage où l’on va qualifier les risques réels en fonction de leur gravité et de leur vraisemblance en ne gardant que les scénarios correspondant aux événements redoutés. Après avoir évalué chacun des risques on pourra choisir parmi les 4 traitements suivants :

• l’éviter
• le réduire
• le prendre
• le transférer

Voilà par exemple quels pourraient être les choix pour l’événement Indisponibilité du site Internet, décrit plus haut (entre parenthèses, les choix optionnels) :

Le risque est pris ici et apparaîtra de fait dans la liste des risques résiduels (risques subsistants après l’application de mesures d’atténuation du risque).

Module 5

Le cinquième module se décompose en 2 étapes :

• Formaliser les mesures de sécurité à mettre en œuvre
• Mettre en œuvre les mesures de sécurité

En gros, il s’agit de fixer les mesures concrètes qui permettront d’éviter, de réduire ou de transférer les risques en tenant des contraintes techniques et budgétaires. Trois lignes de défense sont généralement envisagées :

• préventive : éviter les incidents
• protectrice : bloquer ou contenir les incidents
• récupérative : minimiser les conséquences des incidents

La désactivation des composants inutiles sur le serveur peut être considérée par exemple comme un acte de prévention.

On élaborera ensuite un plan de traitements des risques en s’appuyant sur les mesures retenues et considérées comme applicables. Ci-dessous, un exemple de mesure de sécurité :

On estimera enfin les risques résiduels afin de vérifier qu’ils soient bien compris et acceptés.

Pour conclure

EBIOS a le mérite d’offrir un cadre d’analyse et de gestion des risques. C’est loin cependant d’être une solution « clés en main ». La méthode présente pas mal d’inconvénients, à commencer par sa complexité. Les différentes étapes apparaissent souvent comme redondantes et chacune d’entre elles fait appel à de nombreux artefacts. Par ailleurs, en s’occupant plutôt du « quoi » que du « comment », les actions concrètes ne sont envisagées qu’en dernier recours. Enfin, en ne se basant que sur des menaces connues ou imaginées comme probables, elle en oublie une caractéristique essentielle : leur imprévisibilité.

On peut se demander s’il ne serait pas préférable d’avoir une vision plus organique et qu’au lieu de se défendre en permanence contre une infinité de menaces, on s’y prépare et on vive avec elles, un peu à la manière d’un virus dont on s’immunise avec le temps. C’est ce que nous verrons dans un prochain article.

[1] : Normes de sécurité : les méthodes d’analyse des risques.
https://cyberzoide.developpez.com/securite/methodes-analyse-risques/

[2] : EBIOS (2010) est mort, vive EBIOS (RM) ? Consulté le 06/05/2020.
https://www.riskinsight-wavestone.com/2019/01/ebios-2010-est-mort-vive-ebios-rm/

[3] : Controlling Software Projects, Management Measurement & Estimation, (1982), p. 3.