Qu'est-ce qu'une analyse de risque ?

Je suppose que si vous avez atterri sur cette page, c’est que vous savez ou pensez savoir ce qu’est une analyse de risque parce que vous en avez réalisé entre plusieurs et beaucoup. Probablement des analyses qualitatives, qui sont prépondérantes ou bien semi-quantitatives (ou hybrides), avec les valeurs ordinales illustrées dans les fameuses cartographies en plages colorées du vert au rouge (en anglais heatmap, en français carte thermique … mais d’où vient la couleur verte ?).
Vous avez sans doute parcouru une des nombreuses méthodes d’analyse et d’évaluation des risques … on ne manque pas de littérature dans ce domaine, et si vous travaillez dans les TI ou la cybersécurité, vous vous serez familiarisé soit avec ISO 31000 (risques d’entreprise) ou ISO 27005 (TI et sécurité de l’information), soit avec EBIOS RM. Les plus courageux, ou les plus anciens, ont peut-être côtoyé la méthode MEHARI dans la francophonie et OCTAVE dans l’anglophonie. Les plus fortunés auront peut-être opté par la méthode IRAM2 de l’ISF. Les amoureux des publications du NIST (j’en suis) auront compris comment se complètent les guides SP800-39, 37 et 30. Les plus avant-gardistes (toute proportion gardée), se seront déjà lancés dans la course à la quantification des risques, et il y a beaucoup de chances que vous aurez pénétré le monde merveilleux, mais imparfait, de FAIR (Factor Analysis of Information Risk) affinée par Jack Jones au fil du temps. Je recommande fortement de lire son livre intellectuellement stimulant pour corriger certains défauts hérités de décennies de dérives méthodologiques.

Toutes les méthodologies (comprendre « méthode des méthodes »), les cadres, les bonnes pratiques existent pour accompagner les gestionnaires de risque d’abord, puis les analystes, dans leur quotidien. Toutes introduisent, souvent de manière superficielle, au processus d’analyse et d’évaluation en donnant les étapes logiques. Mais est-ce qu’elles enseignent réellement à analyser un risque ? Force est de constater que non. Elle ont toutes le défaut de séduire exclusivement les analystes qui vont préférer une approche plutôt qu’une autre, vont s’y attacher et négliger toutes les autres. Les bonnes pratiques favorisent un ancrage et endorment les facultés intellectuelles.

L’organisme Étatsunien NIST nous donne 3 définitions dans son glossaire en ligne.

La plus simple : « Le processus qui consiste à comprendre la nature du risque et à déterminer le niveau de risque. » (provient du glossaire ISO 27000)
La plus procédurale (et erronée) : « Le processus global d’identification, d’analyse et d’évaluation du risque » (en fait c’est la définition de l’appréciation de risque de ISO 27000).
La plus complexe : « Le processus d’identification des risques relatifs aux opérations organisationnelles (incluant la mission, les fonctions, l’image, la réputation), les actifs organisationnels, les individus, les autres organisations, et la nation, résultant de l’opération d’un système » (respirez !).

ISO 27005, lui, distingue l’étape d’identification des risques de l’étape d’analyse. Et il a raison, il faut pouvoir avoir identifié des éléments de risque pour pouvoir en faire une analyse. Complétons la définition de ISO 27000 :

« Note 1 : L’analyse du risque fournit la base de l’évaluation du risque (2.74) et des décisions relatives au traitement du risque (2.79).
Note 2 : L’analyse du risque inclut l’estimation du risque. »

Ces définitions sont comme toutes les autres imparfaites, mais elles offrent déjà quelques mots-clés intéressants :

Consiste à comprendre la nature du risque
Consiste à déterminer le niveau de risque (même chose que « inclut l’estimation du risque »)
Fournit la base de l’évaluation de risque

Revenons aux bases par une définition générique du mot « Analyse » (Larousse) : « Étude minutieuse, précise faite pour dégager les éléments qui constituent un ensemble, pour l’expliquer, l’éclairer. » Voilà. Il suffit maintenant de l’appliquer au risque …

