Comprendre la GRC et sa place dans la cybersécurité.

Introduction

Lorsqu’on parle de cybersécurité, les premières images qui viennent souvent à l’esprit sont techniques : pare-feu, antivirus, EDR, SIEM, tests d’intrusion, sauvegardes, chiffrement ou encore gestion des vulnérabilités.

Ces mécanismes sont indispensables. Mais ils ne constituent qu’une partie de la sécurité.

Une organisation peut disposer d’excellentes technologies de cybersécurité et pourtant être incapable de répondre clairement à des questions fondamentales :

Qui décide des priorités de sécurité ? Quels sont les services réellement critiques ? Quels risques l’organisation accepte-t-elle ? Qui peut accepter ces risques ? Comment sait-on que les mesures de sécurité mises en place fonctionnent réellement ? Quelles obligations réglementaires doivent être respectées ? Comment la Direction sait-elle si le niveau de risque devient préoccupant ?

C’est précisément à ce niveau qu’intervient la GRC : Governance, Risk and Compliance, ou Gouvernance, Risques et Conformité.

La GRC permet de relier la cybersécurité à la mission de l’organisation.

Elle transforme une sécurité centrée uniquement sur les équipements et les incidents en une démarche structurée permettant de comprendre les enjeux, décider, maîtriser les risques, démontrer la conformité et vérifier l’efficacité des mesures mises en place.

01Les objectifs du cours

À la fin de ce premier cours, vous devez être capable d’expliquer simplement ce qu’est la GRC et pourquoi elle est indispensable en cybersécurité.

Vous devez également savoir distinguer une menace, une vulnérabilité, un risque et un contrôle ; comprendre la différence entre gouvernance, management et opérations ; expliquer le rôle de la conformité et de l’audit ; comprendre les notions de risque inhérent et résiduel ; et commencer à analyser un service informatique avec une véritable logique GRC.

L’objectif n’est donc pas seulement de retenir des définitions.

L’objectif est de commencer à penser comme un professionnel GRC.

02Avant la GRC : comprendre ce que la cybersécurité cherche réellement à protéger

Une erreur fréquente consiste à considérer que la mission de la cybersécurité est de protéger des ordinateurs, des serveurs ou des réseaux.

Ce n’est pas exactement le cas.

Les systèmes d’information existent parce qu’ils supportent une activité.

Un serveur peut héberger une application de gestion financière. Une base de données peut contenir les informations nécessaires à la facturation. Une plateforme cloud peut supporter la messagerie de toute l’organisation. Un réseau peut permettre à plusieurs agences d’accéder à un service métier essentiel.

Ce que l’organisation cherche réellement à protéger n’est donc pas seulement le serveur ou le réseau.

Elle cherche à protéger sa capacité à accomplir sa mission.

Prenons une banque.

Si son système informatique est indisponible, elle peut perdre sa capacité à exécuter certaines transactions.

Prenons un hôpital.

Une interruption informatique peut empêcher l’accès aux dossiers patients ou perturber certains équipements médicaux.

Prenons une administration publique.

Une indisponibilité prolongée peut empêcher les citoyens d’accéder à certains services essentiels.

Dans chaque cas, le problème informatique devient rapidement un problème métier.

C’est une idée fondamentale que nous retrouverons tout au long de cette Académie :

La cybersécurité n’est pas une finalité. Elle protège la mission, les activités et les objectifs de l’organisation.

03Alors, qu’est-ce que la GRC ?

GRC signifie :

Governance – Risk – Compliance

soit :

Gouvernance – Risques – Conformité.

On pourrait définir simplement la GRC comme :

L’ensemble des mécanismes permettant à une organisation de prendre de bonnes décisions, de maîtriser ses risques et de respecter ses obligations.

Cette définition est volontairement simple.

Mais elle contient déjà l’essentiel.

La gouvernance s’intéresse à la manière dont les orientations sont définies, les responsabilités attribuées et les décisions prises.

La gestion des risques cherche à comprendre les événements susceptibles d’empêcher l’organisation d’atteindre ses objectifs.

La conformité cherche à identifier puis à respecter les obligations applicables.

Ces trois dimensions fonctionnent ensemble.

Une organisation ne peut pas correctement gérer ses risques si elle ne sait pas qui doit prendre les décisions.

Elle ne peut pas assurer sa conformité si elle ne sait pas quelles obligations s’appliquent.

Et elle ne peut pas gouverner efficacement si elle ne possède aucune visibilité sur ses risques.

04La chaîne logique de la GRC

Pour bien comprendre la GRC, il est utile de partir de la mission de l’organisation.

Une organisation existe pour accomplir quelque chose.

Elle définit donc des objectifs.

Ces objectifs peuvent être affectés par des événements indésirables.

Ces événements constituent des risques qu’il faut identifier et traiter.

L’organisation est également soumise à des obligations.

Elle met alors en place des contrôles.

Ces contrôles doivent ensuite être vérifiés.

La logique peut être représentée ainsi :

Mission

↓

