Analyse Des Risques Avec Agile Risk Manager

Cas d'usage
de la méthode EBIOS RM :
Analyse de risque avec Agile Risk Manager
Version 1 - Septembre 2023 | Ce document est la propriété d’ALL4TEC

Pourquoi ce cas d’usage ? 3
La méthode EBIOS Risk Manager 4
Introduction 5
Atelier 1 : Cadrage & Socle de sécurité 7
Atelier 2 : Source de risque 20
Atelier 3 : Scénarios stratégiques 32
Atelier 4 : Scénarios opérationnels 51
Atelier 5 : Traitement du risque 64
Demande de démo 75
Votre contact ALL4TEC 75
Table des matières 2 / 75

Cher lecteur,
L’analyse de risques est aujourd’hui une démarche indispensable et fait partie des
outils les plus importants à la disposition des RSSI. La méthode EBIOS, au fil des
années, a su évoluer et s’adapter à la réalité des systèmes SI et la complexité de
la menace cyber. Sa dernière mouture, EBIOS Risk Manager, propose plus que
jamais une démarche pragmatique, efficace, centrée sur la représentativité, les
métiers et l’écosystème.
Les cas d’usage de la méthode EBIOS RM sont plutôt rares et nous espérons vous
apporter une approche pertinente de la méthode EBIOS RM via notre solution Agile
Risk Manager labellisée EBIOS RM par l’ANSSI depuis 2019.
Vous découvrirez l’usage de la méthode EBIOS RM dans le contexte d’un centre

d’imagerie médicale. Á chaque étape de l’analyse, nous reverrons les bases de la
méthode et nous l’appliquerons à l’aide du workflow proposé par Agile Risk
Manager.
Très cordialement.
L’équipe ALL4TEC
Une démo ? Nous contacter

Pyramide du management du risque numérique
AVANCÉ
CIBLÉ
Approche par « scénarios »

APPRÉCIATION
DES RISQUES
NUMÉRIQUES
NIVEAU DES CYBER ATTAQUES
ÉLABORÉ
CADRE RÈGLEMENTAIRE
ET NORMATIF
Approche par
« conformité »
LARGE SPECTRE
SIMPLE
PRINCIPES DE BASE ET HYGIÈNE
Une démarche itérative en 5 ateliers
ÉCOSYSTÈME
ATELIER 3
SCÉNARIOS
STRATÉGIQUES
ATELIER 1 ATELIER 2 ATELIER 5
CADRAGE ET SOCLE SOURCES DE TRAITEMENT
DE SÉCURITÉ RISQUE DU RISQUE
ATELIER 4
SCÉNARIOS
OPÉRATIONNELS
SYSTÈME
APPRÉCIATION DES RISQUES
CYCLE OPÉRATIONNEL
CYCLE STRATÉGIQUE
Le centre d'imagerie est une unité médicale qui réalise au profit des patients les
examens radiologiques suivants : IRM, scanner, échographie et radio.
Ici, on se concentrera en particulier sur la valeur métier "Echographie" et "Gestion

des patients".
Cette analyse a pour objectif d'identifier et d'évaluer les risques auxquels un

établissement d'imagerie médicale pourrait être confronté de manière directe ou
indirecte, puis de définir un ensemble de mesures de sécurité permettant d'y
remédier.
Notre but est de réaliser une analyse EBIOS RM complète. De ce fait, nous allons
réaliser les 5 ateliers de la méthode. Il est cependant à noter qu’il n’est pas
obligatoire de réaliser ces 5 ateliers, et que ceux-ci peuvent être réalisés
indépendamment, en fonction des objectifs de d’analyse.
Introduction 5 / 75
Atelier 1
Cadrage & socle
de sécurité
Les objectifs de l’atelier
Le but de ce premier atelier est de définir le cadre de l’étude, son périmètre métier
et technique, les événements redoutés associés et le socle de sécurité. Cet atelier
est un prérequis à la réalisation d’une appréciation des risques.
Les participants à l’atelier

Direction Responsable sécurité
RSSI Responsable qualité
Chef du service informatique Juriste
Chef du service administratif
Chef du service des échographies
Les données de sortie

Objectifs de l’étude
Rôles et responsabilités
Cadre temporel
Périmètre métier (valeurs métiers, biens supports)
Événements redoutés et leurs gravités
Socle de sécurité (référentiels de sécurité et états d’application)
Atelier 1 : Cadrage & Socle de sécurité 7 / 75

Dans l’application
Définition du cadre l’étude et du périmètre technique
Pour initier ce premier atelier, nous allons commencer par exposer l’objet et les
attendus. Il s’agira de définir les objectifs de l’étude.
Nous identifierons également tous les participants aux différents ateliers, leurs
rôles et responsabilités.
Il sera ensuite nécessaire de définir le cadre temporel de l’étude (cycle

opérationnel et cycle stratégique).
Dans un second temps, nous allons recenser les missions, valeurs métiers et biens
supports relatifs à l’objet de notre étude.
Dans ce tableau récapitulatif, vous trouverez :
La mission principale (l’objet d’étude)
Les valeurs métiers associées à cette mission
Les personnes responsables de ces valeurs métiers
Les biens supports associés et les personnes responsables

