Identifier, analyser, évaluer et traiter les risques cyber.

02Un risque n'est ni une menace, ni une vulnérabilité, ni un actif

Une grande partie des mauvaises analyses commence par un problème de vocabulaire. On entend par exemple : « Le ransomware est notre principal risque », « cette CVE est un risque critique » ou encore « notre base de données clients représente un risque important ». Ces formulations peuvent être comprises dans une conversation informelle, mais elles deviennent insuffisantes lorsqu'il faut réellement analyser et gouverner le risque.

Un ransomware est d'abord un type de menace ou un moyen d'action. Une CVE décrit une vulnérabilité connue. Une base de données est un actif ou, selon la méthode utilisée, un bien support d'une information ou d'une activité métier. Aucun de ces éléments ne constitue à lui seul un scénario de risque complet.

Prenons un exemple plus construit :

Un groupe cybercriminel exploite une vulnérabilité non corrigée du portail Internet, obtient un accès au réseau interne, élève ses privilèges puis déploie un ransomware sur les systèmes de production, provoquant l'interruption du service client pendant plusieurs jours et des pertes financières importantes.

Cette fois, nous commençons à voir le risque. Nous avons une source de menace, une faiblesse exploitable, un chemin d'attaque, des systèmes concernés, un événement redouté et des conséquences pour l'organisation.

Le premier réflexe professionnel consiste donc à ne jamais s'arrêter au constat technique. Il faut toujours demander :

Quel scénario ce constat rend-il possible et quelles conséquences ce scénario pourrait-il avoir sur les objectifs de l'organisation ?

03Du scénario technique au risque métier

Nous pouvons représenter simplement la construction d'un risque :

Cette chaîne n'est pas une méthode universelle à appliquer mécaniquement. Elle sert d'abord à discipliner notre raisonnement.

Supposons que deux serveurs présentent exactement la même vulnérabilité CVSS 9.8. Le premier est un serveur de test isolé, sans données sensibles, sans exposition Internet et sans connexion directe à la production. Le second est un système d'authentification utilisé par plusieurs applications critiques et accessible depuis des zones fortement exposées. La vulnérabilité technique peut être identique, alors que l'exposition, les conséquences et donc le risque organisationnel peuvent être radicalement différents.

Cela nous conduit à un principe fondamental :

La criticité technique contribue à l'analyse du risque. Elle ne remplace jamais l'analyse du risque.

Un professionnel de la GRC doit savoir faire le chemin dans les deux sens. Il doit pouvoir partir d'un constat technique pour remonter vers les conséquences métier, mais également partir d'une activité critique pour identifier les systèmes, personnes, fournisseurs et informations dont elle dépend.

04Qu'essayons-nous réellement de protéger ?

Un actif n'est pas seulement un équipement inscrit dans un inventaire. Une organisation possède des éléments de valeur beaucoup plus larges : données, processus, services, réputation, propriété intellectuelle, capacités opérationnelles, compétences rares, relations contractuelles ou encore confiance de ses clients et partenaires.

Prenons une plateforme de paiement. Les serveurs qui l'hébergent ont évidemment une valeur financière. Mais ce que l'organisation cherche réellement à préserver est plus large : sa capacité à effectuer les transactions, l'intégrité des montants, la confidentialité des informations, la disponibilité du service, la traçabilité des opérations et la confiance des utilisateurs.

C'est pourquoi une bonne analyse doit être capable de remonter du support technique vers la valeur métier :

Cette logique deviendra particulièrement importante lorsque nous entrerons dans EBIOS Risk Manager.

05Valeurs métier et biens supports

Prenons un portail permettant à des clients de déposer et suivre leurs demandes. La capacité à recevoir et traiter ces demandes constitue une valeur directement liée à l'activité. Les dossiers clients, l'historique des traitements ou les transactions associées peuvent également représenter des valeurs importantes.

Ces valeurs reposent cependant sur des éléments concrets : application web, API, base de données, infrastructure réseau, système d'identité, comptes administrateurs, environnement cloud, postes de travail, sauvegardes et parfois prestataires externes.

Nous pouvons donc avoir :

VALEUR MÉTIER : capacité à traiter les demandes

INFORMATIONS : dossiers et historique des clients

BIENS SUPPORTS : application, base de données, IAM, réseau, cloud, personnel, prestataires

Cette distinction évite de conduire toute l'analyse au niveau du matériel. Si un serveur tombe, la vraie question n'est pas seulement « combien coûte le serveur ? », mais « quelle activité ne peut plus être réalisée et quelles conséquences en résultent ? ».

06L'événement redouté : regarder d'abord les conséquences

Un événement redouté décrit ce que l'organisation ne veut pas voir arriver à quelque chose qui possède de la valeur. Pour une base de données clients, il peut s'agir d'une divulgation massive, d'une altération des informations, d'une destruction ou d'une indisponibilité prolongée. Pour une plateforme de paiement, il peut s'agir d'une manipulation frauduleuse des transactions ou d'une impossibilité d'effectuer les opérations.

Cette manière de raisonner est importante parce qu'elle nous oblige à commencer par les conséquences pour l'organisation avant de nous précipiter sur les techniques d'attaque.

La confidentialité, l'intégrité et la disponibilité constituent naturellement des propriétés centrales. Selon le contexte, l'authenticité, la traçabilité ou la non-répudiation peuvent également être essentielles. Une même information peut donc donner naissance à plusieurs événements redoutés différents et, par conséquent, à plusieurs scénarios de risque.

07Comprendre réellement l'impact

L'impact correspond aux conséquences de la réalisation du scénario. Il ne doit jamais être réduit automatiquement à une somme d'argent. Une cyberattaque peut provoquer simultanément des conséquences financières, opérationnelles, réglementaires, juridiques, réputationnelles ou stratégiques. Dans certains environnements — santé, industrie, énergie, transport, télécommunications ou infrastructures critiques — les conséquences peuvent également affecter directement la sécurité des personnes, la continuité d'un service essentiel ou des intérêts souverains.

