Registre de risques : nommer les scénarios qui arrêteraient l'entreprise

Votre rendez-vous du dimanche · Série risques

Mardi, nous avons lancé la phrase qui sert de point de départ à cette série : votre backlog de vulnérabilités n'est pas votre registre de risques. Chaque dimanche, nous reprendrons une pièce de ce registre, celle que la direction lit, que le conseil arbitre et que les équipes exécutent. On commence par la plus importante, et la plus souvent sautée : nommer ce qui pourrait arrêter l'entreprise.

Un backlog et un registre ne répondent pas à la même question

Un backlog répond à la question : qu'est-ce qui est vulnérable ? C'est une liste d'actifs, de failles et de scores, produite par les outils. Elle est utile, elle est longue, et elle change tous les jours.

Un registre répond à une autre question : qu'est-ce qui pourrait arrêter l'entreprise, et qui en répond ? C'est une courte liste de scénarios, chacun avec une conséquence d'affaires, un propriétaire et une décision.

Les confondre produit trois symptômes que l'on retrouve d'une organisation à l'autre :

• La direction reçoit des milliers de lignes et aucune décision à prendre.
• L'équipe corrige ce qui est noté « critique », pas ce qui menace un processus dont l'entreprise vit.
• Le budget suit le volume d'alertes, pas la baisse du risque.

Ce que ça change : un conseil d'administration ne peut pas arbitrer une liste de vulnérabilités. Il peut arbitrer dix scénarios, à condition qu'ils soient écrits dans sa langue.

Partir des processus d'affaires, pas des actifs

Le réflexe technique consiste à partir de l'inventaire : les serveurs, les applications, les postes. On obtient vite des centaines de lignes, et on se perd avant d'avoir parlé d'argent. Partez plutôt d'une question que n'importe quel dirigeant comprend : quels processus, s'ils s'arrêtaient une semaine, mettraient l'entreprise en difficulté ?

Pour la plupart des organisations, la réponse tient en quelques verbes : encaisser, produire ou rendre le service, livrer, payer, servir les clients, respecter ses obligations. C'est la même logique que le bilan d'impact d'un plan de continuité, et ce n'est pas un hasard : le registre et la continuité regardent les mêmes processus, l'un pour décider, l'autre pour tenir.

Les méthodes publiques disent la même chose. Depuis sa révision d'octobre 2022, ISO/IEC 27005 décrit deux approches complémentaires pour identifier les risques : une approche par événements, qui part des sources de risque et de leurs conséquences, et une approche par actifs, qui descend aux menaces et aux vulnérabilités de chaque actif. La méthode EBIOS Risk Manager de l'ANSSI, librement disponible, consacre deux de ses cinq ateliers à cette étape : les sources de risque, puis les scénarios stratégiques. Les deux convergent sur l'ordre : d'abord les scénarios qui comptent pour l'organisation, ensuite les actifs qui les portent. Le backlog arrive à la fin, pas au début.

L'anatomie d'un scénario

Un scénario utile tient en une phrase, et cette phrase a quatre parties :

1. Une source : qui ou quoi provoque l'événement. Un groupe de rançongiciel, un fraudeur, un employé, un fournisseur défaillant, une panne.
2. Un événement : ce qui se produit. Un chiffrement, un virement détourné, une fuite, une indisponibilité.
3. Ce qui est touché : le processus d'abord, puis les actifs qui le portent.
4. La conséquence d'affaires : en jours d'arrêt, en dollars, en obligations. Une notification réglementaire, des pénalités contractuelles, un client perdu.

Trois versions du même risque montrent la différence :

• Trop technique : « Exploitation d'une vulnérabilité sur le VPN. » C'est une ligne de backlog. Elle dit comment, pas ce qu'on perd.
• Trop vague : « Cyberattaque. » Personne ne peut la traiter, la chiffrer ni s'en voir confier la responsabilité.
• Utile : « Un groupe de rançongiciel chiffre l'ERP et ses sauvegardes ; la facturation et les expéditions s'arrêtent dix jours, et nos deux plus gros clients appliquent leurs pénalités de retard. » Un dirigeant peut la lire, la contester, l'arbitrer.

L'exemple chiffré est fictif, la méthode ne l'est pas : c'est la conséquence, exprimée dans les unités de la direction, qui transforme une inquiétude en décision.

Dix scénarios pour commencer

Voici dix scénarios que la plupart des organisations reconnaissent, des PME aux grandes entreprises, quel que soit le secteur. Ils ne sont pas tous les vôtres : un cabinet n'a pas d'usine, une municipalité ne répond pas à des appels d'offres. Servez-vous-en comme d'une grille de départ, puis réécrivez-les avec vos processus, vos systèmes et vos chiffres.