Mission Réaliser des échographies
Dénomination
Dossiers patients
de la valeur Échographie Gestion des patients
informatisés
métier
Nature de la
Processus Processus Information
valeur métier
Activité quotidienne
consistant à réaliser : Activité consistant à
Activité à réaliser : assurer :
Les échographies
Les documents de prise La sécurité d'accès des
quotidiennes des patients
en charge et données patients
d'intervention patients
Contrôles de la qualité des
Description L'intégrité des données
clichés médicaux
Enregistrer et mettre à patients
jour les infos patients
Renseigner des documents
médico-administratifs La disponibilité des
Organiser le flux données patients
administratif
Imprimer / rendre les
résultat des clichés
Entité ou
Chef du service des Chef du Service Directeur des systèmes
personne
échographies administratif informatiques
responsable
Dénomination
du/des biens Terminal Base de données
Échographe Canal informatique Site physique
supports utilisateur patients
associés
Systèmes
informatiques
Matériel essentiel Système informatique Locaux et
permettant de
Description pour mener à bien Ordinateurs régulant les information installations
stocker des
une échographie d'un service à un autre physiques
informations
sensibles
Entité ou Directeur des

Chef de service des Directeur des systèmes Directeur des L'ensemble des
personne systèmes
échographies informatiques Systèmes services
responsable informatiques

Récapitulatif de la mission et de l’objet d’étude dans Agile Risk Manager
Dans Agile Risk Manager, voici ce que l’on obtient en faisant cette synthèse. Vous
pouvez associer autant d’éléments que vous le souhaitez. Ce n’est ni plus ni moins
qu’un tableau associatif sur lequel nous avons greffé notre périmètre métier.
Pour arriver à ce résultat dans l’application, rien de plus simple. Nous allons
simplement segmenter notre périmètre métier en créant des bases de
connaissances indépendantes dans un premier temps.

Nous avons 3 bases de connaissances :
Une base de valeurs métiers
Une base de biens supports
Une base de responsables
Base de valeurs métier dans Agile Risk Manager

Base de biens supports dans Agile Risk Manager
Base de responsables dans Agile Risk Manager

En associant ces 3 bases, nous pouvons ainsi obtenir un tableau récapitulatif de
la mission avec tout le périmètre associé.
Récapitulatif de la mission avec le périmètre associé

Identification des événements redoutés
Identifier et caractériser les événements redoutés permet aux acteurs de

comparer objectivement l’importance des missions et valeurs métier tout en
prenant conscience des enjeux de sécurité.
Dans EBIOS RM, les événements redoutés sont associés aux valeurs métiers et
traduisent une atteinte préjudiciable pour l’organisation. Le degré de préjudice ou
d’impact est évalué selon une échelle de gravité permettant la hiérarchisation des
événements redoutés.
Notre cadre et périmètre d’étude défini, nous allons nous attaquer à la définition
de ces événements redoutés. In fine, nous retrouverons ces événements lors de
la réalisation des scénarios stratégiques dans l’atelier 3.
Un événement redouté est évalué grâce à une échelle de gravité propre à

l’organisation. C’est à vous de réaliser cette grille d’évaluation en fonction de votre
contexte. Cependant, il est commun d’avoir une grille de notation de ce type.
Échelle de gravité des impacts dans Agile Risk Manager

Cette échelle d’évaluation terminée, nous allons maintenant lister nos
événements redoutés.
Pour obtenir un tableau récapitulatif des événements redoutés, nous allons

répertorier une partie des événements qui pourraient avoir des conséquences
néfastes sur nos valeurs métier.
Pour nous aider dans cette étape, nous allons mener des recherches sur les
valeurs métier selon plusieurs critères :
La disponibilité (Quelles conséquences en cas d’indisponibilité ?)
Son intégrité (Quelles conséquences en cas d’altération ?)
Sa confidentialité (Quelles conséquences en cas de divulgation des

données ?)
Sa traçabilité (Quelles conséquences s’il devient impossible de tracer l’origine

d’une action ?)v
En fonction de ces 5 critères, nous allons imaginer des événements redoutés pour
chaque valeur métier.
Ces questions élucidées, nous associerons un événement redouté à chaque valeur

métier. Dans le même temps, nous associerons une gravité à chaque événement
redouté ainsi que des catégories d’impacts.

Dans l’application, nous allons :
Ajouter des événements dans la « base événements redoutés »
Associer une valeur métier à chaque événement redouté (depuis la base de

valeurs métiers)
Associer des impacts (depuis la base d’impacts)
Associer une gravité (depuis l’échelle de gravité)

Tableau récapitulatif des événements redoutés dans Agile Risk
Manager :
Définition du socle de sécurité

Déterminer le socle de sécurité (et ses écarts) suppose d’adopter une approche
par conformité. Pour cela, nous allons devoir identifier l’ensemble des référentiels
de sécurité qui s’appliquent à l’objet de l’étude.
C’est une liste de mesures de sécurité adapté au domaine pour lesquelles elles
sont destinées. Celles-ci peuvent être internes à l’organisation ou externes si nous
prenons des référentiels « publiques » tels que le guide d’hygiène de l’ANSSI.
Ici, nous allons volontairement prendre un référentiel de sécurité interne (peu

complexe pour la clarté de l’exemple).

Référentiels de sécurité dans Agile Risk Manager : bases de mesures de
sécurité internes

Atelier 2
Sources de
risques
Le but de l’atelier 2 est d’identifier les sources de risque (SR) et leurs objectifs
visés (OV) en lien avec le contexte particulier de l’étude. L’atelier vise à répondre
à la question suivante : qui ou quoi pourrait porter atteinte aux missions et valeurs
métiers identifiés dans l’atelier 1, et dans quels buts ?
Les sources de risque et les objectifs visés sont ensuite caractérisés et évalués en
vue de retenir les plus pertinents. Ils seront utiles à la construction des scénarios
des ateliers 3 et 4.

Direction
RSSI
Chef du service informatique
Responsable sécurité
Responsable qualité

La liste des couples SR/OV prioritaires retenus pour la suite de l’étude.
La liste des couples SR/OV secondaires susceptibles d’être étudiés dans un

