CLUSIF 2011 Guide Developpement Base

METHODES
MEHARI 2010
Guide de dveloppement
dune base de connaissances
danalyse de risque MEHARI
Mars 2012
Espace Mthodes
CLUB DE LA SECURITE DE LINFORMATION FRANAIS

11, rue de Mogador 75009 PARIS
Tel : 01 53 25 08 80 Fax : 01 53 08 81
clusif@clusif.asso.fr - http://www.clusif.asso.fr
MEHARI est une marque dpose par le CLUSIF.

La loi du 11 mars 1957 n'autorisant, aux termes des alinas 2 et 3 de l'article 41, d'une part, que les "copies ou reproductions
strictement rserves l'usage priv du copiste et non destines une utilisation collective" et, d'autre part, que les analyses
et les courtes citations dans un but d'exemple et d'illustration, "toute reprsentation ou reproduction intgrale, ou partielle,
faite sans le consentement de l'auteur ou de ayants droit ou ayants cause est illicite" (alina 1er de l'article 40)
Cette reprsentation ou reproduction, par quelque procd que ce soit, constituerait donc une contrefaon sanctionne par les
articles 425 et suivants du Code Pnal
Remerciements
Le CLUSIF tient mettre ici l'honneur les personnes qui ont rendu possible la ralisation de ce
document, tout particulirement :
Le responsable du groupe de travail :
Jean-Philippe JOUAS
Les contributeurs
Dominique
BUC
BUC SA
Olivier
CORBIER
Docapost
Martine
GAGNE
HydroQubec
Chantale
PINEAULT
AGRM
Jean-Louis
ROULE
Claude
TAILLON
Ministre de l'ducation, du Loisir et du Sport du Qubec
Marc
TOUBOUL
BULL SA
Annabelle
TRAVERSVIAUD
BULL SA
Ainsi que les membres du comit de relecture.
Guide de dveloppement dune

base de connaissance
3/32
CLUSIF 2012
Sommaire
Introduction .................................................................................................................................................. 5
1.
Objectif de ce document .................................................................................................................. 6
Plan du document................................................................................................................................... 6
2.
Principes fondamentaux ................................................................................................................... 7
Principe de prcaution............................................................................................................................ 7
Principe de justification.......................................................................................................................... 8
3.
Dfinir la typologie des actifs .......................................................................................................... 9
Introduction............................................................................................................................................. 9
Paramtres cls pour la dfinition des typologies dactifs...............................................................10
Typologies dactifs primaires.............................................................................................................10
Typologie dactifs secondaires ..........................................................................................................12
4.
Dfinir la typologie des vulnrabilits ..........................................................................................14
5.
Dfinir la typologie des menaces...................................................................................................17
Typologie dvnements dclencheurs ..............................................................................................17

Typologies de conditions de survenance...........................................................................................20
Typologie dacteurs...............................................................................................................................20
Description de la menace dans la base de connaissance .................................................................21
6.
Construire la base de scnarios (liste de scnarios et lments descriptifs) ............................22
7.
Dfinir les services de scurit.......................................................................................................23
Dfinir des services de scurit en accord avec la typologie dactifs.............................................23

Dfinir des services de scurit en accord avec les typologies de vulnrabilits et de menaces24
Dfinir des services de scurit diffrents ou travailler avec des variantes dun mme service 25
8.
Lvaluation de la qualit des services de scurit et llaboration des questionnaires de
diagnostic.....................................................................................................................................................26
Considrations gnrales......................................................................................................................26
Questionnaires dvaluation de la qualit de service........................................................................26
9.
Construire la base de connaissance des scnarios.......................................................................28
Services appels dans les formules de calcul des STATUS.............................................................28
Pertinence de lvaluation des services pour les scnarios qui lappellent .................28
Pertinence dun service pour rduire limpact intrinsque ...........................................28
Pertinence dun service pour rduire la potentialit......................................................29
Traitement des scnarios datteinte lintgrit................................................................................30
10. Finaliser la base de connaissance MEHARI ...................................................................................31
11.
Conseils de mise en oeuvre ............................................................................................................31

4/32
CLUSIF 2012
Introduction
Les principes fondamentaux dune mthode danalyse et de traitement des risques et ses
spcifications fonctionnelles ont t dvelopps dans un document du Clusif relatif la mthode
MEHARI ( MEHARI 2010 - Principes fondamentaux et spcifications fonctionnelles ) et ce
document met en avant la ncessit dune base de connaissances en support de la mthode.
Le schma gnral qui ressort des principes de traitement est repris ci-dessous.
Processus danalyse et
de traitement des risques
Processus dlaboration
Analyse
des besoins
Actifs
Dommages
Analyse des
enjeux :
classification
Analyse des
menaces
Risques
Exposition
aux menaces
Facteurs de
rduction des risques
Base
de scnarios
Audit
des services
de scurit
Base
daudit
Analyse des actifs :

Vulnrabilits
Audit des
Services
de scurit
Apprciation
des risques
Plan de traitement
des risques
Ce schma met en vidence que le processus didentification, danalyse et de traitement des

risques comprend une srie de phases qui peuvent tre ralises au profit dentits diverses et
partages sous la forme dune base de connaissances.
Cest sur ce principe qua t dveloppe la base de connaissances de MEHARI, et,
particulirement, la base MEHARI 2010.
Ceci tant, dautres bases peuvent tre dveloppes pour tre adaptes des environnements ou
des contextes particuliers tel que le traitement de risques lis des informatiques de conduite de
processus industriels (conduite doprations industrielles, surveillances de processus dangereux,
etc.), des entreprises prsentant des particularits telles que des PME, voire des TPE (trs
petites entreprises), des secteurs dactivits spcifiques ou des technologies oprationnelles
comme les SCADA (Supervisory Control And Data Acquisition).

5/32
CLUSIF 2012
1. Objectif de ce document
Ce document est tabli lusage des organisations qui souhaitent dvelopper de nouvelles bases
de connaissances ou adapter les bases du Clusif des contextes ou environnements particuliers.
Les raisons dun tel dveloppement ou dune telle adaptation peuvent tre nombreuses. Citons,
par exemple, lutilisation de la mthode pour lanalyse et la gestion dautres risques que ceux lis
au systme dinformation, son utilisation pour des systmes informatiques spcifiques tels que la
conduite de processus industriels, lexistence de menaces particulires, etc.
A qui sadresse ce document ?

Le dveloppement dune base de connaissance Mhari, qui est le sujet de ce document, ne peut
tre abord sans une trs solide connaissance de la mthode. Ce document sadresse des experts
de la mthode ou, tout le moins, des utilisateurs trs confirms.
Une trs bonne connaissance des principes de la mthode ainsi que de lutilisation de la base de
connaissance fournie par le CLUSIF est suppose acquise.
Plan du document
Le plan densemble et les diffrents aspects abords sont reprsents schmatiquement cidessous.
Base de connaissances
Processus dlaboration
Analyse des besoins :
services
donnes
processus de gestion
Analyse des actifs :

actifs secondaires
Vulnrabilits
intrinsques
Quels
actifs
primaires ?
Liste et typologie dactifs primaires
Quels dommages
potentiels ?
Typologie dactifs secondaires

Liste et typologie de vulnrabilits
Analyse des menaces :

vnements dclencheurs
acteurs
conditions de survenance
Quelles menaces ?
Typologies de menaces
Liste de scnarios de risques
Analyse des facteurs de

rduction des risques possibles :
services de scurit pertinents
effets des services de scurit
Quels services
de scurit pour
rduire les risques ?
Base de services de scurit

Base de scnarios de risques avec rfrences des
services et pondration des effets
Analyse des services de scurit

facteurs de qualit
Quelles mesures
conditionnent
lefficacit des
services ?
Base de questionnaires dvaluation

de la qualit des services de scurit

6/32
CLUSIF 2012
Nous aborderons donc successivement :

