La Gestion Des Risques Pour Les Systèmes D'information

Nicolas Mayer nicolas.mayer@tudor.
.lu Ingnieur R&D Centre de Recherche Public Henri Tudor Luxembourg ; Doctorant lInstitut dInformatique de lUniversit de Namur Jean-Philippe Humbert jean-philippe.humbert@tudor.lu Ingnieur R&D Centre de Recherche Public Henri Tudor Luxembourg ; Doctorant au Centre de Recherche sur les Mdiations (CREM) Universit Paul Verlaine de Metz
La gestion des risques pour les systmes dinformation

Au sein des entreprises, la scurit des systmes dinformation est de plus en plus aborde laide dapproches bases sur les risques. Lexprience montre que de telles tudes prospectives rduisent de manire considrable les pertes lies aux faiblesses de scurit des systmes dinformation. Cette tendance est aussi perceptible dans lvolution du mtier de security officer, qui stend de plus en plus celui de risk manager. Partant de ce constat et afin de mieux apprhender la gestion des risques, cet article introductif a pour but de prsenter lensemble des concepts du domaine, ainsi que son processus, puis trois mthodes parmi les plus intressantes du march.
1. Introduction
Le concept de gestion des risques (ou risk management) a trs certainement fait son apparition la fin des annes 50 aux tats-Unis dans le domaine financier, en relation avec des questions dassurance [1]. Par la suite, la notion de gestion des risques a t tendue dautres domaines, citons notamment lenvironnement, la gestion de projet, le marketing, ainsi que la scurit informatique, qui nous intresse tout particulirement. Cet article a pour objectif de prsenter la gestion des risques de scurit des SI (Systmes dInformation), qui constituent uniquement une partie des risques gnralement associs aux activits ncessitant un SI. Nous ne traiterons pas, par exemple, les risques ayant des causes dordre financier (comme des dcisions en matire dinvestissement) ou organisationnel (par exemple une embauche pour un poste responsabilit). Dans la suite de cet article, la notion de gestion des risques se limitera donc la gestion des risques de scurit lis aux SI . La gestion des risques est dfinie par lISO [8] comme lensemble des activits coordonnes visant diriger et piloter un organisme vis--vis du risque. On dgage en gnral trois finalits la gestion des risques pour les SI : 1. Amliorer la scurisation des systmes dinformation. 2. Justifier le budget allou la scurisation du systme dinformation. 3. Prouver la crdibilit du systme dinformation laide des analyses effectues. Bien quun grand nombre ne soit plus utilis ou confidentiel, on estime quil existe plus de 200 mthodes de gestion des risques. Cette multiplicit entrane une trs grande diversit dans les approches des risques de scurit. Le but de cet article est de prsenter et synthtiser les lments de base de la gestion des risques, ainsi que trois des principales mthodes actuellement utilises.
2. Les fondements
Pour bien apprhender la gestion des risques, ses objectifs et ses limites, il est ncessaire de comprendre en premier lieu les concepts sous-jacents et le processus employ. Article paru dans le magasine MISC n24 (Avril-Mai 2006), ISSN: 1631-9036 1
Nicolas Mayer nicolas.mayer@tudor.lu Ingnieur R&D Centre de Recherche Public Henri Tudor Luxembourg ; Doctorant lInstitut dInformatique de lUniversit de Namur Jean-Philippe Humbert jean-philippe.humbert@tudor.lu Ingnieur R&D Centre de Recherche Public Henri Tudor Luxembourg ; Doctorant au Centre de Recherche sur les Mdiations (CREM) Universit Paul Verlaine de Metz
2.1 Concepts de la gestion des risques La gestion des risques, dans son plus simple appareil , se compose de trois blocs interdpendants. Nous distinguons lorganisation cible de ltude, dfinie par ses assets1 et ses besoins de scurit, puis les risques pesant sur ces assets et enfin les mesures prises ayant pour but de traiter les risques et donc dassurer un certain niveau de scurit.
Figure 1: Les concepts de la gestion des risques
Les assets sont dfinis comme tant lensemble des biens, actifs, ressources ayant de la valeur pour lorganisme et ncessaires son bon fonctionnement. On distingue ici les assets du niveau business des assets lis au SI. Du ct des assets business, on retrouve principalement des informations (par exemple des numros de carte bancaire) et des processus (comme la gestion des transactions ou ladministration des comptes). Les assets business de lorganisme sont bien souvent entirement (ou presque) grs au travers du SI, ce qui entrane une dpendance de ces assets vis--vis de ce dernier. Cest ce que lon appelle les assets systme . On retrouve dans les assets systme les lments techniques, tels les matriels, les logiciels et les rseaux, mais aussi lenvironnement du systme informatique, comme les utilisateurs ou les btiments. Cest cet ensemble qui forme le SI. Le but de la gestion des risques est donc dassurer la scurit des assets, scurit exprime la plupart du temps en termes de confidentialit, intgrit et disponibilit, constituant les objectifs de scurit.
Asset est un anglicisme couramment utilis dans le domaine.
Ces assets protger sont soumis des risques de scurit. Le guide 73 de lISO [8] dfinit un risque par la combinaison de la probabilit dun vnement et de ses consquences. Cette dfinition est gnralement tendue et on dfinit un risque laide de ce que lon nomme lquation du risque : RISQUE = MENACE * VULNRABILIT * IMPACT Cette quation est celle qui est la plus couramment utilise et la plus reconnue dans le domaine de la gestion des risques. Elle joue un rle fondamental dans lidentification et lvaluation du risque. Pour bien comprendre la notion de risque, il est important de se pencher sur chacune de ses composantes. Tout dabord la menace, la source du risque, est lattaque possible dun lment dangereux pour les assets. Cest lagent responsable du risque. Ensuite, la vulnrabilit est la caractristique dun asset constituant une faiblesse ou une faille au regard de la scurit. Enfin limpact reprsente la consquence du risque sur lorganisme et ses objectifs. La menace et la vulnrabilit, reprsentant la cause du risque, peuvent tre qualifies en termes de potentialit. Limpact peut, quant lui, tre qualifi en termes de niveau de svrit. Afin de mitiger ces risques et de protger les assets, une politique de traitement des risques est mise en place. Elle sera constitue dexigences de scurit permettant de rpondre aux risques. Ces exigences de scurit vont ensuite entraner la mise en place de contrles (ou contre-mesures) de scurit implmenter, afin de satisfaire aux exigences. Les contrles sont de deux types : Sur la menace ou la vulnrabilit, afin de limiter la cause du risque ; Sur limpact, afin de limiter la consquence du risque. 2.2 Le processus de gestion des risques Aprs avoir mis en vidence les concepts intervenant dans la gestion des risques, on peut identifier un processus de haut niveau couvrant ses activits. Ce processus est presque toujours appliqu dans les mthodes pratiques de gestion des risques, comme nous le verrons par la suite.
Identification du contexte et des assets
Dtermination des objectifs de scurit
Analyse des risques
Dfinition des exigences de scurit
Slection des contrles
Implmentation des contrles
Figure 2: Le processus de gestion des risques
La premire tape dune dmarche de gestion des risques consiste en lidentification du domaine et des assets. Dans cette partie, il est question de prendre connaissance avec lorganisation, son environnement, son SI et de dterminer prcisment les limites du systme sur lequel va porter ltude de gestion des risques. Une fois notre systme born, on procde en premier lieu lidentification des assets business constituant la valeur de lorganisation. Ensuite, le lien sera fait entre ces assets business et les assets systme, sur lesquels on identifiera et corrigera les risques dun point de vue technique et organisationnel. Ex. : Un site de e-commerce dispose dune base de donnes clients, prsente sur un serveur de son parc informatique et contenant les informations bancaires de ces derniers. La dtermination des objectifs de scurit vise spcifier les besoins en termes de confidentialit, intgrit et disponibilit des assets, en particulier au niveau business. Le lien entre les assets business et les assets systme tant fait en amont, on retrouve donc les besoins en scurit au niveau du systme. Ex. : La base de donnes clients a donc un fort besoin de confidentialit, li la sensibilit des informations quelle contient. Lanalyse des risques constitue le coeur de la dmarche de gestion des risques. Elle a pour finalit lidentification et lestimation de chaque composante du risque (menace/vulnrabilit/impact), afin dvaluer le risque et dapprcier son niveau, dans le but de prendre des mesures adquates (parfois, cette tape est galement appele apprciation du risque [8]). Il y a deux grandes coles pour lidentification des risques : soit en ralisant un audit du systme et de ses diffrents acteurs [5], soit partir de bases de connaissances prdfinies [3,4]. Pour lestimation des risques, il est possible en thorie de les quantifier laide de distributions de probabilits sur les menaces et les vulnrabilits, ainsi quen estimant les cots occasionns par les impacts. En pratique, il 4
se rvle difficile de donner des valeurs absolues et on se contente bien souvent dune chelle de valeurs relatives, par exemple, allant de 1 4. Cette estimation permet de faire un choix, reprsent sur la figure 3, dans le traitement du risque, avant de passer la dtermination des exigences de scurit.
risque constant
accepter
n'existe pas
Occurence
impact maximum tolrable
rduire
ngligeable
transfrer
Impact
Figure 3 : Les diffrentes zones de risque
Dune manire gnrale [7], on considre que : Les risques ayant une occurrence et un impact faible sont ngligeables. Les risques ayant une forte occurrence et un impact important ne doivent pas exister, autrement une remise en cause des activits de lentreprise est ncessaire (on vite le risque, avoidance en anglais) Les risques ayant une occurrence forte et un impact faible sont accepts, leur cot est gnralement inclus dans les cots oprationnels de lorganisation (acceptation du risque). Les risques ayant une occurrence faible et un impact lourd sont transfrer. Ils peuvent tre couverts par une assurance ou un tiers (transfert du risque). Enfin, les autres risques, en gnral majoritaires, sont traits au cas par cas et sont au centre du processus de gestion des risques ; lobjectif, tant de diminuer les risques en les rapprochant au maximum de lorigine de laxe (mitigation du risque laide de contrles). Ex. : Lanalyse des risques montre un certain nombre de scnarios ayant un niveau de risque inquitant pour la base de donnes clients. Un des risques identifis est laccs aux donnes par un utilisateur non-autoris travers le rseau. Cela aurait pour
consquence de nuire la confidentialit des donnes. Ce risque ncessite dtre trait par des contrles de scurit. Une fois lanalyse des risques effectue, la dfinition des exigences de scurit permettra de rduire les risques identifis. Comme prcdemment, en fonction des mthodes, cette tape pourra tre effectue avec lassistance de rfrentiels [9,10], ou aiguille par la connaissance dexperts systme/scurit. La dfinition des exigences de scurit, de par son importance et sa complexit, est souvent effectue de manire incrmentale et par raffinement successif. En effet, on conseille bien souvent de dbuter par des exigences gnrales, qui dfiniront lintention de contrer les risques identifis (de niveau stratgique), pour les raffiner ensuite en des exigences plus prcises (vers le niveau oprationnel). Toutefois les exigences sont censes tre gnriques et applicables tout SI. Il faut galement rappeler que ces exigences de mitigation des risques porteront la fois sur le systme informatique (comme le besoin dencryption des mots de passe), mais aussi sur son environnement (par exemple, lutilisateur du systme ne doit pas dvoiler son mot de passe un tiers ). Ex : Le serveur doit tre protg, dans sa globalit, des intrusions ventuelles. De mme, on dcide de mettre en place un contrle daccs adquat sur la base de donnes. Une authentification distance, plus forte que lauthentification actuelle par login/password, est ncessaire. Toutefois le cot et la simplicit dutilisation de la solution choisie doivent rester un niveau acceptable. Le dernier niveau de raffinement est constitu par la slection des contrles (ou contremesures) de scurit. Les contrles sont linstanciation des exigences de bas niveau pour le systme cible tudi. Ici sont dfinis les choix techniques des solutions de scurit, influencs par le systme dj en place, les comptences disponibles, les cots de mise en oeuvre Ex : On slectionne lajout dun IDS au firewall dj en place. De plus, on dcide de mettre en place une politique de password plus exigeante constitue dun login/password ainsi que dun code de contrle distribu lutilisateur lors de son inscription. Une authentification par carte puce est trop contraignante. Une fois les contrles slectionns, il reste alors les implmenter dans le SI et ventuellement les tester et les valuer. Il subsiste alors indniablement une part de risques traits partiellement ou non, qui constitue ce que lon appelle le risque rsiduel. Ex : Le service informatique de la socit mettra en place lIDS et le prestataire charg de la maintenance du site Web dveloppera un nouveau portail supportant lauthentification dsire. Ce processus est communment admis par les diffrentes mthodes de gestion des risques. Par contre, la terminologie est souvent trs diffrente, dune mthode ou norme une autre. La comparaison du processus de plusieurs mthodes ncessite alors une bonne analyse, mais dans lensemble, le schma prsent prcdemment est suivi. Toutefois, quelques mthodes se distinguent en prsentant une trame quelque peu diffrente ou tendue (tout en gardant bien souvent comme base linamovible processus gnrique prsent). Citons notamment le BS 7799-2:2002 [11] qui voit la gestion des risques
comme un processus suivant le paradigme PDCA ou dautres mthodes utilisant la gestion des risques dans une dmarche de conception de systme [6].
3. La gestion des risques en pratique