second temps et qui feront, si possible, l’objet d’une surveillance attentive
Une cartographie des sources de risque
Atelier 2 : Source de risque 20 / 75

Identification des sources de risque et objectifs visés
Tout le périmètre métier est défini, il est maintenant temps de rentrer dans le vif
du sujet : l’évaluation des sources de risque. Pour ce faire, nous allons lister les
sources de risque ainsi que leurs objectifs visés.
Nous allons devoir établir :
Le profil de l’attaquant
Les objectifs visés
(Voir tableaux sur la prochaine page )

Base de sources de risque dans Agile Risk Manager
Base d’objectifs visés dans Agile Risk Manager
Liste des sources de risque :
Cyber-hacktiviste Personnel interne mécontent

Cyber-terroriste Personnel externe mécontent
Mafia

Liste des objectifs visés :
Vol d'informations médicales Réduction de l'activité du service

sensibles Échographie
Falsification de données médicales Altération des données de

l'échographie
Cryptolockage des données
patients
Indisponibilité de la plate-forme de
prise de rendez-vous.
Évaluation des couples source de risque / objectif visé
L’objectif sera d’identifier les sources de risque et objectifs visés les plus
pertinents. Nous allons utiliser 3 métriques de caractérisation pour apporter une
aide « mathématique » à notre évaluation.
Liste des critères à prendre en compte :
La motivation de la source de risque à atteindre son objectif
Ses ressources (finances, compétences, infrastructure)
Son activité (Est-elle active dans le périmètre de l’objet d’étude ?) - Ce

critère est facultatif.
La prochaine étape sera de déterminer notre système de cotation de nos 3 critères

d’évaluation.
Il est d’usage d’utiliser un système à 3 échelons :
Niveau 1 = +
Niveau 2 = ++
Niveau 3 = +++

Ce n’est ni plus ni moins qu’une notation de 1 à 3. La grille de cotation est libre,
vous pouvez ajouter autant de « notes » que vous le souhaitez, mais le but reste
d’évaluer le plus simplement possible les différents critères.
Nous allons faire ce travail pour nos 3 critères :
La motivation de la source de risque à atteindre son objectif
Les ressources de la source de risque
L’activité de la source de risques (activité dans le périmètre de l’objet

d’étude, industrie concurrente…)

Nous allons également ajouter une échelle de pertinence pour permettre à Agile
Risk Manager de sortir une pertinence cohérente avec les 3 critères de notation
définis.
Échelle de pertinence dans Agile Risk Manager

Un calcul en 2 étapes
La 1ère étape est de créer une matrice pour le niveau de pertinence du couple
« ressources et motivation ».
1ère matrice
En ordonnée : niveau de ressources
En abscisse : niveau de motivation
Nous obtenons une pertinence « ressources / motivation ».
2ème matrice
La 2ème étape consiste à créer une matrice pour le niveau de pertinence du

couple « activité et (pertinence ressources / motivation) ».
C’est cette 2ème matrice qui nous donnera le niveau de pertinence final d’un
couple « source de risques / objectif visé ».
En ordonnée : niveau d’activité
En abscisse : niveau de pertinence « ressource / motivation »
Nous obtenons le niveau de pertinence final d’un couple « SR/OV »

Exemple : 1ère matrice
*Les valeurs utilisées dans cet exemple sont arbitraires.
En ordonnée : niveau de ressources = 2 (++)
En abscisse : niveau de motivation = 2 (++)
Nous obtenons une pertinence « ressources / motivation ».
Selon cette première matrice, la pertinence « ressources / motivation » est

moyenne. (zone orange = 2)
En accord avec l’échelle de pertinence précédemment définie :
x
Exemple : 2ème matrice (finale)
*Les valeurs utilisées dans cet exemple sont arbitraires.
En ordonnée : niveau d’activité = 3 (+++)
En abscisse : niveau de pertinence « ressources / motivation » = 2 (++)
Nous obtenons une pertinence « activité / (ressources / motivation ) »
Cette 2ème matrice indique un niveau de pertinence élevée (zone rouge = 3). C’est
donc cette valeur qui indiquera le niveau de pertinence d’un couple SR/OV.
En accord avec notre échelle de pertinence précédemment définie :
x
Sélection des couples SR/OV retenus pour la suite de
l’analyse
Voilà, nous avons défini toutes les échelles. Grâce à celles-ci, l’application sera
capable d’interpréter les données d’entrées pour proposer une pertinence adaptée
à chaque source de risque.
Procédons maintenant à l’évaluation des sources de risque. C’est dans ce tableau

que nous allons associer une pertinence aux couples source de risque / objectif
visé.
Dans la grille de cotation et pour chaque source de risque, nous avons évalué les
3 critères selon le barème d’évaluation défini précédemment.
Dans Agile Risk Manager, l’évaluation des 3 critères permettra d’obtenir une
« pertinence proposée » par l’application. Il nous sera cependant possible de
retenir une autre pertinence si l’on juge qu’un couple source de risque / objectif
visé doit avoir une pertinence plus ou moins élevée que celle proposée par
l’application.
In fine, nous obtenons ce tableau (voir page suivante ) . Grâce à la pertinence

retenue, nous avons maintenant une aide visuelle pour nous indiquer les couples
source de risques / objectif visé à retenir pour la suite de l’analyse.

Évaluation et sélection des couples « SR/OV » dans Agile Risk Manager
Nous avons décidé de retenir 3 couples (cases cochées dans le tableau) :
Le cyber-terroriste voulant altérer les données de l’échographie
La mafia voulant crypto-locker les données patients
Le personnel interne mécontent voulant réduire l’activité du service

échographie
Pour les couples « Mafia / Cryptolockage des données patients » et « Personnel