Quels actifs ?
Quelles vulnrabilits ?
Quelles menaces ?
Quels scnarios ?
Quels services de scurit ?
Lvaluation de la qualit des services de scurit et llaboration des questionnaires de
diagnostic
Llaboration de la base de connaissance des scnarios
La finalisation de la base de connaissance globale
2. Principes fondamentaux
Deux principes fondamentaux doivent tre rappels en priorit avant tout dveloppement dune
base de connaissance.
Principe de prcaution
Mehari est essentiellement une mthode de gestion de la scurit par lanalyse des risques, mme
si, au sein de MEHARI, certains modules peuvent tre utiliss dans dautres buts que lanalyse de
risque. Il sensuit que lobjectif fondamental de lensemble des modules ou versions de MEHARI
est de grer les risques les plus importants.
Le principe de prcaution qui en dcoule est le suivant :
Principe n 1
Les automatismes ou aides contenus dans les bases de connaissance de la mthode ne
doivent jamais conduire sous-valuer un risque. Il est toujours prfrable quun risque
soit survalu au dpart quitte tre revu la baisse lors dune analyse dtaille plutt que
sous-valu et non slectionn pour une analyse plus fine.
Cest un principe de prcaution qui consiste prendre les mesures ncessaires pour viter que des
automatismes de calcul ne considrent un scnario de risque comme peu grave et lliminent
dune slection, alors quil est dun niveau de gravit lev. Il peut y avoir plusieurs raisons qui
fassent que les automatismes sous-valuent la gravit dun scnario :
Lappel abusif, dans les formules des scnarios, des services de scurit qui, en fait,
ne jouent quun rle marginal pour le scnario.
La survaluation de la qualit des services de scurit, en gnral ou plus

particulirement pour un scnario donn.
Des grilles de dcision mal conues, mal valides ou inadaptes au contexte

7/32
CLUSIF 2012
Principe de justification
A contrario, une mthode qui survaluerait systmatiquement le niveau de gravit des scnarios
de risque et dont le rsultat ne saurait tre expliqu, voire justifi, serait d'une utilit bien faible.
Il dcoule de cette ncessit que les automatismes de la mthode doivent produire, dans la
majorit des cas, une valuation explicable et justifiable du niveau de risque.
En ce qui concerne limpact, la base de lvaluation est la classification des ressources touches
par le scnario et cest donc un lment raisonn et valu trs rigoureusement et en connaissance
de cause, par les utilisateurs eux-mmes. Partant de l, il faut et il suffit que tous les lments de
rduction dimpact soient pris en compte, sous rserve que lon puisse garantir leur efficacit dans
la situation considre (principe de prcaution).
En ce qui concerne la potentialit, il y a un risque de la survaluer, en particulier en labsence de
services efficaces, et de dcrter un scnario de risque comme trs probable alors que chacun sait,
en particulier les utilisateurs, que ce risque ne sest jamais ou que trs rarement concrtis.
Le principe de justification qui dcoule de ce constat est le suivant :
Principe n 2
Les automatismes de la mthode doivent, dans tous les cas, permettre dexpliquer et de
justifier les rsultats obtenus
Ces deux principes servent de fil directeur dans les chapitres suivants.

8/32
CLUSIF 2012
3. Dfinir la typologie des actifs

Introduction
Nous rappelons, ci-dessous, ce qui a t dit des actifs dans le document Principes
fondamentaux et spcifications fonctionnelles de MEHARI .
Les actifs sont le sujet principal du risque : ce sont eux qui vont subir un dommage et le risque
nat bien du fait quune certaine forme dactif est susceptible de subir un dommage.
Il est bien clair, ds lors, que les consquences et que la gravit de la survenance du risque
dpendent de la nature de ces actifs et donc que cette nature (voir ci-dessous) doit faire partie de la
caractrisation du risque.
Mode de description des actifs

a. Les actifs primaires
La description des actifs devant servir valuer les consquences des risques auxquels ils sont
exposs, les lments cls doivent se rfrer aux besoins des organisations que lon peut, dans un
premier temps, classer dans trois catgories :
Les services (fonctionnels),
Les donnes,
Les processus de management.

Cette dcomposition parait la plus apte mettre en vidence les besoins essentiels dune
organisation dont le fonctionnement est essentiellement bas sur la ralisation de services qui,
eux-mmes ont besoin de donnes et tout ceci tout en respectant un ensemble de rgles, crites
ou non, concrtises par des processus de management.
Cette dcomposition, ne de lexprience, est fortement recommande mais ne saurait constituer
une contrainte.
Dans chaque catgorie, des types dactifs primaires peuvent tre distingus, en fonction :
De la nature des besoins,
De la nature des prestataires de service.

Et ventuellement :
Du domaine dactivit et de domaines de responsabilit diffrents,
De la technologie employe,
Des utilisateurs concerns.

Ces typologies doivent correspondre des types de besoins et tre dcrites au niveau fonctionnel.
Remarque : Les actifs primaires correspondent aux besoins des organisations et cest donc ce
niveau quil conviendra dvaluer limportance de ce besoin, importance dont il sera tenu compte
pour juger du niveau de risque, par lintermdiaire dune classification des actifs (reprsente dans
la base de connaissances par le tableau dimpact intrinsque ).
b. Les actifs secondaires ou actifs de support

Les actifs ont des vulnrabilits et ce sont elles dont lexploitation conduit au risque.

9/32
CLUSIF 2012
Pour rechercher ces vulnrabilits, il est essentiel de distinguer, pour chaque actif
primaire :
les diverses formes quil peut revtir,
les diverses contingences dont il peut dpendre.

Ces formes et contingences peuvent tre regroupes sous lappellation dactifs secondaires ou
dactifs de support.
Autant les actifs primaires correspondent des besoins fonctionnels, autant les actifs secondaires
correspondent un niveau matriel et concret et aux moyens ncessaires la ralisation des
besoins fonctionnels.
Paramtres cls pour la dfinition des typologies dactifs

Il ressort des dfinitions et considrations ci-dessus quun point essentiel dans le
dveloppement dune base de connaissances rside dans la dfinition des types dactifs
primaires que lon souhaite distinguer et dans lexpression des actifs secondaires et des
vulnrabilits associes.
Typologies dactifs primaires

En ce qui concerne les actifs primaires, le choix principal rside dans le degr de dtail avec lequel
on souhaite les prciser ou les distinguer.
A titre dexemple, on peut se contenter de considrer les services informatiques, au sens large, ou
souhaiter distinguer les services applicatifs, les services bureautiques, les services systmes
communs, etc. De mme on peut se contenter de considrer les donnes informatiques ou
distinguer les donnes applicatives, les donnes bureautiques, les archives informatiques, etc.
La question est alors : quelles sont les raisons qui pourraient inciter distinguer des types
dactifs primaires les uns des autres ou au contraire les regrouper dans une mme catgorie ? .
Les raisons possibles sont les suivantes :
Distinguer des actifs pouvant avoir des sensibilits notablement diffrentes (et donc
conduire des scnarios de risque de gravits diffrentes).
Distinguer des actifs primaires ayant des actifs secondaires diffrents (en fonction de
formes possibles de ces actifs ou de contingences possibles), donc des vulnrabilits
diffrentes et conduisant des scnarios diffrents.
Distinguer des actifs protgs par des services de scurit diffrents.

Nous allons revenir sur chacun de ces points.
Distinguer des actifs de sensibilits diffrentes

Cela peut sembler une bonne ide que de distinguer des actifs primaires ayant des sensibilits
notablement diffrentes. Cest pour traiter ce point dailleurs quavait t introduite la
dcomposition cartographique en 2007.
Cela permet, il est vrai, davoir des scnarios bien reprsentatifs de types dactivit et donc bien
adapts une communication ddie par secteur dactivit.
Il reste que cela revient crer des variantes de scnarios ne diffrant que par le degr de
sensibilit des actifs et que cela va crer une surcharge de travail au niveau de lanalyse des
scnarios, charge qui aurait pu tre reporte au niveau du dploiement des mesures de scurit, ce
qui est sans doute plus efficace. En effet, cest au niveau du dploiement que lon pourra faire des
10/32
CLUSIF 2012
choix conomiques valables en choisissant de ne dployer les mesures dcides que pour les
actifs les plus sensibles ou, au contraire, de gnraliser ces mesures.
Distinguer des actifs en fonction de leur sensibilit est ainsi, peut-tre, un choix de
communication, mais nest pas une ncessit pour lanalyse des risques. Dans loptique
dune simplification des tches danalyse de risques, cette option ne devrait pas tre
retenue.
Distinguer des actifs primaires ayant des actifs secondaires diffrents

