Un des exemples fréquemment rencontrés dans le domaine de la gestion des risques, c’est l’utilisation d’une 𝐠𝐫𝐢𝐥𝐥𝐞 𝐝’𝐢𝐦𝐩𝐚𝐜𝐭𝐬 métier (en France), d’affaires (au Québec), organisationnels (dans tous mes référentiels, car tout impact doit affecter l’organisation et pas seulement les affaires).

Que vous dit-on ? Une fois défini un scénario de risque, on l’évalue par rapport à l’impact (conséquence pour ISO 27005:2022) que celui-ci aurait sur l’organisation, pour que celle-ci se sente concernée. Généralement, on utilise des types d’impacts très génériques. Ce sont des « valeurs » de l’organisation qui peuvent être affectés de manière négative par les événements d’origine cyber scénarisés.

Le NIST a deux définitions intéressantes relatives à la sécurité de l’information, qui se complètent, et qui en disent tout de suite beaucoup plus que la définition de ISO 27000 :

1. La magnitude de dommage qui peut être attendue comme conséquence d’une divulgation non autorisée d’informations, d’une modification non autorisée de l’information, de la destruction non autorisée d’informations ou de la perte d’information ou d’indisponibilité du système d’informations.

2. L’effet sur les opérations, les actifs, les individus d’une organisation, les autres organisations ou la Nation résultant d’une perte de la confidentialité, de l’intégrité ou de la disponibilité d’un système d’information.

L’impact est donc l’estimation d’une conséquence. Et la conséquence est un événement (survenue d’un ensemble de circonstances attirant l’attention). Ceux qui me suivent ou qui ont suivi une de mes formations en gestion des risques, ont l’habitude de me voir dsitinguer les événements en événement causal et événement conséquent (désolé pour certains archaïsmes). Un scénario de risque n’est que la juxtaposition de ces deux types d’événements interdépendants, l’un étant la cause de l’autre. Nous refusons d’utiliser le terme plus simple de « cause » car il conduirait rapidement à identifier des faiblesses ou des vulnérabilités en lieu et place à des événements initiaux. Or une faiblesse ou une vulnérabilité décrit un état (statique) et non un événement (dynamique). Sans aller trop dans le détail, il est possible de construire des arbres entiers de causes et de conséquences en retraçant tous les événements consécutifs depuis l’état de faiblesse originelle jusqu’à l’événement final entraînant des conséquences larges sur l’organisation. C’est cet enchaînement d’événements qui constitue le scénario de risque le plus complet.

Parmi les impacts qui sont le plus souvent considérés, on trouve :

• L’impact réputationnel (notion « tarte à la crème ») : événements ayant un effet sur la réputation de l’organisation
• L’impact financier (notion très floue, tout n’a-t-il pas une conséquence financière 𝑖𝑛 𝑓𝑖𝑛𝑒 ?) : événements ayant un effet sur les finances de l’organisation
• L’impact stratégique (qu’est-ce qu’une stratégie ?)  : événements ayant un effet sur la stratégie de l’organisation
• L’impact légal ou réglementaire : provenant de la non-application des lois et des règlements applicables
• L’impact opérationnel  : événements ayant un effet sur les opérations de l’organisation (quand ce type d’impact maque, le monde semble dépeuplé)

Ces impacts définissent des types ou des catégories d’impacts. Chaque organisation a ses propres biais pour les identifier et les sélectionner. Une première ligne de défense héritera très certainement des référentiels imposés par la deuxième ligne de défense, que ceux-ci soient pertinents ou non (voir un prochain article sur les méfaits de la propagation des erreurs ou l’idée que la conformité à de mauvais référentiels doive l’emporter sur la pertinence conduisant au non respect des réféfentiels). Il y a d’emblée beaucoup de choses à dire sur cette typologie fragile, on y reviendra. Maintenant, peuvent-ils s’appliquer à un scénario de cybersécurité ?

Prenons un exemple de scénario issu du référentiel Cobit 5, qui n’est pas la meilleure source, mais certaines organisations s’obstinent à l’utiliser malgré tout : « Il y a une infection régulière des ordinateurs portables par des maliciels » (catégorie Malware) ou encore « Des utilisateurs non autorisés essayent de s’introduire dans des systèmes » (catégorie Logiciels). Nous avons bien deux scénarios différents portant sur deux événements distincts dont il faudra estimer, nous dit-on, l’impact sur l’organisation. Organisons cela en tableau pour visualiser les mises en correspondance :