interne mécontent / Réduction de l’activité du service échographie », la pertinence
retenue est la même que celle proposée par l’application.
Concernant le couple « Cyber-terroriste / Altération des données de

l’échographie », la pertinence a été réévaluée de moyenne à élevée au vu de
l’activité élevée des cyber-terroristes sur le territoire.

Atelier 3
Scénarios
stratégiques
L’écosystème comprend l’ensemble des parties prenantes qui gravitent autour de
l’objet de l’étude et concourent à la réalisation de ses missions (partenaires, sous-
traitants, filiales, etc.).
De plus en plus de modes opératoires d’attaquants exploitent les maillons les plus
vulnérables de cet écosystème pour atteindre leur objectif (exemple : atteinte à la
disponibilité d’un service en attaquant le fournisseur de service cloud, piège de la
chaîne logistique d’approvisionnement de serveurs facilitant l’exfiltration de
données sensibles).
L’objectif de l’atelier 3 est de disposer d’une vision claire de l’écosystème, afin d’en
identifier les parties prenantes les plus vulnérables. Il s’agit ensuite de bâtir des
scénarios de « haut niveau », appelés scénarios stratégiques. Ces derniers sont
autant de chemins d’attaque que pourrait emprunter une source de risque pour
atteindre son objectif.
L’atelier 3 est à aborder comme une étude préliminaire de risque. Il peut conduire
à identifier les mesures de sécurité à appliquer vis-à-vis de l’écosystème. Les
scénarios stratégiques retenus dans l’atelier 3 constituent la base des scénarios
opérationnels de l’atelier 4.

Direction Responsable sécurité
RSSI Responsable qualité
Chef du service informatique Juriste
Atelier 3 - Scénarios stratégiques 32 / 75

La cartographie de menace numérique de l’écosystème et les parties
prenantes critiques
Les scénarios stratégiques et événements redoutés
Les mesures de sécurité retenues pour l’écosystème
Construction de la cartographie de menace de
l’écosystème
Une partie prenante est dite critique dès lors qu’elle est susceptible de constituer
un vecteur d’attaque pertinent, du fait par exemple de son accès numérique
privilégié à l’objet étudié, de sa vulnérabilité ou de son exposition.
Une source de risques tentera, dans une logique du moindre effort, d’attaquer la
partie prenante qui apparaît comme le « maillon faible ». L’objectif ici, sera
d’identifier ces parties prenantes critiques pour les inclure dans l’élaboration des
scénarios stratégiques.
Dans un premier temps, nous allons lister toutes les parties prenantes du sujet
d’étude, à savoir le centre d’imagerie médicale.

Base de parties prenantes dans Agile Risk Manager
Fournisseurs des produits Prestataire maintenance

Laboratoires d'analyses échographie
Centre Hospitalier Universitaire Hébergeurs HADS
Médecins traitants Personnel interne
Prestataires IT Personnel externe
Les parties prenantes définies, il nous reste à évaluer la cartographie numérique.

Pour y parvenir, nous allons d’abord définir les échelles de cotation pour évaluer :
L’exposition d’une partie prenante
La fiabilité cyber d’une partie prenante
Le niveau de menace d’une partie prenante
L’intérêt de définir ces échelles se trouve dans la cartographie qui en résultera.

C’est un moyen de définir les zones de contrôle du risque.

Voici ce que nous pouvons obtenir dans l’application :
Plus une partie prenante (cercle dans le graphique ci-dessous) tend vers le
vert, plus son niveau de fiabilité est fort et inversement avec la couleur rouge.
Plus une partie prenante est exposée (cercle dans le graphique), plus le cercle
est large et inversement.
Pour arriver à ce résultat, rien de magique, nous allons utiliser les mathématiques
et un peu de bon sens.

Matrice de critères de cotation de menace des parties prenantes

Ce sont les notes que nous pouvons donner à une partie prenante pour chaque
critère :
Dépendance (1 à 4)
Pénétration (1 à 4)
Maturité cyber (1 à 4)
Confiance (1 à 4)
Il est possible d’aller en dessous ou au-dessus de ce barème de notation. L’idée

est d’avoir un barème cohérent et facilement compréhensible.
Échelle d’exposition dans Agile Risk Manager

Échelle de fiabilité cyber dans Agile Risk Manager

Les critères d’évaluation définis, nous n’avons plus qu’à évaluer les parties
prenantes à partir de cette base de calcul.
Après réflexion, nous obtenons ce tableau d’évaluation des parties prenantes ainsi
que cette cartographie.

Pour faire simple, toutes les parties prenantes dans la zone de danger (rouge) ou
coloriées en rouge dans le tableau, sont très certainement des parties prenantes
à sélectionner pour la suite de l’analyse (ce n’est cependant pas systématique).
Elles sont jugées critiques aux vues des différents critères.
Les parties prenantes situées dans la zone de contrôle (orange) ou coloriées en

orange dans le tableau vont faire l’objet d’une appréciation plus subjective.
Cartographie finale de la menace numérique de l’écosystème

Nous avons décidé de sélectionner 3 partie prenantes critiques pour la suite de
l’analyse.
Dans la zone de danger :
Le prestataire de maintenance de l’échographie
Le personnel interne
Dans la zone de contrôle :
Le centre hospitalier universitaire (au vu des nombreux échanges numériques

entre le centre d’imagerie et l’hôpital)
Les autres parties prenantes n’ont pas été retenues comme « critiques » et seront
mises de côté pour le reste de l’analyse.
Élaboration des scénarios stratégiques
Dans l’étape précédente, nous avons construit la cartographie de le menace

numérique de l’écosystème et sélectionner les parties prenantes critiques.
L’objectif est maintenant d’imaginer des scénarios réalistes de « haut niveau »,