Les donnes bureautiques, par exemple, peuvent tre matrialises sous des formes (actifs
secondaires) diffrentes des donnes applicatives (PDA, cls USB, etc. pour les donnes
bureautiques, disques ou bandes pour les donnes applicatives).
Distinguer des actifs primaires ayant des actifs secondaires diffrents permettra effectivement
dtre plus prcis dans la description des actifs secondaires, donc dans la description de leurs
vulnrabilits et donc dans lidentification et la description des risques
La contrepartie quil est bon davoir en tte est que cela na dintrt que si lon est capable de
mettre en face de ces vulnrabilits spcifiques des services de scurit adapts.
On notera ainsi, ce stade, que la multiplication des actifs primaires et secondaires peut conduire
une multiplication des services de scurit1.
Distinguer des actifs primaires ayant des actifs secondaires et donc des vulnrabilits
diffrents permet de mieux mettre en lumire des scnarios de risques diffrencis mais
ncessite, en contrepartie, de crer des services de scurit eux-mmes diffrencis.
Distinguer des actifs primaires protgs par des services de scurit diffrents
Si les services de scurit sont dj dfinis, parce que la base de connaissance des services existe
et que lon ne souhaite pas en changer, pour des raisons de cohrence des diagnostics ou pour
toute autre raison, la question se pose de savoir si la dfinition et la typologie des actifs doivent
tre alignes sur la typologie des services de scurit (si on a dfini des services de scurit
spcifiques pour le rseau tendu intersites et pour le rseau local, faut-il distinguer le service du
rseau tendu de celui du rseau local ?).
Cela est certainement plus cohrent, mais ce nest pas obligatoire.
En effet, les formules qui serviront apprcier les scnarios de risque sont telles quil est toujours
possible dvaluer simultanment plusieurs alternatives ou variantes en ne retenant au final, pour
le calcul, que le rsultat le plus pessimiste. Par exemple pour un scnario dindisponibilit de
rseau, si on spare en tant quactifs le rseau tendu et le rseau local, on valuera distinctement
les scnarios dindisponibilit pour chaque type de rseau, chacun avec ses services spcifiques,
mais dans le cas o ces actifs sont confondus il faudra prendre soin dvaluer chaque facteur de
rduction de risque pour chaque type de rseau et on prendra systmatiquement le minimum de
chaque facteur.
Si on considre un scnario dindisponibilit de rseau d un incendie :
Par exemple, le fait de distinguer les fichiers courants des fichiers darchive conduira
dfinir des services de scurit diffrents pour la protection des documents courants et la
protection des archives. De mme le fait de distinguer les rseaux locaux des rseaux
tendus conduit diffrencier les services de scurit correspondants.

11/32
CLUSIF 2012
dans le cas o les types dactifs sont distincts on valuera 2 scnarios : un scnario
dindisponibilit du rseau tendu d un incendie et un scnario dindisponibilit du
rseau local d un incendie et, pour les mesures palliatives, on considrera, pour le
premier, le PRA du rseau tendu et pour le second le PRA du rseau local.
Dans le cas ou les deux types de rseau sont considrs comme un seul type dactif, on
nvaluera quun scnario : indisponibilit du rseau d un incendie et on
considrera, au titre des mesures palliatives, le minimum entre le PRA du rseau
tendu et celui du rseau local.
Les calculs seront donc possibles que lon ait distingu les types de rseau ou non.
Par contre, il peut y avoir une difficult ou un jugement trop pessimiste si les types dactifs se
rvlent avoir des sensibilits diffrentes. Si le type dactif le moins sensible a des services de
scurit dun niveau de qualit moindre que le type dactif le plus sensible, cela peut conduire, en
regroupant les types dactifs, un jugement plus svre que la stricte ralit, parce que lon
retiendra le niveau le plus bas de service avec le niveau le plus haut de sensibilit.
Distinguer des actifs protgs par des services de scurit diffrents produira un
jugement sur la gravit des scnarios plus prcis et, dans certains cas, moins pessimiste,
mais cette distinction nest pas indispensable une valuation des risques.
En rsum, plus la typologie des actifs primaires sera fine, plus on pourra tre prcis et
exhaustif dans lidentification et lapprciation des risques, avec comme corollaire quil
faudra distinguer davantage de services de scurit, en cohrence avec la typologie des
actifs.
Plus les services de scurit seront dtaills, plus il sera souhaitable, pour une
apprciation des risques, de dtailler les actifs en consquence, mais sans que cela soit
indispensable2.
Typologie dactifs secondaires

Indpendamment des considrations prcdentes relatives la finesse de dfinition des types
dactifs primaires, il convient ensuite de dfinir les actifs secondaires qui seront lorigine de
vulnrabilits. En effet, autant les actifs primaires correspondent des besoins fonctionnels,
autant les actifs secondaires consistent en des objets concrets utiliss par les processus pour
raliser les services demands.
Il ny a pas de dmarche impose pour rechercher les actifs secondaires pertinents pour chaque
actif primaire, mais on peut faire les recommandations suivantes, en fonction du type gnral
dactif primaire :
Pour les actifs de type services (fonctionnels) :

Distinguer :
Les quipements ncessaires la ralisation du service.
Les moyens de servitude ventuellement ncessaires ces quipements (lectricit,

fluides, etc.).
La distinction dactifs diffrencis apportera une plus grande prcision dans lanalyse de
risques (en particulier dans lvaluation des impacts, au prix dun surcrot de travail lors
de lanalyse des risques.

12/32
CLUSIF 2012
Les lments immatriels ayant une influence directe sur le droulement des processus
supports du service (logiciel, automatisme, paramtrage de processus, procdures,
etc.).
Les lments matriels supports des lments immatriels dcrits ci-dessus.
Les lments logistiques ncessaires aux oprations effectues par du personnel

(locaux, climatisation, restauration, transport, etc.).
Le personnel interne charg dassurer les services.
Les services extrieurs ncessaires et non distingus au niveau des actifs primaires.
Pour les actifs de type donnes :

Distinguer :
Les entits logiques rassemblant les donnes (fichiers, bases de donnes, rpertoire,
etc.).
Les donnes isoles.
Les donnes transitoires (messages, contenus dcrans, etc.).
Les supports matriels des entits ci-dessus (media magntiques ou optiques, supports
papiers, etc.).
Pour les actifs de type processus de management :
Pour ces actifs, il ny a pas, proprement parler, dactifs secondaires distinguer. Par
contre ils seront prciss en fonction des domaines de proccupation possibles
(protection de la vie prive, normes comptables, exigences contractuelles, etc.).

13/32
CLUSIF 2012
4. Dfinir la typologie des vulnrabilits

Les vulnrabilits quil convient de rechercher sont les vulnrabilits intrinsques des actifs
secondaires.
La dmarche recommande pour rechercher les vulnrabilits intrinsques pertinentes pour
chaque actif secondaire ressemble beaucoup celle employe dans lanalyse des modes de
dfaillance et consiste systmatiser une recherche correspondant au diagramme ci-dessous :
Analyse des actifs secondaires :
Quels types de dommage chaque
type dactif peut-il subir ?
Typologie de dommages par

type dactif secondaire
Analyse des dommages potentiels

des actifs secondaires :
Quelles sont les causes possibles
intrinsques de ces dommages ?
Vulnrabilits intrinsques
Ainsi, on doit rechercher, pour les trois critres de base, Disponibilit, Intgrit et Confidentialit,
quels sont les types de dommages possibles, ce qui permettra in fine de dfinir la typologie des
vulnrabilits intrinsques.
Cette recherche peut se faire avec un degr de dtails plus ou moins grand et dpend de la finesse
de description des actifs secondaires.
Il faut noter, en effet, quil y a souvent des possibilits de transfert entre types dactifs secondaires
et types de vulnrabilits. On peut, par exemple, pour une configuration logicielle dfinie comme
actif secondaire, mettre en vidence, comme vulnrabilit, linoprabilit due une absence de
licence, mais on peut aussi dtailler davantage en dfinissant comme actif secondaire la licence
ncessaire au fonctionnement de la configuration logicielle et comme vulnrabilit de cette
licence son effacement, sa disparition, etc. Dans un autre domaine, on peut considrer, comme
vulnrabilit dun serveur, quil dpend de la mise disposition dnergie par des organes de
servitude ou, au contraire, dfinir les moyens de servitude comme actifs secondaires et rechercher
les vulnrabilits dtailles de ces moyens.
Il faut noter que le degr de finesse avec lequel le tableau des vulnrabilits types est
dcrit est un facteur cl, au mme titre que la finesse de description des actifs, facteur qui
influe directement sur la prcision, et corrlativement sur la charge, de lanalyse de
risques.
Pour tablir ce tableau, il est recommand de commencer par tablir un tableau danalyse
prliminaire dcrivant par grand type dactif secondaire (sans dtail ce niveau danalyse) et par
type de consquence (DIC) les types de dommages possibles avant de remplir le tableau des
vulnrabilits intrinsques.
Nous donnons ci-dessous, deux tableaux ainsi labors, titre dexemple :
Un premier tableau danalyse ne considrant que les aspects matriels, immatriels ou

de services et cherchant mettre en vidence les types de dommages possibles.
Un deuxime tableau construit partir dune typologie dactifs secondaires et

reprenant les rsultats du tableau danalyse prcdent

14/32
CLUSIF 2012
Tableau danalyse prliminaire des dommages (exemple) :

Tableau d'analyse prliminaire des dommages
Type d'actif secondaire
Type de
consquence
Type de dommage
Commentaire
lment matriel :
Indisponibilit
Endommagement
physique
L'lment est bien l, mais a t endommag ou

dtruit
Inoprabilit
L'lment est bien l, mais on ne peut y accder ou

le faire fonctionner (absence de cl d'accs ou de
dmarrage, de personnel qualifi, d'quipement de
lecture pour un media, etc.)
Inexploitabilit
Les rsultats ou actions de l'lment ou de sa mise

en uvre ne sont pas conformes ou totalement
absents (panne, blocage, rsultats visiblement
altrs, etc.)
L'lment n'est plus l
quipement fonctionnel,
cblage, dispositifs de
scurit, etc.
Media matriel support de
logiciel, d'automatisme, de
paramtres de processus
ou de donnes
Disparition
lment immatriel :
Dfaut d'intgrit
Altration de l'lment L'lment a t modifi (accidentellement ou

volontairement)
change de l'lment L'lment matriel a t chang avec un autre qui
a t modifi
Divulgation
Duplication de
l'lment
Acquisition par un
tiers de l'lment
L'lment a t dupliqu
Endommagement
logique
Inoprabilit
L'lment est bien l, mais a t pollu ou

visiblement altr
L'lment est bien l, mais on ne peut y accder ou
le faire fonctionner (absence de cl d'accs ou
d'autorisation : licence, jeton, etc.)
Inexploitabilit
Les rsultats ou actions de l'lment ou de sa mise

uvre ne sont pas conformes ou totalement
absents (bug, blocage, incompatibilit de formats,
rsultats visiblement altrs, etc.)
Disparition
L'lment a t effac
Indisponibilit
Logiciel, automatisme,
paramtrage de
processus, procdure, etc.
Donnes (fichiers
constitus, donnes
fugitives, etc.)
Dfaut d'intgrit
Divulgation
Service extrieur
Indisponibilit
ncessaire au
fonctionnement des
services internes ou
l'exploitation des donnes

L'lment matriel a t acquis par un tiers (vol,

perte, envoi)
Altration de l'lment L'lment a t modifi (accidentellement ou

volontairement)
Copie de l'lment
L'lment a t copi
Acquisition par un
tiers de l'lment
L'lment immatriel a t acquis par un tiers (envoi

direct erron ou volontairement fauss)
Inoprabilit
Le service est bien prsent, mais on ne peut y