Objectifs

↓

Gouvernance

↓

Risques et obligations

↓

Décisions

↓

Contrôles

↓

Mise en œuvre

↓

Preuves

↓

Vérification

↓

Assurance

↓

Amélioration

Cette chaîne résume une grande partie du travail GRC.

05Première composante : la gouvernance

La gouvernance représente le G de GRC.

Elle concerne la manière dont une organisation définit ses orientations, attribue les responsabilités, prend les décisions importantes et supervise leur mise en œuvre.

La gouvernance répond notamment à des questions comme :

Qui est responsable de la cybersécurité ?

Qui possède le risque ?

Qui peut décider qu’un risque est acceptable ?

Quels services doivent être considérés comme critiques ?

Quel niveau d’interruption est acceptable ?

Quels investissements sont prioritaires ?

Quels indicateurs doivent être remontés à la Direction ?

Qui doit être informé lorsqu’un seuil de risque est dépassé ?

La gouvernance ne consiste donc pas à configurer des équipements.

Elle définit plutôt les règles du jeu.

06Un exemple concret de gouvernance

Imaginons qu’une organisation possède une application indispensable à son activité.

La Direction décide :

« Une interruption de cette application supérieure à quatre heures n’est pas acceptable. »

Cette décision est une orientation de haut niveau.

L’équipe informatique devra ensuite déterminer comment respecter cette exigence.

Elle pourra mettre en place de la redondance, des sauvegardes, un plan de reprise d’activité, de la supervision ou encore une infrastructure de secours.

La gouvernance n’a pas nécessairement décidé quelle technologie utiliser.

Elle a défini le résultat attendu.

Voilà pourquoi gouvernance et technique sont complémentaires mais différentes.

07Gouvernance, management et opérations

Ces trois niveaux sont souvent confondus.

Pourtant, les distinguer permet de comprendre comment une organisation fonctionne réellement.

La gouvernance décide de l’orientation et supervise.

Le management organise la mise en œuvre.

Les opérations exécutent concrètement les actions.

Prenons le même exemple.

La Direction décide que les applications critiques doivent pouvoir reprendre leur activité dans un délai maximal déterminé.

C’est de la gouvernance.

Le RSSI, la DSI et les responsables métiers définissent une politique de continuité, des responsabilités, un calendrier de tests et des procédures.

C’est du management.

Les administrateurs configurent les sauvegardes, déploient la réplication, réalisent les restaurations et testent les procédures.

Ce sont les opérations.

On peut retenir simplement :

Gouvernance → décide et supervise

Management → organise et pilote

Opérations → exécutent

L’un des rôles du professionnel GRC consiste à vérifier que ces trois niveaux restent alignés.

08Deuxième composante : la gestion des risques

La gestion des risques représente le R de GRC.

Un risque correspond à l’effet potentiel d’un événement incertain sur les objectifs de l’organisation.

En cybersécurité, nous pouvons retenir une formulation plus intuitive :

Un risque cyber est la possibilité qu’un événement lié au numérique affecte les activités, les objectifs ou les intérêts de l’organisation.

Cette définition est importante car elle évite de réduire le risque à une simple vulnérabilité technique.

09Vulnérabilité, menace et risque : la distinction fondamentale

Imaginons qu’un serveur utilise un logiciel contenant une vulnérabilité critique.

Cette vulnérabilité constitue une faiblesse.

Elle ne nous dit cependant pas encore quel est le risque réel.

Pour comprendre le risque, il faut connaître le contexte.

Quel service fonctionne sur ce serveur ?

Le serveur est-il accessible depuis Internet ?

Quelles données contient-il ?

Existe-t-il d’autres protections ?

Quelle serait la conséquence d’une compromission ?

Un serveur de laboratoire isolé ne représente pas nécessairement le même niveau de risque qu’un serveur hébergeant la plateforme financière de l’organisation.

C’est précisément pour cette raison qu’un professionnel GRC ne s’arrête pas à la phrase :

« Nous avons une vulnérabilité critique. »

Il demande :

« Que signifie cette vulnérabilité pour notre organisation ? »

10La vulnérabilité

Une vulnérabilité est une faiblesse susceptible d’être exploitée ou de contribuer à un événement indésirable.

Elle peut être technique.

Par exemple :

un logiciel non corrigé.

Elle peut également être organisationnelle.

Par exemple :

l’absence de procédure de révocation des comptes lorsqu’un collaborateur quitte l’organisation.

Elle peut encore être humaine.

Par exemple :

des utilisateurs insuffisamment sensibilisés au phishing.

Une vulnérabilité est donc une faiblesse. Elle n’est pas, à elle seule, le risque.

11La menace

Une menace est quelque chose capable de provoquer un événement indésirable ou d’exploiter une faiblesse.

Une menace peut être intentionnelle.

Par exemple, un cybercriminel souhaitant voler des données.

Elle peut également être accidentelle.

Une erreur de configuration peut entraîner une fuite d’informations.

Elle peut être technique.

Un disque peut tomber en panne.