Il faut également distinguer les conséquences directes et indirectes. Un ransomware peut générer immédiatement des frais d'investigation, de restauration et de remplacement. Mais les pertes les plus importantes peuvent provenir de l'arrêt d'activité, des retards accumulés, de la perte de clients, de la mobilisation des équipes, d'obligations contractuelles ou de l'atteinte durable à la confiance.

C'est pourquoi le coût d'un incident dépasse souvent largement la valeur comptable de l'équipement initialement compromis.

08Comprendre la vraisemblance sans prétendre prédire l'avenir

L'autre dimension centrale est la vraisemblance. Elle cherche à déterminer dans quelle mesure un scénario peut réellement se produire compte tenu du contexte étudié. Elle ne constitue pas une prophétie.

Une estimation sérieuse peut s'appuyer sur l'historique des incidents, l'exposition du système, les capacités de la source de risque, l'attractivité de la cible, la facilité d'exploitation, l'état des contrôles, les renseignements sur la menace ou encore la fréquence d'événements comparables.

Il faut cependant résister à la tentation de fabriquer une précision qui n'existe pas. Dire qu'un événement possède « exactement 73,4 % de probabilité » n'a aucune valeur particulière si les données permettant de défendre ce chiffre n'existent pas. Une estimation qualitative correctement argumentée peut être beaucoup plus professionnelle qu'une probabilité artificiellement précise.

L'analyse de risque consiste donc aussi à gérer l'incertitude de notre propre analyse.

09Analyser et évaluer ne signifient pas exactement la même chose

Dans le langage courant, les deux termes sont souvent confondus. Pourtant, leur distinction est utile.

Analyser le risque, c'est chercher à le comprendre et à déterminer son niveau en étudiant notamment le scénario, les conséquences, la vraisemblance, les contrôles et les incertitudes. Évaluer le risque, c'est ensuite comparer le résultat de cette analyse aux critères de l'organisation afin de déterminer sa signification : est-il acceptable ? Doit-il être traité ? Avec quelle priorité ? Doit-il être escaladé ?

Nous pouvons retenir :

Puis seulement :

Cette distinction est importante parce qu'un analyste peut produire une estimation du risque sans posséder lui-même l'autorité pour l'accepter.

10Les critères doivent exister avant que les couleurs apparaissent

Imaginons deux analystes évaluant le même incident potentiel. Le premier considère une interruption de huit heures comme « critique », tandis que le second la classe « modérée ». Si l'organisation n'a jamais défini ses critères, les deux peuvent avoir raison selon leur propre intuition.

Une matrice de risque n'apporte donc rien si les catégories qu'elle contient ne sont pas définies. « Faible », « modéré », « élevé » et « critique » doivent correspondre à des seuils ou à des descriptions compréhensibles par les participants. Une organisation peut par exemple définir des critères distincts pour les impacts financiers, opérationnels, réglementaires, réputationnels ou humains.

Les critères de risque permettent ainsi de rendre l'analyse plus cohérente dans le temps et plus comparable entre plusieurs services. Ils doivent également rester alignés avec l'appétence et les tolérances au risque étudiées précédemment.

11Risque inhérent, contrôles et risque résiduel

Le Cours 01 a introduit cette distinction. Nous allons maintenant l'utiliser.

Le risque inhérent représente le niveau de risque considéré avant la prise en compte des contrôles pertinents, selon la convention définie par l'organisation. Le risque résiduel correspond à ce qui subsiste après prise en compte de ces contrôles.

Prenons le scénario de compromission d'un compte administrateur. Sans authentification multifacteur, avec des privilèges excessifs, une faible surveillance et aucun processus régulier de revue des comptes, le scénario peut présenter un niveau de risque très important. L'introduction du MFA, d'un PAM, de restrictions réseau, d'une journalisation renforcée et de revues périodiques peut diminuer sa vraisemblance et parfois son impact.

La logique est :

Mais le raisonnement ne s'arrête pas au déploiement des contrôles. La vraie question de gouvernance devient :

Le risque qui subsiste est-il acceptable au regard de nos critères, et qui possède l'autorité pour l'accepter ?

Nous retrouvons directement le Cours 02.

12Pourquoi quantifier ?

Supposons qu'une équipe sécurité demande 8 000 000 FCFA pour renforcer un service critique. La Direction peut légitimement demander ce que cet investissement permet de réduire. Répondre uniquement « le risque est rouge » ne facilite pas toujours l'arbitrage.

L'analyse quantitative cherche à exprimer tout ou partie de l'exposition au risque sous forme numérique, notamment financière. Elle peut aider à comparer le coût potentiel d'un scénario avec celui d'une mesure de sécurité, à prioriser des investissements ou à présenter le risque dans un langage familier aux décideurs.

Elle possède néanmoins une faiblesse fondamentale : un résultat numérique peut sembler plus objectif qu'il ne l'est réellement. Si les hypothèses de départ sont fragiles, le calcul peut être parfaitement juste tout en produisant une conclusion trompeuse.

Nous devons donc apprendre simultanément à calculer et à challenger le calcul.

13La chaîne AV → EF → SLE → ARO → ALE

Pour notre première approche quantitative, nous allons utiliser cinq variables classiques :

Deux formules structurent le calcul :

puis :

Donc :

Les formules sont simples. La difficulté réelle se trouve dans les hypothèses qui alimentent AV, EF et ARO.

14AV : Asset Value

L'Asset Value représente la valeur que nous attribuons à l'actif ou à l'exposition étudiée. L'erreur classique consiste à utiliser automatiquement le prix d'achat du matériel.

Supposons qu'un serveur ait coûté 2 000 000 FCFA. S'il héberge une activité générant plusieurs dizaines de millions de FCFA de revenus, contient des informations difficiles à reconstituer et nécessite plusieurs jours de travail pour être restauré, considérer AV = 2 000 000 FCFA peut sous-estimer considérablement l'exposition.