indiquant de quelles façons un attaquant pourrait procéder pour atteindre son
objectif.
Ces scénarios stratégiques sont identifiés par déduction et prennent comme point
de départ la liste de nos couples source de risque / objectif visé. L’idée sera de
mettre en relation ces couples avec nos parties prenantes afin de déterminer les
différents points d’entrées des sources de risque.

Dans un premier temps, nous allons lister tous les couples source de risque /
objectif visé retenus lors de l’atelier 2 :
Un cyber-terroriste cherche à altérer les données de l’échographie
La mafia cherche à cryptolocker les données patients
Le personnel interne mécontent cherche à réduire l’activité du service

échographie
Ensuite, nous allons lister toutes les parties prenantes retenues :
Centre hospitalier universitaire
Prestataire maintenance échographie
Personnel interne
Notre spectre de scénarios stratégique est maintenant réduit à ces 2 listes. Nous
allons maintenant catalogués nos événements redoutés.
Base d’événements redoutés dans Agile Risk Manager

Dans ce tableau, nous avions associé une valeur métier avec un événement
redouté. Grâce à cela, l’élaboration de nos scénarios stratégique sera d’autant plus
simple.
Prenons le premier scénario stratégique :
Un cyber-terroriste voulant altérer les données de l’échographie
Source de risques : cyber-terroriste
Valeur métier : échographie
Nous imaginons que le but du cyber-terroriste est d’altérer les données de

l’échographie provoquant potentiellement des erreurs de diagnostique pour les
patients ou tout simplement pour paralyser le service échographie.
Nous arrivons à ce premier schéma représentant notre source de risque et les

différentes actions « haut niveau » qu’il pourrait entreprendre pour altérer les
données de l’échographie.

1er scénario stratégique
Le cyber-terroriste altère les données de l’échographie :
1. En attaquant directement le service échographie (Aucun intermédiaire)
2. En supprimant les données de l’échographie par l’intermédiaire d’un personnel

interne corrompu
3. En créant un canal d’accès illégal depuis le prestataire de maintenance de

l’échographie
Ce scénario est de gravité « grave » comme précédemment défini dans l’atelier 1

dans la base d’événements redoutés.

2ème scénario stratégique
La mafia cryptolocke les données patients
1. En rendant indisponible les données patients via un employé corrompu
2. En volant les données patients via la compromission d’un accès du CHU

Synthèse des scénarios stratégiques
En synthèse, nous nous intéressons donc à nos scénarios stratégiques ci-dessous.
Les 2 scénarios que nous venons de détailler sont de gravité « grave » et sont
retenus pour la suite de l’analyse.
Les scénarios de gravité « Grave » et « Critique » sont généralement sélectionnés

pour la suite de l’analyse. En dessous de ces gravités, c’est à vous de décider de
leurs pertinences.
*Pour la suite de l’exemple, nous allons nous concentrer uniquement sur ces 2
scénarios stratégiques
Liste des scénarios stratégiques retenus :
Cyber-terroriste - Altération des données de l’échographie ( Gravité : Grave)
Altération des données de l’échographie par une attaque directe
Altération des données de l’échographie via la création d’un canal illégal

chez le prestataire de maintenance
Suppression des données de configuration par un employé corrompu
Mafia - Cryptolockage des données patients (Gravité : Grave)
Indisponibilité des données patients via un employé corrompu
Vol des données patients par la compromission d’un accès du CHU

Définition des mesures de sécurité de l’écosystème
A ce niveau de l’analyse, les premières faiblesses structurelles commencent à

apparaître. Cela concerne aussi bien les parties prenantes internes que les parties
prenantes externes.
Pour affiner le niveau de menace de nos parties prenante, il est d’usage de lister
et d’attribuer des mesures de sécurité sur ces parties prenantes. Il sera ensuite
possible d’attribuer un nouveau niveau de menace (prévisionnel) aux parties
prenantes.
(On retrouvera ces mesures de sécurité lors de la génération du PACS dans l’atelier
5)
Dans Agile Risk Manager, nous allons pouvoir faire ce travail dans un tableau
dédié. Nous allons associer des mesures de sécurité à chaque partie prenante en
fonction de notre niveau de connaissances, pour ensuite réévaluer le niveau
d’exposition et de fiabilité cyber des parties prenantes affectées.
Concrètement, nous allons modifier subjectivement ces valeurs :
Dépendance (Une mesure de sécurité diminue telle notre dépendance à une

partie prenante ?)
Pénétration (Une mesure de sécurité limite-t-elle le périmètre d’action d’une

source de risque ?)
Maturité cyber (Une mesure de sécurité augmente-t-elle la compétence

cyber de la partie prenante ?)
Confiance (Une mesure nous rend-elle plus confiante vis-à-vis de la partie

prenante ?)

Aucune méthode « véritablement mathématique » pour évaluer ces impacts. C’est
à vous de le déterminer en fonction de votre « ressenti ». Ce tableau est
uniquement là pour traduire ce ressenti dans l’immédiat.
Nous avons donc réévaluer nos différentes parties prenantes en fonction des
chemins stratégiques et des mesures de sécurités associées.
Voici le résultat sous forme de tableau :
Dans le cas présent, les mesures de sécurité n’ont pas diminué le niveau
d’exposition de nos parties prenantes. Cependant, cela a augmenté le niveau de
fiabilité cyber de celles-ci et plus spécifiquement le niveau de confiance que l’on
leur accorde.

Mathématiquement, plus le niveau de fiabilité est élevé, plus le niveau de menace
baisse.
Et voici le résultat sous forme de graphique :
La menace résiduelle du prestataire de maintenance échographie et du personnel

interne est passé de 4 à 2.7.
Bien que cette baisse soit notable, nos 2 parties prenantes restent tout de même
dans la zone de danger.