Elle peut même être environnementale.

Une coupure électrique, un incendie ou une inondation peuvent affecter la disponibilité d’un système.

Le risque cyber ne se limite donc pas aux hackers.

12Construire un scénario de risque

Prenons une application RH contenant des données personnelles.

Le serveur qui l’héberge n’a pas reçu certaines mises à jour de sécurité.

Nous disposons maintenant de plusieurs éléments.

L’actif est l’application RH et les informations qu’elle contient.

La vulnérabilité est l’absence de correctifs.

La menace peut être un attaquant externe.

Le scénario de risque pourrait être :

Un attaquant exploite une vulnérabilité du serveur RH, obtient un accès au système et exfiltre les données personnelles des collaborateurs.

Nous pouvons maintenant réfléchir aux impacts possibles : perte de confidentialité, indisponibilité, conséquences réglementaires, atteinte à la réputation ou coûts de remédiation.

Nous sommes passés d’un problème technique à un véritable raisonnement GRC.

13La notion d’actif

Un actif est quelque chose ayant de la valeur pour l’organisation.

Beaucoup de personnes pensent immédiatement aux équipements :

serveur, ordinateur, routeur ou pare-feu.

Mais les actifs peuvent être beaucoup plus larges.

Une donnée peut être un actif.

Une application peut être un actif.

Une compétence rare peut être un actif.

La réputation peut être un actif.

Un processus métier peut également être considéré comme un élément essentiel à protéger.

C’est pourquoi les analyses de risques modernes cherchent généralement à comprendre d’abord ce qui a de la valeur pour l’organisation, avant de chercher les menaces qui pourraient l’affecter.

14Impact et vraisemblance

Lorsqu’un scénario de risque est identifié, il faut généralement déterminer deux dimensions.

La première est l’impact.

Autrement dit :

Si le scénario se produit, quelles seront les conséquences ?

Ces conséquences peuvent être financières, opérationnelles, juridiques, réglementaires, humaines ou réputationnelles.

La deuxième dimension est la vraisemblance.

La question devient :

Quelle est la possibilité que ce scénario se réalise dans notre contexte ?

Une analyse de risques ne consiste donc pas simplement à imaginer les pires événements possibles.

Elle doit permettre d’évaluer lesquels nécessitent réellement l’attention de l’organisation.

15Le risque inhérent

Le risque inhérent représente le niveau de risque avant de considérer l’efficacité des mesures de sécurité existantes.

Imaginons une application très sensible exposée directement sur Internet.

Si aucune protection n’était mise en place, le risque de compromission pourrait être particulièrement important.

Cette première évaluation correspond au risque inhérent.

16Le risque résiduel

L’organisation met ensuite en place plusieurs contrôles :

authentification multifacteur, segmentation réseau, protection applicative, supervision, correctifs de sécurité, EDR et journalisation.

Le risque diminue.

Il ne disparaît cependant probablement pas totalement.

Le risque qui reste après la prise en compte des contrôles est appelé :

risque résiduel.

C’est une notion fondamentale en GRC.

Le véritable objectif n’est pas nécessairement de supprimer tous les risques.

Cela serait souvent impossible.

L’objectif consiste à ramener les risques à un niveau acceptable pour l’organisation.

17Peut-on atteindre le risque zéro ?

Non.

Toute activité comporte une part de risque.

Une organisation pourrait parfois réduire presque totalement un risque en arrêtant l’activité qui le génère.

Mais elle pourrait alors ne plus être en mesure d’accomplir sa mission.

Prenons un exemple volontairement simple.

La manière la plus radicale d’empêcher une application accessible sur Internet d’être attaquée serait parfois de la déconnecter complètement d’Internet.

Mais si l’application doit être accessible aux clients, cette solution détruit sa raison d’être.

La gestion des risques cherche donc un équilibre.

Il faut protéger suffisamment l’organisation sans empêcher son fonctionnement.

18L’appétence au risque

L’appétence au risque représente le niveau de risque qu’une organisation est disposée à accepter dans la poursuite de ses objectifs.

Toutes les organisations n’ont pas la même appétence.

Une startup peut accepter davantage de risques associés à l’expérimentation technologique.

Une banque sera probablement beaucoup plus prudente concernant les transactions financières.

Une infrastructure critique pourra avoir une appétence extrêmement faible concernant la disponibilité de certains services.

L’appétence au risque est donc une question de gouvernance.

Elle permet de répondre à une question essentielle :

Jusqu’où l’organisation accepte-t-elle de prendre des risques ?

19La tolérance au risque

La tolérance au risque permet généralement de traduire une orientation générale en limites plus concrètes.

Une organisation peut déclarer :

« Nous avons une très faible appétence pour les interruptions de nos services critiques. »

Cette orientation est utile, mais reste générale.

Elle peut ensuite être traduite en une tolérance plus mesurable :

« Une interruption supérieure à deux heures d’un service classé critique n’est pas acceptable. »

La gouvernance commence alors à devenir exploitable par les équipes opérationnelles.