La valeur pertinente dépend donc de ce que nous modélisons. Elle peut intégrer, selon le scénario et les conventions retenues, le coût de remplacement, la valeur des informations, les coûts de reconstruction, l'interruption de l'activité ou d'autres éléments économiquement justifiables.

Le point essentiel n'est pas de trouver une valeur « magique », mais de pouvoir répondre à :

Pourquoi avons-nous retenu cette valeur et quelles composantes contient-elle ?

15EF : Exposure Factor

L'Exposure Factor représente la proportion de la valeur qui serait perdue si l'événement se produisait une fois. Il est généralement exprimé en pourcentage.

Supposons que l'AV retenue soit de 50 000 000 FCFA et que l'analyse estime qu'une occurrence du scénario provoquerait une perte équivalente à 40 % de cette valeur. L'EF est alors de 40 %, soit 0,40 dans le calcul.

Il faut immédiatement comprendre ce que signifie cette hypothèse : nous ne prétendons pas que l'actif entier disparaît. Nous estimons que le scénario considéré détruit ou affecte économiquement environ 40 % de la valeur retenue.

La qualité de cette estimation doit elle aussi pouvoir être expliquée.

16SLE : combien coûterait une occurrence ?

Le Single Loss Expectancy représente la perte attendue lors d'une occurrence unique du scénario.

La formule est :

Avec :

AV = 50 000 000 FCFA

EF = 40 % = 0,40

nous obtenons :

Dans notre modèle, une occurrence du scénario représente donc une perte estimée à 20 000 000 FCFA.

Attention à une erreur de calcul fréquente : 40 % doit être utilisé sous la forme 0,40, et non 40. Sinon, nous obtiendrions 2 milliards de FCFA, ce qui ne correspond évidemment pas à une exposition de 40 % sur une valeur de 50 000 000 FCFA.

17ARO : annualiser la fréquence

L'Annualized Rate of Occurrence représente le nombre moyen d'occurrences estimées sur une année.

Une occurrence annuelle correspond à ARO = 1. Deux occurrences annuelles donnent ARO = 2. Mais l'ARO peut également être inférieur à 1. Une occurrence tous les deux ans correspond à 0,5, une occurrence tous les quatre ans à 0,25, et une occurrence tous les dix ans à 0,1.

Ce point est important : un événement rare ne possède pas un ARO égal à zéro.

L'ARO est également l'une des variables les plus difficiles à estimer en cybersécurité. Les attaques évoluent, les architectures changent, certaines organisations disposent de peu d'historique et les événements majeurs sont heureusement rares. Nous reviendrons donc sur la provenance de cette estimation.

18ALE : exprimer l'exposition annuelle

L'Annualized Loss Expectancy représente la perte annuelle attendue dans le modèle.

La formule est :

Si notre SLE est de 20 000 000 FCFA et que nous estimons le scénario à une occurrence tous les quatre ans, soit ARO = 0,25, nous obtenons :

Cela ne signifie absolument pas que NOVACOM perdra 5 000 000 FCFA chaque année. L'organisation peut ne rien perdre pendant trois ans puis subir une perte de 20 000 000 FCFA la quatrième année. L'ALE représente une exposition annualisée attendue, compte tenu des hypothèses utilisées.

Cette nuance doit être parfaitement comprise avant d'utiliser l'ALE devant une Direction.

19Cas quantitatif : NOVACOM

Nous allons conserver NOVACOM, l'organisation fictive introduite au Cours 02, afin que notre Académie construise progressivement un véritable cas GRC plutôt qu'une succession d'exemples indépendants.

NOVACOM exploite un portail numérique critique permettant aux clients de déposer et suivre leurs demandes. L'organisation étudie un scénario de compromission entraînant une interruption importante du portail, des opérations de restauration et plusieurs conséquences économiques.

Pour l'exercice, l'analyse retient une AV de 50 000 000 FCFA. Il ne s'agit pas uniquement de la valeur des serveurs : cette valeur représente le périmètre économique retenu pour le scénario. Une occurrence est estimée susceptible d'affecter environ 40 % de cette valeur, soit EF = 0,40. Enfin, sur la base des hypothèses de notre cas pédagogique, le scénario est estimé à une occurrence tous les quatre ans, soit ARO = 0,25.

Le calcul devient :

puis :

NOVACOM peut donc présenter le risque ainsi :

Sur la base des hypothèses retenues, une occurrence du scénario représenterait environ 20 000 000 FCFA de perte et l'exposition annualisée est estimée à 5 000 000 FCFA.

Cette formulation est beaucoup plus rigoureuse que : « ce risque nous coûte 5 000 000 FCFA par an ».

20Introduire le coût d'un contrôle

Supposons maintenant qu'une mesure de sécurité coûte 2 000 000 FCFA par an. Elle réduit significativement la capacité de l'attaquant à réussir et limite les conséquences d'une compromission.

Après traitement, l'organisation estime :

AV = 50 000 000 FCFA

EF = 10 %

ARO = 0,10

Nous obtenons :

puis :

La réduction de l'exposition annualisée modélisée est donc :

5 000 000 - 500 000 = 4 500 000 FCFA / an

Pour un contrôle coûtant 2 000 000 FCFA par an, l'investissement paraît économiquement intéressant dans le cadre de nos hypothèses.

Mais attention au vocabulaire. Nous ne devons pas annoncer : « ce contrôle nous fera économiser 4 500 000 FCFA par an ». Il réduit de 4 500 000 FCFA une perte annuelle attendue modélisée. L'incident peut ne jamais se produire, ou ses conséquences réelles peuvent être très différentes de notre estimation.

21Le calcul financier ne possède pas l'autorité de décision