1. Rançongiciel sur le système de gestion : l'ERP, le dossier client ou la paie sont chiffrés ; plus de commandes, plus de facturation, plus de salaires. Voir notre fiche sur le rançongiciel.
2. Arrêt du service rendu : une chaîne de production, un centre d'appels ou une plateforme en ligne s'arrête. La CCQ a vécu quinze jours sans services cet été, et toute une industrie avec elle.
3. Fraude au paiement : un virement détourné, ou les coordonnées bancaires d'un fournisseur modifiées. C'est le scénario de notre épisode sur l'IA offensive : aucun système n'est piraté, l'argent part quand même.
4. Compromission de la messagerie de la direction : un compte de dirigeant sert à donner des ordres, à lire les négociations, à préparer la fraude. C'est la compromission de courriel d'affaires.
5. Fuite de renseignements personnels : des données de clients ou d'employés sortent. Au Québec, c'est un incident de confidentialité au sens de la Loi 25, avec un registre à tenir et, s'il y a risque de préjudice sérieux, un avis à la Commission d'accès à l'information et aux personnes concernées.
6. Indisponibilité d'un fournisseur critique : l'hébergeur, le logiciel de gestion en mode SaaS ou le sous-traitant qui porte un processus tombe, et son arrêt devient le vôtre.
7. Intrusion par un prestataire : un fournisseur qui a accès à vos systèmes, pour la maintenance ou l'infogérance, sert de porte d'entrée. Les trois incidents de Master of Malt, Cooksongold et la Bourse du Népal sont tous passés par là.
8. Perte d'un site : un bureau, une usine ou un entrepôt devient inaccessible, physiquement ou parce que son réseau doit être isolé.
9. Vol d'informations stratégiques : soumissions, plans, listes de prix, propriété intellectuelle. Rien ne s'arrête, mais un concurrent ou un acheteur en sait trop.
10. Perte d'un accès critique : les comptes administrateurs, l'identité infonuagique ou la console de sauvegarde ne sont plus sous votre contrôle, ou une seule personne en détient les clés.

Si votre liste dépasse vingt lignes dès le premier jet, elle redevient un backlog déguisé. Gardez les dix qui feraient le plus mal, et notez les autres pour plus tard.

Les trois pièges

Trop technique. Le scénario parle d'une faille, d'un port, d'un produit. Il appartient au backlog. Remontez d'un cran : qu'est-ce que cette faille permettrait de faire à quel processus ?

Trop vague. « Cyberattaque », « fuite de données », « panne informatique ». Ces mots ne se traitent pas, ne se chiffrent pas et ne s'assignent pas. Ajoutez la source, le processus et la conséquence jusqu'à ce que la phrase puisse être contestée par quelqu'un.

Sans propriétaire. Un scénario sans nom à côté reste un constat, pas un risque géré. Et le nom doit être celui d'une personne, pas d'un service : « la TI » ne prend pas de décision. Ce sera le sujet de dimanche prochain, parce qu'un risque a en réalité plusieurs propriétaires, qui ne font pas le même travail.

Le test de la semaine : trente minutes, trois personnes

Réunissez trois personnes : quelqu'un des finances, quelqu'un des opérations, quelqu'un de la TI. Pas plus. Réglez une minuterie sur trente minutes.

1. Écrivez ensemble dix scénarios, chacun en une phrase, avec ses quatre parties : la source, l'événement, ce qui est touché, la conséquence d'affaires.
2. Pour chacun, inscrivez à côté le nom de la personne qui en répond aujourd'hui. Pas celle qui devrait, celle qui le fait.
3. Comptez.

Trois résultats doivent vous alerter. Moins de cinq scénarios avec un propriétaire nommé : vous avez une liste de craintes, pas encore un registre. Des scénarios tous écrits par la TI : votre registre parle de technique, et la direction ne s'y reconnaîtra pas. Aucune conséquence exprimée en jours ou en dollars : personne ne pourra arbitrer entre deux risques, ni défendre un budget.

Ce que vous devriez avoir dimanche prochain

Une page. Dix scénarios écrits dans la langue de la direction, une colonne « propriétaire » avec ses trous bien visibles, et pour chaque scénario un ordre de grandeur de la conséquence, même grossier. Ce n'est pas encore un registre complet. C'est la partie qui manque à la plupart des registres.

Où FortaRisks intervient

Un registre tenu à la main vieillit dès qu'il est publié. Forta Cockpit tient le vôtre à jour : il se remplit tout seul à partir des signaux de la plateforme, sur 9 domaines et 52 sous-domaines de risque, et chaque risque porte son niveau inhérent et son niveau résiduel. Vos scénarios d'affaires restent les vôtres ; la plateforme apporte ce qui se passe réellement dessous. Pour situer votre organisation dès maintenant, le score de risque cyber gratuit vous donne en dix minutes une lecture de vos principaux domaines.

Dimanche prochain : les quatre propriétaires de chaque risque. Celui qui l'accepte, celui qui le traite, celui qui le surveille et celui qui en rend compte, et pourquoi les confondre est la première cause d'un registre que personne ne lit.

Sources : ISO, ISO/IEC 27005:2022, lignes directrices pour la gestion des risques liés à la sécurité de l'information · ANSSI, la méthode EBIOS Risk Manager