20Comment traiter un risque ?

Lorsqu’un risque est identifié et évalué, l’organisation doit décider quoi en faire.

Quatre stratégies sont classiquement utilisées.

Éviter le risque signifie supprimer l’activité qui génère le risque.

Réduire le risque consiste à mettre en place des mesures afin d’en diminuer la vraisemblance ou l’impact.

Transférer ou partager le risque consiste à transférer une partie de l’exposition à une autre organisation, par exemple à travers certaines dispositions contractuelles ou une assurance.

Enfin, accepter le risque signifie reconnaître que le niveau résiduel est considéré comme acceptable.

Cette dernière option est importante.

Accepter un risque n’est pas la même chose qu’ignorer un risque.

Une véritable acceptation doit être consciente, documentée et effectuée par une personne disposant de l’autorité nécessaire.

21Qui possède le risque ?

Nous arrivons ici à une distinction capitale.

Le RSSI n’est pas automatiquement propriétaire de tous les risques cyber.

Pourquoi ?

Parce que les conséquences du risque touchent généralement une activité métier.

Imaginons un système permettant à une Direction financière de réaliser ses opérations.

Le RSSI peut identifier les risques de cybersécurité, recommander des mesures et accompagner leur traitement.

Mais il ne devrait pas décider seul qu’une interruption importante du processus financier est acceptable.

Le propriétaire du processus métier doit être impliqué.

C’est la notion de Risk Owner, ou propriétaire du risque.

Le Risk Owner possède suffisamment d’autorité et de responsabilité pour décider comment le risque doit être traité ou accepté.

Le professionnel GRC facilite cette décision.

Il n’a pas pour rôle de décider à la place de tout le monde.

22Troisième composante : la conformité

La conformité représente le C de GRC.

Elle répond à une question apparemment simple :

Quelles règles devons-nous respecter ?

La difficulté est que ces règles peuvent provenir de nombreuses sources.

Une organisation peut simultanément être soumise à des lois nationales, des réglementations sectorielles, des contrats, des normes, des exigences clients et ses propres politiques internes.

Le travail de conformité commence donc par l’identification des exigences réellement applicables.

On parle parfois de Compliance Universe, c’est-à-dire l’ensemble des obligations auxquelles l’organisation doit se conformer.

23Une obligation n’est pas encore un contrôle

Imaginons qu’une exigence indique :

Les accès administratifs doivent bénéficier d’un niveau de protection renforcé.

Cette exigence exprime ce qui doit être obtenu.

Mais il faut ensuite déterminer comment l’organisation va y répondre.

Elle pourrait décider d’utiliser :

* l’authentification multifacteur ; * des comptes administrateurs séparés ; * une solution de gestion des accès privilégiés ; * une surveillance spécifique des connexions.

Ces mécanismes constituent des contrôles.

Nous pouvons alors construire une chaîne :

Exigence

↓

Contrôle

↓

Responsable

↓

Mise en œuvre

↓

Preuve

↓

Test

↓

Conclusion

C’est une logique essentielle en audit et en conformité.

24Être conforme signifie-t-il être sécurisé ?

Pas nécessairement.

C’est une distinction que tout professionnel GRC doit comprendre.

Une organisation peut respecter exactement une exigence réglementaire particulière mais rester exposée à d’autres risques.

Inversement, une organisation peut avoir mis en place de très bonnes protections techniques sans pouvoir démontrer qu’elle respecte certaines obligations réglementaires.

La conformité répond principalement à :

Respectons-nous les exigences applicables ?

La gestion des risques répond davantage à :

Les risques qui peuvent affecter nos objectifs sont-ils correctement maîtrisés ?

Les deux disciplines sont donc complémentaires.

25Le contrôle : le lien entre le risque et l’action

Un contrôle est une mesure destinée à modifier un risque ou à satisfaire une exigence.

Prenons un risque simple :

Compromission d’un compte administrateur à la suite du vol de son mot de passe.

L’organisation met en place une authentification multifacteur.

Le MFA devient un contrôle destiné à réduire la probabilité qu’un attaquant puisse se connecter uniquement avec le mot de passe volé.

Mais il ne suffit pas d’écrire :

« Nous avons du MFA. »

Encore faut-il déterminer s’il fonctionne réellement.

26Trois questions à poser sur un contrôle

Lorsqu’un professionnel GRC évalue un contrôle, trois niveaux de réflexion sont particulièrement utiles.

Le contrôle est-il bien conçu ?

Le mécanisme choisi permet-il réellement de répondre au risque ?

Le contrôle est-il réellement mis en œuvre ?

Un MFA prévu dans une politique mais jamais activé ne protège rien.

Le contrôle est-il efficace ?

Même installé, le contrôle peut comporter des faiblesses.

Imaginons que le MFA soit activé pour 95 % des utilisateurs, mais pas pour certains comptes administrateurs très sensibles.

Le contrôle existe.

Il est largement déployé.

Mais son efficacité peut rester insuffisante.