Imaginons maintenant une situation différente. L'ALE d'un scénario est estimée à 2 000 000 FCFA et le contrôle permettant de satisfaire une obligation réglementaire coûte 5 000 000 FCFA par an.

Une lecture purement financière pourrait conduire à dire : « le contrôle coûte davantage que le risque, donc ne le mettons pas en œuvre ». Ce raisonnement peut être totalement inadéquat.

Certaines mesures sont nécessaires parce qu'elles répondent à une obligation légale, réglementaire ou contractuelle, protègent la sécurité des personnes, conditionnent une autorisation d'exercer ou préservent une activité essentielle. Une organisation peut également décider que certains événements sont incompatibles avec son appétence au risque même lorsque leur coût financier attendu semble faible.

Nous retrouvons ici une distinction essentielle :

L'analyse quantitative fournit une information à la gouvernance. Elle ne remplace pas la gouvernance.

Le nombre aide à décider. Il ne possède aucune autorité.

22D'où viennent réellement AV, EF et ARO ?

C'est ici que commence l'analyse professionnelle.

AV peut s'appuyer sur les données comptables, les coûts de remplacement, les revenus associés au service, les coûts d'interruption, les résultats d'un BIA, la valeur des informations ou les coûts de reconstruction. EF peut être estimé à partir d'incidents précédents, d'exercices, de simulations, d'expertise métier et technique ou d'analyses de scénarios comparables. ARO peut exploiter l'historique interne, des données sectorielles, la threat intelligence, les incidents observés chez des organisations similaires ou l'évolution de l'exposition.

Mais ces données ne sont pas toujours disponibles. Une organisation qui n'a jamais subi de ransomware destructeur ne peut pas en conclure que son ARO est nul. Elle peut simplement avoir été moins exposée, mieux protégée, moins ciblée ou chanceuse jusqu'à présent.

Une analyse sérieuse documente donc ses hypothèses. Lorsque l'incertitude est importante, il peut être préférable de travailler avec des fourchettes plutôt que de prétendre connaître une valeur exacte.

23Le piège de la fausse précision

Comparez les deux résultats suivants :

et :

Si les données de départ sont elles-mêmes approximatives, la deuxième formulation peut être beaucoup plus rigoureuse. Le nombre de décimales n'est pas un indicateur de maturité.

C'est une leçon importante de l'analyse quantitative :

La précision du calcul ne peut jamais être supérieure à la qualité des données qui l'alimentent.

Le professionnel doit donc être capable de défendre les hypothèses, mais aussi d'expliquer leurs limites.

24Ce que l'analyse quantitative fait bien… et ce qu'elle fait moins bien

L'analyse quantitative est particulièrement utile lorsqu'il faut comparer des expositions financières, soutenir une analyse coût/bénéfice, arbitrer certains investissements ou parler un langage directement compréhensible par les fonctions financières et la Direction.

Elle devient cependant plus délicate lorsque les données sont rares, que les scénarios évoluent rapidement ou que les conséquences sont difficiles à monétiser. Comment attribuer une valeur précise à une perte durable de confiance ? À l'indisponibilité d'un service public essentiel ? À une atteinte à la souveraineté ? À un incident susceptible de mettre des personnes en danger ?

Il faut donc éviter deux dogmes opposés : « tout risque doit être converti en argent » et « la cybersécurité ne peut jamais être quantifiée ». Le bon analyste choisit le niveau de quantification adapté à la décision recherchée et à la qualité des informations disponibles.

25Pourquoi utiliser une analyse qualitative ?

Toutes les organisations ne possèdent pas les données permettant d'attribuer une valeur financière crédible à leurs scénarios. Et même lorsqu'elles les possèdent, certaines conséquences restent mieux exprimées à travers des critères de gravité et de vraisemblance.

Une analyse qualitative peut par exemple utiliser quatre niveaux de gravité — limitée, significative, grave et critique — et quatre niveaux de vraisemblance — faible, modérée, élevée et très élevée. Ces catégories permettent de comparer les scénarios, à condition que leur signification soit explicitement définie.

La différence fondamentale avec une approche improvisée est là : qualitatif ne signifie pas arbitraire.

Une appréciation qualitative sérieuse repose sur des critères documentés, une compréhension du contexte, des participants compétents et un scénario suffisamment précis pour permettre une discussion argumentée.

26La matrice de risque : utile, mais dangereuse si elle devient le raisonnement

Une organisation peut croiser gravité et vraisemblance dans une matrice afin de visualiser ses priorités. Par exemple :

Cette matrice est uniquement un exemple pédagogique. Elle ne constitue ni une matrice universelle ni « la matrice EBIOS RM ».

Le danger apparaît lorsque l'organisation commence directement par demander : « quelle couleur mettons-nous ? » sans avoir correctement défini le scénario. Une case rouge ne nous dit ni qui attaque, ni pourquoi, ni comment, ni ce qui est réellement affecté.

La matrice représente le résultat d'un raisonnement. Elle ne doit pas remplacer le raisonnement.

27Quantitatif et qualitatif peuvent travailler ensemble

Il n'existe aucune obligation de choisir définitivement entre les deux approches.

Un scénario peut par exemple être évalué comme présentant une gravité critique, une vraisemblance élevée et, parallèlement, une perte financière potentielle comprise entre 30 000 000 et 50 000 000 FCFA. La dimension qualitative permet d'intégrer des conséquences opérationnelles, réglementaires ou réputationnelles ; la quantification apporte une information supplémentaire pour certains arbitrages.

La maturité consiste donc moins à choisir un camp qu'à savoir quel niveau de représentation est pertinent pour la décision à prendre.

Nous allons maintenant appliquer cette logique à une méthode structurée d'analyse de risque : EBIOS Risk Manager.

28Comprendre la logique avant les cinq ateliers

EBIOS Risk Manager est une méthode d'appréciation et de traitement du risque numérique. Sa force pédagogique tient notamment au fait qu'elle ne commence pas par demander la liste des vulnérabilités du système. Elle part du plus haut niveau — les missions de l'objet étudié — puis descend progressivement vers les éléments métier et techniques et les chemins d'attaque.