accder ou le faire fonctionner (absence de moyen
de communication, service volontairement inactif,
absence de contrat ou de support administratif,
mise en oeuvre du service impossible pour des
raisons internes ou externes, etc.)
Inexploitabilit
Les rsultats ou actions de la mise uvre du

service ne sont pas conformes ou totalement
absents (incapacit technique, incompatibilit de
dlais, rsultats visiblement incomplets, etc.)
Disparition
Le service n'existe plus ou n'est dfinitivement plus

assur.
15/32
CLUSIF 2012
Tableau des vulnrabilits intrinsques :

Tableau des vulnrabilits intrinsques gnriques
Type d'actif secondaire
Type de
consq.
DIC
Type de
dommage
Type de vulnrabilit
Endommagement
Possibilit d'endommagement ou de destruction d'un quipement
Inoprabilit
Possibilit d'incapacit mettre ou maintenir l'quipement en service
Inexploitabilit
Possibilit de non fonctionnement ou de fonctionnement incorrect d'un quipement
Disparition
Possibilit de disparition d'un quipement
Altration
Possibilit de modification matrielle d'un quipement
change
Possibilit qu'un quipement soit chang avec un quipement modifi
Endommagement
Possibilit d'endommagement gnral ou de destruction totale des locaux ncessaires au

service
Inoprabilit
Possibilit qu'il soit impossible ou interdit d'accder aux locaux
Endommagement
Possibilit d'endommagement gnral ou de destruction totale des moyens de servitude

ncessaires au service
Inoprabilit
Possibilit d'incapacit mettre ou maintenir en service les moyens de servitude
Endommagement
logique
Possibilit d'endommagement de configurations immatrielles
Inoprabilit
Possibilit de blocage d'un processus par dfaut d'autorisation
Inexploitabilit
Possibilit de non fonctionnement intrinsque d'un logiciel, d'un automatisme ou d'un

processus (bug, dysfonctionnement majeur, erreurs rcurrentes, etc.)
Disparition
Possibilit d'effacement de configurations immatrielles
Altration
Possibilit d'altration des configurations immatrielles supports de processus
Divulgation
Possibilit de diffusion de configuration
Blocage
Possibilit de blocage des comptes utilisateurs
Disparition
Possibilit de perte des moyens ncessaires la connexion au service
Endommagement
physique
Possibilit de destruction ou d'endommagement de media support de logiciel
Inoprtabilit
Possibilit d'incapacit mettre le media en service (format de lecteur, incompatibilit de

format de lecture, etc.)
Disparition
Possibilit de disparition de media support de logiciel
Catgorie : Service
lment matriel :
quipement fonctionnel, cblage,
dispositifs de scurit, etc.
Media matriel support de
logiciel, d'automatisme ou de
Locaux
Moyens de servitude :
Alimentation en nergie, fluides et
climatisation, etc.
lments immatriels (support

d'un processus) :
paramtrage de processus,
procdure, etc.
Compte ou moyen d'accs au

service
Media support de logiciel
D et C
Service extrieur ncessaire au

fonctionnement des services
internes ou l'exploitation des
donnes
Echange
Possibilit d'change de media support de logiciel par un media modifi
Duplication
Possibilit de duplication de media support de logiciel
Inoprabilit
Possibilit d'incapacit mettre en uvre le service extrieur
Inexploitabilit
Possibilit de non fonctionnement du service extrieur
Disparition
Possibilit de disparition du prestataire du service extrieur
Endommagement
physique
Possibilit d'endommagement ou de destruction de media support de donnes
Inoprtabilit
Possibilit d'incapacit lire le media (format de lecteur, incompatibilit de format de

lecture, etc.)
Catgorie : donnes
Media support de donnes
D et C
Disparition
Possibilit de disparition de media support de donnes
Echange
Possibilit d'change de media support de donnes avec un media contenant des donnes
modifies
Duplication
Possible duplication de media support de donnes
Endommagement
logique
Possibilit d'endommagement logique du fichier de donnes
Inexploitabilit
Possibilit d'altration massive ou d'inexploitabiit du fichier support de donnes
Disparition
Possibilit d'effacement du fichier de donnes
Altration
Possibilit d'altration du fichier support de donnes
Divulgation
Possibilit de duplication ou diffusion (et divulgation) de fichier support de donnes
Moyen d'accs aux donnes
Disparition
Possibilit de disparition d'un moyen ncessaire pour l'accs aux donnes (cls logiques ou
physiques)
Altration
Possibilit d'altration de donnes en transit ou messages
Donnes en transit, messages,

crans
Divulgation
Possibilit de duplication (et divulgation) de donnes en transit, messages, crans
Perte
Possibilit de perte de donnes en transit ou messages
Fichier support de donnes
D et C
Catgorie : processus de fonctionnement

Procdures et directives

Inefficience
Possibilit que les procdures appliques soient inefficientes (vis--vis des obligations
lgales, rglementaires ou contractuelles)
16/32
CLUSIF 2012
5. Dfinir la typologie des menaces