C’est précisément ce genre de différence que recherchent les audits.

27Les différentes familles de contrôles

Il existe plusieurs manières de classifier les contrôles.

Une classification simple consiste à regarder leur fonction.

Un contrôle préventif cherche à empêcher l’incident. Le MFA en est un bon exemple.

Un contrôle détectif cherche à repérer qu’un événement s’est produit ou est en train de se produire. Un SIEM ou certains mécanismes de surveillance peuvent jouer ce rôle.

Un contrôle correctif aide à corriger une situation après qu’une faiblesse a été identifiée.

Un contrôle de récupération vise à restaurer un service ou une capacité, comme une procédure de restauration depuis une sauvegarde.

Une deuxième classification distingue généralement les contrôles organisationnels, techniques et physiques.

Ces catégories ne sont pas opposées.

Une protection efficace combine généralement plusieurs types de contrôles.

28Le concept de défense en profondeur

Un principe important de la sécurité consiste à ne pas dépendre d’une seule mesure.

Imaginons qu’un utilisateur reçoive un courriel de phishing.

L’organisation peut disposer de plusieurs niveaux de défense.

La passerelle de messagerie peut bloquer le message.

S’il passe, la sensibilisation peut permettre à l’utilisateur de reconnaître la fraude.

S’il clique malgré tout, l’EDR peut détecter une activité malveillante.

Si les identifiants sont volés, le MFA peut compliquer leur exploitation.

Les journaux peuvent enfin permettre de détecter une tentative suspecte.

Cette logique s’appelle souvent defense in depth, ou défense en profondeur.

Elle montre pourquoi la maîtrise du risque repose généralement sur un ensemble cohérent de contrôles, et non sur une technologie unique.

29La preuve : « Montrez-moi que cela fonctionne »

La GRC possède une culture très importante de la preuve.

Supposons qu’un administrateur affirme :

« Tous les serveurs sont sauvegardés chaque nuit. »

Pour un audit ou une évaluation GRC, cette déclaration seule n’est généralement pas suffisante.

Il faudra rechercher des éléments permettant de la confirmer.

Par exemple :

un rapport de sauvegarde, une configuration, des journaux, un historique d’exécution ou les résultats d’un test de restauration.

Le professionnel GRC apprend donc à poser une question simple mais puissante :

Comment pouvons-nous démontrer que ce contrôle existe et qu’il fonctionne ?

Une bonne preuve doit être pertinente par rapport à ce que l’on cherche à vérifier, suffisamment fiable, récente lorsque cela est nécessaire et vérifiable.

30Contrôle et assurance

Le contrôle cherche à réduire le risque.

L’assurance cherche à donner confiance dans le fait que le dispositif fonctionne réellement.

Prenons un exemple.

L’équipe informatique affirme que tous les comptes administrateurs sont protégés par MFA.

Le contrôle existe.

Une revue indépendante vérifie la configuration et découvre que deux comptes d’urgence ont été exclus sans justification.

Cette vérification fournit de l’assurance sur l’état réel du contrôle.

Voilà pourquoi GRC et audit sont fortement liés.

31Politique, standard, procédure et guide

Une organisation possède généralement plusieurs niveaux de documentation.

Ces documents ne remplissent pas tous le même rôle.

Une politique fixe une orientation ou une règle de haut niveau.

Par exemple :

Les accès aux informations sensibles doivent être limités aux personnes autorisées.

Un standard précise une exigence obligatoire permettant d’appliquer cette politique.

Par exemple :

Tous les comptes privilégiés doivent utiliser une authentification multifacteur.

Une procédure explique concrètement comment réaliser une activité.

Par exemple :

Procédure de création d’un compte administrateur.

Enfin, un guide propose généralement des recommandations pratiques.

Par exemple :

Guide de configuration sécurisée d’un serveur Ubuntu.

La hiérarchie peut être résumée ainsi :

Politique → Standard → Procédure → Guide → Preuves

Cette distinction deviendra particulièrement importante lorsque nous travaillerons sur le SMSI et ISO 27001.

32Les acteurs de la GRC

La GRC ne peut pas fonctionner si l’organisation considère que la cybersécurité appartient exclusivement à la DSI ou au RSSI.

La Direction définit les orientations et arbitre les décisions importantes.

Les responsables métiers connaissent les processus, la criticité des activités et les conséquences d’une interruption.

La DSI met en œuvre de nombreux contrôles techniques.

Le RSSI pilote ou coordonne le programme de sécurité et conseille l’organisation sur ses risques.

Les fonctions Risk et Compliance apportent leurs cadres de gestion et de surveillance.

L’audit fournit une assurance indépendante.

Enfin, chaque collaborateur possède également une part de responsabilité dans l’application des règles de sécurité.

La GRC est donc fondamentalement transverse.

33Le modèle des trois lignes

Pour comprendre cette répartition, le modèle des trois lignes est particulièrement utile.

La première ligne correspond aux métiers et aux opérations.