La méthode articule également deux logiques complémentaires. D'une part, un socle de sécurité permet de traiter les exigences de référence auxquelles l'objet étudié doit se conformer. D'autre part, l'approche par scénarios cherche à confronter ce socle à des menaces intentionnelles et ciblées, en tenant compte de l'écosystème réel de l'organisation.

Les cinq ateliers répondent à une progression intellectuelle très naturelle :

Cette progression est capitale. Elle nous empêche de commencer immédiatement par les pare-feu, les CVE ou les adresses IP.

29Le contexte

NOVACOM fournit à ses clients un service numérique permettant de créer un compte, déposer une demande, transmettre des documents, suivre l'avancement d'un dossier et payer certaines prestations. Le portail est devenu suffisamment important pour qu'une indisponibilité prolongée perturbe directement l'activité de l'organisation.

Le service dépend d'une application web, d'API, d'une base de données clients, d'un système d'identité, d'un hébergement cloud, d'un prestataire de maintenance, d'une messagerie Microsoft 365, de composants réseau et d'un prestataire de paiement.

La Direction souhaite répondre à une question très concrète :

Quels scénarios cyber pourraient compromettre durablement le portail ou les données clients, et quelles mesures devons-nous prioriser ?

Nous allons conduire cette analyse en suivant les cinq ateliers.

30Commencer par comprendre ce qui compte

Le premier atelier sert à définir l'objet de l'étude, son périmètre, les participants, le cadre temporel, les missions et valeurs métier, les biens supports, les événements redoutés et leur gravité. Il permet également d'examiner le socle de sécurité applicable.

Notre objet d'étude sera :

Le service numérique NOVACOM permettant le dépôt, le paiement et le suivi des demandes clients.

Nous choisissons, pour l'exercice, un horizon de trois ans. Cette précision est importante : une analyse de risque n'est pas intemporelle. L'architecture, les fournisseurs, les activités, la menace et les obligations peuvent évoluer.

Le périmètre métier comprend quatre missions principales : permettre aux clients de déposer leurs demandes, permettre aux équipes NOVACOM de les traiter, garantir la traçabilité des opérations et préserver les informations confiées à l'organisation.

31Identifier les valeurs métier

Nous retenons quatre valeurs métier principales :

Le changement de perspective est important. Nous n'avons toujours pas parlé de pare-feu. Nous commençons par ce qui permet à NOVACOM d'accomplir sa mission.

32Identifier les biens supports

Les valeurs métier ne vivent pas seules. VM1 dépend notamment de l'application web, des API, du DNS et de l'hébergement. VM2 dépend de la base de données et du stockage documentaire. VM3 dépend de l'application métier, de l'IAM et des postes des utilisateurs. VM4 dépend notamment de l'API de paiement et des composants permettant d'en assurer la traçabilité.

À cela s'ajoutent des supports transversaux : comptes administrateurs, infrastructure réseau, sauvegardes, Microsoft 365, postes de travail et prestataires.

Cette cartographie commence à créer une relation exploitable :

Elle permettra plus tard de descendre vers les scénarios techniques sans perdre le lien avec les conséquences métier.

33Définir les événements redoutés

Nous demandons maintenant : qu'est-ce que NOVACOM ne veut absolument pas voir arriver à ses valeurs métier ?

Pour VM2 — Données clients — un événement redouté pourrait être une divulgation massive et non autorisée des dossiers clients. Pour VM3, nous pourrions retenir l'altération des informations de traitement entraînant des décisions incorrectes. Pour VM1, nous retiendrons une indisponibilité prolongée du portail empêchant le dépôt et le suivi des demandes. Enfin, pour VM4, une manipulation frauduleuse des transactions constitue un événement redouté pertinent.

Remarquons que nous ne décrivons toujours pas comment l'attaque se produit. C'est volontaire. Nous regardons d'abord le problème du point de vue de NOVACOM : quelles conséquences redoutons-nous ?

34Évaluer la gravité

Pour notre étude pédagogique, NOVACOM adopte quatre niveaux de gravité. G1 correspond à une conséquence limitée et facilement récupérable ; G2 à une perturbation significative nécessitant une mobilisation particulière ; G3 à une atteinte grave à un service ou à des informations importantes ; G4 à une conséquence critique susceptible d'affecter directement les missions, les clients ou la capacité de fonctionnement de l'organisation.

Nous obtenons :

Ces valeurs appartiennent à notre étude de cas. Elles ne doivent pas être présentées comme une échelle universelle imposée par EBIOS RM.

35Examiner le socle de sécurité

Avant d'imaginer des attaquants sophistiqués, NOVACOM doit vérifier les exigences de sécurité qui devraient déjà être satisfaites. Le socle peut provenir de politiques internes, d'obligations réglementaires ou contractuelles, de référentiels retenus par l'organisation ou d'autres exigences applicables.

Notre diagnostic simplifié montre que le MFA des administrateurs est en place et que les sauvegardes existent, mais que les tests de restauration sont irréguliers, la revue des comptes prestataires insuffisante et la centralisation de certains journaux incomplète.

Ces écarts n'ont pas besoin d'attendre les ateliers suivants pour être pris au sérieux. Ils peuvent déjà alimenter le plan de traitement.

À la fin de l'Atelier 1, NOVACOM sait donc ce qu'elle étudie, ce qui possède de la valeur, ce qu'elle redoute, à quel point elle le redoute et quelles exigences fondamentales présentent des écarts.

La question suivante devient naturellement :

Qui pourrait vouloir provoquer ces événements et pourquoi ?

36Identifier l'agresseur et son objectif

L'Atelier 2 introduit deux concepts importants : la source de risque (SR) et l'objectif visé (OV). Il ne suffit plus de dire « des hackers peuvent nous attaquer ». Nous devons identifier les catégories d'acteurs réellement pertinentes pour notre contexte et comprendre ce qu'elles pourraient chercher à accomplir.