Il ny a pas de risque sil ny a pas une cause, qui fait que la vulnrabilit intrinsque de lactif est
effectivement exploite.
Il est cependant ncessaire dinclure dans la menace dautres aspects que la simple cause.
En effet, il est ncessaire de prciser tout ce qui peut avoir une influence sur la
probabilit doccurrence du risque et donc tout paramtre descriptif de la manire dont le
dommage pourrait survenir qui aurait ou pourrait avoir une influence sur cette
probabilit.
Cest ainsi quil peut tre ncessaire de dcrire :
Lvnement dclenchant loccurrence du risque (si les variantes dvnements nont

pas la mme probabilit).
Le caractre volontaire ou accidentel de cet vnement.
Lacteur dclenchant cet vnement, et en particulier les acteurs ayant des droits
particuliers qui pourront plus (ou moins) facilement agir.
Les circonstances dans lesquelles survient cet vnement

Il est clair, en effet, que chacun de ces paramtres peut influer sur la probabilit doccurrence du
risque.
Ici encore, le niveau de dtail avec lequel est dcrit chacun de ces points est un lment
cl dans la dtermination du nombre de menaces diffrentes et donc, in fine, du nombre
de risques diffrents quil faudra analyser et valuer.
Ceci tant, deux lments sont prendre en compte pour le choix du niveau de dtail, quel que
soit llment analys :
Un niveau de dtail supplmentaire conduit-il distinguer des menaces ayant des

probabilits intrinsques diffrentes ?
Existe-t-il des mesures de scurit (dissuasives ou prventives) diffrentes qui rendent

ncessaires de distinguer des lments auxquels peuvent sappliquer des mesures
diffrentes ?
Nous allons revenir ci-dessous sur chacun des lments constituant les menaces.
Typologie dvnements dclencheurs

La recherche des vnements dclencheurs doit tre organise avec lobjectif dtre aussi
exhaustive que possible.
Un tableau, comme le tableau danalyse prliminaire des dommages utilis pour les vulnrabilits
peut tre construit. Un tel tableau directement issu du tableau prcdent est donn ci-dessous,
titre dexemple (tableau en 2 parties).
Il complte simplement les dommages par leurs causes possibles en termes dvnements
dclencheurs.

17/32
CLUSIF 2012
Tableau d'analyse prliminaire des menaces (causes des dommages)

Type d'actif secondaire Type de
consquence
Type de dommage
Evnements dclencheurs possibles
lment matriel :
Endommagement
physique
vnement naturel accidentel d l'environnement :

- Incendie
- Inondation
- surcharge lctrique
- pollution chimique, vieillissement, etc.
- etc.
Accident provoqu par erreur humaine
- Erreur de manipulation
- Erreur de procdure
Indisponibilit
quipement fonctionnel,
cblage, dispositifs de
scurit, etc.
Media matriel support
de logiciel,
d'automatisme, de
ou de donnes
Malveillance :
- Dgradation volontaire physique directe
- Dgradation indirecte (accident provoqu)
Inoprabilit
Inexploitabilit
Disparition
Dfaut
d'intgrit
Altration
change
Divulgation

Duplication de
l'lment matriel
Acquisition par un
tiers de l'lment
matriel
Accident touchant le personnel d'exploitation :

- Intoxication alimentaire
- Epidmie ou pandmie
Accident touchant des lments ncessaires aux oprations :
- Destruction de licence ou de jeton
- Destruction ou endommagement de cl
- Absence d'nergie, de climatisation,
- Incapacit logistique (locaux, transports, restauration, etc.)
Erreur humaine touchant des lments ncessaires aux oprations :
- Perte de licence, de jeton ou de cl
- Moyen de lecture inadapt (non conserv ou non mis jour)
Action volontaire du personnel d'exploitation :
- Dmission collective massive
- Mouvement social avec arrt de travail
Non fonctionnement matriel :
- Panne matrielle
- Saturation accidentelle (rseau, systme)
Malveillance :
- Saturation volontaire (attaque en dni de service)
Disparition accidentelle :
- Perte / Oubli
Disparition volontaire :
- Vol
Modification par erreur de la configuration matrielle :
- modification errone de cblage
- suppression/inhibition par erreur de dispositifs de scurit
Modification volontaire de la configuration matrielle :
- modification de cblage
- suppression/inhibition volontaire de dispositifs de scurit
Echange volontaire avec un lment matriiel modifi
Duplication volontaire de l'lment matriel
Acquisition accidentelle :
- Perte / Oubli
- Envoi par erreur ou accident un mauvais destinataire
Disparition volontaire :
- Vol
18/32
CLUSIF 2012
Tableau d'analyse prliminaire des menaces (causes des dommages)

Type d'actif secondaire Type de
consquence
Type de dommage
Evnements dclencheurs possibles
lment immatriel :
Endommagement
logique

- Erreur de manipulation entchant la cohrence des lments
- Erreur de procdure
Malveillance :
- Dgradation volontaire directe
- Dgradation indirecte (accident provoqu)
Inoprabilit

- Destruction de licence ou de jeton
- Destruction ou endommagement de cl
Indisponibilit
paramtrage de
processus, procdure,
etc.
Donnes (fichiers
constitus, donnes
fugitives, etc.)
Erreur humaine touchant des lments ncessaires aux oprations :

- Perte de licence, de jeton ou de cl
- Logiciel de lecture inadapt (non conserv ou non mis jour)
Inexploitabilit
Non fonctionnement logiciel :

- Panne logicielle
- Saturation accidentelle (incapacit systme traiter des appels
mutiples)
Blocage de comptes utilisateurs :
- Attaque en dni de service
- Blocage volontaire pour raisons de scurit
Disparition

- Erreur de manipulation ou procdure entranant l'effacement de
l'lment
Malveillance :
- Effacement volontaire direct
- Effacement indirect provoqu
Dfaut
d'intgrit
Altration logique
Divulgation
Copie de l'lment
Modification par erreur de la configuration logicielle ou des donnes :

- erreur de frappe ou de saisie
- modification errone de squencement et d'enchanements
- suppression/inhibition par erreur de dispositifs de scurit
Modification volontaire de la configuration logicielle ou des donnes :
- falsification de donnes
- falsification de programmes
- suppression/inhibition volontaire de dispositifs de scurit
Duplication volontaire de l'lment immatriel
Acquisition par un
tiers
Services extrieurs ou
tiers
Indisponibilit
Inoprabilit
Acquisition accidentelle :
- Non effacement avant rebut, transfert, etc.
- Envoi par erreur ou accident un mauvais destinataire
Accident touchant le personnel d'exploitation :
- Intoxication alimentaire
- Epidmie ou pandmie
- Indisponibilit des moyens de communication avec le prestataire
- Indisponibiilit des conditions administratives (contrat, financement)
Action volontaire du personnel d'exploitation :
- Dmission collective massive
- Mouvement social avec arrt de travail
Inexploitabilit
Disparition
Non fonctionnement des qipements du prestataire :

- Panne matrielle
- Saturation accidentelle (rseau, systme)
Malveillance :
- Saturation volontaire (attaque en dni de service)
Disparition du prestataire :
- Dpt de bilan
Arrt volontaire d'activit :
- Cessation d'activit (partielle ou totale)
Il convient de noter que les types dvnements dclencheurs signals ci-dessus peuvent tre
dvelopps ou au contraire synthtiss, en fonction du degr de dtail souhait et jug optimal.
Il convient galement de noter que seule la nature de lvnement dclencheur a une
influence sur la potentialit intrinsque du risque, les conditions de survenance et le type
19/32
CLUSIF 2012
dacteur nintervenant que sur la potentialit rsiduelle, par lintermdiaire des mesures
dissuasives et prventives qui peuvent dpendre de ces circonstances ou du type
dacteur.
Typologies de conditions de survenance

Certaines circonstances de survenance ont une influence directe sur la potentialit rsiduelle dun
risque, une fois des mesures spcifiques mises en place.
Cest en particulier le cas pour :
Les actions volontaires menes, sur des lments matriels ou immatriels, distance
ou non, depuis lintrieur de lentreprise ou non, pendant les heures de prsence du
personnel ou non, selon certaines phases dun processus, etc.
Les accidents ou erreurs survenant certaines phases particulires dun processus