Ce sont les équipes qui réalisent l’activité au quotidien et qui gèrent directement une grande partie des risques.

La deuxième ligne regroupe les fonctions qui apportent des cadres, du conseil, de la supervision et du challenge.

La fonction cybersécurité, la gestion des risques ou la conformité peuvent se situer ici selon l’organisation.

La troisième ligne est principalement représentée par l’audit interne.

Son rôle consiste à fournir une assurance indépendante sur le fonctionnement du système de gouvernance, de gestion des risques et de contrôle.

Cette séparation permet d’éviter une situation problématique :

La même personne conçoit le contrôle, l’exploite, vérifie son fonctionnement et déclare elle-même qu’il est efficace.

L’indépendance devient alors très faible.

34Le cycle GRC

La GRC fonctionne comme un cycle continu.

Tout commence par la compréhension du contexte de l’organisation : sa mission, ses objectifs, ses processus, ses actifs et ses parties prenantes.

Les risques et obligations sont ensuite identifiés.

Des contrôles sont mis en place.

Leur efficacité est surveillée.

Les résultats sont communiqués aux personnes responsables.

Des décisions sont prises.

Enfin, le dispositif est amélioré.

Nous pouvons résumer ce cycle ainsi :

Comprendre

→ Identifier

→ Évaluer

→ Décider

→ Traiter

→ Vérifier

→ Rapporter

→ Améliorer

Puis le cycle recommence.

Pourquoi ?

Parce que l’environnement change constamment.

De nouvelles technologies apparaissent.

De nouveaux fournisseurs sont utilisés.

De nouvelles vulnérabilités sont découvertes.

Les activités évoluent.

Les réglementations changent.

La gestion des risques doit donc évoluer avec l’organisation.

35Comment raisonne un professionnel GRC ?

Prenons une phrase typique :

« Notre serveur n’a pas été mis à jour depuis six mois. »

Une réaction purement technique serait :

« Il faut immédiatement installer les mises à jour. »

Cela peut être parfaitement correct.

Mais le professionnel GRC commence par comprendre le contexte.

Quel service est hébergé ?

Quelle est sa criticité ?

Le serveur est-il exposé ?

Quelles données sont présentes ?

Quelle vulnérabilité existe réellement ?

Quels contrôles compensatoires sont déjà en place ?

Pourquoi les correctifs ne sont-ils pas installés ?

Le patch peut-il provoquer une interruption ?

Existe-t-il une fenêtre de maintenance ?

Quelle personne accepte le risque pendant la période où le serveur reste vulnérable ?

Le professionnel GRC ne remplace donc pas le technicien.

Il ajoute le contexte, le risque et la décision.

36Du langage technique au langage métier

Une compétence extrêmement importante en GRC consiste à traduire.

Prenons :

CVE critique, CVSS 9.8, Remote Code Execution.

Cette formulation est utile pour une équipe technique.

Pour un comité de direction, elle peut être traduite en :

Une vulnérabilité présente sur le serveur de l’application financière pourrait permettre à un attaquant distant de prendre le contrôle du système. Une exploitation pourrait interrompre les opérations et exposer certaines données sensibles.

La deuxième formulation ne remplace pas la première.

Elle répond simplement aux besoins d’un public différent.

Le professionnel GRC doit être capable de parler :

le langage technique ;

le langage du risque ;

le langage de la conformité ;

le langage métier ;

et le langage de la Direction.

C’est précisément cette capacité à relier plusieurs mondes qui fait sa valeur.

37CAS PRATIQUE — Messagerie Microsoft 365

Imaginons une organisation utilisant Microsoft 365 pour sa messagerie.

Pour l’équipe technique, le service peut sembler simple :

Les utilisateurs peuvent envoyer et recevoir leurs courriels.

Mais regardons maintenant le service avec une approche GRC.

La première question n’est pas immédiatement technique.

Nous devons comprendre l’importance du service.

Si Microsoft 365 devient indisponible pendant une heure, l’impact peut être limité.

Si la messagerie reste inaccessible plusieurs jours, les conséquences peuvent devenir très importantes.

La gouvernance doit donc permettre de déterminer le niveau de disponibilité attendu et les personnes responsables.

Nous pouvons ensuite étudier les risques.

Que se passe-t-il si un compte administrateur est compromis ?

Que se passe-t-il si le prestataire chargé de l’administration devient indisponible ?

Que se passe-t-il si des données sont supprimées ?

Que se passe-t-il si le service cloud subit une panne importante ?

Que se passe-t-il si un utilisateur victime de phishing compromet sa boîte mail ?

La réflexion sur les contrôles vient ensuite.

Le MFA peut réduire certains risques.

La gestion des privilèges peut réduire l’exposition des administrateurs.

La journalisation permet d’obtenir de la visibilité.

Les procédures de continuité permettent d’anticiper certaines interruptions.

Mais la GRC ne s’arrête pas à l’existence de ces contrôles.

Il faut aussi pouvoir les vérifier.

Le MFA est-il appliqué à tous les administrateurs ?

