Qu’est-ce qu’une analyse de risques ?
écrit par Guillaume Alliel | 12/06/2023 | 10 min de lecture
Une analyse de risques est une démarche permettant, sur un périmètre donné, à la fois de connaître ses risques, de les prioriser et d’adopter le plan de traitement adéquat.
Ebios RM, ISO27005, Mehari,… Ces noms arrivent généralement très vite lorsque l’on commence à parler d’analyse de risques de cybersécurité. Le néophyte qui se lance sur le sujet peut se laisser vite impressionner par la technicité apparente de ces méthodologies et se dire que décidément, l’analyse de risques est une affaire de techniciens chevronnés à laquelle il ne risque pas de comprendre grand-chose. Pas d’analyse de risques possible hors de ces sentiers bien quadrillés !
Sauf qu’à force, on en oublie l’essentiel de ce qu’est l’analyse de risques et on finit par faire plutôt de la conformité à des méthodes qui ont pourtant été conçues comme des moyens et non comme des fins. Tout l’opposé de ce qu’est censée être une analyse de risques.
Avant de dessiner les contours de ce qu’elle est, précisons d’abord ce que n’est pas l’analyse de risques.
L’analyse de risques n’est pas une recherche de vulnérabilités
Non, le rapport d’un scan de vulnérabilité n’est pas une analyse de risques. On commet parfois la grave erreur de penser qu’en listant toute une série de vulnérabilités, on a fait le travail. Une telle liste peut éventuellement nourrir une analyse de risques mais elle n’en est ni l’essentiel, ni un composant incontournable (quand je fais une analyse sur un projet en phase de cadrage, je n’ai encore aucune vulnérabilité en production).
Quelle différence entre une vulnérabilité et un risque ?
- Une vulnérabilité est un bug technique ou une faille organisationnelle entraînant ou permettant la réalisation d’une action non autorisée et non prévue dans le fonctionnement normal d’un système.
- Un risque est un événement portant atteinte à la réalisation des objectifs d’un système en exploitant potentiellement une vulnérabilité de ce système.
Une vulnérabilité existe en tant que telle alors qu’un risque est toujours dépendant d’un ou de plusieurs objectifs. Il est donc hautement contextuel.
L’absence de règles de validation pour les inputs d’un formulaire, un mot de passe faible ou l’absence de double authentification sont des vulnérabilités. Mais elles n’entraînent pas nécessairement des risques. Ne pas imposer de double authentification pour l’accès d’un utilisateur à un journal classique en ligne est rarement un risque pour l’organisation. Une injection SQL n’est pas non plus systématiquement un risque et d’ailleurs nombre d’entre elles identifiés dans les tests d’intrusion n’ont absolument aucun impact sur le bon fonctionnement de l’application.
Un risque c’est par exemple : “Impossibilité de réaliser la paie des salariés” ou “Fuite massive des données personnelles de la base des donateurs de l’association”. Le langage n’est pas technique : il est orienté “métier” et limpide pour tout membre de l’organisation, en particulier la Direction.
Si une vulnérabilité ne permet pas clairement la réalisation, avec une probabilité raisonnable, d’un scénario ayant un impact notable pour l’organisation alors ce n’est pas un risque ou au plus un risque négligeable qu’il n’est pas pertinent de mentionner dans une analyse de risques. Peu nous importe qu’une vulnérabilité permette d’extraire les données d’une base de données si ces données sont publiques de toute manière !
L’analyse de risques n’est pas un exercice de conformité
Une analyse de conformité est un exercice binaire : on prend une liste de questions ou de points de contrôle et on se demande si l’objet d’étude est conforme ou pas. C’est assez simple et mécanique. La principale difficulté est que cela peut être fastidieux en fonction de la taille, de la complexité du périmètre et du nombre de preuves à récolter.
L’approche par les risques demande en revanche une vraie réflexion et une appropriation du contexte. De la même façon qu’une vulnérabilité ne représente pas forcément un risque, une non-conformité au point d’une norme ou d’une grille de questions quelconque peut n’avoir aucun impact pour une organisation mais un impact sévère pour une autre. Les questionnaires de conformité se basent d’ailleurs souvent sur des vulnérabilités potentielles.
Toutefois, une approche par conformité peut avoir sa pertinence en tant qu’étape préliminaire d’une analyse de risque : les exigences retenues constituent dans ce cas une base couvrant des risques jugés communs à tous les périmètres de l’organisation pouvant faire l’objet de cette analyse de risques.
Paradoxalement, on peut perdre l’esprit d’une analyse de risques en cherchant à se conformer absolument à une méthode donnée au détriment de la pertinence de l’analyse. Il s’agit d’une erreur trop classique : partir d’une méthodologie reconnue (Ebios RM, ISO27005, …) et être plus attentif à bien cocher les différentes étapes de la méthode qu’à vraiment faire le travail de prise de recul, quitte à adapter la méthode pour le contexte.
L’analyse de risques est un vrai moment de réflexion qui ne peut ni être entièrement automatisé ni être réduit à une liste de questions binaires
La qualité d’une analyse de risques est hautement dépendante de :
- Une définition claire du périmètre
- Une très bonne compréhension du contexte, des objectifs des acteurs et des processus de ce périmètre
C’est cela qui va guider ensuite toute l’étude : on ne recherche pas des vulnérabilités à l’aveugle mais plutôt des événements redoutés qui pourraient empêcher l’atteinte de certains objectifs. Ce sont ces événements redoutés qui permettront ensuite de prioriser les vulnérabilités à traiter.
On doit ressortir d’une analyse de risques avec a minima les éléments suivants :
- Une liste d’événements redoutés / risques (et non de vulnérabilités)
- Des cotations de ces risques permettant de les positionner les uns par rapport aux autres en termes d’importance pour l’organisation
- Un plan de traitement pour ces risques avec un vrai travail de priorisation par rapport à la cotation établie
La liste des vulnérabilités éventuelles, permettant la réalisation des risques identifiés, est pertinente surtout pour déterminer les bonnes mesures à mettre en place. Mais elle n’intéressera pas forcément le décideur métier qui prend connaissance des résultats de l’analyse.
Toute démarche et étude permettant d’aboutir à ces éléments constitue une analyse de risques. On n’est ainsi pas obligé de suivre Ebios RM à la lettre pour réaliser une analyse de risques.
A vrai dire un simple brainstorming peut déjà constituer une analyse de risques. L’essentiel est de se poser ces questions :
- Quels sont les événements que je redoute pour la réalisation des objectifs de ce système et/ou de mon organisation, indépendamment même de toute considération technique ?
- Quelles contre-mesures mettre en place pour diminuer la probabilité et/ou l’impact de ces événements ? (ce qui revient à se poser aussi la question des modalités possibles de réalisation concrète des risques identifiés et donc des vulnérabilités exploitables)
- Selon quels critères les prioriser ?
Les méthodes connues ne sont rien d’autres que des tentatives d’établir une démarche plus ou moins précise servant de guide dans la réponse à ces questions. Elles ont une valeur certaine pour gagner du temps et avoir des sources d’inspiration pour les méthodologies que l’on va mettre en place dans son organisation !
Mais à partir de là, chacun doit être libre d’adapter ces méthodes, voire de se créer sa propre méthode par rapport à son contexte ! Le tout est de ne pas perdre de vue l’objectif :
- Identifier des risques majeurs parlant pour le métier afin de faciliter la communication avec lui et assurer la valeur de mon analyse de risques
- Etablir un plan de traitement cohérent avec le contexte (objectifs, contraintes budgétaires, réglementations, culture d’entreprise, etc.)
Donc non : “Faire une analyse de risques” n’est pas forcément synonyme de “Faire une Ebios”. La méthode Ebios RM sera par exemple tout à fait adaptée pour une homologation dans un contexte soumis à des contraintes réglementaires fortes. En revanche, dans une organisation avec une culture de la gestion des risques encore naissante, et souhaitant mettre en place une méthodologie rapide d’analyse des risques dans les projets, l’application de la méthode Ebios RM pourrait décourager les équipes projets d’intégrer la sécurité. Des adaptations d’Ebios RM ou la définition d’une méthode ad hoc s’impose.
C’est pourquoi chez Phinasoft, nous optons pour une approche résolument pragmatique et contextuelle de l’analyse de risques qui ne se limite pas à l’application de grilles méthodologiques rigides : nous vous aidons à mettre en place une démarche vraiment adéquate et surtout utile pour votre contexte. Parfois Ebios RM sera ce qu’il vous faut, parfois une version adaptée, parfois quelque chose de complètement différent.
Synthèse - Qu'est-ce qu'une analyse de risques ?
Une analyse de risques de cybersécurité est une démarche collaborative dans laquelle sont impliqués des acteurs métiers et techniques, accompagnés par des experts en sécurité.
Elle s’appuie sur une méthodologie d’analyse de risques qui a pour objectif d’aider les acteurs de la démarche à :
Définir le périmètre de l’étude
Identifier des événements redoutés pour le métier
Identifier les menaces et les vulnérabilités pouvant permettre la réalisation de ces événements
Classer à partir de cela des scénarios de risques en fonction de leur niveau d’impact et de probabilité
Déterminer une série de contre-mesures permettant de réduire les probabilités d’occurrence, voire les impacts de ces scénarios
Fournir à l’acteur métier en charge du périmètre les moyens de prendre les meilleures décisions possibles de maîtrise du risque
Cette méthodologie peut correspondre à des standards du marché (Ebios RM, Mehari, NIST SP800-30 et 39, …), s’en inspirer librement ou bien être définie de façon ad hoc par rapport au besoin.
Une analyse de risques n’est pas une liste de vulnérabilité ou une évaluation de conformité à des exigences définies de façon indépendante du contexte.
Afin de choisir la meilleure méthodologie pour votre contexte et un outil adapté, vous pouvez opter pour les services spécialisés de Phinasoft sur le sujet !