3 - EBIOS Analyse de Rique Cours

EBIOS
Version 1.2
1
EBIOS
Plan
• Introduction et définitions, notions fondamentales
• La méthode EBIOS
• Annexe ISO 27001
• Avantages et inconvénients EBIOS
• Ce qu’il faut retenir…
2
EBIOS
Introduction à la méthode EBIOS
3
EBIOS
Définition
EBIOS:
▪ Expression des Besoins et Identification des Objectifs de Sécurité.
▪ Il s’agit non seulement d’une méthode d’appréciation du risque de
sécurité de l’information, mais aussi d’un outil d’assistance à la gestion
du risque.
▪ Elle est reconnue par les administrations, référence dans le secteur
privé
▪ Méthode créée et supportée par l’ANSSI (Agence Nationale pour la
Sécurité des Systèmes d’Information), Service à compétence nationale
▪ l’ANSSI est rattachée au secrétaire général de la défense et de la
sécurité nationale. Le SGDSN assiste le Premier ministre dans l’exercice
de ses responsabilités en matière de défense et de sécurité nationale.
4
EBIOS
Définition
EBIOS est une méthode qui permet de :
▪ disposer d'éléments de langage communs ;
▪ disposer d'une démarche claire et structurée à respecter ;
▪ se baser sur un référentiel validé par l'expérience ;
▪ s'assurer d'une exhaustivité des actions à entreprendre ;
▪ réutiliser la même approche en amélioration continue et sur
d'autres périmètres…
5
EBIOS
Définition
EBIOS est une boite à outil modulable en fonction:
▪ Du périmètre étudié :
▪ application
▪ processus métier
▪ organisation entière… Enjeux :
▪ De l’état de la cible de l’étude : Atteindre ses
▪ systèmes existants
▪ systèmes en cours d'élaboration
objectifs métiers et
▪ Du but de l’étude : stratégiques sur la
▪ Elaborer un plan d’action base de décisions
▪ Elaborer une politique de sécurité rationnelles.
▪ Etablir un cahier de charges
6
EBIOS
Les acteurs de l’analyse
- Les acteurs: qui sont-ils?
• Les acteurs
✓Aident à l’identification des situations craintes par l’organisme
• Les opérationnels
✓Connaissent les menaces et aident à l’identification des
vulnérabilités et des mesures de sécurité correspondantes
• La direction, le commanditaire
✓Il élabore la stratégie de traitement des risques
7
EBIOS
Définitions
8
EBIOS
Qu’est-ce qu’un risque
• ISO/IEC 27005
• Possibilité qu’une menace donnée exploite les vulnérabilités d’un
bien ou d’un groupe de biens et nuise donc à l’organisation
• EBIOS
• Scénario, avec un niveau donné, combinant un événement
redouté et un ou plusieurs scénarios de menaces
• MEHARI
• Situation à risque peut être caractérisée par:
✓Des facteurs structurels qui dépendent du métier de l’entreprise,
de son environnement, de son contexte
✓Des facteurs de réduction de risques qui sont directement
fonction des mesures de sécurité mises en place
9
EBIOS
Qu’est-ce qu’un risque
• Un risque c’est donc:
• La combinaison d’un évènement ayant une probabilité P
et de ses conséquences G (gravité). Cette combinaison
s’appelle Criticité.
• Un risque n’est donc pas:

• Un aléas, non quantifiable
• Un imprévu, non identifiable
• Un fait avéré (on parle alors de contrainte)
10
EBIOS
Risque – Notions: Niveau de risque
• Criticité = Probabilité X Impact
• Probabilité
✓On parle aussi de vraisemblance
✓Estimation de la possibilité qu’un scénario de menace
se produise. Elle représente sa force d’occurrence.
• Impact
✓On parle de gravité
✓Estimation de la hauteur des effets d’un événement
redouté. Elle représente ses conséquences.
11
EBIOS
Risque – Notions: Niveau de risque
Le niveau de risque correspond à l’estimation de sa gravité et de sa vraisemblance
Gravité / niveau d’impact Vraisemblance / Probabilité

• Estimation de la hauteur des • Estimation de la possibilité qu’un scénario
effets d’un évènement de menace ou qu’un risque se produise
redouté ou d’un risque • La vraisemblance représente sa force
d’occurrence
• La gravité représente ses
• Elle dépend essentiellement:
conséquences
✓ De l’exposition aux menaces considérées
• Elle dépend essentiellement:
✓ De l’existence plus ou moins avérée de
✓ De la hauteur et du vulnérabilité
nombre des impacts ✓ De la facilité d’exploitation des
✓ De la valeur du bien vulnérabilités identifiées
considéré ✓ De la capacité et de la motivation des
sources de menaces 12
EBIOS
Risques – Erreurs courantes
• Ne pas confondre risque et gravité!
▪ Le facteur probabilité ne doit pas être écarté.

✓Rare X Impact fort = Fréquent X Impact faible
▪ La criticité d’un risque peut est la même entre un
scénario d’accident fréquent et peu grave et un scénario
rare et grave.
▪ On parle de gravité
✓Estimation de la hauteur des effets d’un événement
redouté. Elle représente ses conséquences. 13
EBIOS
Principes fondamentaux de la
sécurité de l’information
14
EBIOS
Information et actif
❑ Information : Données significatives
❑ Actif: tout ce qui a une valeur pour l’organisme
• L’information;
• Le logiciel comme un programme d’ordinateur;
• Les équipements et les locaux;
• Les services;
• Les personnes et leurs qualifications, aptitudes et expérience
• Intangibles comme la réputation et l’image
❑ Système d’information: Ensemble des moyens matériels, logiciels
et organisationnels qui permettent de recevoir, de conserver et de
traiter l’information
15
EBIOS
Sécurité de l’Information
ISO 27000, Clause 2.89
❑Vulnérabilité: La faiblesse d’un actif ou d’une mesure qui

peuvent être exploitées par une ou plusieurs menaces.
Les vulnérabilités intrinsèques : elles sont relatives aux

caractéristiques inhérentes des actifs.
Les vulnérabilités extrinsèques : elles sont relatives aux
caractéristiques de circonstances spécifiques de l’actif.
16
EBIOS
• Faiblesse
• Faille
• Insuffisance
• Manquement
17
EBIOS
❑Menace: Cause potentielle d’un incident indésirable qui peut

nuire à un système ou à un organisme.
Par définition, une menace est la cause potentielle d’un incident

entrainant un préjudice pour des actifs, comme l’information, des
processus et des systèmes et, par conséquent, être préjudiciable
pour les organismes.
18
EBIOS
ISO 27005, Annexe C
• Action
• Situation
• Evènement
19
EBIOS
Relation entre vulnérabilité et menace
• Faiblesse • Action
• Faille • Situation
• Insuffisance • Evènement
• Manquement
20
EBIOS
Impact
• Pertes
• Dégâts
• Conséquences
21
EBIOS
Risque et sécurité de l’information
❑La possibilité qu’une menace donnée exploite les

vulnérabilités d’un actif ou d’un groupe d’actifs et cause ainsi
un préjudice à l’organisme.
Il est mesuré en termes d’une combinaison de la

probabilité d’un évènement et de ses conséquences.
22
EBIOS
Risque et sécurité de l’information
23
EBIOS
Qu’est-ce qu’un scénario de menace?
24
EBIOS
Principes fondamentaux de la sécurité
Relations entre les concepts de la sécurité de l’information
25
EBIOS
Notions fondamentales
Les 4 critères
▪ Disponibilité: Assurer que le système d’information est en toute

situation actif et opérant
▪ Intégrité : Assurer que les données, les traitements et les
systèmes, tout au long de la chaîne de production des services,
ne sont pas corrompus
▪ Confidentialité : Assurer que les accès aux traitements, aux
données et aux systèmes sont fournis aux seules personnes
autorisées
▪ Traçabilité ou Preuve : Assurer que les actions réalisées sont
conservées afin d’être en mesure d’apporter la certitude de leur
réalisation et leur imputabilité 26
EBIOS
Risque – Exemple 1
Accident de voiture
• Facteur de risque : Route sinueuse, voiture

• Source de menace : la pluie
• Vraisemblance : forte => Faible visibilité, pneus usés
(vulnérabilités)
• Impact : Grave => Perte de vies humaines
27
EBIOS
Risque – Exemple 2
Une attaque sur le site Internet de ma société
• Ce que je crains: « Le defacing de ma page d’accueil »

• Menace: concurrent ou un « script kiddie »
• Facteurs aggravants: pas de pare-feu applicatif, vieille
version d’Apache, code PHP présentant des vulnérabilités
• Probabilité d’attaque: moyenne
• Impact: Moyen…atteinte à l’image de marque
28
EBIOS
Risque – Que retenir de ces exemples?
Un risque est composé de divers paramètres:
• La notion d’évènement redouté (« ce que je crains »)