Existe-t-il des exceptions ?

Qui revoit les comptes privilégiés ?

Les restaurations ont-elles déjà été testées ?

Les accès du prestataire sont-ils encadrés ?

L’organisation possède-t-elle un moyen d’escalader directement un incident critique ?

Nous sommes maintenant passés d’une question :

« Est-ce que Microsoft 365 fonctionne ? »

à :

« Les risques associés à notre dépendance à Microsoft 365 sont-ils suffisamment maîtrisés ? »

C’est une manière très différente de regarder le système d’information.

38Dans la peau du GRC

Vous arrivez dans une organisation.

Le Directeur informatique vous annonce :

« Nous avons un excellent niveau de sécurité. Nous avons acheté un nouveau pare-feu, un EDR et un SIEM. »

Votre rôle n’est pas de contester cette affirmation immédiatement.

Vous devez d’abord comprendre ce qu’elle signifie.

Vous pourriez commencer par demander :

Quels services critiques cherchez-vous à protéger ?

Quels sont actuellement vos principaux risques cyber ?

Existe-t-il un registre des risques ?

Qui accepte les risques importants ?

Quels contrôles sont considérés comme essentiels ?

Comment leur efficacité est-elle mesurée ?

Quels incidents significatifs sont survenus récemment ?

Quelles obligations réglementaires doivent être respectées ?

À quelle fréquence la Direction reçoit-elle un reporting sur les risques cyber ?

Ces questions permettent de découvrir une idée essentielle :

Le niveau de maturité GRC d’une organisation ne peut pas être déterminé uniquement par le nombre d’outils de sécurité qu’elle possède.

39Une erreur classique : commencer par l’outil

Une organisation découvre qu’elle doit améliorer sa cybersécurité.

La première réaction peut être :

« Il nous faut un SIEM. »

Ou :

« Il nous faut un SOC. »

Ou encore :

« Nous devons acheter une solution GRC. »

Ces solutions peuvent être pertinentes.

Mais la première question devrait être :

Quel problème cherchons-nous à résoudre ?

Si l’organisation ne connaît pas ses actifs critiques, ses risques, ses responsabilités et ses objectifs de sécurité, l’achat d’un outil supplémentaire ne réglera pas automatiquement le problème.

La GRC cherche donc d’abord à structurer le raisonnement.

40Ce que la GRC n’est pas

La GRC n’est pas une activité consistant uniquement à remplir des tableaux Excel.

Elle ne consiste pas à réciter des normes.

Elle ne consiste pas à produire des politiques que personne n’applique.

Elle ne consiste pas non plus à déclarer tous les risques « critiques » pour se protéger personnellement.

Une GRC mature doit aider l’organisation à prendre des décisions réalistes.

Elle doit permettre de répondre :

Qu’est-ce qui est important ?

Qu’est-ce qui peut mal se passer ?

Quel niveau de risque sommes-nous prêts à accepter ?

Que devons-nous faire en priorité ?

Comment savons-nous que cela fonctionne ?

41Le véritable rôle du professionnel GRC

Le professionnel GRC se trouve au croisement de plusieurs disciplines.

Il doit comprendre suffisamment la technologie pour discuter avec les équipes techniques.

Il doit comprendre les processus métiers pour évaluer les conséquences d’un incident.

Il doit maîtriser les méthodes de gestion des risques.

Il doit savoir interpréter les obligations réglementaires et normatives.

Il doit être capable d’analyser les contrôles et leurs preuves.

Enfin, il doit savoir communiquer avec le management et la Direction.

Son rôle n’est donc pas simplement de dire :

« Nous avons un risque élevé. »

Il doit être capable d’expliquer :

Pourquoi ce risque est important, quelles options sont possibles, combien elles coûtent éventuellement, quel risque restera après traitement et quelle décision doit maintenant être prise.

42Premier modèle mental à retenir

À chaque fois que vous examinerez un problème cyber pendant cette Académie, essayez de suivre cette logique :

1. Quel objectif ou service cherche-t-on à protéger ?

2. Qu’est-ce qui pourrait empêcher cet objectif d’être atteint ?

3. Quelles seraient les conséquences ?

4. Quels contrôles existent ?

5. Sont-ils réellement efficaces ?

6. Quel risque reste ?

7. Ce risque est-il acceptable ?

8. Qui doit prendre la décision ?

Ces huit questions constituent déjà un excellent réflexe GRC.

43EXERCICE PRATIQUE 01 — Analyser un service avec une logique GRC

Choisissez un service informatique.

Il peut s’agir d’une messagerie, d’un Active Directory, d’une application métier, d’un serveur de fichiers ou d’une plateforme cloud.

L’objectif n’est pas encore de réaliser une analyse de risques complète.

Vous devez simplement apprendre à replacer le système dans son contexte.

Commencez par décrire le service en quelques lignes.

Pourquoi existe-t-il ?

Qui l’utilise ?

Que se passerait-il s’il devenait indisponible pendant une heure ? Une journée ? Plusieurs jours ?