Étude minutieuse : on ne le dira pas assez, malgré toutes les aides qui sont mises à notre disposition, il faut comprendre que l’analyse est une étude minutieuse. Donc lorsqu’un gestionnaire vient nous voir à 8h pour obtenir une analyse express pour 16H le même jour, il faut user de tact pour lui expliquer ce qu’une analyse de risque requiert comme temps pour la collecte d’informations, leur compréhension, leur synthèse, etc.
Éléments constitutifs : cela a l’air d’aller de soi, mais un risque est une chose assez complexe. Il faut pouvoir l’appréhender, en décomposer les parties, expliquer et évaluer sa nature incertaine.
Expliquer, éclairer : avant même de penser à évaluer quelque chose qui ressemble à un risque, au débotté, entre le fromage et le dessert, résumé sur un napperon de papier, il faut vraiment comprendre l’enjeu et être capable de l’expliquer à une personne totalement (ou presque néophyte). Encore une fois, cela requiert du temps, l’expérience aide, avec son lot d’erreurs qui tracent le chemin de la compréhension.

Trop souvent, les analyses de risque, spécialement celles qui sont outillées, sont une agrégation très expéditive de spéculations sans aucune rationalité, produites à la minute ou presque, sans produire aucune documentation soutenant les hypothèses retenues et le contexte relatif au problème posé. En revanche, elles vont dans le plus grand des détails pour évaluer tout un tas de critères afin de rendre cette (absence d’)analyse crédible.

Analyse de risque : « c’est l’étude minutieuse, aussi précise que possible, d’un événement incertain (appelé risque) pouvant affecter une organisation, dont il faut comprendre et estimer ses composantes (ou facteurs) que sont sa probabilité (ou vraisemblance) d’occurrence et la magnitude de son impact . »

Une analyse de risque a donc ses propres exigences, somme toute assez logiques, que sont :

Un temps suffisant pour analyser le problème posé
L’existence d’une documentation (données en entrée du processus)
La capacité à communiquer aussi bien à l’oral qu’à l’écrit les conclusions de l’analyse
La capacité à identifier, recueillir des données de qualité, pertinentes et aussi exactes que possible
La capacité à énoncer des faits et émettre des hypothèses plausibles pour le contexte de l’analyse.

Il va sans dire qu’actuellement il y a une mode qui se répand rapidement, de se prétendre analyste émérite sans jamais rien lire sur les risques (ni sur rien en général) et de refuser d’écrire un rapport d’analyse de risque décent, dans un français correct (compréhensible). J’offre un conseil gratuitement aux recruteurs dans notre industrie : demandez au candidat à un poste d’analyste de risque quel est le dernier ouvrage qu’il a lu sur le sujet et s’il a de la facilité pour rédiger des rapports. Soyez même taquins, testez ce qu’il vous répondra, car ce qui est aussi très en vogue c’est de survendre une expérience souvent indigente voire inexistante en matière d’analyse de risque. Comprendre, en gros, ce que devrait être la gestion de risques avec ses rôles et ses responsabilités, les différentes lignes de défense (être certifié CRISC par exemple), ne sous-entend aucunement que l’on soit capable d’analyser les risques.

Mais alors qu’analyse-t-on ?

Je vous remercie d’avoir posé cette question … L’objet étudié est un événement incertain (le risque). Cet événement nous intéresse parce qu’à un moment donné quelqu’un a eu une inquiétude sur le fait d’être personnellement (ou plus probablement son organisation) exposé d’une manière ou d’une autre à cet événement. En général, surtout en sécurité de l’information, celui-ci a des effets négatifs, c’est-à-dire qu’il pourrait générer une perte qu’il est possible de qualifier (ca fait mal un peu, beaucoup ou terriblement) et/ou de quantifier (puisque les entreprise ont vocation à gagner de l’argent, elles n’aiment pas en perdre).