✓L’accident de voiture
✓La modification/effacement des données de mon site
• La notion de bien essentiel
✓Ce que je veux protéger…mon conducteur, mon site web
• La notion de bien support
✓Ensemble des composantes de mon environnement et
porteuses de vulnérabilités
29
EBIOS
Risque – Que retenir de ces exemples? Suite
• La notion de source de menaces

✓C’est-à-dire un élément menaçant mes biens
essentiels
✓…la pluie, le concurrent
• Vulnérabilité ou absence de mesure

✓Vulnérabilité: les correctifs de sécurité ne sont pas
appliqués
✓Absence de mesure: mon développeur n’est pas
sensibilisé aux bonnes pratiques de développement
30
EBIOS
Evènement redouté
• Définition d’EBIOS
• « Ce que je veux protéger »
• Scénario, avec un niveau donné, représentant une
situation crainte par l’organisme
Un évènement redouté combine:

✓Le bien essentiel
✓Le besoin et niveau de sécurité
✓La source de menace
✓L’impacts
31
EBIOS
Evènement redouté
• Exemple 3: Un adolescent de 15 ans pirate le système de
son collège pour améliorer ses notes
Un adolescent de 15 ans a été interpellé pour s’être introduit
dans le système informatique de son collège dans le but de
modifier ses résultats scolaires. Dépité de n’avoir pas pu
atteindre ce but, le collégien a saturé le système informatique
en expédiant plus de 40.000 courriels, manœuvre qui a
provoqué une indisponibilité pendant 4 jours.
✓Le bien essentiel : ?
✓Le besoin et niveau de sécurité : ?
✓La source de menace : ?
✓L’impacts : ? 32
EBIOS
Evènement redouté
• Exemple 3: Un adolescent de 15 ans pirate le système
de son collège pour améliorer ses notes
Un évènement redouté
✓Bien essentiel: les résultats scolaires
✓Besoin et niveau de sécurité: intégrité - forte
✓Source de menace: élève malveillant
✓Impacts: Atteinte à l’image de marque, perte de
crédibilité, etc.
33
EBIOS
Scénario de menace
• Définition d’EBIOS
• « Qui peut nuire à mes biens? Comment? »
• Représente les menaces envisageables et plausibles
• « Scénario, avec un niveau donné, décrivant des modes
opératoires ».
Un scénario de menace combine:

✓Source de menace
✓Bien support
✓Critère de sécurité
✓Menaces
✓Vulnérabilités exploitables 34
EBIOS
Scénario de menace
• Exemple 3: Un adolescent de 15 ans pirate le système de
son collège pour améliorer ses notes
Un adolescent de 15 ans a été interpellé pour s’être introduit dans le
système informatique de son collège dans le but de modifier ses
résultats scolaires. Dépité de n’avoir pas pu atteindre ce ut. Le
collégien a saturé le système informatique en expédiant plus de
40.000 courriels, manœuvre qui a provoqué une indisponibilité
pendant 4 jours.
✓Source de menace : ?
✓Bien support : ?
✓Critère de sécurité : ?
✓Menaces : ?
✓Vulnérabilités exploitables : ? 35
EBIOS
Scénario de menace
Un scénario de menace :
• Source de menace: un adolescent de 15 ans agissant

délibérément par appât du gain
• Bien support: Système informatique du collège
• Critère de sécurité: intégrité
• Menaces: Elévation de privilèges, modification de contenu
• Vulnérabilités exploitables: Accès facile et possibilité de
modifier des données
36
EBIOS
Définitions importantes
• Bien essentiel: Information ou processus jugé comme important pour
l’organisme. On appréciera ses besoins de sécurité mais pas ses
vulnérabilités
• Bien support: bien sur lequel reposent des biens essentiels. On distingue
notamment les systèmes informatiques, les organisations et les locaux. On
appréciera ses vulnérabilités mais pas ses besoins de sécurité
• Critère de sécurité: Caractéristique d’un bien essentiel permettant
d’apprécier ses différents besoins de sécurité
• Besoin de sécurité: Définition précise et non ambiguë du niveau
d’exigences opérationnelles relatives à un bien essentiel pour un critère de
sécurité donné (disponibilité, confidentialité, intégrité)
• Source de menace: Chose ou personne à l’origine de menaces. Elle peut
être caractérisée par son type (humain ou environnemental), par sa cause
(accidentelle ou délibérée) et selon le cas par ses ressources disponibles,
son expertise, sa motivation…
37
EBIOS
Autres définitions importantes
• Menace: Moyen type utilisé par une source de menace
• Vulnérabilité: caractéristique d’un bien support qui peut
constituer une faiblesse ou une faille au regard de la
sécurité des systèmes d’information
• Impact: Conséquence directe ou indirecte de
l’insatisfaction des besoins de sécurité sur l’organisme et/ou
sur son environnement
• Gravité: Estimation de la hauteur des effets d’un
évènement redouté ou d’un risque
38
EBIOS
Processus de management du
risque
39
EBIOS
Processus du management du risque
Modèle général de la norme ISO 27005
Établissement du
▪ Deux activités séquentielles et itératives : contexte
• l’appréciation du risque Appréciation du risque

Analyse de risque
• le traitement du risque
Surveillance et réexamen du risque

Identification du risque
▪ Peut s’appliquer : Estimation du risque
Communication
• à l’entreprise entière Évaluation du risque
• à un secteur d’activité Évaluation du risque
• à un SI Appréciation du
risque satisfaisante ?
non
• une application… Traitement du risque

oui
▪ La granularité des éléments pris en Traitement du risque
compte est importante : Traitement du risque

satisfaisant ?
non
• trop fine elle va complexifier l’étude oui
Acceptation du risque
• trop grosse elle va la rendre inefficace
40
EBIOS
Processus de management du risque
Etapes de la norme ISO 27005
1. Établissement du contexte
Processus de définition de l’objectif, du périmètre, des contraintes et
du cadre méthodologique
2. Identification du risque
Processus utilisé pour trouver, lister et caractériser les
éléments à risques
3. Estimation du risque
Processus utilisé pour affecter des valeurs à la probabilité et
aux conséquences d’un risque
4. Évaluation du risque
Processus utilisé pour prioriser les risques évalués en tenant
compte du niveau d’acceptabilité de l’entreprise
41
EBIOS
Processus de management du risque
Etapes de la norme ISO 27005
5. Traitement du risque
Processus utilisé pour identifier et évaluer les options de
traitement du risque
6. Acceptation du risque
Processus de décision sur l’acceptation de la méthode de
traitement, afin que le risque résiduel soit tolérable
7. Communication du risque
Échange et partage de l’information concernant un risque entre le
décideur et les autres parties prenantes
8. Surveillance et réexamen du risque
Processus utilisé pour garantir une pérennité de l’analyse de
risque, via des contrôles et un réexamen réguliers
42
EBIOS
Structure de la méthode
EBIOS
43
EBIOS
Structure de la méthode
44
EBIOS
Rôles et responsabilités
Les fonctions génériques, qui peuvent endosser ces
responsabilités, sont les suivantes :
▪ Responsable = Responsables du périmètre de l'étude