(saisie de donnes, stockage, traitement, impression, envoi, etc.)
Le tableau prcdemment utilis danalyse des menaces peut alors tre complt pour dcrire les
conditions de survenance quil conviendrait de distinguer pour une meilleure valuation des
menaces et des risques, et, en particulier :
Les lieux dans lesquels lvnement dclencheur survient,
Les priodes de temps auxquelles il survient,
Les voies daccs utilises,
Les tapes de processus concernes.
Typologie dacteurs
Les types dacteurs ont une influence sur la potentialit rsiduelle dun risque pour la simple
raison que certaines mesures sont spcifiques certains types dacteurs (les contrles daccs
nont pas deffet contre des utilisateurs lgitimement autoriss)
Le tableau danalyse des menaces prcdemment utilis peut alors galement tre complt pour
dcrire les types dacteurs quil conviendrait de distinguer pour une meilleure valuation des
menaces et des risques, et, en particulier :
Les acteurs internes ayant des droits permanents,
Les acteurs internes ayant des droits privilgis de par leur fonction,
Les acteurs externes ayant des profils particuliers,
Les acteurs externes qui il a t octroy des droits temporaires,
Etc..

20/32
CLUSIF 2012
Description de la menace dans la base de connaissance

La description de la menace dun risque dans la base de connaissance doit ainsi comprendre :
La description de lvnement dclencheur,
Le type de dommage,
Les conditions de survenance,
Le type dacteur.

21/32
CLUSIF 2012
6. Construire la base de scnarios (liste de scnarios et

lments descriptifs)
La base de scnarios sera ainsi construite en rassemblant les divers lments analyss plus haut
savoir :
Le type dactif
Type dactif primaire
Type dactif secondaire
Le type de vulnrabilit
Type de dommage
Type de vulnrabilit intrinsque
Le type de menace
Type dvnement dclencheur
Type de conditions de survenance
Type dacteur
Il est fortement recommand de complter cette description dune expression littrale dcrivant
le risque en termes simples et parlant pour tout utilisateur de la base de connaissance.

22/32
CLUSIF 2012
7. Dfinir les services de scurit

Dans MEHARI, on fait appel aux services de scurit pour valuer la potentialit et limpact
rsiduels et ceci en fonction du niveau de qualit de ces services.
Cela impose que lon sache valuer cette qualit, mais aussi que lon soit sr que lefficacit ainsi
value sapplique bien dans le cas du scnario de risque analys, conformment au principe n 1
rappel en dbut de document. Une premire condition pour cela est, bien entendu, quil ny ait
aucune ambigut sur la finalit du service.
Cest pour cette raison que le Clusif a tabli en principe la ncessit dtablir, pour chaque service
de scurit, une fiche dcrivant :
la finalit du service,
les scnarios de risque sur lesquels il agit, cest--dire les rsultats attendus de la mise
en uvre du service,
les mcanismes ou solutions possibles de ralisation et de mise en oeuvre,
les lments caractristiques de la qualit du service, cest--dire les critres de

jugement de :
son efficacit,
sa robustesse,
sa mise sous contrle.
Ceci tant, il faut tre conscient quun service peut toujours tre dcompos en sous-services ,
linfini, chaque question pose aujourdhui ayant sa propre finalit et pouvant, la limite, tre
leve au rang de service et dcompose en sous-questions et ainsi de suite.
La question du niveau de dtail des services de scurit est donc une question cl, ayant une
influence dcisive sur la charge dvaluation et de diagnostic de la qualit desdits services.
Pour dfinir au mieux ce niveau de dtail, il faut tenir compte de plusieurs paramtres :
Dfinir des services de scurit cohrents avec la typologie dactifs (voir chapitre 3).
Dfinir des services de scurit cohrents avec la typologie des vulnrabilits
Dfinir des services de scurit cohrents avec la typologie des menaces
Faire un choix entre dfinir des services diffrents ou utiliser des variantes du mme
service (par le schma daudit)
Nous allons aborder, ci-dessous, ces diffrents aspects.
Dfinir des services de scurit cohrents avec la typologie dactifs

Nous avons dj voqu ce point au chapitre 3. Prcisons les impratifs et les options.
Il peut sembler indispensable quaux actifs distingus dans la typologie des actifs correspondent
des services de scurit distincts. Outre que cela parait naturel, cela permet des diagnostics plus
prcis et donc une meilleure analyse des risques auxquels lentit est expose.
En fait, cela nest pas obligatoire, tant que lon respecte les principes dfinis pour tablir les
questionnaires de diagnostic des services (voir chapitre suivant). En effet, si ces principes sont
respects, tout ce que lon risque regrouper des services protgeant des actifs diffrents est de
23/32
CLUSIF 2012
faire un diagnostic pessimiste. En effet, le mme service tant valu pour plusieurs types dactifs
diffrents, on sera amen poser des questions relatives chaque type dactif et faire une
valuation globale fonction de la plus mauvaise rponse.
Un tel diagnostic pessimiste nest pas dangereux en terme danalyse de risque mais peut conduire
des plans daction inutiles et donc des dpenses inutiles.
Autrement dit, si les actifs sont distincts, ils peuvent avoir des classifications diffrentes, c'est-dire des besoins diffrents, et le regroupement de services peut conduire surprotger des actifs
qui ne ncessitaient pas un tel niveau de protection.
Sans tre obligatoire, il est donc conseill de dfinir des services de scurit distincts
pour des actifs distincts.
A linverse, si des actifs ont t confondus et regroups, un niveau de dtail plus fin au niveau des
services de scurit quau niveau des actifs ne prsente pas dinconvnient au plan de lanalyse des
risques. Le seul inconvnient est laccroissement de la charge de travail, mais il nest mme pas
sr que le surcrot de travail ne puisse pas savrer utile par la suite pour le choix des mesures de
scurit.
Prenons un exemple pour clairer ce dernier point :
Supposons que lon ait dfini comme type dactif linfrastructure informatique (sans faire de dtail
entre le rseau tendu, le rseau local, les systmes informatiques et les systmes bureautiques),
alors que des services de scurit distincts sont valus lors du diagnostic, il sera ais de prendre
en compte la varit des services dans les formules de calcul des facteurs de rduction de risque,
par lemploi des fonctions min et max .
Dfinir des services de scurit cohrents avec les typologies de

vulnrabilits et de menaces
Nous avons galement voqu ce point plus haut dans ce document.
Disons globalement que le mme raisonnement que ci-dessus sapplique et que lon peut noncer
le principe suivant :
Sans tre obligatoire, il est donc conseill de dfinir des services de scurit distincts
pour pallier des vulnrabilits ou des menaces distinctes.
Pour prciser ce point, on peut ajouter les arguments suivants :
Les tableaux utiliss pour analyser puis dfinir les types de vulnrabilits ont t utiliss et
complts pour dfinir les types de menaces. Or ce sont ces menaces et ou ces vulnrabilits qui
devront tre combattues ou rduites par des services de scurit pour limiter les risques.
De la mme manire que pour les types dactifs, des types de services de scurit distincts pour
des vulnrabilits ou des menaces distinctes ne sont pas obligatoires mais conduiront des plans
de scurit plus optimiss et une moindre dpense dnergie.
A linverse et de mme que pour les types dactifs, des services de scurit dfinis de manire plus
fine que les vulnrabilits ou les menaces ne limposent ne sont pas un inconvnient du point de
vue de lanalyse de risque, les formules de calcul des facteurs de rduction de risque permettant
den tenir compte.

24/32
CLUSIF 2012
Dfinir des services de scurit diffrents ou travailler avec des

variantes dun mme service
La question se pose parfois de dfinir des services de scurit diffrents ou de traiter les
diffrences par des variantes de services au niveau du schma daudit.
Cette question a maintes fois t pose, par exemple pour les contrles daccs : faut-il dfinir des
services de contrle daccs diffrents pour le rseau tendu, le rseau local, laccs aux systmes,
aux applications et pour les contrles daccs applicatifs aux donnes, etc, avec linconvnient
invitable de devoir rpondre autant de fois des questions trs proches, si ce nest identiques,
pour des actifs diffrents ventuellement scuriss avec une politique de scurit commune et ne
peut-on plutt travailler avec des variantes.
Une premire rponse factuelle est que, mme avec des variantes, il faudra poser autant de
questions que de variantes et que cela ne simplifiera donc pas la tche mais imposera en outre un
vocabulaire unique ce qui peut tre un inconvnient de comprhension.
La deuxime rponse, plus fonctionnelle, est rechercher dans les formules de calcul des facteurs
de rduction des risques et dpend donc, en grande partie, de larchitecture des systmes et de
limbrication des services de scurit qui assurent les services.
Si plusieurs services de scurit pouvant tre diffrents ou assurs par des variantes diffrentes
sont utiliss en srie , le meilleur dentre eux assurant et imposant le niveau de scurit de
lensemble ce qui se traduit par des max dans les formules, ils ne peuvent tre traits avec
efficacit par des variantes et doivent tre considrs comme des services distincts ( noter que
cest bien le cas des contrles daccs voqus plus haut).
Si, par contre, les diffrents services sont des options, donc utiliss en parallle et appels par des
formules avec des min , ils peuvent tre traits par des variantes.
Dernire remarque sur ce sujet. Si on ne considre quun service unique, sans variante, les
questionnaires devront tre gnraux et ne pas dtailler les questions par type dactifs lintrieur
dun mme questionnaire : cest lors de la rponse globale que les personnes interviewes devront
tenir compte de larchitecture pour faire une rponse approprie.