Pour NOVACOM, nous considérons notamment un groupe cybercriminel organisé motivé par l'argent, un prestataire malveillant ou compromis disposant déjà de certains accès, un acteur intéressé par l'espionnage économique et un employé malveillant.

Une même source de risque peut poursuivre plusieurs objectifs. Un groupe cybercriminel peut chercher à extorquer l'organisation en interrompant son activité, voler des données revendables ou détourner des transactions. L'employé malveillant peut chercher à extraire des informations ou saboter certains dossiers.

Nous construisons donc des couples SR/OV.

37Sélectionner plutôt qu'imaginer tout ce qui est possible

Une analyse de risque peut rapidement devenir infinie si l'on cherche à documenter toutes les menaces imaginables. L'objectif de l'Atelier 2 est précisément de sélectionner les couples SR/OV suffisamment pertinents pour mériter une analyse plus approfondie.

Pour notre cas :

La pertinence doit être argumentée à partir du contexte : secteur, exposition, données, visibilité de l'organisation, incidents connus, capacités de l'adversaire, motivation et opportunités.

Pour la suite, nous retenons notamment le couple suivant :

SR : groupe cybercriminel organisé — OV : extorquer NOVACOM en interrompant son activité et en menaçant de divulguer des données clients.

Nous savons désormais qui et pourquoi.

La prochaine question est :

Par où cet acteur pourrait-il passer ?

38Sortir des frontières de l'organisation

L'une des idées fortes de l'Atelier 3 consiste à regarder l'écosystème. Une organisation peut protéger correctement ses propres systèmes et rester exposée par un fournisseur, un sous-traitant, un partenaire ou une dépendance numérique.

NOVACOM dépend notamment d'un hébergeur cloud, d'un prestataire de maintenance applicative, d'un fournisseur d'identité, d'un prestataire de paiement, de Microsoft 365, d'un fournisseur DNS et de partenaires avec lesquels des données peuvent être échangées.

Ces acteurs ne sont évidemment pas « dangereux » par nature. L'analyse cherche plutôt à comprendre leur rôle dans les scénarios : quel niveau d'accès possèdent-ils ? Quelle dépendance créent-ils ? Une compromission de leur environnement permettrait-elle d'atteindre nos valeurs métier ? Pouvons-nous les remplacer facilement ? Quelle confiance leur accordons-nous et sur quelles preuves ?

39Construire un scénario stratégique

Nous retenons un premier scénario :

Un groupe cybercriminel compromet le prestataire de maintenance de NOVACOM et exploite la relation de confiance ou les accès dont celui-ci dispose pour pénétrer le système d'information, atteindre les données clients et interrompre le portail afin d'extorquer l'organisation.

À ce stade, nous ne décrivons pas encore précisément le phishing, l'exploitation d'une CVE ou les commandes utilisées par l'attaquant. Le scénario reste stratégique. Il relie la source de risque, son objectif, l'écosystème et les valeurs métier.

Un second scénario pourrait être :

Le groupe cybercriminel cible directement l'identité d'un administrateur NOVACOM afin d'obtenir des privilèges suffisants pour atteindre le portail et ses données.

Nous avons donc plusieurs chemins stratégiques possibles vers le même objectif.

40L'écosystème fait partie de notre risque

Cette étape révèle un principe majeur de la cybersécurité moderne :

Une organisation ne maîtrise pas entièrement son niveau de risque en protégeant uniquement ce qu'elle possède directement.

Cloud, SaaS, fournisseurs, logiciels, API, opérateurs, prestataires et partenaires étendent les dépendances et les chemins possibles.

L'analyse peut donc déjà produire des mesures sur l'écosystème : imposer le MFA aux prestataires, utiliser des comptes nominatifs, limiter les privilèges, contractualiser certaines obligations de sécurité, définir des exigences de notification d'incident, revoir régulièrement les accès ou restreindre les connexions à certaines périodes.

L'Atelier 3 commence ainsi à transformer l'analyse en actions, sans attendre la fin de la méthode.

41Passer de « par où ? » à « comment ? »

Nous savons désormais que le prestataire peut constituer un chemin stratégique intéressant pour notre source de risque. L'Atelier 4 descend au niveau opérationnel afin de comprendre comment l'attaque pourrait réellement se dérouler sur les biens supports.

Prenons le scénario prestataire. Un chemin d'attaque possible pourrait être :

Cette chaîne change profondément la manière de penser les contrôles. Nous ne cherchons plus « les meilleurs outils de cybersécurité » dans l'absolu. Nous cherchons où casser le scénario.

42La défense en profondeur prend ici tout son sens

Si le MFA empêche l'utilisation directe d'identifiants volés, une première étape devient plus difficile. Si le compte du prestataire respecte le moindre privilège, sa compromission offre moins de possibilités. Si la segmentation limite les mouvements, l'attaquant rencontre un nouvel obstacle. Si l'EDR ou la supervision détecte certaines activités anormales, la probabilité d'interrompre l'attaque augmente. Enfin, si des sauvegardes protégées et testées existent, certaines conséquences du chiffrement peuvent être réduites.

Nous retrouvons ici plusieurs principes étudiés depuis le Cours 01 : Least Privilege, Defense in Depth, séparation des responsabilités, surveillance et résilience. Ils ne sont plus des principes abstraits ; nous voyons précisément à quelle étape du scénario ils interviennent.

43Estimer la vraisemblance du scénario

Pour notre étude pédagogique, NOVACOM utilise quatre niveaux : V1 faible, V2 modérée, V3 élevée et V4 très élevée. Là encore, ces catégories doivent être définies et ne constituent pas une échelle universelle à copier sans adaptation.