Il y a ici deux problèmes : le scénario de risque est très opérationnel et il ne permet pas de déduire avec certitude le type d’impact qu’il aura sur l’organisation, mais assurément, ils traitent d’événements qui affecteront, plus ou moins, les opérations ; les types d’impacts manquent de granularité et semblent bien lointains des événements décrits par les scénarios. Ce phénomène s’accroît dramatiquement lorsque les organisations décident qu’un scénario de risque doit décrire des attaques. Premier constat : il est presque toujours impossible de déduite les conséquences précises qu’auront des événements de cybersécurité lorsqu’ils ne décrivent que des procédés techniques, des tactiques ou des vecteurs d’attaque. Deuxième constat : l’injonction théorique nous fait oublier une notion basique qu’un scénario de risque de cybersécurité est avant tout opérationnel et, comme l’énoncent les définitions ci-dessus, on s’attend à décrire et à mesurer avant tout des conséquences de sécurité. Et cette partie est souvent oubliée par les équipes en charge des analyses des risques ou de la conception des référentiels, par abus de théorie et manque de pragmatisme. Le BIA (Business Impact Assessment), dans le contexte d’une analyse de risque et non de la continuité d’activité, procède toujours de d’un SIA (Security Impact Assessment). En fait, dans la pratique, ils sont indissociables. Les dissocier est une erreur qui diminue la pertinence du travail de l’analyste.

Voici le tableau qui devrait être utilisé en premier lieu. Chaque type d’impact organisationnel issue d’un BIA est découpé en 3 critères de SIA (valables pour la sécurité de l’information) symbolisés par la triade CID (pour Confidentialité, Intégrité, Disponibilité) :

On l’interprète comme cela : « quel événements relatifs à la perte de confidentialité. intégrité et disponibilité de l’actif X auraient une conséquence notable sur l’axe réputationnel, financier, réglementaire ou opérationnel ? »

En se posant systématiquement ce type de question, on va pouvoir s’assurer aussi que le scénario de risque retenu n’est pas juste un événement de menace simple (vecteur, TTP), mais décrit des circonstances qui affectent réellement l’organisation à partir de la perte d’objectifs. Si on fait l’erreur de décrire un scénario par « risque d’élévation de privilège » il sera illusoire de le rattacher à un quelconque risque. En revanche, l’ajout de vecteurs et de TTPs dont on aura préalablement recueilli des statistiques, permettent non seulement de compléter et rendre unique un scénario, mais aussi d’estimer les probabilités d’occurrence des événements.

Mais si on voulait décrire des conséquences pertinentes, il faudrait les rendre plus granulaires et les associer à des événements conséquents qui aient un sens pour l’organisation. Par exemple, pour l’organisation Y, quels événements spécifiques pourraient affecter négativement la réputation ? D’où le tableau suivant :

Tout événement de cybersécurité (événement causal) doit être associé à une conséquence pour l’organisation (événement conséquent) qui peut être mesurable par l’organisation.

Une fois que nous avons corrigé ce premier problème, force est de constater que cette typologie très générale est conceptuellement un peu fragile. D’abord, pour une organisation, toute conséquence affecte directement ou indirectement ses capacités financières, que ce soit par une perte de revenu, une sanction administrative ou un dépassement de budget. On s’attendrait donc à ce que l’aspect financier se retrouve en filigrane dans toutes les conséquences. Ensuite, on doit distinguer les conséquences immédiates (souvent plus fréquentes, mais de moins grande magnitude) à un événement de cybersécurité, des conséquences tardives (souvent plus rares, mais de plus grande magnitude). Et pour une fois, je vais reprendre tel quel le modèle apporté par la méthode FAIR (Factor Analysis of Information Risk) qui devrait être étudiée par tous les analystes qualitatifs tant elle remet de l’ordre et du bon sens dans l’exercice de la discipline.

FAIR énonce les conséquences suivantes :

• Magnitude de Perte Primaire (PLM, Primary Loss Magnitude) associées aux réaction des parties prenantes primaires (qui sont affectées immédiatement)
  • Perte de productivité (ralentissement de la production, chômage technique)
  • Remplacement d’un bien ou correction d’un problème
  • Réaction (immédiate) à un incident (p. ex. déclenchement d’un plan de continuité des affaires, confinement d’un système, activation d’une cellule de crise)
• Magnitude de Perte Secondaire (SLM, Secondary Loss Magnitude) associées aux réaction des parties prenantes secondaires (qui sont affectées plus tard)
  • Perte d’un avantage compétitif (ou d’une part de marché)
  • Atteinte à la réputation (coûts liés aux relations publiques)
  • Amendes et décisions de justice (coûts liés à assurer une défense juridique)
  • Réaction (plus tardive) à un incident (p. ex. le coût lié à l’implication des forces de l’ordre, à la notification de régulateurs et clients)