25/32
CLUSIF 2012
8. Lvaluation de la qualit des services de scurit et

llaboration des questionnaires de diagnostic
Considrations gnrales
Le but du diagnostic et des questions tant d'valuer la qualit de chaque service de scurit, il
importe de dfinir lchelle de cotation.
La thorie est que la qualit reflte la fois lefficacit du service (pour atteindre sa finalit),
sa robustesse pour se dfendre contre une attaque directe visant le court-circuiter et sa mise
sous contrle. Il sagit donc dune chelle absolue , indpendante des capacits de la
technologie rpondre l'exercice du service.
Une autre vision raliste serait une rfrence ce qui se fait gnralement .
Cette voie consisterait, par exemple, considrer quun mot de passe est la mthode
dauthentification trs majoritairement employe et donc que l'on doit pouvoir atteindre une note de
3, voire de 4, si ces mots de passe sont trs bien grs (toutes les rgles connues sont appliques, il
nest pas stock ni transmis en clair, on ne peut tenter de le dcouvrir par essais successifs, etc.). Avec
une telle approche, on pourrait obtenir une note de 3 ou de 4 avec une authentification par mot de
passe, alors que le service est inefficace dans nombre de cas : attaque mene par un initi situ dans
lentourage immdiat de lutilisateur qui sauthentifie et qui peut tout simplement lobserver, attaque
mene par une personne ayant accs au poste et capable dy introduire un logiciel espion, attaque
mene par un informaticien capable de modifier le code du processus dauthentification, etc.
Cette drive est, bien videmment, contraire lesprit de la mthode. Elle est, en pratique,
impossible matriser puisque la rfrence ne peut tre dfinie (quel est le niveau de ce qui se
fait ?).
La qualit de service doit tre juge dans labsolu par rapport aux critres standards
de qualit (efficacit, robustesse, mise sous contrle), indpendamment des pratiques
courantes.
Des dfinitions de niveau de qualit de service ont t donnes, et se trouvent dans la
documentation standard de MEHARI.
Questionnaires dvaluation de la qualit de service

Les deux principes gnraux exposs en dbut de document conduisent exiger des
questionnaires que, pour chaque service, chaque question pose soit pertinente et justifie.
Toute question superflue par rapport la finalit du service peut conduire une survaluation du
service (contraire au principe de prcaution) ou une sous-valuation qui ne saurait tre justifie
(contraire au principe de justification).
Toute question pose doit tre pertinente et justifie eu gard la finalit du service.
Ceci impose un certain nombre de contraintes ceux qui tablissent les questionnaires ou qui les
valident :
Vrifier que chaque question pose correspond bien la finalit du service.

26/32
CLUSIF 2012
Vrifier que chaque service abord lest bien en profondeur et que les questions
essentielles sont bien poses. Sinon, choisir entre rajouter des questions ou supprimer
le service.
Vrifier que lon traite bien tous les aspects de la qualit de service, savoir son
efficacit, sa robustesse et sa mise sous contrle.
Vrifier que si lon rpond oui (ou 1) toutes les questions du service (et que, par
dfinition, on obtient alors la note maximale de 4) la qualit du service correspond
bien la dfinition de qualit retenue, cest--dire que le service accomplit totalement
sa fonctionnalit, quil est bien sous contrle avec un excellent niveau de robustesse.

27/32
CLUSIF 2012
9. Construire la base de connaissance des scnarios

La construction de la base de connaissance des scnarios, une fois tablie la base des scnarios
(leur liste et leurs caractristiques descriptives), consiste essentiellement tablir pour chacun les
formules de calcul des facteurs de rduction de risque.
Pour respecter lesprit de la mthode, les principes fondamentaux cits en dbut de document
doivent tre respects. Lapplication de ces principes conduit un certain nombre de
prescriptions dveloppes ci-dessous.
Services appels dans les formules de calcul des STATUS

Pertinence de lvaluation des services pour les scnarios qui lappellent
Par application du principe de prcaution, il est ncessaire que lappel un service de scurit soit
pertinent, cest--dire que lon soit sr que lvaluation du service, faite lors dun audit, soit
pertinente pour le scnario. Ceci a deux types de consquences :
Si une seule question parmi d'autres, dans le questionnaire de diagnostic du service, a