▪ RSSI = Responsable de la sécurité de l'information
▪ Risk manager = Gestionnaire de risques
▪ Autorité = Autorités de validation
▪ Dépositaire = Dépositaire de biens essentiels (utilisateurs
ou maîtrises d'ouvrage)
▪ Propriétaire = Propriétaire de biens supports
45
EBIOS
Sources de menaces
Nous avons trois types de sources de menaces tirées de la base de connaissances
EBIOS/
1. Sources humaines agissant de manière délibérée:
✓ Personnes ou groupes de personnes mal intentionnées, qu’elles soient physiques
ou morales, et qui peuvent être à l’origine de risques. Elles peuvent être
internes ou externes au sujet de l’étude.
2. Sources humaines agissant de manière accidentelle
✓ Personnes ou groupes de personnes sans intention de nuire, qu’elles soient
physiques ou morales, et qui peuvent être à l’origine de risques. Ceci comprend
tout type d’activités humaines. Elles peuvent être internes ou externes au sujet
de l’étude.
3. Sources non humaines
✓ Choses ou objets qui peuvent être à l’origine de risques. Elles peuvent être
internes au sujet de l’étude ou externe à celui-ci. Il peut s’agir de contingences
ou de malchance. Leurs capacités dépendent principalement de leurs ressources
disponibles et de leur dangerosité 46
EBIOS
Sources humaines agissant de manière délibérée
▪ Source humaine interne, malveillante, avec de faibles capacités
✓ Collaborateur malveillant avec des possibilités d’action limitées sur le système
d’information (personnel en fin de contrat ou voulant se venger de son employeur
ou de ses collègues…), stagiaire agissant de manière ludique, client désirant
obtenir des avantages, personnel d’entretien.
▪ Source humaine interne, malveillance, avec des capacités importantes
✓ Collaborateur malveillant avec d’importantes connaissances et possibilités d’action
sur le système d’information (manager ambitieux en fin de contrat ou voulant se
venger de son employeur ou de ses collègues, développeur agissant par égo ou de
manière ludique, fraudeur, actionnaire…), sous-traitant ou prestataire, personnel
de maintenance ou d’assistance à distance.
▪ Source humaine interne, malveillante, avec des capacités illimitées
✓ Collaborateur malveillant avec des connaissances et possibilités d’action illimitées
sur le système d’information (administrateur système ou réseau agissant par
vengeance, dirigeant…)
47
EBIOS
Sources humaines agissant de manière délibérée
▪ Source humaine externe, malveillante, avec de faibles capacités
✓ Script-kiddies, vandale
▪ Source humaine externe, malveillance, avec des capacités
importantes
✓ Militant agissant de manière idéologique ou politique, pirate
passionné, casseur ou fraudeur, ancien employé désirant se venger
d’un licenciement, concurrent, groupement professionnel,
organisation de lobbying, syndicat, journaliste, organisation non
gouvernementale.
▪ Source humaine externe malveillante, avec des capacités
illimitées
✓ Organisation criminelle, agence gouvernementale ou organisation
sous le contrôle d’un Etat étranger, espions, organisation terroriste
48
EBIOS
Sources humaines agissant de manière accidentelle
▪ Source humaine interne, sans intention de nuire, avec de faibles capacités
✓Collaborateur maladroit ou inconscient avec des possibilités d’action limitées sur
le système d’information, personnel à faible conscience d’engagement, peu
sensibilisé ou peu motivé dans sa relation contractuelle avec l’organisme,
personnel d’entretien maladroit, stagiaire, thésard, intérimaire, utilisateur,
fournisseur, prestataire, sous-traitant, client, actionnaires
▪ Source humaine interne, sans intention de nuire, avec des capacités
importantes
✓ Collaborateur maladroit ou inconscient avec d’importantes connaissances et
possibilités d’action sur le système d’information (manager, développeur…).
▪ Source humaine interne, sans intention de nuire avec des capacités
illimitées
✓ Collaborateur maladroit ou inconscient avec des connaissances et possibilités
d’action illimitées sur le système d’information ( administrateur système ou
réseau, dirigeant…) 49
EBIOS
Sources humaines agissant de manière accidentelle
• Source humaine externe, sans intention de nuire, avec de faibles
capacités
✓ Entourage du personnel, personne réalisant des travaux dans le
voisinage, manifestants, visiteur maladroit, forte ambiance sonore.
• Source humaine externe, sans intention de nuire malveillance, avec
des capacités importantes
✓ Matériels émettant des ondes, des vibrations, activités industrielles
dégageant des substances chimiques toxiques ou susceptibles de
provoquer des sinistres mineurs, trafic routier ou aérien pouvant générer
des accidents.
• Source humaine externe malveillante, avec des capacités illimitées
✓ Matériels émettant des radiations ou des impulsions électromagnétiques,
activités industrielles susceptibles de provoquer des sinistres majeurs,
explosion dans le voisinage. 50
EBIOS
Sources non humaines
• Code malveillant d’origine inconnue
✓ Virus informatique, code malveillant non ciblé, ou ciblé mais d’origine
inconnue.
• Phénomène naturel
✓ Phénomène météorologique ou climatique aléatoire (foudre, canicule…),
chute de roches, infiltration de sable, usure (temps qui s’écoule),
phénomène naturel imprévisible mais récurrent.
• Catastrophe naturelle ou sanitaire
✓ Eruption volcanique, pandémie, feu de forêt
• Activité animale
✓ Rongeurs, présence d’animaux dangereux pour l’homme
• Evènement interne
✓ Incendie de locaux, accident de chantier, fuite de canalisations,
changement du réseau 51
EBIOS Objectif : collecter les éléments
Module 1: Contexte nécessaires à la gestion des risques
Trois activités principales:

• Activité 1.1: définir le cadre de gestion
des risques
✓ Périmètre de l’étude et contexte de la
gestion des risques
• Activité 1.2 Préparer les métriques
✓ Paramètres et échelles nécessaires
pour l’analyse
• Activité 1.3 Identifier les biens
✓ Identifier les biens
essentiels/supports de l’organisme et
nécessaires pour les modules 2 et52 2
EBIOS
Module 1: Etude du contexte
Activité 1.1- Cadre de la gestion des risques
• Cadrer l’étude des risques
✓ Dans quel contexte intervient l’étude?
✓ Quel est l’objectif de l’étude?
✓ Les étapes du processus et les rôles ?
• Décrire le contexte général
✓ Description de l’organisation, des enjeux, des processus métiers
• Délimiter le périmètre de l’étude
✓ Description technique et fonctionnelle du périmètre de l’étude, les interfaces
• Identifier les paramètres à prendre en compte
✓ Référentiels applicables, contraintes impactant l’étude
• Identifier les sources de menaces
✓ Qui peut menacer mon système d’information? 53
EBIOS
Exemple :
Les étapes du
processus et
les rôles
54
EBIOS
Exemple :
Les sources de
menace
55
EBIOS
Activité 1.2- Les métriques à préparer
▪ Critères de sécurité et échelles (DICT)
- Différentes catégories de biens essentiels

▪ N° de carte bancaire
▪ CV
▪ Données médicales
▪ Bibliographie
▪…
D’où la nécessité de définir différents critères afin de prendre en

compte l’ensemble des besoins de sécurité de l’organisme
56
EBIOS
▪ Critères de sécurité et échelles (DICT)
Principales questions à se poser

✓ Quels sont les critères à retenir pour l’étude?
o Disponibilité: accessibilité du bien essentiel
o Intégrité: non altération du bien essentiel
o Confidentialité: non divulgation ou compromission du bien essentiel
o Traçabilité: niveau de traçabilité souhaité (besoin ou contrainte)
✓ Quelle est la définition de chacun des critères retenus?
57
EBIOS
Module 1: Contexte
Critères de sécurité retenus pour l’étude
58
EBIOS
Module 1: Contexte
Les critères de sécurité constituent des facteurs permettant de relativiser
l’importance des différents biens essentiels selon les besoins métiers, et serviront
ainsi à décrire les conditions dans lesquelles le métier s’exerce convenablement.
Trois critères de sécurité sont incontournables:
• La disponibilité: elle reflète le besoin que des biens essentiels soient accessibles:
elle peut correspondre à la durée nécessaire pour avoir accès au bien essentiel (ex.:
1 heure, 1 journée, 1 semaine…) et/ou à un taux (ex.: 99%); on peut même séparer
ces deux notions en deux critères de sécurité distincts;
• L’intégrité: elle reflète le besoin que des biens essentiels ne soient pas altérés; elle
correspond autant à leur niveau de conformité qu’à leur stabilité, leur exactitude,
leur complétude…;
• La confidentialité: elle reflète le besoin que des biens essentiels ne soient pas
compromis ni divulgués: elle correspond au nombre ou catégories de personnes
autorisées à y accéder. 59
EBIOS
Module 1: Contexte
▪ Pour chaque critère retenu, définir les échelles

✓ Conseil: 3 ou 4 niveaux d’échelles au maximum
Echelle en termes de disponibilité
60
EBIOS
Echelle en termes d’intégrité
61
EBIOS
Echelle en termes de confidentialité
62
EBIOS
Module 1: Contexte
Echelle de niveaux de gravité / impact

✓ En cas d’incident, comment évaluer les dégâts ou pertes supportées par
l’organisme?
✓ Les bien n’ont pas la même valeur :
▪ Différence de contribution à la création de valeur
D’où La
o Données financières de l’entreprise, notion
o Informations sur les salaires du personnel, gravité et de
niveaux de
o Registre des visites,
gravité
o CV, bibliographie,
o stratégie d’entreprise … 63
EBIOS
Critères de sécurité
Estimation de la gravité des événements redoutés et des risques
Niveaux de
Description détaillée de l'échelle
l'échelle
1. Négligeable L’entreprise surmontera les impacts sans aucune difficulté.
2. Limitée L’entreprise surmontera les impacts malgré quelques difficultés
3. Importante L’entreprise surmontera les impacts avec de sérieuses difficultés.
4. Critique L’entreprise ne surmontera pas les impacts (sa survie est menacée).
Exemples d’impacts :
Financiers, Image et réputation, Juridiques et réglementaires,
Organisationnels et sociaux 64
EBIOS
Module 1: Contexte
Echelle de niveaux de vraisemblance

✓ Plusieurs évènements différents qui peuvent conduire à un ou
plusieurs risques
▪ différences de sources
▪ différences de motivations D’où La notion
▪ Différences de cibles Vraisemblance et
de niveaux de
▪ Facilité de l’attaque… vraisemblance
65
EBIOS
Critères de sécurité
Echelle pour estimer la vraisemblance des scénarios de menaces et des risques
Niveaux de l'échelle Description détaillée de l'échelle

1. Minime Cela ne devrait pas se (re)produire.
2. Significative Cela pourrait se (re)produire.
3. Forte Cela devrait se (re)produire un jour ou l'autre.
4. Maximale Cela va certainement se (re)produire prochainement.
66
EBIOS
Module 1: Contexte
• Critères de gestion des risques

✓Quoi faire lors de l’étude des évènements redoutés ?
✓Quoi faire lors de l’étude des scénarios de menaces ?
✓Comment estimer les risques ?
✓Comment évaluer les risques ?
67
EBIOS
Module 1: Contexte
Critères de gestion des risques

▪ Les critères de gestion des risques permettent :
✓ d'estimer et d'évaluer les risques
✓ de prendre des décisions concernant leur appréciation et leur
traitement.
▪ Ils peuvent :
✓ être imposés
✓ résulter d'obligations légales et réglementaires
✓ résulter d'autres exigences auxquelles l'organisme répond.
68
EBIOS
Critères de sécurité Exemple de critères de gestion des risques
Action Critère de gestion des risques (règle choisie pour réaliser l'action)
Estimation des événements Les événements redoutés sont estimés en termes de gravité à l'aide de
redoutés (module 2) l'échelle définie à cet effet.
Évaluation des Les événements redoutés sont classés par ordre décroissant de
Événements redoutés vraisemblance.
(module 2)
Estimation des risques - La gravité d'un risque est égale à celle de l'événement redouté considéré.
(module 4) - La vraisemblance d'un risque est égale à la vraisemblance maximale de tous les
scénarios de menaces liés à l'événement redouté considéré.
Évaluation des risques - Les risques dont la gravité est critique, et ceux dont la gravité est importante et
(module 4) la vraisemblance forte ou maximale, sont jugés comme intolérables.
- Les risques dont la gravité est importante et la vraisemblance significative, et
ceux dont la gravité est limitée et la vraisemblance forte ou maximale, sont jugés
comme significatifs.
- Les autres risques sont jugés comme négligeables.
69
EBIOS
Module 1: Contexte
Risques intolérables
Risques significatifs
Risques négligeables
70
EBIOS
Module 1: Contexte
Activité 1.3- Identifier les biens
▪ Identification des biens essentiels
✓ Ce sont les « actifs » du périmètre étudié: fonctions ou informations
essentielles aux métiers de l’organisation
✓ La granularité dépend du but de l’étude
✓ Sur la base de documents fonctionnels et d’entretiens avec les
métiers
▪ Identification des biens supports
✓ Composants du SI, techniques et non techniques qui supportent les
éléments essentiels identifiés.
✓ Affinage au cours de l’analyse indispensable
▪ Liens entre biens essentiels et biens supports
▪ Mesures de sécurité existantes 71
EBIOS
Module 1: Contexte
▪ Exemple d’identification des biens essentiels
Processus essentiels Informations essentielles concernées Dépositaires
Établir les devis (estimation du • Cahier des charges Service commercial
coût global d'un projet, • Catalogues techniques
négociations avec les clients…) • Contrat (demande de réalisation)
• Devis
Créer des plans et calculer les • Dossier technique d'un projet Bureau d'études
Structures • Paramètres techniques (pour les calculs de structure)
• Plan technique
• Résultat de calcul de structure
Créer des visualisations • Dossier technique d'un projet Bureau d'études
• Visualisation 3D
Gérer le contenu du site Internet • Informations société (contacts, présentation…) Directeur adjoint
• Exemple de devis
• Exemple de visualisation 3D
• Page Web 72
EBIOS
Module 1: Contexte
Types de biens supports
▪les systèmes informatiques et de téléphonie (SYS), qui peuvent être décomposés en :

▪ matériels (MAT),
▪ logiciels (LOG),
▪ canaux informatiques et de téléphonie (RSX) ;
▪ les organisations (ORG), qui peuvent être décomposées en :
▪ personnes (PER),
▪ supports papier (PAP),
▪ canaux interpersonnels (CAN) ;
▪ les locaux (LOC), qui hébergent les autres biens supports et fournissent les ressources ;
73
EBIOS
Module 1: Contexte
▪ Exemple d’identification des biens supports
74
EBIOS
Module 1: Contexte
▪ Exemple d’identification des biens supports
75
EBIOS
Module 1: Contexte
Liens entre
biens
essentiels
et biens
supports
76
EBIOS
Module 1: Contexte
Liens entre
biens
essentiels et
biens
supports
77
EBIOS
Module 1: Contexte
▪ Exemple de
mesures de
sécurité
existantes
78
EBIOS
Module 2: Evènements redoutés
Une seule activité:
• Activité 2: Apprécier les

évènements redoutés
79
EBIOS
Sur la base des éléments essentiels identifiés: décliner et
évaluer les évènements que l’organisation redoute;
▪ Quels sont les besoins de sécurité de chaque bien essentiel ?
✓Au max: 4 évènements par bien essentiel
▪ Quelles sources de menaces peuvent les affecter ?
▪ Quels seraient les impacts si l’évènement se produisait ?
▪ Quelle serait la gravité d’un tel événement?
✓Utiliser l’échelle pour pondérer la gravité
80
EBIOS
Exemple concret: données d’un SIRH
• Evènement redouté: « Compromission des fiches de paie »

Bien essentiel: fiches de paie
• Critère et besoin de sécurité: confidentialité, niveau
« confidentiel »
• Sources de menaces: stagiaire RH, personnel interne, trojan
• Impacts: image de marque, juridique, grève, baisse de productivité
• Gravité: Importante
❑ Autres éléments redoutés possibles pour ce bien: « Altération

des fiches de paie » et « indisponibilité des fiches de paie »
81
EBIOS
Exemple de tableau d’évènements redoutés
Chaque ligne du tableau suivant représente un événement redouté par

l’entreprise xxxxxx (bien essentiel, critère de sécurité, besoin de
sécurité selon les échelles de besoin, sources de menaces et impacts).
La gravité de chaque évènement redouté est estimée (cf. échelle de
gravité) sans tenir compte des mesures de sécurité existantes.
82
EBIOS
Exemple de
tableau
d’évènements
redoutés
83
EBIOS
Exemple de
tableau
d’évènements
redoutés
84
EBIOS
Classifier les
événements
redoutés
85
EBIOS
Module 3: Scénarios de menace
• Activité 3: Apprécier les

scénarios de menace
86
EBIOS
Module 3: Scénarios de menaces
A garder en tête:
• Les biens supports « supportent » les biens essentiels
• Les menaces sur les biens supports impactent donc les biens
essentiels
But du module: analyser tous les scénarios de menaces
• Quelles menaces peuvent s’exercer sur chaque bien support?
✓Modification, divulgation, etc.
• Quelles sources de menaces peuvent en être à l’origine?
✓Concurrent? Administrateur? Virus? Tornade?
• Quelles sont les vulnérabilités potentiellement utilisables?
• Y a-t-il des prérequis pour que la menace se réalise?
✓Connaissance du progiciel? Connaissance du bâtiment?
• Quelle est la vraisemblance des scénarios? 87
EBIOS
Un scénario de menace est composé:

• D’un bien support
• Une menace, exploitant une ou plusieurs vulnérabilités
• Les prérequis nécessaires pour mener à bien la menace
• La ou les sources de menaces?
• La vraisemblance du scénario
88
EBIOS
Exemple:
• Bien support: Serveur Web Apache de l’Intranet (LOG)
• Menace: LOG-DEP: Dépassement des limites d’un logiciel
• Vulnérabilités: Absence de contrôle d’innocuité (« Permet
de saisir n’importe quelles données » « Permet de saisir
n’importe quel volume de données »
• Prérequis: Accès logique au logiciel
• Source de menace: personnel interne malveillant, virus
• Vraisemblance: faible
89
EBIOS
Avantage: Menaces/Scénario/Vulnérabilités sur un tableau
• La menace est générique: « Menace impactant la disponibilité »
• Les vulnérabilités pouvant conduire à une indisponibilité sont énumérées
90
EBIOS
91
EBIOS
92
EBIOS
Classifier des
scénarios de
menaces
93
EBIOS
Récapitulatif Entretiens Acteurs
Direction / Commanditaire
• Identifier les enjeux, contraintes, paramètres à prendre en compte et
les sources de menace
• Identifier les impacts
Métiers
• Identification des biens essentiels et expression des besoins de sécurité
• Identification des évènements redoutés
Opérationnels / Techniques
• Identification des biens supports
• Identification des mesures de sécurité existantes
• Identification des menaces et vulnérabilités
94
EBIOS
Module 4: Etude des risques
Deux activités:
• Activité 4.1: Apprécier les

risques
• Activité 4.2: Identifier les
objectifs de sécurité
95
EBIOS
Activité 4.1: Apprécier les risques
Mettre en évidence et de caractériser les risques réels pesant

sur le périmètre de l'étude.
Pour chaque bien essentiel :

▪ Evènements redoutés
▪ Les scénarios de menaces donnant lieu à chaque évènement redoué
▪ Les biens supports concernés et les mesures de sécurité qui existent
▪ Le niveau de risque
96
EBIOS
Données
Données
97
EBIOS
Serveur
indisponible
Ordinateur
indisponible
Risque Données
d’indisponibilité
des données
firewall
Routeur indisponible
Internet
indisponible
indisponible
98
EBIOS
Menace sur le
Serveur
Menace sur causant une
l’Ordinateur indisponibilité
causant une
indisponibilité
Risque Données
d’indisponibilité
des données
Menace sur le
Plusieurs Menace sur le firewall
causant une Menace sur
scénarios de routeur
indisponibilité Internet
menace pour un causant une
causant une
même risque indisponibilité
indisponibilité
99
EBIOS
• Confrontation les évènements redoutés aux scénarios de menaces
Exemple: Risque lié à l'indisponibilité d'un devis au-delà de

72h
✓ ER:
100
EBIOS
• Confrontation les évènements redoutés aux scénarios de menaces
✓ SM:
101
EBIOS
• Identifier les mesures de sécurités existantes
✓ SM:
102
EBIOS
• Définir le niveau de risque (Gravité x Impact)
Nouvelle vraisemblance en tenant compte

des mesures de sécurités existantes
Répéter cette partie pour chaque risque 103

EBIOS
Module 4:
Etude des risques
Déterminer la criticité
de chaque risque après
les mesures de
sécurités existantes
Risque net =
Risque brut en prenant en compte
les mesures existantes
104
EBIOS
Activité 4.2: Identifier les objectifs de sécurité
• Les choix de traitement des risques:
• Choix 1: La réduction du risque
✓ Démarche classique: « Je traite le risque »
✓ Les mesures standards:
o Mesures de prévention -> réduction de la vraisemblance (probabilité
d’occurrence)
o Mesures de protection-> réduction de l’impact (conséquences)
✓ Le niveau de risque doit être géré en introduisant, supprimant ou en modifiant des
contrôles afin que le risque résiduel puisse être réapprécié à un niveau acceptable.
Des contrôles de sécurité appropriés et justifiés devraient être choisis pour répondre
aux besoins identifiés par l’évaluation et le traitement du risque.
✓ La sélection des mesures de sécurité devrait tenir compte des critères d’acceptation
des risques, ainsi que des exigences juridiques, réglementaires. 105
EBIOS
• Choix 2: Prévention par « évitement »
✓ Suspension de l’activité à risque (refus du risque) ou refonte…
✓ Lorsque les risques identifiés sont considérés comme trop élevés ou

que les coûts de mise en œuvre du traitement risquent de dépasser
les avantages, une décision peut être prise pour éviter le risque
entièrement par l’annulation d’une ou d’un ensemble d’activités ou la
modification des conditions en vertu desquelles l’activité est exploitée
106
EBIOS
▪ Choix 2: Prévention par « évitement »: Exemples
✓ En arrêtant certaines activités (arrêter d’utiliser internet dans un
centre de recherche, interdire les transactions par carte bancaire)
✓ En enlevant les actifs d’une zone à risque (ne pas stocker des
documents sensibles dans l’intranet de l’organisme ou déménager
les serveurs au 4ème étage afin d’éviter un risque d’inondation)
✓ En décidant de ne pas échanger certaines informations sensibles
(avec des tierces parties) si une protection suffisante n’est pas
garantie
107
EBIOS
• Choix 3: Le transfert (ou partage du risque)
Il existe deux grandes méthodes de transfert de risque:
• Externalisation de l’activité à risque (outsourcing): Transfert de
tout ou partie d’une fonction d’une entreprise vers un partenaire
externe. Par exemple, une organisation externalise la surveillance de
son réseau à un fournisseur externe qui peut assurer un service
24h/7j, ce qui ne peut pas être réalisé par son personnel.
• Assurance ou garantie financière: Toute autre forme de couverture
de risque contractée par une organisation en échange du paiement en
ligne. Si le risque se matérialise, l’organisme sera compensé par
l’assurance en fonction des modalités convenues entre les parties. 108
EBIOS
• Choix 3: Le transfert (ou partage du risque)
✓ Le transfert de risque requiert la décision de partager certains
risques avec des parties externes (le cas le plus courant étant la
souscription d’un contrat d’assurance)
✓ Le transfert de risques peut créer de nouveaux risques ou modifier
des risques existants et identifiés. Par conséquent, le traitement de
nouveaux risques découlant de l’opération de transfert, peut être
nécessaire
✓ Le transfert de risque est par ailleurs une élimination « non
absolue » du risque (exemple: utilisation de tiers pour le transport,
la manutention, etc.). 109
EBIOS
• Choix 4: L’acceptation du risque-> Acceptation du
risque en toute connaissance de cause
✓Il existera certains risques pour lesquels l’organisme ne
pourra pas identifier de contrôles de sécurité ou pour
lesquels les coûts de mise en œuvre de contrôles de sécurité
seront supérieurs à la perte potentielle entraînée par la
réalisation du risque.
✓Dans ce cas, la décision peut être prise d’accepter le risque
et de vivre avec les conséquences de celui-ci s’il se réalise.
110
EBIOS
Choix 4: L’acceptation du risque-> Acceptation du risque
en toute connaissance de cause
✓L’acceptation du risque actuel doit cependant être

documenté
✓Si le niveau de risque répond au critères d’acceptation des
risques, il n’est pas nécessaire de mettre en œuvre des
mesures de sécurité supplémentaires et le risque peut être
accepté de facto
✓Quand un risque est accepté, les parties prenantes
concernées doivent en être informées et accepter le risque.
111
EBIOS
Activité 4.2.1 : Options des traitement
Possible de choisir plusieurs options pour chaque risque.

Un risque peut être:
▪ partiellement réduit par la mise en œuvre de mesures de
sécurité,
▪ partiellement transféré par le recours à une assurance
▪ partiellement pris pour ce qui subsiste
112
EBIOS
Le choix des options de traitement est fonction de :

▪ des éléments constitutifs du risque (bien essentiel, bien
support, critère de sécurité touché, impacts, …) : ils
permettent de juger de la faisabilité de leur traitement
▪ des critères de gestion des risques retenus
▪ des paramètres à prendre en compte
113
EBIOS
• Quels risques
vais-je traiter?
• Plusieurs issues:
✓Evitement
✓Réduction
✓Transfert
✓Acceptation
114
EBIOS
Module 4: Etude des risques: Risque résiduel
• Risque résiduel: C’est le risque subsistant après le
traitement du risque.
• La notion de risque résiduel peut être définie comme étant le
risque qui subsiste après la mise en place des mesures de
sécurité visant à atténuer le risque inhérent, et peut être
résumée comme suit:
• Risque résiduel =
✓Risque net – risque traité par les mesures de sécurité
✓Risque après la mise en œuvre des mesures de sécurité
• En toute circonstance, le risque résiduel doit être compris,
accepté et approuvé par la direction. 115
EBIOS
Module 4: Etude des risques: Risque résiduel
Activité 4.2.2 : Risque résiduel
Il peut être utile de déterminer la gravité et la vraisemblance attendues

une fois les objectifs de sécurité satisfaits
116
EBIOS
Module 5: Etude des mesures de sécurité
Deux activités:
• Activité 5.1: Formaliser les

mesures de sécurité
• Activité 5.2: Mettre en œuvre
les mesures de sécurité
117
EBIOS
Activité 5.1.1: Déterminer les mesures de sécurité
• En réponse à la stratégie de traitement retenue (objectifs de
sécurité), déterminer les moyens d’atteindre les objectifs de
sécurité;
• Tenir compte des contraintes budgétaires et techniques,
• Deux types de mesures de réduction
✓Mesure agissant sur la vraisemblance
✓Mesure agissant sur la gravité
• Prévoir une matrice de couverture « Risques par mesure de
sécurité »
118
EBIOS
Activité 5.1.1: Déterminer les mesures de sécurité
une ligne récupératrice, destinée à minimiser les conséquences

Principes de des incidents et des sinistres et revenir à l'état initial, à l'aide de
défense en mesures de sécurité qui agissent sur :
profondeur ✓les besoins de sécurité des biens essentiels (récupération,
restauration…),
✓les sources de menaces (réaction offensive…),
✓les impacts (compensation…).
une ligne préventive, destinée à éviter l'apparition
des incidents et des sinistres à l'aide de mesures une ligne protectrice, destinée à bloquer, contenir et détecter
de sécurité qui agissent sur : l'apparition des incidents et des sinistres à l'aide de mesures de
✓les sources de menaces (dissuasion, déception…), sécurité qui agissent sur :
✓les besoins de sécurité des biens essentiels ✓les besoins de sécurité des biens essentiels (confinement…),
(anticipation, prévention…), ✓les sources de menaces (lutte…),
✓les vulnérabilités des biens supports (réduction ✓les menaces (détection, protection, réaction défensive…),
des failles, préparation…) ; ✓les vulnérabilités des biens supports (résistance, résilience…) ;
119
EBIOS
120
EBIOS
Activité 5.1.2: Analyser les risques résiduels
• Rappel: les mesures de « réduction » conduisent

systématiquement à des risques résiduels, mais moins critiques,
donc acceptables (en fonction des seuils d’acceptation).
• Exemple concret:
✓ Risque: « Compromission de fiche de paie par une menace
sur un poste nomade »; Criticité = Gravité forte x
Vraisemblance forte
✓ Mesures: Anonymisation des fiches de paie (gravité),
chiffrement, sensibilisation, câble lock (vraisemblance)
✓ Risque résiduel: Gravité faible x Vraisemblance faible
121
EBIOS
122
EBIOS
Activité 5.1.3: Rédiger une déclaration d’applicabilité
• Justifie la couverture des paramètres à prendre en compte,

identifiés au début de l’étude
• Exemple:
✓Paramètre à prendre en compte: « L’application manipule
des données à caractère nominatif, ces données doivent
donc être protégées conformément aux dispositions de la
CNIL »
✓Justifier la couverture de ce paramètre par les mesures
identifiées 123
EBIOS
Activité 5.1.3: Rédiger une déclaration d’applicabilité
Comment les paramètres à

prendre en compte
(références applicables,
contraintes et hypothèses)
ont été pris en compte au
sein de l'étude et de
justifier le fait de ne pas en
avoir tenu compte, le cas
échéant.
124
EBIOS
Elaborer le plan d’actions et suivre la réalisation des mesures de
sécurité
• Pour chaque mesure de sécurité précédemment formalisée, il
convient d’indiquer, par exemple:
1.Son libellé
2.Sa priorité
3.Le responsable de la mise en œuvre
4.Si besoin, le détail des actions à mener
5.Le coût prévisionnel de mise en œuvre
6.L’état d’avancement
7.Les moyens de contrôler la mise en œuvre
8.Les éventuels risques, résiduels ou induits, mis en évidence au fur et à
mesure de l’avancement du plan d’action 125
EBIOS
Elaborer le plan d’actions et suivre la réalisation des mesures
de sécurité
• D’une manière générale, chaque action du plan d’action

devrait être:
✓ S - Spécifique ( un acteur, un domaine à la fois);
✓ M- Mesurable (définition du moyen de contrôle);
✓ A- Atteignable (éventuellement en plusieurs étapes, avec les
ressources nécessaires);
✓ R- Réaliste (en fonction des acteurs, de leurs capacités)
✓ T- liée au temps (avec une date butoir, un délai, une période
définie) 126
EBIOS
127
EBIOS
Annexe ISO 27001: Mesures de

sécurité
128
EBIOS
Annexe A de l’EBIOS
• La norme ISO 27002 fournit une liste d’objectifs et des
mesures de sécurité généralement pratiqués qui doivent
être utilisés comme lignes directrices de mise en œuvre
lors du choix et de la mise en œuvre des mesures pour
réaliser la sécurité de l’information.
• Elle fournit des lignes directrices en matière de mesures de
la sécurité de l’information
• Les clauses 5 à 18, en particulier, fournissent des conseils
spécifiques ainsi qu’un guide de mise en œuvre relatifs aux
meilleures pratiques, venant à l’appui des mesures
spécifiées à l’annexe A de l’ISO 27001 (clause A.5 à A.18).
129
EBIOS
Annexe A de l’EBIOS
• La norme ISO 27002, c’est : un total de 35 catégories de sécurité

principales et 114 mesures.
Chapitre 5 : Politique de Sécurité de l’information Chapitre 12 : Sécurité liée à l’exploitation
Chapitre 6 : Organisation de la Sécurité Chapitre 13 : Sécurité des télécommunications
Chapitre 14 : Acquisition, développement et

Chapitre 7 : Sécurité liée aux RH
maintenance des systèmes
Chapitre 8 : Gestion des actifs (classification) Chapitre 15 : Relations avec les fournisseurs
Chapitre 16 : Gestion des incidents liés à la sécurité

Chapitre 9 : Contrôle d’accès
de l’information
Chapitre 10 : Cryptographie Chapitre 17 : Gestion de la continuité d’activité
Chapitre 11 : Sécurité physique et environnementale Chapitre 18 : Conformité
130
EBIOS
Norme ISO 27002
Chapitre 5 – Politique de Sécurité
• 5.1 Orientations de la direction en matière de

sécurité de l'information
• 5.1.1 Document de politique de sécurité
• 5.1.2 Revue des politiques de sécurité de l'information
• Points clefs
• Se focalise sur la formalisation et la mise en œuvre
d’une PSI
• Introduit la notion de soutien de la direction, de
conformité aux besoins métier et d’application à la
totalité de l’entreprise
131
EBIOS
Norme ISO 27002
Chapitre 5 – Politique de Sécurité
• Une structure pyramidale au service de la communication des règles et principes de
sécurité
Document fondateur d’une 15aine de pages
rappelant les grands principes de Sécurité
Dirigeants
PGSI
Documents fondateurs opérationnels à
destination de tous les collaborateurs
PSSI
Chartes PSSI : toute la DSI
Chartes : tout collaborateur
Documents opérationnels de règles
Standards spécifiques à 1 thème (habilitation, patch
management, politique antivirale…)
(Politiques
opérationnelles) Acteurs SSI concernés
Procédures opérationnelles décrivant les

Procédures de sécurité actions et gestes à réaliser (création d’un
compte utilisateur, procédure de
sauvegarde…)
132
EBIOS
Norme ISO 27002
Chapitre 6 – Organisation de la Sécurité
• 6.1 Organisation interne
• 6.1.1 - Fonctions et responsabilités liées à la sécurité de l’information
• 6.1.2 - Séparation des tâches
• 6.1.3 - Relations avec les autorités
• 6.1.4 - Relations avec des groupes de travail spécialisés
• 6.1.5 - La sécurité de l’information dans la gestion de projet
• Points clefs
• Se focalise sur l’implication de la direction au sein du cycle PDCA
• Décrit toute l’organisation permettant la gestion de la sécurité
• Introduit les relations avec des experts externes à l’organisation
• 6.2 - Appareils mobiles et télétravail
• 6.2.1 - Politique en matière d’appareils mobiles
• 6.2.2 - Télétravail
133
EBIOS
Norme ISO 27002
Chapitre 7 – Sécurité liée aux RH
• 7.1 - Avant L'embauche
• 7.1.1 - Sélection des candidats
• 7.1.2 - Termes et conditions d’embauche
• 7.2 - Pendant la durée du contrat
• 7.2.1 - Responsabilités de la direction
• 7.2.2 - Sensibilisation, apprentissage et formation à la sécurité de l’information
• 7.2.3 - Processus disciplinaire
• 7.3 - Rupture, terme ou modification du contrat de travail
• 7.3.1 - Achèvement ou modification des responsabilités associées au contrat de travail
• Points clefs
• Mentionne les responsabilités en matière de sécurité avant, pendant et après l’embauche
134
EBIOS
Norme ISO 27002
Chapitre 8 – Gestion des actifs
• 8.1.1 - Inventaire des actifs
• 8.1.2 - Propriété des actifs
• 8.1.3 - Utilisation correcte des actifs
• 8.1.4 - Restitution des actifs
• 8.2 - Classification de l'information
• 8.2.1 - Classification des informations
• 8.2.2 - Marquage des informations
• 8.2.3 - Manipulation des actifs
• 8.3 - Manipulation des supports
• 8.3.1 - Gestion des supports amovibles
• 8.3.2 - Mise au rebut des supports
• 8.3.3 - Transfert physique des supports
135
EBIOS
Norme ISO 27002
Chapitre 8 – Classification des actifs
• Quels actifs sont à classifier ?
• Les applications et services SI
• Importance de l’attribution d’un propriétaire métier
• Selon les 4 critères de sécurité : Disponibilité, Intégrité, Confidentialité,
Preuve
• Définition de la notion d’applications critiques/sensibles :
• Moyenne de 15 à 20% d’applications critiques en nombre :
classification correcte
• Ajout de critères de classification supplémentaires : RTO/RPO
(DIMA/PDMA)
• Les actifs de support
• Héritage de la classification des applications et services SI qu’ils
supportent 136
EBIOS
Norme ISO 27002
• Quels actifs sont à classifier ?

• Les données
• Souvent difficile à définir et à typer
• Approche plus simple par les applications : héritage de la cotation DICP
• Les critères les plus pertinents sont Intégrité (disponibilité de la
donnée) et Confidentialité
• D’autres classifications supplémentaires sont souvent définies : données
à caractère personnel, RPO (PDMA)…
• Autres classifications possibles
• Compétences, personnes (RH)
• Sites, bâtiments
• Tiers externes… 137
EBIOS
Norme ISO 27002
• Et vous ?
• Sauriez-vous dire quelles sont les 10 applications les plus critiques
de votre organisation ?
• Sauriez-vous lister les données les plus sensibles au sein de votre

organisation ?
138
EBIOS
Norme ISO 27002
Chapitre 9 – Contrôle des accès
• 9.1 - Exigences métiers en matière de contrôle d’accès
• 9.1.1 - Politique de contrôle d’accès
• 9.1.2- Accès aux réseaux et aux services réseau
• 9.2 - Gestion de l'accès utilisateur
• 9.2.1 - Enregistrement et désinscription des utilisateurs
• 9.2.2 - Distribution des accès aux utilisateurs
• 9.2.3 - Gestion des droits d’accès à privilèges
• 9.2.4 - Gestion des informations secrètes d’authentification des utilisateurs
• 9.2.5 - Revue des droits d'accès utilisateurs
• 9.2.6 - Suppression ou adaptation des droits d’accès
• 9.3 - Responsabilités des utilisateurs
• 9.3.1 - Utilisation d’informations secrètes d’authentification
• Points clefs
• Focus sur la formalisation des procédures d’habilitation
• Protection de l’accès des utilisateurs mis en avant 139
EBIOS
Norme ISO 27002
Chapitre 9 – Contrôle des accès
• 9.4 - Contrôle de l’accès au système et à l’information

• 9.4.1 - Restriction d'accès à l'information
• 9.4.2 - Sécuriser les procédures de connexion
• 9.4.3 - Système de gestion des mots de passe
• 9.4.4 - Utilisation de programmes utilitaires à privilèges
• 9.4.5 - Contrôle d'accès au code source des programmes
• Points clefs
• Protection des accès au Système d’information (poste, application et serveur)
• Importance du cloisonnement des réseaux et des règles de filtrage entre les zones de
confiance
140
EBIOS
Norme ISO 27002
Chapitre 10 – Cryptographie
• 10.1 - Mesures cryptographiques

• 10.1.1 - Politique d'utilisation des mesures cryptographiques
• 10.1.2 - Gestion des clefs
• Points clefs
• Gestion de la PKI et des clefs de chiffrement
• Importance de la cryptographie pour les données/transactions les plus sensibles
141
EBIOS
Norme ISO 27002
Chapitre 11 – Sécurité physique et environnementale
• 11.1 - Zones sécurisées

• 11.1.1 - Périmètre de sécurité physique
• 11.1.2 - Contrôle d’accès physique
• 11.1.3 - Sécurisation des bureaux, des salles et des équipements
• 11.1.4 - Protection contre les menaces extérieures et environnementales
• 11.1.5 - Travail dans les zones sécurisées
• 11.1.6 - Zones de livraison et de chargement
• Points clefs
• Décrit le « zonage » des bureaux et des locaux informatiques
• Cela inclut notamment les zones d’accès public, de livraison et de chargement
• Appuie des normes de sécurité physique (classification Tiers, norme TIA 942, NFPA75…)
• «Il ne sert à rien de mettre une porte blindée sur un mur en carton»
142
EBIOS
Norme ISO 27002
Chapitre 11 – Sécurité physique et environnementale
• 11.2 - Matériels
• 11.2.1 - Emplacement et protection des matériels
• 11.2.2 - Services généraux
• 11.2.3 - Sécurité du câblage
• 11.2.4 - Maintenance des matériels
• 11.2.5 - Sortie des actifs
• 11.2.6 - Sécurité des matériels et des actifs hors des locaux
• 11.2.7 - Mise au rebut ou recyclage sécurisé(e) des matériels
• 11.2.8 - Matériels utilisateur laissés sans surveillance
• 11.2.9 - Politique de bureau propre et de l'écran verrouillé
• Points clefs
• La protection physique du matériel est nécessaire pour réduire les risques d’accès non
autorisé à l’information et se prémunir contre la perte et les dommages
• Cela inclut la fin de vie des matériels et les sorties de matériels (pour maintenance par
exemple)
143
EBIOS
Norme ISO 27002
Chapitre 12 – Sécurité de l’exploitation
• 12.1 - Procédures et responsabilités liées à l'exploitation

• 12.1.1 - Procédures d'exploitation documentées
• 12.1.2 - Gestion des changements
• 12.1.3 - Dimensionnement
• 12.1.4 - Séparation des environnements de développement, de test et d’exploitation
• Points clefs
• Importance de la séparation des tâches
• Importance du cloisonnement des environnements
144
EBIOS
Norme ISO 27002
• 12.2 - Protection contre les logiciels malveillants
• 12.2.1 - Mesures contre les logiciels malveillants
• 12.3 - Sauvegarde
• 12.3.1 - Sauvegarde des informations
• 12.4 - Journalisation et surveillance
• 12.4.1 - Journalisation des événements
• 12.4.2 - Protection de l’information journalisée
• 12.4.3 - Journaux administrateur et opérateur
• 12.4.4 - Synchronisation des horloges
• 12.5 - Maîtrise des logiciels en exploitation
• Points clefs
• Disponibilité et fiabilité des matériels et des systèmes sont à prendre en compte
• Importance de la sauvegarde et de la protection antivirale
145
EBIOS
Norme ISO 27002
• 12.6 - Gestion des vulnérabilités techniques
• 12.6.1 - Gestion des vulnérabilités techniques
• 12.6.2 - Restrictions liées à l’installation de logiciels
• 12.7 - Considérations sur l’audit des systèmes d’information
• 12.7.1 - Mesures relatives à l’audit des systèmes d’information
• Points clefs
• Contrôle du système d’information par la mise en place de contrôle et d’un suivi des
audits
146
EBIOS
Norme ISO 27002
Chapitre 13– Sécurité des communications
• 13.1 - Gestion de la sécurité des réseaux
• 13.1.1 - Contrôle des réseaux
• 13.1.2 - Sécurité des services de réseau
• 13.1.3 - Cloisonnement des réseaux
• 13.2 - Transfert de l’information
• 13.2.1 - Politiques et procédures de transfert de l’information
• 13.2.2 - Accords en matière de transfert d’information
• 13.2.3 - Messagerie électronique
• 23.2.4 - Engagements de confidentialité ou de non-divulgation
• Points clefs
• Sécurisation des accès externes et interne du SI.
• Contrôle des échanges de l’information.
147
EBIOS
Norme ISO 27002
Chapitre 14 – Acquisition, Développement et Maintenance des SI
• 14.1 - Exigences de sécurité applicables aux systèmes d’information
• 14.1.1 - Analyse et spécification des exigences de sécurité de l’information
• 14.1.2 - Sécurisation des services d’application sur les réseaux publics
• 14.1.3 - Protection des transactions liées aux services d’application
• 14.2 - Sécurité en matière de développement et d'assistance technique
• 14.2.1 - Politique de développement sécurisé
• 14.2.2 - Procédures de contrôle des changements de système
• 14.2.3 - Revue technique des applications après changement apporté à la plateforme d’exploitation
• 14.2.4 - Restrictions relatives aux changements apportés aux progiciels
• 14.2.5 - Principes d’ingénierie de la sécurité des systèmes
• 14.2.6 - Environnement de développement sécurisé
• 14.2.7 - Développement externalisé
• 14.2.8 - Test de la sécurité du système
• 14.2.9 - Test de conformité du système
• 14.3 - Données de test
• 14.3.1 - Protection des données de test
148
EBIOS
Norme ISO 27002
Chapitre 15 – Relations avec les fournisseurs
• 15.1 - Sécurité dans les relations avec les fournisseurs
• 15.1.1 - Politique de sécurité de l’information dans les relations avec les fournisseurs
• 15.1.2 - La sécurité dans les accords conclus avec les fournisseurs
• 15.1.3 - Chaîne d’approvisionnement des produits et des services informatiques
• A15.2 - Gestion de la prestation du service
• 15.2.1 - Surveillance et revue des services des fournisseurs
• 15.2.2 - Gestion des changements apportés dans les services des fournisseurs
• Points clefs
• Gestion des tiers au niveau des contrats, du suivi et du contrôle
149
EBIOS
Norme ISO 27002
Chapitre 16 – Gestion des incidents liés à la sécurité de l’information
• 16.1 - Gestion des incidents liés à la sécurité de l’information et améliorations
• 16.1.1 - Responsabilités et procédures
• 16.1.2 - Signalement des événements liés à la sécurité de l’information
• 16.1.3 - Signalement des failles liées à la sécurité de l’information
• 16.1.4 - Appréciation des événements liés à la sécurité de l’information et prise de
décision
• 16.1.5 - Réponse aux incidents liés à la sécurité de l’information
• 16.1.6 - Tirer des enseignements des incidents liés à la sécurité de l’information
• 16.1.7 - Collecte de preuves
• Points clefs
• On prend en compte uniquement les incidents de sécurité ➔ Une bonne définition de ce
qu’est un incident de sécurité est à réaliser !
150
EBIOS
Norme ISO 27002
Chapitre 16 – Gestion des incidents lie à la sécurité de l’information
• Se base généralement sur le processus existant de gestion des incidents IT
• S’intègre dans les processus ITIL
Traitement
Traitement Traitement
Niveau 3 /
Niveau 1 Niveau 2
Gestion de Crise
Déclaration Prise en compte Résolution Bilan / Cloture
• Norme ISO 27035 : Security Incident Management

151
EBIOS
Norme ISO 27002
Chapitre 16 – Gestion des incidents lie à la sécurité de l’information
• Limites et difficultés
• Difficulté dans la définition d’un incident de sécurité
• Lorsque le processus reste interne, tout va bien en général
• Dès qu’un prestataire ou un tiers externe intervient, les contraintes contractuelles doivent
jouer à plein
• Négligence d’une traçabilité des incidents très graves (pas de bilan ou de formalisation d’une
fiche incident)
• Facteurs clefs de succès
• Un processus de gestion des incidents généralement bien implémenté et outillé
• Traiter les incidents majeurs au sein d’un processus de gestion de crise spécifique
• Définir des indicateurs de mesure de l’efficacité du processus de gestion des incidents (temps
de résolution, temps de prise en compte, taux d’incidents résolus « à temps », etc.)
152
EBIOS
Norme ISO 27002
Chapitre 17 – Sécurité de l’information dans la gestion de la Continuité d’Activités
• 17.1 - Continuité de la sécurité de l'information
• 17.1.2 - Organisation de la continuité de la sécurité de l’information
• 17.1.2 - Mise en œuvre de la continuité de la sécurité de l’information
• 17.1.3 - Vérifier, revoir et évaluer la continuité de la sécurité de l’information
• 17.2 - Redondance
• 17.2.1 - Disponibilité des moyens de traitement de l’information
• Points clefs
• La norme traite de la continuité de la sécurité de l’information et non de la continuité
business (ISO 22301)
• Mise en œuvre de la redondance des composants
153
EBIOS
Norme ISO 27002
Chapitre 18 – Conformité
• 18.1 - Conformité aux obligations légales et réglementaires
• 18.1.1 - Identification de la législation et des exigences contractuelles applicables
• 18.1.2 - Droits de propriété intellectuelle
• 18.1.3 - Protection des enregistrements
• 18.1.4 - Protection de la vie privée et protection des données à caractère personnel
• 18.1.5 - Réglementation relative aux mesures cryptographiques
• 18.2 - Revue de la sécurité de l’information
• 18.2.1 - Revue indépendante de la sécurité de l’information
• 18.2.2 - Conformité avec les politiques et les normes de sécurité
• 18.2.3 - Vérification de la conformité technique
• Points clefs
• Correspondant CNIL & Prise en compte de la législation
• Contrôle permanent
154
EBIOS
Avantages et inconvénients
d’EBIOS
155
EBIOS
Avantages d’EBIOS
• Une méthode claire: elle définit clairement les acteurs, leurs rôles et
les interactions
• Une approche exhaustive: contrairement aux approches d’analyse
des risques par scénarios, la démarche structurée de la méthode EBIOS
permet d’identifier les éléments constitutifs des risques
• Une démarche adaptative: la méthode EBIOS peut être adaptée au
contexte de chacun et ajustée à ses outils et habitudes
méthodologiques grâce à une certaine flexibilité
156
EBIOS
Inconvénients d’EBIOS
• La méthode EBIOS ne fournit pas de
recommandations ni de solutions immédiates aux
problèmes de sécurité.
• Il n'y a pas d’audit et d'évaluation de la méthode.
157
EBIOS
Ce qu’il faut retenir
158
EBIOS
Pourquoi gérer les risques
Pour savoir ce qu’il faut protéger…
• Identifier les biens essentiels (« Assets »)
✓ Notion d’évènements redoutés / classification d’actifs
De qui/quoi?
• Identifier les menaces et vulnérabilités
Dans quel but?

• Proposer une stratégie de défense appropriée
✓ Prioriser les actions à mener en fonction de la criticité des risques
✓ Adapter les moyens et leur niveau de robustesse en fonction des
menaces 159
EBIOS
Gestion des risques - Questions
160

3 - EBIOS Analyse de Rique Cours

Transféré par

Informations du document

Titre original

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

3 - EBIOS Analyse de Rique Cours

Transféré par

Droits d'auteur :

Formats disponibles

EBIOS

Introduction à la méthode EBIOS

• Un risque n’est donc pas:

Gravité / niveau d’impact Vraisemblance / Probabilité

▪ Le facteur probabilité ne doit pas être écarté.

❑Vulnérabilité: La faiblesse d’un actif ou d’une mesure qui

Les vulnérabilités intrinsèques : elles sont relatives aux

❑Menace: Cause potentielle d’un incident indésirable qui peut

Par définition, une menace est la cause potentielle d’un incident

❑La possibilité qu’une menace donnée exploite les

Il est mesuré en termes d’une combinaison de la

▪ Disponibilité: Assurer que le système d’information est en toute

• Facteur de risque : Route sinueuse, voiture

• Ce que je crains: « Le defacing de ma page d’accueil »

Un risque est composé de divers paramètres:

• La notion d’évènement redouté (« ce que je crains »)

• La notion de source de menaces

• Vulnérabilité ou absence de mesure

Un évènement redouté combine:

Un scénario de menace combine:

• Source de menace: un adolescent de 15 ans agissant

• l’appréciation du risque Appréciation du risque

Surveillance et réexamen du risque

▪ Peut s’appliquer : Estimation du risque

• à un secteur d’activité Évaluation du risque

• une application… Traitement du risque

▪ La granularité des éléments pris en Traitement du risque

compte est importante : Traitement du risque

• trop fine elle va complexifier l’étude oui

▪ Responsable = Responsables du périmètre de l'étude

Trois activités principales:

- Différentes catégories de biens essentiels

D’où la nécessité de définir différents critères afin de prendre en

Principales questions à se poser

✓ Quelle est la définition de chacun des critères retenus?

Critères de sécurité retenus pour l’étude

▪ Pour chaque critère retenu, définir les échelles

Echelle en termes de disponibilité

Echelle en termes de confidentialité

Activité 1.2- Les métriques à préparer

Echelle de niveaux de gravité / impact

Activité 1.2- Les métriques à préparer

Echelle de niveaux de vraisemblance

Echelle pour estimer la vraisemblance des scénarios de menaces et des risques

Niveaux de l'échelle Description détaillée de l'échelle

Activité 1.2- Les métriques à préparer

• Critères de gestion des risques

Activité 1.2- Les métriques à préparer

Critères de gestion des risques

▪les systèmes informatiques et de téléphonie (SYS), qui peuvent être décomposés en :

• Activité 2: Apprécier les

Exemple concret: données d’un SIRH

• Evènement redouté: « Compromission des fiches de paie »

❑ Autres éléments redoutés possibles pour ce bien: « Altération

Exemple de tableau d’évènements redoutés

Chaque ligne du tableau suivant représente un événement redouté par

• Activité 3: Apprécier les

Un scénario de menace est composé:

• Activité 4.1: Apprécier les

Mettre en évidence et de caractériser les risques réels pesant

Pour chaque bien essentiel :

Exemple: Risque lié à l'indisponibilité d'un devis au-delà de

Nouvelle vraisemblance en tenant compte