Parce que ces conséquences sont issues d’une méthode quantitative ou le coût financier est le dénominateur commun, aucun impact financier n’est mis en exergue. La méthode offre une typologie plus pertinente.

Revenons à nos moutons cybernétiques : si le scénario sélectionné ne décrit pas un événement pouvant être associé à l’une des conséquences ci-dessus, c’est qu’il n’est pas pertinent et est inexploitable. Reprenons un des exemples de scénarios Cobit très imparfaits ci-dessus et ajoutons des informations manquantes pour construire des scénarios plus pertinents, distincts et procédant de la perte de la confidentialité, de l’intégrité et de la disponibilité :

• Il y a une infection régulière des ordinateurs portables par des maliciels (entraînant quoi pour les utilisateurs, les processus de l’organisation ?)
  • Ralentissant le poste de travail (conséquence primaire sur le système)
    • Réduisant la productivité des utilisateurs légitimes
      • Forçant les équipes informatiques à intervenir
    • Entraînant le mécontentement des utilisateurs
      • Forçant les équipes informatiques à intervenir
  • Entraînant un redémarrage inopiné d’applications (conséquence primaire sur les applications)
    • Réduisant la productivité des utilisateurs légitimes
    • Entraînant le mécontentement des utilisateurs
• Des utilisateurs non autorisés essayent de s’introduire dans des systèmes (pour faire quoi ? Avec quelles conséquences ?)
  • Dégradant le fonctionnement du système
    • Réduisant la productivité des utilisateurs légitimes
    • Entraînant le mécontentement des utilisateurs
  • Accédant en lecture à des données confidentielles
    • Entraînant une non-conformité réglementaire
      • Affectant la réputation de l’entreprise
      • Menant à une amende pour non-conformité
    • Entraînant une violation d’obligations contractuelles
      • Menant la perte d’un client important
    • Entraînant des articles de presse à grande diffusion
      • Affectant durablement la répudiation de l’organisation
        • Menant à des opérations dispendieuses de relations publiques
      • Provoquant une fuite importante de clients

Ce n’est pas exhaustif, mais cela renforce la structure et la mise en relation des événements. Ces relations peuvent être mises en évidence par des arbres de conséquences complets.

Dans les exemples incorrects provenant de Cobit 5, il est difficile de faire une association plausible. Il vaudra mieux réécrire un scénario en suivant la syntaxe suivante, plutôt que de sélectionner au hasard dans divers référentiels des mauvais exemples :

Cas 1 : l’audience principale n’est pas technique

Impact sur les CID + événement de sécurité haut niveau + actif concerné + type d’acteur (interne/externe) (+ cause supposée ou avérée) + Conséquence organisationnelle

Par exemple :
« Indisponibilité de la base de données X par suite de l’attaque par un acteur externe (rendue possible par un défaut de configuration) occasionnant une perte importante de productivité (idéalement quantifiable). »

Cas 2 : l’audience principale est technique

Impact sur les CID + TTP ou vecteur + actif concerné (+ cause supposée ou avérée) + Conséquence opérationnelle

Par exemple :
« Divulgation de données confidentielles suite à un abus de privilèges par un acteur interne permettant de visualiser le contenu d’une base de données X (rendue possible par un processus d’octroi des permissions défaillant) occasionnant une non-conformité avec la loi sur la protection des renseignements personnels (Québec) »

En résumé :

• Le choix de la typologie d’impacts (ou de conséquences) est très important et il doit avoir du sens autant pour décrire un scénario de cybersécurité que pour estimer les conséquences sur l’organisation
•  Le choix de la typologie doit influencer la manière dont on décrit un scénario de risque pour permettre de faire un lien logique et vraisemblable
• Il est impossible d’estimer une conséquence autre qu’opérationnelle pour un événement si on ne retient de lui que son aspect opérationnel et technique
• On ne doit jamais faire ce qu’une norme, un cadre ou une bonne pratique nous force ou suggère de le faire, par principe, mais parce que cela fait du sens après analyse de toutes les informations et après avoir porté un regard critique

Igor Scerbo est le fondateur de l’entreprise de services Cyriskintel, le concepteur de divers référentiels et formateur en gouvernance et gestion des risques.

The post Méfiez-vous des injonctions issues de bonnes pratiques appeared first on Cyriskintel.

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

The post Qu’est-ce qu’une analyse de risque ? appeared first on Cyriskintel.