Le scénario passant par le prestataire est classé V3 — Élevée. Cette estimation est argumentée : le prestataire dispose déjà d'un accès, certains privilèges sont trop larges, la revue des comptes présente un écart et la source de risque possède des capacités compatibles avec le chemin envisagé.

Nous obtenons alors :

Source de risque : groupe cybercriminel

Objectif : extorsion

Événements redoutés : divulgation des dossiers + indisponibilité

Gravité : G4

Vraisemblance : V3

Le scénario devient un risque suffisamment structuré pour être comparé, priorisé et traité.

44Compter les vulnérabilités n'est pas mesurer la vraisemblance

Un scénario contenant cinq vulnérabilités n'est pas automatiquement plus probable qu'un scénario n'en contenant qu'une. Une seule faiblesse extrêmement exploitable peut ouvrir tout le chemin, tandis qu'une chaîne de nombreuses faiblesses peut exiger des conditions très difficiles à réunir.

L'estimation doit donc examiner le chemin dans son ensemble : compétences nécessaires, ressources de l'attaquant, préconditions, exposition, contrôles, possibilités de détection et difficultés techniques.

C'est exactement pour cette raison que l'analyse par scénarios apporte davantage qu'un simple scanner de vulnérabilités.

45Revenir vers la décision

Nous avons commencé par la mission de NOVACOM. Nous avons identifié ce qu'elle redoute, puis les sources de risque, leurs objectifs, l'écosystème, les scénarios stratégiques et enfin les chemins opérationnels.

L'Atelier 5 referme la boucle : que décidons-nous de faire ?

Les grandes stratégies de traitement restent celles déjà introduites dans l'Académie : éviter le risque, le réduire, le partager ou transférer certaines conséquences lorsque cela est réellement possible, ou l'accepter dans les conditions définies par la gouvernance.

Pour notre scénario principal, NOVACOM choisit essentiellement de réduire le risque.

46Construire le traitement à partir du scénario

Le plan de traitement ne doit pas devenir une liste générique de contrôles. Chaque mesure doit modifier quelque chose dans le scénario.

NOVACOM décide notamment d'imposer un MFA fort sur les accès prestataires, de supprimer les comptes partagés, de généraliser les comptes nominatifs, de réduire les privilèges, d'introduire des accès temporaires lorsque cela est possible, de renforcer la segmentation, de centraliser la journalisation, de détecter les connexions anormales, de revoir régulièrement les droits et de renforcer les tests de restauration.

Nous pouvons relier chaque mesure à son effet :

C'est ainsi que l'on passe d'un catalogue de contrôles à un plan de traitement du risque.

47Prévenir ne suffit pas

Une stratégie réaliste suppose qu'une partie des attaques pourra dépasser certaines protections. Il faut donc raisonner en profondeur : prévenir lorsque cela est possible, détecter ce qui franchit les barrières, répondre rapidement et restaurer l'activité.

MFA, durcissement et segmentation contribuent à la prévention. EDR, SIEM, journaux et alertes IAM soutiennent la détection. Les procédures d'incident, la révocation rapide des accès ou l'isolation des systèmes permettent la réponse. Les sauvegardes et le PRA contribuent à la récupération.

La sécurité mature n'est donc pas :

« Comment faire pour qu'aucune attaque ne réussisse jamais ? »

mais plutôt :

« Comment réduire la probabilité de réussite, détecter suffisamment tôt, limiter les conséquences et restaurer l'activité ? »

48Réévaluer le risque résiduel

Avant traitement, notre scénario était estimé G4 / V3. Après les mesures retenues, la gravité potentielle peut rester très importante si l'attaquant parvient malgré tout à son objectif, mais la vraisemblance peut être réduite. Pour l'exercice, nous retenons G4 / V1.

Le risque n'a donc pas disparu.

Il reste maintenant à comparer ce niveau résiduel aux critères de NOVACOM. S'il est compatible avec les tolérances définies, l'autorité compétente pourra éventuellement l'accepter. Dans le cas contraire, des mesures supplémentaires, une modification du service ou une escalade seront nécessaires.

Et nous revenons exactement au Cours 02 :

L'analyse de risque n'est pas un processus parallèle à la gouvernance. Elle alimente la gouvernance.

49Construire un registre des risques

Une organisation peut réaliser d'excellentes analyses et néanmoins perdre le contrôle si les résultats restent dispersés dans des rapports. Le registre des risques permet de conserver une vision structurée des scénarios, de leur niveau, des responsables, des traitements et des décisions.

Un enregistrement pourrait par exemple contenir :

Le format exact varie selon les organisations. L'important est que le registre permette de répondre rapidement : quel est le risque, qui le porte, que faisons-nous, où en sommes-nous et quand doit-il être réévalué ?

50Bien formuler un risque

« Risque lié au prestataire » est trop vague.

Une formulation plus utile serait :

Un groupe cybercriminel pourrait compromettre un compte du prestataire de maintenance et exploiter ses privilèges pour accéder au portail NOVACOM, exfiltrer les données clients puis interrompre le service à des fins d'extorsion, entraînant une atteinte critique à la confidentialité des informations et à la disponibilité du service.

Cette phrase n'est pas intéressante parce qu'elle est plus longue. Elle l'est parce qu'elle rend visibles la source, le chemin, l'objectif, les actifs et les conséquences.

Une autre structure simple peut aider :

En raison de [cause ou condition], [événement] pourrait se produire, entraînant [conséquences].

Par exemple :

En raison de privilèges excessifs accordés aux comptes prestataires, la compromission d'un de ces comptes pourrait permettre un accès non autorisé aux systèmes critiques, entraînant une exfiltration de données et une interruption du portail.

La formulation oblige l'analyste à clarifier sa pensée.

51Le risque doit vivre

Une analyse réalisée aujourd'hui n'est pas éternellement valide. Une nouvelle architecture, un changement de fournisseur, une nouvelle vulnérabilité, l'évolution d'un groupe d'attaquants, un incident chez un partenaire ou une modification de l'activité peuvent changer le niveau de risque.