Quelles informations sont traitées ?

Qui est responsable du service ?

Identifiez ensuite trois à cinq scénarios de risque.

Ne vous contentez pas d’écrire :

Malware.

Essayez de formuler un scénario.

Par exemple :

Un compte administrateur est compromis à la suite d’une attaque de phishing et l’attaquant utilise ses privilèges pour modifier la configuration du service.

Identifiez enfin les contrôles existants.

Pour chacun d’eux, posez-vous la question :

Comment pourrais-je prouver que ce contrôle fonctionne réellement ?

44LIVRABLE PORTFOLIO 01 — Fiche d’analyse GRC d’un service

Ce premier livrable doit rester simple mais professionnel.

Il constituera la première pièce du portfolio de l’Académie.

Informations générales

Analyse

Conclusion

Terminez le document par un court paragraphe répondant à trois questions :

Quel est le principal risque identifié ?

Le niveau de protection actuel semble-t-il suffisant ?

Quelle décision devrait être prise en priorité ?

Le but du livrable n’est pas d’obtenir immédiatement une analyse parfaite.

Il permettra de mesurer votre progression lorsque nous reviendrons sur le même exercice après les modules consacrés à ISO 27001, ISO 27005, ISO 31000 et EBIOS Risk Manager.

45Quiz de validation

46LES PIÈGES À ÉVITER

À ce stade, retenez particulièrement quatre erreurs.

Confondre vulnérabilité et risque.

Une vulnérabilité n’a de sens qu’une fois replacée dans son contexte.

Considérer le RSSI comme propriétaire de tous les risques.

Le risque appartient généralement au responsable disposant de la responsabilité sur l’activité concernée.

Confondre conformité et sécurité.

Respecter une règle ne garantit pas que tous les risques sont maîtrisés.

Croire qu’un contrôle existe parce qu’il est écrit.

Une politique n’est pas une preuve de mise en œuvre.

47LES CONCEPTS À SAVOIR EXPLIQUER SANS NOTES

Avant de passer au cours suivant, vous devez être capable d’expliquer naturellement les concepts suivants :

GRC

Gouvernance

Risque

Menace

Vulnérabilité

Actif

Impact

Vraisemblance

Risque inhérent

Risque résiduel

Appétence au risque

Tolérance au risque

Risk Owner

Contrôle

Preuve

Assurance

Conformité

Trois lignes

Si vous pouvez expliquer ces notions avec un exemple simple sans réciter une définition, l’objectif du cours est atteint.

48RÉFÉRENCES POUR APPROFONDIR

Ce premier cours doit progressivement être complété par plusieurs référentiels que nous étudierons plus profondément pendant l’Académie.

ISO 31000 nous aidera à structurer la gestion des risques à l’échelle de l’organisation.

ISO/IEC 27001 nous permettra de comprendre le fonctionnement d’un système de management de la sécurité de l’information.

ISO/IEC 27005 approfondira la gestion des risques liés à la sécurité de l’information.

NIST Cybersecurity Framework 2.0 nous permettra notamment d’étudier la gouvernance cyber et le lien entre cybersécurité et gestion des risques.

EBIOS Risk Manager nous apprendra ensuite à construire des scénarios de risques cyber beaucoup plus élaborés.

COBIT apportera une vision complémentaire de la gouvernance des systèmes d’information.

Enfin, le Three Lines Model de l’Institute of Internal Auditors nous servira à approfondir la répartition des responsabilités entre management, fonctions de contrôle et audit interne.

Ces référentiels ne doivent pas être appris comme des textes à réciter.

Nous les utiliserons comme des outils pour raisonner et construire des dispositifs GRC réels.

49À RETENIR

Si vous ne deviez conserver que quelques idées de ce premier cours, retenez celles-ci.

La cybersécurité protège d’abord la mission et les objectifs de l’organisation.

La gouvernance permet de déterminer qui décide, ce qui est important et quel niveau de risque est acceptable.

La gestion des risques permet de comprendre ce qui pourrait empêcher l’organisation d’atteindre ses objectifs.

La conformité permet de comprendre quelles obligations doivent être respectées.

Les contrôles permettent de modifier le risque ou de satisfaire une exigence.

Les preuves et l’assurance permettent de vérifier que ces contrôles ne sont pas seulement déclarés, mais réellement appliqués et efficaces.

Enfin, le professionnel GRC doit constamment faire le lien entre :

TECHNOLOGIE

↓

RISQUE

↓

MÉTIER

↓

DÉCISION

C’est ce changement de perspective qui constitue le véritable point de départ de la GRC.

SYNTHÈSEFil rouge du cours

À chaque fois qu’un problème cyber vous sera présenté, ne commencez plus immédiatement par demander :

« Quelle solution technique devons-nous installer ? »

Commencez par demander :

« Quel objectif cherchons-nous à protéger, quel risque menace cet objectif et quelle décision l’organisation doit-elle prendre ? »

À partir de cette question, vous commencez déjà à raisonner comme un professionnel GRC.