On analyse d’abord le problème posé, ici ce fameux événement qui nous empêcherait de dormir. Il faut le définir clairement et lui attribuer un contexte. Ce problème se manifesterait dans des circonstances particulières, sous différentes influences qu’il faudra identifier et en estimer l’importance. Dans les technologies et en sécurité de l’information, cet événement va d’abord affecter les biens tangibles (relativement concrets) de l’entreprise avant d’impacter ceux non tangibles (relativement abstraits). Un système informatique est tangible, une information ou un processus le sont nettement moins, même si on en perçoit l’existence. En général le bien tangible contient et manipule des informations qui servent à un processus. Sinon ces informations n’auraient aucune valeur pour l’entreprise.

L’analyse étant un processus cognitif cherchant à appréhender des incertitudes (ce qu’on connaît mal ou pas du tout), il est fréquent que cela implique de poser des questions, à soi-même ou à un gentil collègue qui fera semblant d’écouter. Et là il y a tout un tas de questions à poser :

Pourquoi est-ce qu’un tel événement est possible ? L’est-il vraiment ? Dans quelles circonstances peut-il surgir et générer un effet négatif ?
De quel type d’événement s’agit-il ? Est-ce un événement accidentel ou intentionnel ? Serait-il le fruit du hasard ou d’une vile conspiration ?
Qui aurait intérêt à déclencher un tel événement (même si cet aspect intéresserait davantage les forces de l’ordre que nous-mêmes, cela permet de dessiner la tableau complet relatif au problème posé)
Ai-je déjà vécu ce type d’événement, dans quelles circonstances et avec quel effet sur mes activités ? Avec quelle fréquence ?
Est-ce que les événements passés peuvent m’informer sur les événements futurs ? Accidentels sûrement, intentionnels probablement pas …
Puisque tout événement a au moins une cause et au moins une conséquence, quelles seraient elles ?
De quelle manière peut-il m’affecter directement et indirectement (effet de bord) ?
Quels sont les différents types de biens (ou actifs) qui pourraient être affectées et par quelle action ? À quel point ces biens sont importants pour moi ?
Ont-ils une valeur pécuniaire estimable ?
Puis-je estimer la conséquence engendrée par cet événement ?

Ces questions ne sont pas exhaustives, mais les réponses permettent de commencer à envisager des scénarios de risque (ou modalités de pertes) plausibles, pertinents qui seront évalués … je ne suis pas un fan de la confusion engendrée par ISO 27005 parlant d’appréciation et d’évaluation, et des boîtes dans des boîtes. présenté simplement le processus ressemblerait à quelque chose comme ça, dans une vision laïque, à chaque boîte correspondrait son lot de questions :

Même si je n’ai pas spécifiquement parlé d’analyse de risque en tant que tel, on peut reconnaître les différentes étapes et on peut les rapprocher des questions posées plus haut. Tous ces éléments d’analyse doivent être documentés sous deux formes : dans un rapport de risque détaillé pour fournir les arguments et les données sur demande de toute partie prenante et dans un document de synthèse (résumé analytique / sommaire exécutif).

L’analyse de risque est le cœur du système et il faut lui apporter tout le soin nécessaire. Que vous utilisiez une approche qualitative ou quantitative de l’évaluation des risques, la phase de l’analyse est la même. C’est elle qui va recueillir les informations pertinentes et exactes, puis informer et expliquer. Si les informations prises en compte sont de piètre qualité, il ne faut rien attendre du rapport d’analyse de risque et de l’évaluation qui suit. Si on on saisit des erreurs dans un système, on obtiendra des résultats erronés. Même si on les exprime en dollars et qu’on exploite des simulateurs Monte-Carlo.
Si on est trop paresseux pour documenter l’analyse, où se trouvera sa mémoire, dans le cerveau de l’analyste qui en réalisera vingt ou cinquante à l’année ? Comment être capable de défendre les résultats qui pourraient impliquer de nouveaux investissements ?

Igor S.

CISSP, CRISC, CISM, ISO 27001, ISO 27005, ISO 27032

Qu’est-ce qu’une analyse de risque ?