Atelier 4
Scénarios
opérationnels
L’objectif de l’atelier 4 est de construire des scénarios opérationnels. Ils
schématisent les modes opératoires que pourraient mettre en œuvre les sources
de risque pour réaliser les scénarios stratégiques. Cet atelier adopte une
démarche similaire à celle de l’atelier précédent mais se concentre sur les biens
supports.
Les scénarios opérationnels obtenus sont évalués en termes de vraisemblance. À

l’issue de cet atelier, vous allez réaliser une synthèse de l’ensemble des risques
de l’étude.

RSSI
Expert cybersécurité

La liste des scénarios opérationnels et leur vraisemblance.
Atelier 4 - Scénarios opérationnels 51 / 75

Préparation des données
Nous avons nos scénarios stratégiques, il nous faut maintenant détailler le mode
opératoire de nos sources de risque. Pour chaque chemin d’attaque, nous allons
élaborer une "cyber kill chain".
Nous allons également préparer plusieurs bases de connaissances pour mener à

bien cet atelier :
Une base d’actions élémentaires
Une échelle de cotation de vraisemblance des actions élémentaires
Une matrice de niveau de risque (gravité sur (/) vraisemblance)

Base d’actions élémentaires dans Agile Risk Manager
Vous pouvez renseigner autant d’actions élémentaires que vous souhaitez, elles
vous seront proposées lors de la création des scénarios opérationnels.
Échelle de cotation de la vraisemblance dans Agile Risk Manager
C’est la note de vraisemblance que vous donnerez à une action élémentaire. Cette
cotation sera utilisée en abscisse dans la matrice de niveau de risque.

Définition de la matrice de niveau de risque
En abscisse : la vraisemblance du scénario opérationnel
En ordonnée : la gravité du scénario de risque associé
Dans cette matrice, nous retrouvons la vraisemblance de notre scénario

opérationnel et la gravité associée au scénario de risque.

Le niveau de risque d’un scénario est calculé comme cela :
En abscisse : la vraisemblance finale retenue sur le scénario de risque
En ordonnée : la gravité associée au scénario de risque (le chemin dont on

décrit le mode opératoire actuel)
Exemple :
Le scénario de risque R3 : Un cyber-terroriste altère les données de

l’échographie
Gravité du scénario de risque : 3 (Grave)
Vraisemblance du scénario de risque : 3 (Très vraisemblable)
Son niveau de risque serait inacceptable (zone rouge). Des mesures devront être
prises pour atténuer ce risque dans l’atelier 5 lors du traitement du risque.
Élaboration et évaluation des scénarios opérationnels
Une attaque réussie relève le plus souvent de l’exploitation de plusieurs failles. Les
attaques intentionnelles suivent généralement une démarche séquencée. Celles-
ci viennent exploiter de manière coordonnée plusieurs vulnérabilités de nature
informatique, organisationnelle ou encore physique.
La démarche doit vous permettre d’identifier les biens supports critiques

susceptibles de servir de vecteurs d’entrée ou d’exploitation ou de relais de
propagation pour l’attaque modélisée.
Notre préparation des données étant terminé, nous allons passer à la réalisation
des scénarios opérationnels.
Pour l’exemple, nous allons nous concentrer sur le scénario opérationnel « R4 - La

mafia altère les données patients par l’intermédiaire d’un employé corrompu »
Scénario stratégique associé : La mafia cryptolocke les données patients
Scénario opérationnel : R4 - La mafia rend indisponible les données patients

par l’intermédiaire d’un employé corrompu.

Ici, nous avons 2 modes opératoires identifiés :
1. La mafia recherche des informations sur les employés grâce à des sources
ouvertes, soudoie un employé en interne qui se trouve avoir accès à un compte
utilisateur avec des droits avancés. Celui-ci n’a plus qu’à uploader un
ransomware développé par la mafia sur les serveurs de l’organisation.
2. La mafia recherche des informations sur les employés grâce à des sources
ouvertes, soudoie un employé en interne. La mafia donne une clé USB piégée à
l’employé corrompu. Celui n’a plus qu’à l’insérer sur un poste non surveillé, en
« libre accès ». Grâce à cette clé, la mafia aura accès à des informations de
connexion d’un administrateur qui se connectera via ce poste pour ensuite
uploader un ransomware sur les serveurs du centre d’imagerie médicale.
Dans l’application, nous pouvons ajouter plusieurs paramètres à nos actions

élémentaires. Nous avons précédemment défini des échelles de cotation et de
vraisemblance. C’est à ce moment que nous allons pouvoir utiliser ces données.

Nous n’allons pas voir tous les autres scénarios opérationnels, la logique reste
la même, mais vous pourrez les retrouver dans l’exemple embarqué dans
l’application.
Résultats
Notre scénario opérationnel (R4 : La mafia rend indisponible les données patients
par l’intermédiaire d’un employé corrompu) a une vraisemblance de 3.
L’événement redouté associé à ce scénario opérationnel (indisponibilité des

données patients) à une gravité de 3 (Grave). Cela a été défini dans l’atelier 1.
Maintenant, grâce à notre matrice de niveau de risque, il nous suffit de placer

notre scénario opérationnel en fonction de ces 2 valeurs
Notre scénario opérationnel :
R4 – Indisponibilité des données patients par un employé corrompu
Gravité du scénario opérationnel : Grave (3)
Vraisemblance du scénario opérationnel : Très vraisemblable (3)

Grâce à cette matrice, nous savons maintenant que ce scénario opérationnel
possède un risque initial inacceptable. Il est impératif de prendre des mesures
pour atténuer les risques ainsi que leurs conséquences.
Application des mesures de sécurité sur les actions