Mme aprs en avoir dgrossi les fondements, la notion de risque reste un concept difficile apprhender. La complexit des organisations actuelles associe aux enjeux business forcent ne pas sen remettre exclusivement ses subjectivits, en rsum sa perception intellectuelle , mais plutt faire confiance des mthodes formelles prouves. En un mot : Nul besoin de r-inventer la roue en matire danalyse des risques . Mieux vaut plutt profiter du travail effectu et des guides disposition. Tel que dcrit prcdemment, plus de 200 mthodes de gestion/analyse des risques sont dclines actuellement travers le monde. Ces dernires sont plus ou moins bien finalises, plus ou moins faciles daccs ou tout simplement inconnues ! A ce titre, le Club Informatique des Grandes Entreprises Franaises (CIGREF) a rcemment rappel, en regard du domaine de la scurit des SI, que labondance de normes et de mthodes est souvent source de confusion . Il ne faut, en effet, pas se perdre dans le ddale des mthodes et tenter daller lessentiel sur cette thmatique. Mais comment faire son choix au milieu de la jungle des rfrentiels danalyse des risques ? Une premire aide prcieuse est fournie via la prsentation, en amont, des fondements caractrisant les concepts et processus de la gestion des risques pour les SI. Ces concepts transcrivent le cadre de comprhension ncessaire pour apprhender sereinement la matire. En effet, partir de ces informations, le choix peut alors se faire, de manire progressive et en fonction du contexte. Pour rduire le champ du choix au coeur des mthodes formelles, certaines sont actuellement trs populaires, faisant rfrence dans leur domaine. A ce titre, nous avons choisi de dtailler EBIOS [3], MEHARI [4] et OCTAVESM [5] qui remplissent efficacement leur rle dans la conduite dune dmarche de gestion des risques. EBIOS (Expression des Besoins et Identification des Objectifs de Scurit) Il sagit dune mthode dveloppe et maintenue par la DCSSI (Direction Centrale de la Scurit des Systmes dInformation). Cette mthode, cre en 1995, se compose de cinq guides (Introduction, Dmarche, Techniques, Outillages pour lapprciation des risques et Outillages pour le traitement des risques) et dun logiciel support. Sa diffusion est gratuite [3]. La mthode a pour objectif la formalisation dobjectifs de scurit adapts aux besoins du systme audit (et de son contexte).
Figure 4 : Dmarche EBIOS globale
EBIOS apprhende les risques de scurit en tenant compte des trois blocs interdpendants des concepts de gestion prsents en amont. La mthode travaille par construction du risque, adoptant une prise en compte du contexte de lorganisation cible, en privilgiant le primtre du SI, les lments essentiels, les fonctions et les informations (correspondant aux assets business), et enfin les entits (assets systme). La seconde phase de la mthode permet de dgager les besoins via une grille des services souhaits de scurit (respect des critres Confidentialit, Intgrit, Disponibilit ). Le risque adapt lorganisation est ainsi construit et renforc par la prise en compte relative des vulnrabilits et des menaces sappliquant sur les assets et juges critiques. De linterdpendance entre ces phases se dcline ensuite naturellement la dfinition des exigences de scurit de haut-niveau (appeles ici objectifs ) puis de bas-niveau (appeles exigences ), conformment ISO 15408 [9] et ISO 17799 [10]. Cette dernire phase permet de slectionner les bonnes contremesures strictement adaptes aux besoins de lorganisation. Tous les concepts prsents dans la premire partie sont donc prsents, malgr des diffrences de terminologie. Quant au processus de gestion des risques, les phases 5 et 6 vues prcdemment ne sont pas rellement dveloppes, ce qui ne permet pas de valider vritablement le cycle thorique dans son ensemble. Dans ce cas, certains considrent alors EBIOS exclusivement comme une mthodologie danalyse des risques. OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) Cette mthode dvaluation du risque [5] est publie par le Software Engineering Institute (SEI) de la Carnegie Mellon University, reconnue dans le domaine de la scurit des SI (fdration des Computer Emergency & Reponse Team CERTS). Les fondements mmes de cette mthode reposent sur la possibilit de raliser une analyse des risques de lintrieur de lorganisation, exclusivement avec des ressources internes. Pleinement oriente vers les grands comptes, une version OCTAVE-S (Small) peut, cependant, facilement se dcliner au sein dune petite structure conomique.
OCTAVE est une mthode dvaluation des vulnrabilits et des menaces sur les actifs oprationnels. Une fois ces derniers identifis, la mthode permet de mesurer les menaces et les vulnrabilits pesant sur eux. Les trois phases suivantes dclines au coeur dOCTAVE, respectent lanalyse progressive des trois blocs des concepts de gestion des risques prsents en amont : La phase 1 (vue organisationnelle) permet didentifier les ressources informatiques importantes, les menaces associes et les exigences de scurit qui leur sont associes. La phase 2 (vue technique) permet didentifier les vulnrabilits de linfrastructure (ces dernires, une fois couples aux menaces, crant le risque). La phase 3 de la mthode dcline le dveloppement de la stratgie de scurit et sa planification (protection et plan de rduction des risques). On retrouve galement dans cette mthode lensemble des concepts prsents en premire partie. Concernant le processus, la mme remarque faite prcdemment, pour EBIOS, est valable : les deux dernires tapes sont peu ou pas abordes, la mthode se voulant tre principalement une mthode danalyse des risques.
Figure 5 : Les phases principales d'OCTAVE
MEHARI (Mthode Harmonise dAnalyse de RIsques) MEHARI demeure une des mthodes danalyse des risques les plus utilises actuellement. Elle est drive de deux autres mthodes danalyse des risques (MARION et MELISA). MEHARI est maintenue en France par le CLUSIF (Club de la Scurit des Systmes dInformation Franais) [4], via notamment le Groupe de Travail ddi cette mthode. MEHARI se prsente comme une vritable bote outils de la scurit des SI, permettant dapprhender le risque de diffrentes manires au sein dune organisation, et compose de plusieurs modules. Ces derniers, indpendamment de la dmarche scurit choisie, permettent notamment : Danalyser les enjeux de la scurit (en dcrivant les types de dysfonctionnements redouts) et, corrlativement, de classifier les ressources et informations selon les trois critres scurit de base (Confidentialit, Intgrit, Disponibilit). Dauditer les services de scurit, de manire prendre en compte lefficacit de chacun, son contrle, et de synthtiser les vulnrabilits. Danalyser les situations de risques, permettant dvaluer les potentialits et les impacts intrinsques, ainsi que les facteurs dattnuation de risque, puis, enfin, de dduire un indicateur de gravit de risque.
Figure 6 : Dmarche MEHARI globale
MEHARI prsente une grande diversit dans lutilisation de ses modules. Trois approches se dtachent plus particulirement : En se basant sur une analyse dtaille des risques, il est possible de mettre en oeuvre des plans de scurit. Cette dmarche se dcline au niveau stratgique, mais aussi oprationnel. Le premier niveau permet la cohrence des besoins et du contexte de lensemble de lorganisation. Le second niveau dfinit les units business autonomes au coeur de lorganisation et en charge des dcisions ncessaires en matire de scurit. En se basant sur laudit de scurit, ou plus prcisment aprs un diagnostic de ltat de scurit, la ralisation de plans dactions est facilite. En effet, des faiblesses releves dcoulent alors, directement, les actions entreprendre. Dans le cadre de la gestion dun projet particulier, tenir compte de la scurit, en se basant, de nouveau, sur lanalyse des risques, et ainsi faciliter llaboration de plans daction. Les besoins de scurit sont alors directement intgrs aux spcifications du projet, et intgrer dans le plan de scurit global de lentit concerne. Cette mthode saligne avec les deux premires en termes de couverture du processus de gestion des risques.
4. Conclusion
La notion de risque, qui demeure intangible, reste difficile apprhender : Les risques dsignent un futur quil sagit dempcher davenir [12]. Les risques en relation avec la scurit se doivent de reposer sur des techniques et des mthodologies particulires. Ces
10
mthodes permettent de prendre en compte toutes les facettes du risque, une dmarche dterminante afin de ne pas oublier des concepts essentiels : En France 100% des grandes entreprises effectuent ce type danalyses de risques, via une mthodologie formelle (CIGREF). Dans cet article, seules ont t proposes des mthodes orientes Analyse des risques , majoritaires dans le domaine en raison de la complexit inhrente cette partie, mais de nombreux guides existent galement pour les autres tapes [2]. Concernant le choix dune mthode, la question est complexe et pourrait faire lobjet dun article elle seule. Outre ltendue de la couverture de la mthode, quelques critres de choix retenir peuvent tre le type dapproche (audit ou analyse laide de bases de connaissances), leur origine (secteur priv, universitaire, militaire), leur facilit dutilisation, leur gratuit, des sources ouvertes, etc. (cette liste tant loin dtre exhaustive). Il demeure que les analyses non formelles, dans un contexte scurit, sont trs rares et gnralement non exhaustives. La force des concepts et du processus de gestion des risques prsents en amont est globalement vrifie au coeur des diffrentes mthodes dcrites. De fait, il serait dommage de ne pas profiter de ces vritables guides mthodologiques pour parfaire votre scurit !
Bibliographie
[1] Dubois, J.-C., Lanalyse du risque : une approche conceptuelle et systmique, Chenelire-McGrawHill, 1996. ISBN : 2-89461-066-1 [2] IT Baseline Protection Manual, BSI - Germany, October 2003. http://www.bsi.bund.de/english/gshb/ [3] Expression des Besoins et Identification des Objectifs de Scurit (EBIOS), Direction Centrale de la Scurit des Systmes dInformation, Fvrier 2004. http://www.ssi.gouv.fr/fr/confiance/ebiospresentation.html [4] Mthode Harmonise dAnalyse de Risques (MEHARI), Principes et mcanismes, CLUSIF, Version 3, Octobre 2004. http://www.clusif.asso.fr/ [5] Operationally Critical Threat, Asset and Vulnerability Evaluation (OCTAVE), Carnegie Mellon - Software Engineering Institute, Juin 1999. http://www.cert.org/octave/ [6]Ebrahimi T., Leprvost F., Warusfel B., Les enjeux de la scurit multimdia Vol.1 (trait IC2, srie Informatique et SI), Chapitre : Contributions mthodologiques pour lamlioration de lanalyse des risques, Hermes, 2005. ISBN : 2-7462-1207-2 [7] Bosworth, Seymor and Michael E. Kabay, Computer Security Handbook, 4th edition, Chapter 47, John Wiley & Sons, 2002. ISBN: 0-471-41258-9 [8] ISO/IEC Guide 73:2002, Risk management Vocabulary Guidelines for use in standards. [9] Common Criteria for Information Technology Security Evaluation, Version 2.2 (galement ISO 15408), 2004. http://www.commoncriteriaportal.org [10] ISO/IEC 17799:2005, Information Technology Security techniques - Code of Practice for Information Security Management
11
[11] BS 7799-2:2002, Information security management systems Specification with guidance for use [12] Ulrich Beck, La Socit du risque Sur la voie dune autre modernit, Flammarion Champs 2003, 522 pages. ISBN : 2-08-080058-2.
12

La Gestion Des Risques Pour Les Systèmes D'information

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

La Gestion Des Risques Pour Les Systèmes D'information

Hochgeladen von

Copyright:

Verfügbare Formate

Nicolas Mayer nicolas.mayer@tudor.

La gestion des risques pour les systmes dinformation

Figure 1: Les concepts de la gestion des risques

Asset est un anglicisme couramment utilis dans le domaine.

Identification du contexte et des assets

Dtermination des objectifs de scurit

Analyse des risques

Dfinition des exigences de scurit

Slection des contrles

Implmentation des contrles

Figure 2: Le processus de gestion des risques

impact maximum tolrable

Figure 3 : Les diffrentes zones de risque

3. La gestion des risques en pratique

Figure 4 : Dmarche EBIOS globale

Figure 5 : Les phases principales d'OCTAVE

Figure 6 : Dmarche MEHARI globale

Das könnte Ihnen auch gefallen