Le registre doit donc être relié à des mécanismes de surveillance et de revue. Certains événements doivent déclencher une réévaluation sans attendre la date de revue prévue.

Le risque devient ainsi une information de management et non un document produit une fois par an pour satisfaire un audit.

52Deux approches, mais une même décision

Notre analyse quantitative nous permet de demander :

Quelle exposition financière pouvons-nous raisonnablement estimer ?

EBIOS RM nous permet d'explorer une question différente :

Quels scénarios intentionnels et ciblés sont pertinents pour notre contexte, comment pourraient-ils se réaliser et comment devons-nous les traiter ?

Ces approches peuvent parfaitement se compléter.

Nous pourrions alors disposer simultanément d'un scénario intelligible, d'une appréciation qualitative et d'une estimation financière.

C'est souvent plus riche que de chercher à faire entrer tout le risque dans une seule mesure.

53Deux erreurs symétriques

La première erreur serait de réduire EBIOS RM à une matrice 4 × 4. La méthode est beaucoup plus riche : elle structure le cadrage, les valeurs métier, les événements redoutés, les sources de risque, les objectifs visés, l'écosystème, les scénarios stratégiques, les scénarios opérationnels et le traitement.

La seconde erreur serait de réduire l'analyse quantitative à un exercice scolaire où l'on applique mécaniquement :

AV × EF × ARO = ALE

Savoir calculer l'ALE est utile. Mais savoir demander « d'où vient cet ARO ? » est plus important encore.

Dans les deux approches, la compétence essentielle reste la même : challenger le raisonnement qui produit le résultat.

54Exercice pratique 03 : analyser le même risque sous deux angles

Choisissez un service réel ou fictif : Active Directory, Microsoft 365, application financière, plateforme de paiement, infrastructure réseau, portail web, système industriel, application RH ou environnement cloud.

Commencez par décrire la mission du service, ce qui possède de la valeur et un scénario de risque suffisamment précis.

Pour le volet quantitatif, déterminez une AV et justifiez-la, estimez l'EF, calculez le SLE, estimez l'ARO et calculez l'ALE. Proposez ensuite une mesure de traitement, estimez son coût et recalculez l'exposition résiduelle. Votre conclusion ne doit pas se limiter à « le contrôle est rentable » : expliquez les hypothèses, leurs limites et les autres dimensions pouvant influencer la décision.

Pour le volet qualitatif, reprenez le même environnement et conduisez une analyse structurée : valeurs métier, événements redoutés, gravité, sources de risque, objectifs visés, scénario stratégique, scénario opérationnel, vraisemblance, mesures de traitement et risque résiduel.

À la fin, vous devez être capable de présenter le risque à une Direction sans commencer par une CVE, une adresse IP ou le nom d'un outil.

55Le livrable

Ce troisième livrable constitue une étape importante du portfolio. Il doit montrer que vous êtes capable de transformer une situation technique en analyse de risque et de passer ensuite de l'analyse à la décision.

Le dossier comportera d'abord une fiche de contexte présentant l'organisation, le service étudié, sa mission, le périmètre, l'horizon temporel, les valeurs métier, les principaux biens supports et le Risk Owner.

Le volet quantitatif utilisera la structure suivante :

Il comparera ensuite l'exposition avant et après traitement :

Le volet EBIOS RM documentera les cinq ateliers : cadrage, valeurs métier, biens supports, événements redoutés et socle ; couples SR/OV ; écosystème et scénarios stratégiques ; chemins opérationnels et vraisemblance ; enfin stratégie de traitement, mesures, risque résiduel et mécanisme de suivi.

Le dossier se terminera par une synthèse de management d'une page maximum répondant à six questions : quel est le scénario le plus préoccupant ? Pourquoi ? Quel traitement est prioritaire ? Quelle exposition financière peut raisonnablement être estimée ? Quel risque subsiste ? Qui doit prendre la décision finale ?

C'est cette dernière page qu'un décideur devrait pouvoir lire en premier.

56Les dix questions à savoir poser

Lorsque vous êtes confronté à un nouveau risque, entraînez-vous à reconstruire mentalement les questions suivantes :

1. Quelle mission ou quel objectif cherchons-nous à protéger ?
2. Quelles valeurs métier sont essentielles ?
3. Quel événement redoutons-nous réellement ?
4. Qui ou quoi pourrait provoquer cet événement ?
5. Pourquoi cette source chercherait-elle à le faire ?
6. Par quels chemins le scénario pourrait-il se produire ?
7. Quelles seraient les conséquences pour l'organisation ?
8. Quelle est la vraisemblance du scénario et sur quoi repose notre estimation ?
9. Quels contrôles modifient déjà le risque ?
10. Quel risque subsiste, et qui possède l'autorité pour décider de son traitement ou de son acceptation ?

Ces dix questions sont plus importantes que la mémorisation mécanique d'une matrice. Elles permettent de reconstruire le raisonnement même lorsque l'organisation change de méthode ou de référentiel.

57Les pièges professionnels à éviter

Plusieurs erreurs reviennent régulièrement. Confondre menace, vulnérabilité et risque conduit à des registres peu exploitables. Inventer AV, EF ou ARO produit des résultats numériques sans fondement. Utiliser une matrice sans définir les échelles transforme l'analyse qualitative en opinion. Commencer EBIOS RM par les équipements techniques fait perdre le lien avec les missions et valeurs métier. Ignorer l'écosystème revient à oublier une partie importante de la surface réelle de risque.

Deux autres erreurs sont particulièrement dangereuses. La première consiste à considérer qu'un contrôle déployé signifie que le risque est « réglé » : il faut toujours s'intéresser au risque résiduel. La seconde consiste à produire une excellente analyse sans propriétaire, sans échéance et sans décision. Dans ce cas, le risque a été documenté, mais il n'est pas réellement gouverné.