élémentaires
Vous aurez peut-être remarqué des « cadenas » sur les actions élémentaires. En
prévision de la réalisation du PACS dans l’atelier 5, nous pouvons identifier des
mesures de sécurité à associer à des actions élémentaires.

Grâce à notre base de référentiels réalisée dans l’atelier 1, il nous suffit de
sélectionner celle que nous souhaitons affecter à l’action élémentaire, et le tour
est joué. Bien-sûr, rien ne vous empêche de revenir à l’atelier 1 et d’ajouter « à la
volée » de nouveaux référentiels ou de nouvelles mesures.

De notre côté, nous avons donc appliqué plusieurs mesures de sécurité sur des
actions élémentaires. (Visibles grâce à un « cadenas » sur chaque action
élémentaire).
Ici, pas de méthode miracle, c’est à vous de définir des mesures de sécurité
adaptées en fonction des actions élémentaires et du contexte.
Nous avons associé toutes les mesures de sécurité jugées nécessaires sur les
actions élémentaires. Tout ce travail portera ses fruits dans le prochain atelier,
lorsque nous générerons le PACS à partir de ces mesures de sécurité identifiées.
Nous connaissons maintenant les risques à corriger en fonction de leur priorité, il

est maintenant temps de passer à l’atelier 5 où nous allons réaliser le traitement
du risque ainsi que le plan d’amélioration continue de la sécurité.

Atelier 5
Traitement des
risques
Le but de cet atelier est de réaliser une synthèse des scénarios de risque identifiés
et de définir une stratégie de traitement du risque. Cette stratégie aboutit à la
définition de mesures de sécurité, recensées dans un plan d’amélioration continue
de la sécurité (PACS). Les risques résiduels sont ensuite identifiés ainsi que le
cadre de suivi de ces risques.

Direction
Responsable qualité
RSSI

La stratégie de traitement du risque
La synthèse des risques résiduels
Le plan d’amélioration continue de la sécurité (PACS)
Le cadre du suivi des risques.
Atelier 5 - Traitement du risque 64 / 75

Synthèse des scénarios de risques et stratégie de

traitement du risque
Ici, nous avons 3 zones :
La zone rouge représente une zone de risque inacceptable. Il est urgent de

prendre des mesures.
La zone orange représente une zone de risque modérée, il faudra prendre des
mesures quand la situation le permettra.
La zone verte représente une zone de risque faible, il n’est pas nécessaire de
prendre des mesures dans l’immédiat.

En synthèse, nous avons donc 5 scénarios de risques :
R1 : Un cyber-terroriste altère des données de l’échographie par une

attaque directe
R2 : Un cyber-terroriste supprime les données de configuration via un

employé corrompu
R3 : Un cyber-terroriste altère les données de l’échographie via un canal

illégal chez le prestataire de maintenance de l’échographie
R4 : La mafia rend les données patients indisponibles via un employé

corrompu
R5 : La mafia vole des données patients via la compromission d’un accès

CHU
Avant de passer au traitement du risque dans Agile Risk Manager, nous allons
devoir définir quelques paramètres propres à l’atelier 5.
Liste des paramètres de notation :
Échelle coût complexité
Échelle d’échéance

Échelle coût complexité dans Agile Risk Manager
C’est la difficulté et le coût à mettre en œuvre une mesure de sécurité.
Échelle coût complexité dans Agile Risk Manager
Ce sont les jalons de mise en œuvre de nos mesures de sécurité.

Ces données préparées, nous allons pouvoir débuter notre PACS. Cependant, pour
le remplir, il nous faut des mesures de sécurité à appliquer.
Ces mesures peuvent être identifiées depuis plusieurs sources :
Des mesures de sécurité à intégrer sur les parties prenantes (Atelier 3)
Des mesures de sécurité à intégrer sur les actions élémentaires (Atelier 4)
Des mesures de sécurité à ajouter directement dans l’atelier 5. (Par exemple,

des mesures de sécurité standards)
Nous allons partir du postulat que nous souhaitons seulement appliquer les
mesures de sécurité identifiées sur les actions élémentaires dans l’atelier 4.
Dans l’atelier 4, nous avons associé des mesures de sécurité à des actions
élémentaires. Nous allons nous servir de ce travail pour élaborer notre PACS.
Dans l’application, dans la section « PACS », il existe une option pour rassembler
en un seul clic, toutes les mesures de sécurité appliquées sur des actions
élémentaires.
Pré-complétion du PACS dans Agile Risk Manager

Le travail d’identification des mesures de sécurité étant déjà fait, inutile de le
refaire une seconde fois. Il nous restera simplement à définir :
L’échéance d’application (en fonction du contexte)
Le coût/complexité (en fonction du contexte)
Les responsables pour l’application de chaque mesure

Évaluation des risques résiduels
Nous avons maintenant notre PACS, c’est bien ! Mais il reste une dernière étape
pour compléter notre analyse. L’évaluation des risques résiduels par jalon. Ce n’est
pas pour rien que nous avons défini une échéance d’application « prévisionnelle ».
Grâce aux échéances, Agile Risk Manager va être capable de vous générer un
tableau récapitulatif ainsi qu’une matrice de réduction du risque par jalon.
C’est ici que nous allons appliquer une réduction en agissant sur la réduction de
la gravité ou de la vraisemblance.

Prenons le scénario de risque que nous avons réalisé :
R4 : La mafia rend indisponible les données patients via un employé corrompu.
Nous avons 3 mesures de sécurité à appliquer sur différentes périodes. Sur ces
différentes périodes, nous avons besoin de savoir quel sera le niveau de risque
résiduel du scénario de risque à chaque application d’une mesure de sécurité.
Désactivation des ports USB des terminaux (3 mois)
Mise en place d’une double authentification sur les terminaux de