un effet sur le scnario, mais si l'ensemble des autres questions du questionnaire n'a
pas d'effet sur ce scnario, il ne faut pas faire appel ce service (sinon une bonne note
due aux autres questions rduirait sans raison le niveau de risque du scnario).
Il est ncessaire enfin que le service sapplique avec efficacit, dans toute la gnralit
de sa dfinition et que les questions qui auront t poses pour valuer le service
soient pertinentes dans le contexte du scnario tudi. Exemple : Si on fait appel au
PCU (Plan de Continuit des activits Utilisateurs), c'est dans la gnralit de sa
fonction, c'est--dire en appui d'un PRA (Plan de Reprise d'Activits informatiques) Si
le scnario est tel que le PRA ne s'appliquera pas, c'est un PCU particulier qu'il
faudrait faire appel et on ne doit pas faire appel au service gnral PCU (mais
ventuellement crer un service spcifique de Plan de secours entirement manuel ).
En toute rigueur, le principe qui dcoule des deux points ci-dessus, pourrait sexprimer ainsi :
Les services appels dans des formules de calcul de STATUS sont tels que toute question
pose pour valuer le service est pertinente pour les scnarios qui l'appellent.
On prendra garde, nanmoins, quune application trop stricte de ce principe ne conduise un
trop grand miettement des services et on retiendra plutt un nonc moins radical :
Un scnario ne doit faire appel un service que si son valuation est pertinente pour le
scnario, quelles que soient les questions auxquelles il est rpondu affirmativement.
Pertinence dun service pour rduire limpact intrinsque

Il sagit ici des services appels par les formules de calcul des facteurs de rduction dimpact,
pouvant donc avoir un rle de confinement ou comme mesure palliative.
Par application du principe de prcaution, il est ncessaire que lon soit sr que ce service agira
effectivement sur limpact rsiduel et donc sur les critres et seuils dimpact qui ont t la base
de lvaluation de limpact intrinsque.
Prenons quelques exemples :
Si un critre dimpact a t la destruction ou lindisponibilit durable dlments

dinfrastructure avec des seuils variant avec ltendue ou lampleur des lments

28/32
CLUSIF 2012
atteints, un service de dtection dincendie aura bien une influence sur limpact
rsiduel. Si, par contre, pour le mme niveau dimpact maximal, le critre tait la
destruction ou lindisponibilit de certains lments prcis de linfrastructure (impact
maximal d, par exemple, une classification de niveau 4 pour tel serveur, de niveau 2
pour tel autre), alors il nest pas sr que la dtection dincendie soit pertinente car si
lincendie nait proximit immdiate de llment le plus critique, sa dtection pourrait
ne pas changer le niveau dimpact rsiduel (dtection trop tardive).
Si un critre dimpact est la fraude, avec des seuils fonction du montant de la fraude,
un service de contrle permanent applicatif peut tre pertinent pour rduire limpact
dun scnario de fraude. Si, par contre, pour le mme critre dimpact, les seuils sont
uniquement fonction des domaines concerns (RH, gestion de clientle, etc.), les
contrles permanent ne seront peut-tre pas pertinents et ne devraient pas tre
retenus.
Ceci conduit exprimer le principe suivant :
Lappel un service pour rduire limpact doit tre pertinent, quels que soient les critres et seuils dimpact qui ont
t lorigine de lvaluation de limpact intrinsque du scnario.
Lapplication stricte de ce principe serait nanmoins pnalisante pour les scnarios pour lesquels
on ne peut dcider lavance, dans la base de connaissance, si tel service sera pertinent ou non
car on ignore les critres utiliss et la nature des seuils dimpact correspondants, comme dans les
exemples ci-dessus.
Il est ncessaire de prvoir alors une variable permettant au responsable de lanalyse de risque de
dcider, au cas par cas, si on peut faire appel ces services ou non.
Cest ainsi qua t cre, dans la base de connaissance de MEHARI, une variable permettant de
dclarer un scnario confinable ou non.
Le principe devient alors :
Lappel effectif un service pour rduire limpact dun scnario, appel ventuellement
fonction dune variable de commande spcifique, doit tre pertinent compte tenu des
critres et seuils dimpact utiliss pour valuer limpact intrinsque.
Sagissant ici de construire une base de connaissance, lapplication de ce principe doit tre
comprise ainsi :
Dans les cas o il y doute sur le caractre gnral de la pertinence du service de scurit
pour un scnario donn, il convient, par application des deux principes de prcaution et
de justification, de mettre en place les formules faisant appel au service mais de
positionner la variable de commande sur la position o lappel au service est inhib, de
sorte quil faille une action volontaire de validation (ou de suppression de linhibition)
pour que lappel au service devienne effectif.
Pertinence dun service pour rduire la potentialit

Il sagit ici des services appels par les formules de calcul des facteurs de rduction de potentialit,
pouvant donc avoir un rle de dissuasion ou de prvention.
Par application du principe de prcaution, il est ncessaire que lon soit sr que ce service agira
effectivement sur la potentialit rsiduelle et donc sur les considrations qui ont t la base de
lvaluation de la potentialit intrinsque.

29/32
CLUSIF 2012
Cest le parallle de ce qui a t dit ci-dessus. Il est, cependant, beaucoup plus simple mettre en
uvre car la potentialit intrinsque des vnements dclencheurs ne dpend pas (gnralement)
dlments externes non dfinis.
On peut nanmoins exprimer le principe de base suivant :
Lappel effectif un service pour rduire la potentialit dun scnario doit tre pertinent
quelles que soient les raisonnements utiliss pour valuer la potentialit intrinsque.
Lapplication de ce principe revient en pratique recommander une parfaite adquation entre le
niveau de dtail des vnements dclencheurs et le niveau de dtail des services de scurit, ainsi
que nous lavons dj expliqu.
Traitement des scnarios datteinte lintgrit

Quand on analyse des scnarios datteinte lintgrit, on traite, en pratique, plusieurs types de
scnarios :
Les scnarios datteinte lintgrit dune base de donnes ou de fichiers, pour lesquels,
une fois le dfaut dintgrit dtect, les mesures palliatives consistent rparer les fichiers ou bases endommages pour pouvoir redmarrer sur des bases saines. Ces scnarios peuvent tre volutifs (confinables) ou non (voir paragraphe suivant).
Les scnarios de type fraude pour lesquels il ny a gure de mesures palliatives et qui ne
sont pas volutifs (limpact maximum est atteint ds laction consomme) mais pour
lesquels il existe des mesures de limitation dimpact direct (contrles permanents, seuils
de dtection, etc.) qui font quils doivent tre considrs comme confinables.
Certains scnarios derreurs ou daccident ayant le mme type de consquences quune
fraude, c'est--dire un impact limitable ou confinable, sans mesures palliatives possibles.
Les premiers sont, en fait, des scnarios datteinte la disponibilit ; la cause initiale est bien un
dfaut dintgrit mais ds que ceci est connu, on se trouve ramen un problme de
disponibilit et, lors de lvaluation de limpact intrinsque on suppose trs
gnralement, que lintgrit est atteinte mais que lon ne le sait pas.
Ces scnarios sont intituls Pollution massive de donnes et doivent tre traits
comme des scnarios datteinte la disponibilit.
Par contre, pour les scnarios datteinte lintgrit de type fraude ou quivalent
(deuxime et troisime type cit ci-dessus), on doit considrer que le dfaut dintgrit
nest pas connu.
Ds lors, il ne devrait pas exister de service pertinent en mesures palliatives susceptibles de
rduire limpact. Par contre des mesures de confinement restent possibles.
Les scnarios datteinte lintgrit sont considrs comme confinables mais ne devraient pas faire appel, en
standard, des mesures palliatives.

30/32
CLUSIF 2012
10. Finaliser la base de connaissance MEHARI

La dernire tape dans la construction dune base de connaissance MEHARI est sa finalisation et
sa mis en forme dans un format final, directement exploitable ou non.
Nous naborderons pas ici les aspects techniques car ils dpendent du type de support que lon
souhaite offrir. Les bases de connaissance MEHARI ont t livres, avant la version 2010 sous
une forme non directement exploitable alors que depuis la dernire version, les bases Excel ou
OpenOffice permettent une exploitation directe.
11. Conseils de mise en uvre

Il pourrait sembler que lordre prsent, actifs, puis vulnrabilits, puis menaces, puis services de
scurit, puis scnarios et base de scnarios, etc. ne soit pas obligatoire et que lon puisse
commencer par les services de scurit et remonter en sens inverse.
Nous considrons quil est prfrable de commencer par les actifs et non linverse, mais le dbat
peut tre ouvert ce sujet, tant que lensemble des principes prsents dans ce document est
respect.

31/32
CLUSIF 2012
LESPRIT DE LCHANGE
CLUB DE LA SCURIT DE L'INFORMATION FRANAIS

11, rue de Mogador
75009 Paris
01 53 25 08 80
clusif@clusif.asso.fr
Tlchargez les productions du CLUSIF sur
www.clusif.asso.fr

CLUSIF 2011 Guide Developpement Base

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CLUSIF 2011 Guide Developpement Base

Загружено:

Авторское право:

Доступные форматы

METHODES

CLUB DE LA SECURITE DE LINFORMATION FRANAIS

MEHARI est une marque dpose par le CLUSIF.

Ministre de l'ducation, du Loisir et du Sport du Qubec

Ainsi que les membres du comit de relecture.

Guide de dveloppement dune

Objectif de ce document .................................................................................................................. 6

Dfinir la typologie des vulnrabilits ..........................................................................................14

Dfinir la typologie des menaces...................................................................................................17

Typologie dvnements dclencheurs ..............................................................................................17

Dfinir les services de scurit.......................................................................................................23

Dfinir des services de scurit en accord avec la typologie dactifs.............................................23

Conseils de mise en oeuvre ............................................................................................................31

Guide de dveloppement dune

Analyse des actifs :

Ce schma met en vidence que le processus didentification, danalyse et de traitement des

Guide de dveloppement dune

A qui sadresse ce document ?

Analyse des actifs :

Liste et typologie dactifs primaires

Typologie dactifs secondaires

Analyse des menaces :

Analyse des facteurs de

Base de services de scurit

Analyse des services de scurit

Base de questionnaires dvaluation

Guide de dveloppement dune

Nous aborderons donc successivement :

La survaluation de la qualit des services de scurit, en gnral ou plus

Des grilles de dcision mal conues, mal valides ou inadaptes au contexte

Guide de dveloppement dune

Guide de dveloppement dune

3. Dfinir la typologie des actifs

Mode de description des actifs

Les services (fonctionnels),

Les processus de management.

De la nature des besoins,

De la nature des prestataires de service.

Du domaine dactivit et de domaines de responsabilit diffrents,

Des utilisateurs concerns.

b. Les actifs secondaires ou actifs de support

Guide de dveloppement dune

les diverses formes quil peut revtir,

les diverses contingences dont il peut dpendre.

Paramtres cls pour la dfinition des typologies dactifs

Typologies dactifs primaires

Distinguer des actifs protgs par des services de scurit diffrents.

Distinguer des actifs de sensibilits diffrentes

Distinguer des actifs primaires ayant des actifs secondaires diffrents

Guide de dveloppement dune

Typologie dactifs secondaires

Pour les actifs de type services (fonctionnels) :

Les quipements ncessaires la ralisation du service.

Les moyens de servitude ventuellement ncessaires ces quipements (lectricit,

Guide de dveloppement dune

Les lments matriels supports des lments immatriels dcrits ci-dessus.

Les lments logistiques ncessaires aux oprations effectues par du personnel

Le personnel interne charg dassurer les services.

Pour les actifs de type donnes :

Les donnes isoles.

Les donnes transitoires (messages, contenus dcrans, etc.).

Pour les actifs de type processus de management :

Guide de dveloppement dune

4. Dfinir la typologie des vulnrabilits