Evaluation des Risques : Methodes Qualitatives et Quantitatives
Une fois les menaces et vulnerabilites identifiees, il faut mesurer le risque qu’elles representent pour l’organisation. L’evaluation des risques est le coeur de la gestion de la securite de l’information : elle permet de determiner quels actifs proteger en priorite, combien investir dans les contre-mesures, et quelles methodologies utiliser pour produire des resultats exploitables par la direction. Cet article couvre en profondeur les deux grandes approches — quantitative et qualitative — ainsi que les principales methodologies standardisees (NIST SP 800-30, FRAP, OCTAVE, FMEA, arbres de defaillance) et les formules incontournables du CISSP : SLE, ARO et ALE.
1. Evaluation des risques vs analyse des risques
Une evaluation des risques (risk assessment) est un outil fondamental de la gestion des risques. C’est une methode d’identification des vulnerabilites et des menaces, et d’estimation des impacts possibles afin de determiner ou implementer des controles de securite. Apres qu’une evaluation des risques est menee et que les resultats sont analyses, une analyse des risques (risk analysis) est conduite : c’est un examen detaille des composantes du risque visant a s’assurer que la securite est rentable, pertinente, opportune et reactive face aux menaces.
Il est facile d’appliquer trop de securite, pas assez de securite, ou les mauvais controles, et de depenser trop d’argent dans le processus sans atteindre les objectifs necessaires. L’analyse des risques aide les organisations a prioriser leurs risques et montre a la direction le montant des ressources a consacrer a la protection.
Les quatre objectifs principaux de l’analyse des risques
- Identifier les actifs et leur valeur pour l’organisation
- Determiner la probabilite qu’une menace exploite une vulnerabilite
- Determiner l’impact metier de ces menaces potentielles
- Fournir un equilibre economique entre l’impact de la menace et le cout de la contre-mesure
Comparaison cout/benefice
L’analyse des risques fournit une comparaison cout/benefice (cost/benefit comparison) qui met en regard le cout annualise des controles face au cout potentiel de la perte. Un controle ne devrait generalement pas etre implemente si son cout annualise depasse le cout annualise de la perte. Par exemple, si une installation vaut 100 000 $, il n’est pas logique de depenser 150 000 $ pour la proteger.
Dimensionnement du projet (Project Sizing)
Il est important de definir ce que vous etes cense faire avant de commencer a travailler. Avant de demarrer une evaluation, l’equipe doit effectuer un dimensionnement du projet (project sizing) pour comprendre quels actifs et menaces doivent etre evalues. La plupart des evaluations se concentrent sur la securite physique, la securite technologique ou la securite du personnel. Tenter de tout evaluer en meme temps peut etre une entreprise considerable.
La direction devrait definir le perimetre de l’evaluation, qui sera le plus souvent dicte par les exigences de conformite organisationnelle et les contraintes budgetaires. De nombreux projets ont ete a court de fonds et arrete par consequent, parce qu’un dimensionnement adequat n’avait pas ete effectue au debut du projet.
Soutien de la direction
Une evaluation des risques doit etre soutenue et dirigee par la direction generale pour reussir. La direction doit definir le but, le perimetre, nommer une equipe, allouer le temps et les fonds necessaires, et reagir aux conclusions. Il est essentiel que la direction examine les resultats de l’evaluation et agisse en consequence. A quoi bon tout cet effort si la direction ne reagit pas aux conclusions ? Malheureusement, cela arrive bien trop souvent.
2. Valorisation des actifs (Asset Valuation)
Pour comprendre les pertes possibles et comment les prevenir, nous devons comprendre la valeur d’un actif susceptible d’etre impacte par une menace. La valeur repose sur l’information relative aux parties impliquees, le travail necessaire pour le developper, le cout de maintenance, les dommages en cas de perte ou destruction, le prix qu’un ennemi paierait, et les penalites potentielles.
Si une organisation ne connait pas la valeur de l’information et des autres actifs qu’elle cherche a proteger, elle ne sait pas combien d’argent et de temps consacrer a leur protection. Si la valeur calculee de la formule secrete de votre entreprise est x, alors le cout total de protection devrait etre inferieur a x.
La valeur reelle d’un actif est determinee par l’importance qu’il a pour l’organisation dans son ensemble. Elle doit refleter tous les couts identifiables qui surviendraient si l’actif etait reellement endommage — pas seulement le prix d’achat, mais aussi le cout de remplacement ou reparation, la perte de productivite, et la valeur de toute donnee corrompue ou perdue.
Les 10 criteres pour assigner une valeur aux actifs
| # | Critere |
|---|---|
| 1 | Cout d’acquisition ou de developpement de l’actif |
| 2 | Cout de maintenance et de protection de l’actif |
| 3 | Valeur de l’actif pour les proprietaires et les utilisateurs |
| 4 | Valeur de l’actif pour les adversaires |
| 5 | Prix que d’autres sont prets a payer pour l’actif |
| 6 | Cout de remplacement de l’actif en cas de perte |
| 7 | Activites operationnelles et de production affectees si l’actif est indisponible |
| 8 | Problemes de responsabilite juridique si l’actif est compromis |
| 9 | Utilite et role de l’actif dans l’organisation |
| 10 | Impact de la perte de l’actif sur la marque ou la reputation de l’organisation |
Actifs tangibles vs intangibles
Les actifs peuvent etre tangibles (ordinateurs, installations, fournitures) ou intangibles (reputation, donnees, propriete intellectuelle). Il est generalement plus difficile de quantifier la valeur des actifs intangibles, qui peut evoluer au fil du temps. Comment attribuer une valeur monetaire a la reputation d’une entreprise ? Ce n’est pas toujours une question facile, mais il est important de pouvoir y repondre.
Les 5 raisons pour lesquelles la valorisation est utile
- Effectuer des analyses cout/benefice efficaces
- Selectionner des contre-mesures et protections specifiques
- Determiner le niveau de couverture d’assurance a souscrire
- Comprendre ce qui est exactement a risque
- Se conformer aux exigences legales et reglementaires
3. Equipes d’evaluation des risques
Chaque organisation possede des departements differents, chacun avec ses propres fonctionnalites, ressources, taches et particularites. Pour une evaluation des risques la plus efficace possible, l’organisation doit constituer une equipe incluant des individus de nombreux voire tous les departements afin d’identifier et traiter toutes les menaces.
Les membres de l’equipe peuvent etre du management, des developpeurs, du personnel IT, des integrateurs systeme, des responsables operationnels — en fait, tout personnel cle de l’organisation. Ce melange est necessaire car si l’equipe ne comprend que des informaticiens, elle pourrait ne pas comprendre, par exemple, les types de menaces auxquelles fait face le departement comptable, ou comment l’organisation dans son ensemble serait affectee si les fichiers de donnees du departement comptable etaient effaces par un acte accidentel ou intentionnel.
L’equipe doit egalement inclure des personnes qui comprennent les processus de leurs departements respectifs, c’est-a-dire des individus au bon niveau hierarchique. Cela peut etre une tache difficile, car les managers deleguent parfois le travail d’evaluation a des niveaux inferieurs. Cependant, les personnes a ces niveaux inferieurs peuvent ne pas avoir une connaissance suffisante des processus que l’equipe doit evaluer.
Les 4 bonnes questions a poser
Lors de l’examen des risques, il est bon de garder plusieurs questions a l’esprit. Les soulever aide a s’assurer que l’equipe d’evaluation et la direction savent ce qui est important :
- Quel evenement pourrait survenir ? (evenement de menace)
- Quel serait l’impact potentiel ? (risque)
- A quelle frequence cela pourrait-il arriver ? (frequence)
- Quel degre de confiance avons-nous dans les reponses aux trois premieres questions ? (certitude)
Ces informations sont recueillies a travers des enquetes internes, des entretiens et des ateliers. Considerer les menaces sous cet angle aide l’equipe a se concentrer sur les taches a accomplir et a prendre des decisions plus precises et pertinentes.
4. Methodologies d’evaluation des risques
L’industrie a developpe differentes methodologies standardisees pour mener les evaluations des risques. Chacune possede les memes composantes de base (identifier les vulnerabilites, associer les menaces, calculer les valeurs de risque), mais chacune a un focus specifique. Gardez a l’esprit que les methodologies se recoupent largement car chacune a le meme objectif : identifier les elements qui pourraient nuire a l’organisation afin de les traiter.
Voici comment choisir la methodologie appropriee :
| Besoin | Methodologie recommandee |
|---|---|
| Programme de gestion des risques a l’echelle de l’organisation, integre au programme de securite | OCTAVE |
| Focus sur les risques de securite IT uniquement | NIST SP 800-30 |
| Budget limite, evaluation ciblee sur un systeme ou processus individuel | FRAP |
| Analyse detaillee des modes de defaillance d’un systeme critique, ou analyse par arbre de defaillance | FMEA ou Fault Tree Analysis |
4.1 NIST SP 800-30
Le NIST SP 800-30, Revision 1, Guide for Conducting Risk Assessments, est specifique aux menaces des systemes d’information et a la facon dont elles sont liees aux risques de securite de l’information. Il presente les etapes suivantes :
- Preparer l’evaluation
- Conduire l’evaluation :
- Identifier les sources de menaces et les evenements
- Identifier les vulnerabilites et les conditions predisposantes
- Determiner la probabilite d’occurrence
- Determiner l’ampleur de l’impact
- Determiner le risque
- Communiquer les resultats
- Maintenir l’evaluation
La methodologie de gestion des risques du NIST est principalement axee sur les systemes informatiques et les problematiques de securite IT. Elle ne couvre pas explicitement les types de menaces organisationnelles plus larges (planification de succession, problematiques environnementales, ou la facon dont les risques de securite s’articulent avec les risques metier). C’est une methodologie qui se concentre sur les composantes operationnelles d’une entreprise, pas necessairement sur le niveau strategique superieur.
4.2 FRAP (Facilitated Risk Analysis Process)
Le Facilitated Risk Analysis Process (FRAP) est un second type de methodologie d’evaluation des risques. L’essence de cette methodologie qualitative est de se concentrer uniquement sur les systemes qui necessitent reellement une evaluation, pour reduire les couts et les delais.
Le FRAP met l’accent sur les prescreenings pour que les etapes d’evaluation soient menees uniquement sur les elements qui en ont le plus besoin. Il est concu pour analyser un systeme, une application ou un processus metier a la fois. Les donnees sont recueillies et les menaces sont priorisees en fonction de leur criticite. L’equipe documente les controles a mettre en place et les plans d’action pour l’implementation.
4.3 OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)
La methodologie OCTAVE a ete creee par le Software Engineering Institute (SEI) de l’Universite Carnegie Mellon. Elle est destinee aux situations ou les personnes gerent et dirigent elles-memes l’evaluation des risques de securite de l’information au sein de leur organisation.
OCTAVE place les personnes qui travaillent au sein de l’organisation en position de pouvoir pour prendre les decisions concernant la meilleure approche d’evaluation de la securite. Elle repose sur l’idee que les collaborateurs qui travaillent dans l’environnement comprennent le mieux ce qui est necessaire et quels risques ils affrontent. Les individus de l’equipe d’evaluation participent a des series d’ateliers facilites. Le facilitateur aide les membres a comprendre la methodologie et comment l’appliquer aux vulnerabilites et menaces identifiees au sein de leurs unites metier. OCTAVE met l’accent sur une approche auto-dirigee par l’equipe.
Le perimetre d’OCTAVE est generalement beaucoup plus large que le FRAP. Alors que FRAP serait utilise pour evaluer un systeme ou une application, OCTAVE peut etre utilise pour evaluer tous les systemes, applications et processus metier de l’organisation.
Les 8 processus (etapes) d’OCTAVE
- Identifier les connaissances au niveau de l’entreprise
- Identifier les connaissances au niveau operationnel
- Identifier les connaissances du personnel
- Etablir les exigences de securite
- Cartographier les actifs d’information prioritaires vers l’infrastructure d’information
- Conduire l’evaluation des vulnerabilites de l’infrastructure
- Mener l’analyse de risque multidimensionnelle
- Developper la strategie de protection
4.4 FMEA (Failure Modes and Effect Analysis)
L’Analyse des Modes de Defaillance et de leurs Effets (FMEA) est une methode permettant de determiner les fonctions, d’identifier les defaillances fonctionnelles, d’evaluer les causes de defaillance et leurs effets a travers un processus structure. Elle est couramment utilisee dans le developpement de produits et les environnements operationnels.
L’objectif est d’identifier ou un systeme est le plus susceptible de tomber en panne, puis de corriger les failles ou d’implementer des controles pour reduire l’impact. Vous pouvez choisir de mener une FMEA sur votre reseau pour identifier les points uniques de defaillance (single points of failure), evaluer leur criticite (risque), et identifier les controles necessaires (reduction du risque).
La FMEA utilise les modes de defaillance (comment quelque chose peut casser ou echouer) et l’analyse des effets (impact de cette casse ou defaillance). L’application de ce processus a une defaillance chronique permet de determiner ou exactement la defaillance est la plus susceptible de se produire. Pensez-y comme la capacite de regarder vers l’avenir et de localiser les zones problematiques, puis d’appliquer des mesures correctives avant qu’elles ne deviennent des responsabilites reelles.
Les 5 etapes de la FMEA
- Commencer par un schema bloc d’un systeme ou controle
- Considerer ce qui se passe si chaque bloc du schema echoue
- Dresser un tableau dans lequel les defaillances sont associees a leurs effets et a une evaluation des effets
- Corriger la conception du systeme et ajuster le tableau jusqu’a ce que le systeme ne presente plus de problemes inacceptables
- Faire reviser par plusieurs ingenieurs l’Analyse des Modes de Defaillance et de leurs Effets
La FMEA a d’abord ete developpee pour l’ingenierie des systemes. Son objectif est d’examiner les defaillances potentielles dans les produits et les processus impliques. Cette approche s’est revelee efficace et a ete recemment adaptee pour la gestion des risques et la mitigation des vulnerabilites connues.
La FMEA est utilisee dans la gestion des risques d’assurance en raison du niveau de detail, de variables et de complexite qui continue de croitre a mesure que les entreprises comprennent le risque a des niveaux de plus en plus granulaires.
Table 2-2 : Exemple de documentation FMEA
| Element | Fonction | Mode de defaillance | Cause | Effet sur le composant | Effet sur l’assemblage superieur | Effet sur le systeme | Methode de detection |
|---|---|---|---|---|---|---|---|
| Filtre applicatif IPS | Protection perimetre en ligne | Cesse de fermer | Surcharge de trafic | Point unique de defaillance, deni de service | L’IPS bloque le flux de trafic entrant | L’IPS est mis hors service | Verification de sante, envoi du statut a la console et e-mail a l’administrateur securite |
| Moteur antivirus central | MAJ signatures push vers tous les serveurs et postes | Cesse de fournir une protection adequate et a jour | Le serveur central tombe en panne | Les logiciels antivirus individuels ne sont pas mis a jour | Le reseau est infecte par des malwares et/ou infecte d’autres systemes | Le serveur central peut etre infecte | Verification de battement, statut envoye a la console centrale et e-mail a l’administrateur reseau |
| Conduite de suppression incendie | Suppression incendie dans le batiment, 1 sur 5 zones | Cesse de fermer | L’eau dans les tuyaux gele | Aucun | Le batiment 1 n’a pas d’agent d’extinction disponible | Rupture des conduites du systeme d’extinction | Capteurs d’extinction connectes directement a la console du systeme incendie central |
4.5 Analyse par arbre de defaillance (Fault Tree Analysis)
Alors que la FMEA est tres utile comme methode de sondage pour identifier les principaux modes de defaillance d’un systeme donne, elle n’est pas aussi utile pour decouvrir les modes de defaillance complexes impliquant plusieurs systemes ou sous-systemes. L’analyse par arbre de defaillance (fault tree analysis) s’avere generalement plus efficace pour identifier les defaillances pouvant survenir au sein d’environnements complexes.
Un effet indesirable est pris comme la racine ou evenement sommet d’un arbre logique. Ensuite, chaque situation ayant le potentiel de causer cet effet est ajoutee a l’arbre sous forme de series d’expressions logiques. Les arbres de defaillance sont ensuite etiquetes avec des chiffres reels relatifs aux probabilites de defaillance, generalement a l’aide de programmes informatiques capables de calculer les probabilites a partir de l’arbre.
Lors de la construction de l’arbre, vous devez lister avec precision toutes les menaces ou defauts pouvant survenir dans un systeme. Les branches de l’arbre peuvent etre divisees en categories generales (menaces physiques, menaces reseau, menaces logicielles, menaces Internet, menaces de composants). Ensuite, une fois toutes les categories en place, vous pouvez elaguer les branches qui ne s’appliquent pas au systeme en question.
Quelques-uns des evenements de defaillance logicielle les plus courants pouvant etre explores a travers une analyse par arbre de defaillance :
- Fausses alarmes
- Gestion insuffisante des erreurs
- Problemes de sequencement ou d’ordre
- Sorties avec un timing incorrect
- Sorties valides mais inattendues
5. Approches d’analyse des risques
A ce stade, nous avons accompli les etapes suivantes : developper une politique de gestion des risques, constituer une equipe, identifier les actifs a evaluer, calculer leur valeur, identifier les vulnerabilites et menaces, et choisir une methodologie. La prochaine etape est de determiner si notre approche sera quantitative ou qualitative.
Une analyse quantitative des risques assigne des valeurs monetaires et numeriques a tous les elements de l’analyse (valeur des actifs, frequence des menaces, severite des vulnerabilites, cout des dommages, cout des contre-mesures, incertitude, probabilite). Chaque element est quantifie et entre dans des equations pour determiner le risque total et residuel. C’est une approche plus scientifique ou mathematique (objective).
Une analyse qualitative des risques utilise une approche plus « douce ». Elle ne quantifie pas les donnees et n’attribue pas de valeurs numeriques. Par exemple, la ou une analyse quantitative pourrait conclure que l’organisation risque de perdre 100 000 $ en cas de buffer overflow sur un serveur web, 25 000 $ si une base de donnees est compromise, et 10 000 $ si un serveur de fichiers est compromis, une analyse qualitative ne presenterait pas ces conclusions en valeurs monetaires mais assignerait des niveaux comme Haut, Moyen et Bas, ou des couleurs Rouge, Jaune et Vert.
Une analyse quantitative utilise des calculs de risque pour tenter de predire le niveau de pertes monetaires et la probabilite pour chaque type de menace. Une analyse qualitative ne fait pas ces calculs. Elle est davantage basee sur l’opinion et le scenario (subjective) et utilise un systeme de notation pour relayer le niveau de criticite du risque.
5.1 Outils automatises d’analyse des risques
La collecte de toutes les donnees necessaires pour alimenter les equations d’analyse des risques et l’interpretation correcte des resultats peut etre ecrasante si elle est faite manuellement. Plusieurs outils automatises sur le marche rendent cette tache beaucoup moins penible et, esperons-le, plus precise. Les donnees collectees sont reutilisables, ce qui reduit considerablement le temps necessaire pour les analyses subsequentes. L’equipe d’analyse des risques peut egalement produire des rapports complets et des graphiques a presenter a la direction.
L’objectif de ces outils est de reduire l’effort manuel, estimer les pertes futures attendues, et determiner l’efficacite et les benefices des contre-mesures choisies. La plupart des outils d’analyse automatisee des risques importent les informations dans une base de donnees et executent plusieurs types de scenarios avec differents parametres pour donner une vue panoramique des resultats si differentes menaces se concretisaient.
5.2 Etapes d’une analyse quantitative des risques
Si nous choisissons une analyse quantitative, nous allons utiliser des equations mathematiques pour notre processus d’interpretation des donnees. Les equations les plus courantes sont le SLE (Single Loss Expectancy) et l’ALE (Annualized Loss Expectancy).
Le facteur d’exposition (EF) represente le pourcentage de perte qu’une menace realisee pourrait causer sur un actif donne. Par exemple, si un entrepot de donnees a une valeur d’actif de 150 000 $ et qu’on estime qu’un incendie endommagerait 25 % de l’entrepot, alors le SLE serait de 37 500 $.
Le taux d’occurrence annualise (ARO) represente la frequence estimee d’une menace specifique sur une periode de 12 mois. Il peut aller de 0.0 (jamais) a 1.0 (une fois par an) et au-dela (plusieurs fois par an). Par exemple, si la probabilite d’un incendie est d’une fois tous les 10 ans, l’ARO est de 0.1.
La valeur de l’ALE indique a l’organisation combien elle devrait depenser par an pour proteger l’actif contre cette menace. Il ne serait pas judicieux pour l’organisation de depenser plus que 3 750 $ par an pour proteger l’entrepot contre les incendies.
Table 2-3 : Exemples de calculs SLE et ALE
| Actif | Menace | SLE (Single Loss Expectancy) | ARO (Annualized Rate of Occurrence) | ALE (Annualized Loss Expectancy) |
|---|---|---|---|---|
| Installation | Incendie | 230 000 $ | 0.1 | 23 000 $ |
| Secret commercial | Vol | 40 000 $ | 0.01 | 400 $ |
| Serveur de fichiers | Panne | 11 500 $ | 0.1 | 1 150 $ |
| Donnees metier | Ransomware | 283 000 $ | 0.1 | 28 300 $ |
| Informations de carte de credit client | Vol | 300 000 $ | 3.0 | 900 000 $ |
Avec ces donnees, l’organisation peut prendre des decisions metier intelligentes sur les menaces a traiter en priorite en fonction de leur severite, de la probabilite qu’elles se concretisent, et du montant a depenser pour se proteger. Par exemple, le risque de ransomware representant un ALE de 28 300 $, l’organisation peut justifier des depenses allant jusqu’a ce montant pour des mesures preventives comme les sauvegardes hors ligne, la formation de sensibilisation au phishing, la detection de malwares et l’assurance.
L’incertitude (Uncertainty)
En analyse des risques, l’incertitude fait reference au degre de manque de confiance dans une estimation. Elle est exprimee en pourcentage, de 0 a 100 %. Si vous avez un niveau de confiance de 30 % dans quelque chose, alors vous avez un niveau d’incertitude de 70 %. La capture du degre d’incertitude lors de la conduite d’une analyse des risques est importante, car elle indique le niveau de confiance que l’equipe et la direction devraient accorder aux chiffres resultants.
Lors d’une analyse quantitative, certaines personnes pensent a tort que le processus est purement objectif et scientifique parce que les donnees sont presentees sous forme de valeurs numeriques. Mais il reste toujours une part de subjectivite : comment savons-nous qu’un incendie ne se produira qu’une fois tous les 10 ans ? Comment savons-nous que les dommages d’un incendie seront exactement 25 % de la valeur de l’actif ? Nous ne connaissons pas ces valeurs exactement — elles doivent etre basees sur des donnees historiques et l’experience du secteur.
Resultats attendus d’une analyse quantitative
L’equipe d’analyse des risques doit avoir des objectifs clairement definis. Voici les resultats generalement attendus :
- Valeurs monetaires assignees aux actifs
- Liste exhaustive de toutes les menaces significatives
- Probabilite d’occurrence de chaque menace
- Potentiel de perte que l’organisation peut supporter par menace sur une periode de 12 mois
- Contre-mesures recommandees
Bien que cette liste paraisse courte, il y a generalement un detail considerable sous chaque element. Le rapport sera presente a la direction, qui se preoccupera des pertes monetaires potentielles et des couts necessaires pour attenuer ces risques. Bien que le rapport doive etre aussi detaille que possible, il devrait aussi inclure un resume executif pour que la direction puisse rapidement saisir les conclusions globales de l’analyse.
5.3 Analyse qualitative des risques
Une autre methode d’analyse des risques est qualitative : elle n’assigne pas de chiffres ni de valeurs monetaires aux composantes et aux pertes. Au lieu de cela, les methodes qualitatives parcourent differents scenarios de possibilites de risque et classent la gravite des menaces ainsi que la validite des differentes contre-mesures possibles. (Un balayage large peut inclure des centaines de scenarios.)
Les techniques d’analyse qualitative pour recueillir les donnees comprennent le jugement, les meilleures pratiques, l’intuition et l’experience. Des exemples de techniques qualitatives incluent :
- Technique Delphi
- Brainstorming
- Storyboarding
- Focus groups
- Enquetes et questionnaires
- Checklists
- Entretiens individuels
L’equipe d’analyse determine la meilleure technique pour les menaces a evaluer, en tenant compte de la culture de l’organisation et des individus impliques.
L’equipe qui effectue l’analyse rassemble du personnel ayant une connaissance des menaces evaluees. Chaque membre du groupe recoit un scenario decrivant les menaces et leur potentiel, et repond en donnant son ressenti et son experience sur la probabilite de la menace et l’etendue des dommages possibles. Le groupe explore chaque scenario de vulnerabilite identifiee et la facon dont elle pourrait etre exploitee. L’« expert » du groupe, celui qui est le plus familier avec ce type de menace, revise le scenario pour s’assurer qu’il reflete une menace reelle. Les protections qui diminueraient les dommages sont evaluees, et le scenario est joue pour chaque protection.
Matrice de risque qualitative (Figure 2-4)
L’exposition et la possibilite de perte peuvent etre classees comme haute, moyenne ou basse sur une echelle de 1 a 5 ou de 1 a 10. Une matrice de risque qualitative courante est presentee ci-dessous :
La technique Delphi
La technique Delphi est une methode de decision de groupe utilisee pour s’assurer que chaque membre donne une opinion honnete de ce qu’il pense que sera le resultat d’une menace particuliere. Elle evite qu’un groupe d’individus se sente presse de suivre les processus de pensee des autres et leur permet de participer de maniere independante et anonyme.
Chaque membre du groupe fournit son opinion sur une menace donnee et la soumet a l’equipe effectuant l’analyse. Les resultats sont compiles et distribues aux membres du groupe, qui ecrivent ensuite leurs commentaires anonymement et les retournent au groupe d’analyse. Les commentaires sont compiles et redistribues pour d’autres commentaires jusqu’a ce qu’un consensus soit forme. Cette methode est utilisee pour obtenir un accord sur les couts, les valeurs de perte et les probabilites d’occurrence sans que les individus aient a s’exprimer verbalement.
Table 2-4 : Exemple d’analyse qualitative
L’equipe d’analyse des risques presente un scenario expliquant la menace d’un hacker accedant a des informations confidentielles sur cinq serveurs de fichiers au sein de l’organisation. Le scenario est distribue sous forme ecrite a une equipe de cinq personnes (responsable IT, administrateur BDD, developpeur, operateur systeme, responsable operationnel), qui evaluent chaque critere de 1 a 5 (1 etant le moins severe/probable) :
| Menace : Hacker accedant aux informations confidentielles | Severite | Probabilite de la menace | Perte potentielle pour l’organisation | Efficacite du pare-feu | Efficacite du systeme de detection d’intrusion | Efficacite du honeypot |
|---|---|---|---|---|---|---|
| Responsable IT | 4 | 2 | 4 | 4 | 3 | 2 |
| Administrateur BDD | 4 | 4 | 4 | 3 | 4 | 1 |
| Developpeur | 2 | 3 | 3 | 4 | 2 | 1 |
| Operateur systeme | 3 | 4 | 3 | 4 | 2 | 1 |
| Responsable operationnel | 5 | 4 | 4 | 4 | 4 | 2 |
| Resultats (moyennes) | 3.6 | 3.4 | 3.6 | 3.8 | 3 | 1.4 |
Ces donnees sont compilees dans un rapport et presentees a la direction. Avec ces informations, la direction verra que son personnel (ou un ensemble choisi) estime que l’achat d’un pare-feu protegera l’organisation contre cette menace mieux qu’un systeme de detection d’intrusion (IDS) ou un honeypot. C’est le resultat de l’examen d’une seule menace, et la direction examinera la severite, la probabilite et le potentiel de perte de chaque menace pour savoir lesquelles presentent le plus grand risque et lesquelles doivent etre traitees en premier.
6. Quantitatif vs qualitatif : comparaison
Chaque methode a ses avantages et inconvenients. L’equipe d’analyse des risques, la direction, les outils d’analyse et la culture de l’organisation determineront quelle approche — quantitative ou qualitative — devrait etre utilisee. L’objectif de l’une ou l’autre est d’estimer le risque reel d’une organisation et de classer la severite des menaces afin de mettre en place les bonnes contre-mesures dans un budget realiste.
Table 2-5 : Quantitatif vs qualitatif — 10 attributs compares
| Attribut | Quantitatif | Qualitatif |
|---|---|---|
| Ne necessite pas de calculs | X | |
| Necessite des calculs plus complexes | X | |
| Implique un degre eleve de supposition | X | |
| Fournit des zones generales et des indications de risque | X | |
| Est plus facile a automatiser et evaluer | X | |
| Utilise dans le suivi des performances de gestion des risques | X | |
| Permet l’analyse cout/benefice | X | |
| Utilise des metriques verifiables et objectives de maniere independante | X | |
| Fournit les opinions des personnes qui connaissent le mieux les processus | X | |
| Presente des pertes claires pouvant etre accumulees sur un an | X |
Inconvenients de l’approche quantitative
- Les calculs peuvent etre complexes. La direction peut-elle comprendre comment ces valeurs ont ete derivees ?
- Sans outils automatises, le processus est extremement laborieux
- Un travail preparatoire important est necessaire pour recueillir des informations detaillees sur l’environnement
- Les standards ne sont pas disponibles : chaque fournisseur a sa propre facon d’interpreter les processus et leurs resultats
Inconvenients de l’approche qualitative
- Les evaluations et les resultats sont subjectifs et bases sur l’opinion
- Elimine la possibilite de creer une valeur monetaire pour les discussions cout/benefice
- Developper un budget de securite a partir des resultats est difficile car les valeurs monetaires ne sont pas utilisees
- Les standards ne sont pas disponibles : chaque fournisseur a sa propre facon d’interpreter les processus et leurs resultats
Points cles a retenir
- L’evaluation des risques (risk assessment) est l’effort global de collecte de donnees ; l’analyse des risques (risk analysis) est l’examen detaille de ces donnees pour produire des resultats exploitables.
- Les 4 objectifs de l’analyse des risques : identifier les actifs et leur valeur, determiner la probabilite des menaces, evaluer l’impact metier, fournir un equilibre economique.
- La valorisation des actifs repose sur 10 criteres et doit couvrir les actifs tangibles et intangibles.
- L’equipe d’evaluation doit etre inter-departementale et poser 4 questions cles : evenement possible, impact potentiel, frequence, degre de certitude.
- NIST SP 800-30 : focus securite IT, 4 etapes (preparer, conduire, communiquer, maintenir).
- FRAP : qualitatif, un systeme a la fois, pas de formules mathematiques.
- OCTAVE : Carnegie Mellon SEI, auto-dirige, 8 processus, perimetre organisation entiere.
- FMEA : modes de defaillance et effets, 5 etapes, identification des points uniques de defaillance.
- Analyse par arbre de defaillance : portes logiques OR (un evenement suffit) et AND (tous les evenements necessaires), ideal pour les systemes complexes.
- Formules quantitatives : SLE = AV x EF et ALE = SLE x ARO.
- L’incertitude est exprimee de 0 a 100 % et indique le degre de manque de confiance dans les estimations.
- L’analyse qualitative utilise des techniques comme Delphi, brainstorming, focus groups et produit des classements (L/M/H/E) plutot que des valeurs monetaires.
- La technique Delphi permet une participation anonyme et independante pour atteindre un consensus sans pression sociale.
- L’approche hybride (quantitatif pour les actifs tangibles, qualitatif pour les intangibles) est la plus pragmatique.
Glossaire
| Risk Assessment | Evaluation des risques : processus global d’identification des vulnerabilites, des menaces et d’estimation des impacts pour determiner ou implementer des controles de securite. |
| Risk Analysis | Analyse des risques : examen detaille des composantes du risque visant a s’assurer que la securite est rentable, pertinente, opportune et reactive face aux menaces. |
| Asset Valuation | Valorisation des actifs : processus d’attribution d’une valeur monetaire ou relative aux actifs de l’organisation, base sur 10 criteres incluant le cout d’acquisition, de maintenance, de remplacement et l’impact en cas de perte. |
| Project Sizing | Dimensionnement du projet : etape prealable a une evaluation des risques visant a definir le perimetre (securite physique, technologique, personnel) et les contraintes budgetaires. |
| NIST SP 800-30 | Guide du NIST pour la conduite d’evaluations des risques, specifique aux systemes d’information. 4 etapes : preparer, conduire, communiquer, maintenir. |
| FRAP | Facilitated Risk Analysis Process : methodologie qualitative concentree sur un systeme a la fois, sans formules mathematiques, privilegiant l’efficacite et la rentabilite. |
| OCTAVE | Operationally Critical Threat, Asset, and Vulnerability Evaluation : methodologie du SEI de Carnegie Mellon, auto-dirigee par l’equipe, 8 processus, perimetre organisationnel large. |
| FMEA | Failure Modes and Effect Analysis : methode structuree d’identification des defaillances fonctionnelles, de leurs causes et de leurs effets, en 5 etapes. |
| Fault Tree Analysis | Analyse par arbre de defaillance : methode utilisant des portes logiques OR et AND pour modeliser les defaillances dans des environnements complexes multi-systemes. |
| SLE (Single Loss Expectancy) | Perte attendue pour un seul evenement. Formule : SLE = Valeur de l’actif (AV) x Facteur d’exposition (EF). |
| ALE (Annualized Loss Expectancy) | Perte attendue annualisee pour une menace donnee. Formule : ALE = SLE x ARO. |
| ARO (Annualized Rate of Occurrence) | Taux d’occurrence annualise : frequence estimee d’une menace sur une periode de 12 mois. Plage de 0.0 (jamais) a plus de 1.0 (plusieurs fois par an). |
| EF (Exposure Factor) | Facteur d’exposition : pourcentage de l’actif qui serait endommage si une menace specifique se concretisait. |
| Uncertainty | Incertitude : degre de manque de confiance dans une estimation, exprime en pourcentage de 0 a 100 %. |
| Technique Delphi | Methode de decision de groupe ou chaque participant fournit son opinion de maniere anonyme et independante, avec des iterations jusqu’a consensus. |
| Cost/Benefit Comparison | Comparaison cout/benefice : mise en regard du cout annualise des controles face au cout potentiel de la perte pour determiner la pertinence d’un investissement en securite. |
| Single Point of Failure | Point unique de defaillance : composant dont la panne entraine l’arret de tout un systeme ou service. |