l’échographie (6 mois)
Limiter au strict besoin opérationnel les droits d’administration sur les postes
de travail (9 mois)
Dans Agile Risk Manager, vous aurez la possibilité de diminuer la gravité résiduelle
et la vraisemblance résiduelle par jalon. Ainsi, vous pourrez voir la réduction
prévisionnelle dans une matrice de risque segmentée par jalon.

Mise en place des mesures de sécurité à 3 mois

In fine, nous avons toutes nos mesures de sécurité à appliquer ainsi que leur
échéance d’application prévisionnelle. Il reste maintenant à les appliquer
conformément aux échéances.
Dans cet exemple, nous avons réduit le risque de chaque scénario de risque
jusqu’au point ou le risque résiduel de ceux-ci soit acceptable.
Nous avons uniquement détaillé un scénario de risque, mais le travail reste

identique pour tous les autres scénarios. Il suffira de dupliquer le processus, et
vous obtiendrez le même résultat.

Cette analyse de risque sur Agile Risk Manager touche à sa fin. Ici, nous avons
volontairement fait une analyse de risque synthétique mais sachez qu’il existe un
bon nombre de fonctionnalités avancées pour vous aider dans votre travail
d’analyse.
Génération automatique des rapports
Pré-cotation de la vraisemblance des actions élémentaires
Pré-cotation de la réduction de risque des mesures de sécurité
Génération semi-automatique des scénarios stratégiques
Travail collaboratif
Import et export des données / référentiels
Etc.
Si vous êtes intéressé pour aller plus loin avec Agile Risk Manager, n’hésitez pas
à contacter notre équipe d’experts pour planifier une démonstration plus poussée.
Vous aurez également droit à une version d’essai pour mettre en pratique tout ce
que nous venons de voir dans cette analyse de risque EBIOS RM.
AGILE RISK
MANAGER Atelier 5 - Traitement du risque 74 / 75
Une démo ?
Édition : Guillaume Samson - guillaume.samson@all4tec.net
Commercial : Pierre Foubert - pierre.foubert@all4tec.net
Appel découverte : Agenda

Analyse Des Risques Avec Agile Risk Manager

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Analyse Des Risques Avec Agile Risk Manager

Transféré par

Droits d'auteur :

Formats disponibles

Cas d'usage

Analyse de risque avec Agile Risk Manager

Version 1 - Septembre 2023 | Ce document est la propriété d’ALL4TEC

La méthode EBIOS Risk Manager 4

Atelier 1 : Cadrage & Socle de sécurité 7

Atelier 2 : Source de risque 20

Atelier 3 : Scénarios stratégiques 32

Atelier 4 : Scénarios opérationnels 51

Atelier 5 : Traitement du risque 64

Votre contact ALL4TEC 75

Table des matières 2 / 75

Vous découvrirez l’usage de la méthode EBIOS RM dans le contexte d’un centre

Une démo ? Nous contacter

Approche par « scénarios »

PRINCIPES DE BASE ET HYGIÈNE

Une démarche itérative en 5 ateliers

APPRÉCIATION DES RISQUES

Ici, on se concentrera en particulier sur la valeur métier "Echographie" et "Gestion

Cette analyse a pour objectif d'identifier et d'évaluer les risques auxquels un

Les participants à l’atelier

RSSI Responsable qualité

Chef du service informatique Juriste

Chef du service administratif

Chef du service des échographies

Les données de sortie

Périmètre métier (valeurs métiers, biens supports)

Événements redoutés et leurs gravités

Socle de sécurité (référentiels de sécurité et états d’application)

Atelier 1 : Cadrage & Socle de sécurité 7 / 75

Il sera ensuite nécessaire de définir le cadre temporel de l’étude (cycle

Dans ce tableau récapitulatif, vous trouverez :

La mission principale (l’objet d’étude)

Les valeurs métiers associées à cette mission

Les personnes responsables de ces valeurs métiers

Les biens supports associés et les personnes responsables

Atelier 1 : Cadrage & Socle de sécurité 8 / 75

Entité ou Directeur des

Atelier 1 : Cadrage & Socle de sécurité 9 / 75

Atelier 1 : Cadrage & Socle de sécurité 10 / 75

Une base de valeurs métiers

Une base de biens supports

Une base de responsables

Base de valeurs métier dans Agile Risk Manager

Atelier 1 : Cadrage & Socle de sécurité 11 / 75

Base de responsables dans Agile Risk Manager

Atelier 1 : Cadrage & Socle de sécurité 12 / 75

Récapitulatif de la mission avec le périmètre associé

Atelier 1 : Cadrage & Socle de sécurité 13 / 75

Identifier et caractériser les événements redoutés permet aux acteurs de

Un événement redouté est évalué grâce à une échelle de gravité propre à

Échelle de gravité des impacts dans Agile Risk Manager

Atelier 1 : Cadrage & Socle de sécurité 14 / 75

Pour obtenir un tableau récapitulatif des événements redoutés, nous allons

La disponibilité (Quelles conséquences en cas d’indisponibilité ?)

Son intégrité (Quelles conséquences en cas d’altération ?)

Sa confidentialité (Quelles conséquences en cas de divulgation des

Sa traçabilité (Quelles conséquences s’il devient impossible de tracer l’origine

Ces questions élucidées, nous associerons un événement redouté à chaque valeur

Atelier 1 : Cadrage & Socle de sécurité 15 / 75

Ajouter des événements dans la « base événements redoutés »

Associer une valeur métier à chaque événement redouté (depuis la base de

Associer des impacts (depuis la base d’impacts)

Associer une gravité (depuis l’échelle de gravité)

Atelier 1 : Cadrage & Socle de sécurité 16 / 75