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

PARTIE I

Partir De La Mission, Pas De La Technologie

02Ce que la cybersécurité cherche réellement à protéger

Dire que la cybersécurité protège des serveurs, des postes de travail ou des réseaux est techniquement vrai, mais insuffisant. Une organisation ne déploie pas un serveur pour le plaisir de posséder un serveur. Elle l’utilise parce qu’il héberge une application, stocke des informations ou supporte un service nécessaire à son activité.

Dans une banque, la compromission d’un système est importante parce qu’elle peut empêcher l’exécution de transactions, altérer leur intégrité, exposer des informations sensibles ou affecter la confiance des clients. Dans un hôpital, une interruption du système d’information peut perturber l’accès aux dossiers patients, ralentir les soins ou affecter des équipements critiques. Dans une administration publique, l’indisponibilité d’un service numérique peut empêcher les citoyens d’accéder à une prestation essentielle.

Le même raisonnement s’applique à presque toutes les organisations : la technologie est un moyen. Ce que l’on cherche réellement à préserver est la capacité de l’organisation à accomplir sa mission et atteindre ses objectifs.

La chaîne logique devient alors :

MISSION

↓

OBJECTIFS

↓

ACTIVITÉS ET PROCESSUS

↓

SERVICES

↓

INFORMATIONS ET SYSTÈMES

↓

RISQUES

Cette représentation change profondément la manière d’aborder la cybersécurité. On ne protège plus un serveur uniquement parce qu’il présente une vulnérabilité critique. On cherche à comprendre ce qui dépend de ce serveur et ce que l’organisation pourrait perdre si le scénario redouté se réalisait.

03De l’actif technique à la valeur métier

Un actif est quelque chose qui possède de la valeur pour l’organisation. Cette définition dépasse largement les équipements matériels. Un serveur peut être un actif, mais une base de données, une application, une compétence rare, une réputation, une relation contractuelle, un processus métier ou la confiance des clients peuvent également être essentiels.

Prenons une plateforme de paiement. Les serveurs qui l’hébergent possèdent évidemment une valeur financière. Pourtant, l’organisation cherche surtout à préserver sa capacité à effectuer les transactions, l’intégrité des montants, la disponibilité du service, la confidentialité des informations et la traçabilité des opérations.

Nous pouvons ainsi remonter du support technique vers l’enjeu organisationnel :

SERVEUR / APPLICATION / RÉSEAU → SERVICE → PROCESSUS MÉTIER → OBJECTIF DE L’ORGANISATION

Cette logique est fondamentale en GRC. Elle permet d’éviter une erreur fréquente : évaluer les risques uniquement à partir de la criticité technique des composants.

PARTIE II

Comprendre Réellement La Grc

04Une définition utile de la GRC

GRC signifie :

Governance — Risk — Compliance

soit :

Gouvernance — Risques — Conformité

Une définition simple mais suffisamment complète serait :

La GRC est l’ensemble des mécanismes permettant à une organisation de définir ses orientations, comprendre et maîtriser ses risques, respecter ses obligations, prendre des décisions et vérifier que les mesures mises en place produisent réellement les résultats attendus.

Ces trois dimensions ne doivent pas être étudiées séparément.

La gouvernance détermine notamment les orientations, les responsabilités, les autorités, les niveaux de risque acceptables et les mécanismes de surveillance.

La gestion des risques permet d’identifier ce qui pourrait empêcher l’organisation d’atteindre ses objectifs, d’en comprendre les conséquences et de proposer des traitements.

La conformité consiste à identifier les obligations applicables et à démontrer qu’elles sont correctement prises en compte.

La GRC apparaît donc comme un système intégré.

Une organisation ne peut pas gérer correctement ses risques si elle ne sait pas qui possède l’autorité pour prendre les décisions. Elle ne peut pas démontrer sa conformité si elle ne sait pas quelles obligations lui sont applicables. Elle ne peut pas gouverner efficacement sans disposer d’informations sur ses risques, l’efficacité de ses contrôles et les écarts à ses obligations.

05La chaîne de valeur GRC

Nous pouvons résumer une grande partie de la GRC par la chaîne suivante :

MISSION

↓

OBJECTIFS

↓

RISQUES ET OBLIGATIONS

↓

DÉCISIONS

↓

EXIGENCES

↓

CONTRÔLES

↓

MISE EN ŒUVRE

↓

PREUVES

↓

TESTS

↓

ASSURANCE

↓

REPORTING

↓

AMÉLIORATION

Cette chaîne mérite d’être comprise, car elle servira de colonne vertébrale à toute l’Académie.

L’organisation poursuit une mission et des objectifs. Ces objectifs sont soumis à des risques et à des obligations. Des décisions sont prises afin de définir ce qui doit être protégé et à quel niveau. Ces décisions sont traduites en exigences, puis en contrôles. Les contrôles sont mis en œuvre, leur existence doit pouvoir être démontrée par des preuves, leur efficacité doit être testée et les résultats doivent être communiqués aux responsables concernés. Enfin, les écarts identifiés doivent alimenter l’amélioration du dispositif.

La GRC n’est donc pas un tableau Excel. C’est un système de décision, de maîtrise et de vérification.

PARTIE III

Gouverner La Cybersécurité

06Gouvernance, management et opérations

Ces trois niveaux sont souvent confondus.

La gouvernance détermine l’orientation, attribue les responsabilités, fixe certaines limites et surveille les résultats. Le management transforme ces orientations en politiques, programmes, ressources, procédures et plans d’action. Les opérations réalisent concrètement les activités.

Prenons un service critique. La Direction peut décider qu’une interruption supérieure à quatre heures est incompatible avec les besoins de l’organisation. Cette décision relève de la gouvernance. La DSI, le RSSI et les métiers peuvent ensuite définir une politique de continuité, un PRA, des objectifs de sauvegarde et un programme de tests. Cela relève du management. Les administrateurs configurent ensuite la réplication, réalisent les sauvegardes et exécutent les tests de restauration : ce sont les opérations.

La relation peut être résumée ainsi :

GOUVERNANCE → ORIENTER ET SURVEILLER

MANAGEMENT → ORGANISER ET PILOTER

OPÉRATIONS → EXÉCUTER

Ces niveaux doivent rester alignés. Une politique irréaliste, une exigence sans responsable ou une décision de Direction impossible à appliquer techniquement constituent autant de problèmes de gouvernance et de management.

07Appétence, tolérance et décision

La gouvernance doit également permettre de déterminer quel niveau de risque est acceptable.

L’appétence au risque représente le niveau de risque que l’organisation est disposée à accepter dans la poursuite de ses objectifs. Cette notion reste souvent générale. Une organisation peut déclarer qu’elle possède une faible appétence pour les interruptions de services critiques ou pour la divulgation d’informations sensibles.

La tolérance au risque traduit ensuite cette orientation en limites plus concrètes. Une organisation peut par exemple décider qu’une indisponibilité de plus de quatre heures d’un service critique n’est pas acceptable, ou qu’aucun compte administrateur exposé ne doit fonctionner sans MFA.

La gouvernance transforme ainsi une intention générale en décisions exploitables.

Ces notions seront approfondies dans le Cours 02, où nous examinerons précisément qui possède le risque, qui peut décider de son acceptation et à quel moment une situation doit être escaladée.

08Le Risk Owner : introduction

Le Risk Owner, ou propriétaire du risque, est la personne qui possède la responsabilité et l’autorité nécessaires pour gérer un risque déterminé.

Cette notion est importante parce que le RSSI n’est pas automatiquement propriétaire de tous les risques cyber. Le RSSI peut identifier un risque, l’analyser, proposer des mesures, conseiller la Direction et suivre son traitement. Mais si ce risque menace une activité financière, industrielle, commerciale ou administrative, l’autorité permettant d’accepter ses conséquences peut appartenir à un responsable métier ou à un niveau supérieur de management.

Le professionnel GRC facilite donc la décision. Il ne décide pas automatiquement à la place de l’organisation.

PARTIE IV

Comprendre Le Risque

09Un risque n’est pas une vulnérabilité

L’une des erreurs les plus fréquentes en cybersécurité consiste à confondre menace, vulnérabilité et risque.

Imaginons qu’une application RH soit hébergée sur un serveur non corrigé. Le logiciel contient une vulnérabilité permettant une exécution de code à distance.

La vulnérabilité est la faiblesse technique.

Une menace pourrait être un attaquant externe disposant des capacités nécessaires pour exploiter cette faiblesse.

Mais le risque n’apparaît réellement que lorsque nous remettons ces éléments dans leur contexte.

Le scénario pourrait être :

Un attaquant exploite la vulnérabilité du serveur RH, prend le contrôle du système et exfiltre les informations personnelles des collaborateurs, entraînant une violation de confidentialité, une interruption du service et des conséquences réglementaires et réputationnelles.

Nous avons maintenant un véritable scénario de risque.

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

SOURCE DE MENACE

↓

ACTION

↓

VULNÉRABILITÉ

↓

ACTIF AFFECTÉ

↓

ÉVÉNEMENT REDOUTÉ

↓

CONSÉQUENCES

La criticité technique contribue donc à l’analyse du risque. Elle ne la remplace pas.

10Menace, vulnérabilité, actif et scénario

Une vulnérabilité est une faiblesse susceptible d’être exploitée ou de contribuer à un événement indésirable. Elle peut être technique, comme un logiciel non corrigé ; organisationnelle, comme l’absence de processus de révocation des comptes ; ou humaine, comme une sensibilisation insuffisante au phishing.

Une menace est une source ou un événement capable d’exploiter une faiblesse ou de provoquer un dommage. Elle peut être intentionnelle, comme un groupe cybercriminel, accidentelle, comme une erreur humaine, technique, comme une panne, ou environnementale, comme un incendie.

Un actif représente quelque chose ayant de la valeur pour l’organisation.

Enfin, un scénario de risque relie ces différents éléments de manière suffisamment précise pour permettre d’en comprendre les conséquences.

Cette dernière notion est particulièrement importante : un registre contenant uniquement des lignes comme « ransomware », « phishing », « panne Internet » ou « CVE critique » décrit des sujets de sécurité, mais pas nécessairement des risques suffisamment construits pour être gouvernés.

11Impact et vraisemblance

Une fois le scénario construit, deux dimensions deviennent essentielles.

L’impact décrit les conséquences potentielles si le scénario se réalise. Ces conséquences peuvent être financières, opérationnelles, réglementaires, juridiques, réputationnelles, stratégiques ou humaines.

La vraisemblance cherche à apprécier dans quelle mesure le scénario peut réellement se produire dans le contexte étudié. Elle peut dépendre de l’exposition, des capacités de la menace, des contrôles existants, de l’attractivité de la cible, de l’historique d’incidents ou d’autres éléments disponibles.

Il faut cependant éviter la fausse précision. Une probabilité de « 72,4 % » n’est pas plus professionnelle qu’une appréciation qualitative correctement argumentée si aucune donnée robuste ne justifie ce chiffre.

Le Cours 03 approfondira précisément ces questions et montrera comment construire une analyse quantitative, qualitative et EBIOS Risk Manager.

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

Le risque inhérent représente le niveau de risque considéré avant prise en compte des contrôles pertinents, selon la convention retenue par l’organisation.

Des mesures sont ensuite mises en œuvre : MFA, segmentation, EDR, sauvegardes, procédures, journalisation, contrôles contractuels ou autres protections.

Le niveau de risque restant après prise en compte de ces mesures constitue le risque résiduel.

La logique est simple :

RISQUE INHÉRENT → CONTRÔLES → RISQUE RÉSIDUEL

Le risque ne disparaît généralement pas complètement.

La véritable question devient donc :

Le risque qui subsiste est-il compatible avec les critères de l’organisation ?

Et immédiatement après :

Qui possède l’autorité pour prendre cette décision ?

Nous retrouvons ici le lien direct entre analyse du risque et gouvernance.

13Traiter un risque

Lorsqu’un risque a été identifié et évalué, plusieurs stratégies sont possibles.

L’organisation peut éviter le risque en supprimant l’activité qui le génère, réduire le risque en mettant en place des mesures, partager ou transférer certaines conséquences lorsque cela est possible, ou accepter le risque lorsque son niveau résiduel est compatible avec les critères de l’organisation.

Une acceptation de risque ne signifie jamais simplement :

« Nous n’avons rien fait. »

Une acceptation mature suppose une décision informée, consciente, documentée et prise par l’autorité compétente.

Cette question sera approfondie dans le Cours 02.

PARTIE V

Comprendre La Conformité

14La conformité commence par les obligations applicables

La conformité répond d’abord à une question :

Quelles exigences devons-nous respecter ?

Ces exigences peuvent provenir de plusieurs sources : lois, règlements, contrats, exigences clients, normes adoptées volontairement, politiques internes ou obligations sectorielles.

L’ensemble de ces obligations constitue ce que certaines organisations appellent leur Compliance Universe.

Mais identifier une obligation n’est que le début.

Il faut ensuite la traduire en exigences opérationnelles.

Supposons qu’un texte impose une protection renforcée des comptes administrateurs. Cette phrase ne précise pas nécessairement quels mécanismes techniques utiliser. L’organisation devra traduire l’obligation en exigences concrètes et définir les mesures appropriées.

15De l’obligation au contrôle

La chaîne logique peut être représentée ainsi :

OBLIGATION

↓

EXIGENCE

↓

CONTRÔLE

↓

RESPONSABLE

↓

MISE EN ŒUVRE

↓

PREUVE

↓

TEST

↓

CONCLUSION

Prenons une exigence :

Les accès privilégiés doivent bénéficier d’une protection renforcée.

L’organisation peut décider d’exiger des comptes nominatifs, un MFA, une séparation des comptes administrateurs, un PAM ou une journalisation renforcée.

Ces mécanismes constituent des contrôles.

Mais leur simple existence dans une politique ne démontre pas qu’ils sont appliqués.

Il faudra rechercher des preuves et éventuellement tester leur fonctionnement.

La conformité ne consiste donc pas seulement à posséder des documents. Elle consiste à transformer les obligations en dispositifs démontrables.

16Conformité et sécurité ne sont pas synonymes

Une organisation peut respecter une exigence précise tout en restant exposée à d’autres risques importants. À l’inverse, une organisation peut disposer de protections techniques avancées tout en étant incapable de démontrer qu’elle respecte certaines obligations réglementaires ou contractuelles.

La conformité répond principalement à :

Respectons-nous les exigences applicables ?

La gestion du risque répond davantage à :

Les risques susceptibles d’affecter nos objectifs sont-ils suffisamment maîtrisés ?

Les deux approches sont complémentaires.

Une GRC mature cherche à éviter deux dérives : construire une cybersécurité uniquement pour satisfaire des audits, ou construire une sécurité techniquement performante mais incapable de démontrer sa conformité.

PARTIE VI

Contrôles, Preuves Et Assurance

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

Un contrôle est une mesure qui modifie un risque ou permet de satisfaire une exigence.

Prenons le scénario suivant :

Compromission d’un compte administrateur après vol du mot de passe.

L’authentification multifacteur peut réduire la probabilité qu’un attaquant exploite uniquement le mot de passe volé.

Le MFA devient donc un contrôle.

Mais lorsqu’on évalue un contrôle, trois questions doivent être distinguées.

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

Le mécanisme choisi permet-il réellement de répondre au risque ou à l’exigence ?

Le contrôle est-il effectivement mis en œuvre ?

Une politique prévoyant le MFA ne protège personne si le MFA n’est pas activé.

Le contrôle fonctionne-t-il efficacement dans la durée ?

Le MFA peut être déployé sur 95 % des comptes, mais absent précisément sur certains comptes administrateurs critiques.

Cette distinction entre conception, mise en œuvre et efficacité constitue une base importante de l’audit et de l’assurance.

18Les différentes fonctions des contrôles

Les contrôles peuvent être classés de plusieurs manières.

Un contrôle préventif cherche à empêcher l’événement. Un contrôle détectif cherche à identifier qu’un événement est en train de se produire ou s’est produit. Un contrôle correctif aide à remédier à une situation. Un contrôle de récupération vise à restaurer une capacité.

Une organisation peut également distinguer les contrôles organisationnels, techniques et physiques.

L’essentiel n’est pas de mémoriser les classifications. Il faut surtout comprendre qu’un scénario important est rarement maîtrisé par une seule mesure.

C’est le principe de défense en profondeur.

19Défense en profondeur

Prenons une attaque de phishing.

La passerelle de messagerie peut bloquer le message. S’il passe, l’utilisateur peut l’identifier grâce à la sensibilisation. S’il clique, l’EDR peut détecter l’activité malveillante. Si les identifiants sont compromis, le MFA peut empêcher leur utilisation directe. Si l’attaquant tente ensuite une activité inhabituelle, la journalisation et la supervision peuvent déclencher une alerte.

La sécurité repose donc sur plusieurs couches.

La question GRC n’est pas seulement :

Avons-nous un contrôle ?

mais :

L’ensemble des contrôles réduit-il suffisamment le scénario de risque ?

20La preuve : démontrer plutôt que déclarer

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

Supposons qu’un responsable affirme :

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

Cette déclaration ne suffit pas à un auditeur ou à un professionnel GRC.

Il faut pouvoir démontrer que le contrôle existe.

On pourra rechercher des rapports de sauvegarde, des journaux d’exécution, une configuration, des alertes d’échec ou des résultats de tests de restauration.

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

Le réflexe devient alors :

Comment pouvons-nous démontrer que ce contrôle existe et fonctionne réellement ?

21Contrôle et assurance

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

L’assurance cherche à fournir un niveau de confiance sur le fait que le dispositif fonctionne réellement.

Supposons que l’équipe informatique affirme que tous les comptes administrateurs sont protégés par MFA. Une revue indépendante constate que deux comptes d’urgence restent exclus sans justification.

Le contrôle existe.

Mais l’assurance obtenue révèle une faiblesse.

C’est pourquoi l’audit interne joue un rôle important dans les systèmes de gouvernance, de gestion des risques et de contrôle.

22Le modèle des trois lignes : introduction

Le modèle des trois lignes permet de comprendre comment les responsabilités peuvent être organisées.

La première ligne réalise les activités et gère directement les risques associés.

La deuxième ligne apporte des cadres, de l’expertise, du conseil, de la surveillance et du challenge. Selon l’organisation, certaines fonctions cybersécurité, Risk ou Compliance peuvent exercer ces responsabilités.

La troisième ligne, principalement représentée par l’audit interne, fournit une assurance indépendante et objective.

L’objectif n’est pas de créer trois silos. Il s’agit de distinguer :

qui gère le risque ;

qui apporte expertise et surveillance ;

qui vérifie indépendamment le dispositif.

Cette notion sera approfondie dans le Cours 02.

PARTIE VII

Faire Fonctionner La Grc Comme Un Système

23Politique, standard, procédure et guide

Une organisation utilise généralement plusieurs niveaux de documentation.

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

Un standard traduit cette politique en exigences obligatoires plus précises.

Une procédure décrit comment réaliser une activité.

Un guide apporte des recommandations pratiques.

Nous pouvons représenter la logique ainsi :

POLITIQUE

↓

STANDARD

↓

PROCÉDURE

↓

CONTRÔLES

↓

PREUVES

↓

MESURES

↓

REPORTING

Une documentation bien conçue ne constitue donc pas une fin en soi. Elle doit conduire à des pratiques réelles, produire des preuves et permettre un suivi.

24Le cycle GRC

La GRC fonctionne comme un cycle continu.

L’organisation commence par comprendre son contexte, sa mission, ses objectifs, ses activités, ses actifs, ses parties prenantes et ses obligations. Elle identifie ensuite les risques, définit des priorités, met en œuvre des contrôles, surveille leur fonctionnement, rapporte les résultats et améliore son dispositif.

Nous pouvons retenir :

COMPRENDRE → IDENTIFIER → ÉVALUER → DÉCIDER → TRAITER → VÉRIFIER → RAPPORTER → AMÉLIORER

Puis le cycle recommence.

L’environnement évolue constamment : nouvelles technologies, nouveaux fournisseurs, nouvelles vulnérabilités, nouveaux projets, nouveaux usages, nouveaux incidents, évolution réglementaire.

Une analyse ou un contrôle valable aujourd’hui peut devenir insuffisant demain.

PARTIE VIII

Raisonner Comme Un Professionnel Grc

25Ne pas s’arrêter au constat technique

Prenons cette phrase :

« Notre serveur n’a pas été corrigé depuis six mois. »

La réaction technique immédiate peut être :

« Il faut le patcher. »

Cela peut être parfaitement juste.

Mais le professionnel GRC cherche d’abord à comprendre :

Quel service fonctionne sur ce serveur ? Quelle activité en dépend ? Le système est-il exposé ? Quelles informations contient-il ? Quelles vulnérabilités sont réellement présentes ? Quels contrôles compensatoires existent ? Pourquoi les correctifs n’ont-ils pas été appliqués ? Quel serait l’impact d’une interruption ? Quelle personne possède le risque pendant la période d’exposition ?

Le GRC n’empêche pas l’action technique.

Il ajoute contexte, risque, responsabilité et décision.

26Traduire la cybersécurité en langage de décision

Prenons une formulation purement technique :

CVSS 9.8 — Remote Code Execution.

Elle est parfaitement utile pour une équipe technique.

Mais devant une Direction, une traduction plus utile pourrait être :

Une vulnérabilité présente sur le serveur de l’application financière pourrait permettre à un attaquant distant d’en prendre le contrôle. Une exploitation pourrait interrompre le processus de facturation et exposer certaines informations sensibles. La correction nécessite une interruption planifiée et une décision doit être prise avant la fin de la semaine.

Nous sommes passés du langage technique à un langage intégrant :

CONTEXTE + CONSÉQUENCE + EXPOSITION + OPTION + DÉCISION

Cette capacité de traduction constitue l’une des compétences essentielles du professionnel GRC.

PARTIE IX

Cas Intégré : Microsoft 365

27Regarder Microsoft 365 avec une logique GRC

Imaginons une organisation dont la messagerie, les calendriers et une partie importante de la collaboration reposent sur Microsoft 365.

Une approche purement technique pourrait commencer par la configuration de la plateforme.

Une approche GRC commence plus haut.

La première question consiste à comprendre pourquoi ce service est important.

Si Microsoft 365 devient indisponible pendant une heure, l’organisation peut encore fonctionner. Si la messagerie est indisponible pendant plusieurs jours, certaines activités peuvent être fortement perturbées. Si un compte administrateur est compromis, les conséquences peuvent devenir beaucoup plus importantes.

Nous identifions donc plusieurs scénarios possibles : compromission d’un compte utilisateur après phishing, compromission d’un compte administrateur, suppression de données, indisponibilité du fournisseur, mauvaise configuration, accès excessif d’un prestataire ou absence de capacité de restauration.

Les contrôles peuvent inclure le MFA, la gestion des privilèges, les politiques d’accès, la journalisation, les sauvegardes ou mécanismes de rétention, la surveillance et des procédures de continuité.

Mais la GRC ne s’arrête pas à leur existence.

Il faut également demander : tous les administrateurs sont-ils réellement protégés par MFA ? Existe-t-il des exceptions ? Les comptes privilégiés sont-ils revus ? Les restaurations ont-elles été testées ? Les accès prestataires sont-ils encadrés ? Les événements de sécurité sont-ils surveillés ? Existe-t-il une procédure claire d’escalade en cas d’incident majeur ?

Nous pouvons alors transformer la question :

Microsoft 365 fonctionne-t-il ?

en :

Les risques associés à notre dépendance à Microsoft 365 sont-ils compris, suffisamment maîtrisés et correctement gouvernés ?

Voilà la différence entre une vision simplement technique et une vision GRC.

PARTIE X

Le Modèle Mental Du Cours

28Les huit questions fondamentales

Lorsque vous examinez désormais un problème de cybersécurité, entraînez-vous à reconstruire les huit questions suivantes :

• Quel objectif, service ou processus cherchons-nous à protéger ?
• Qu’est-ce qui pourrait empêcher cet objectif d’être atteint ?
• Quelles seraient les conséquences pour l’organisation ?
• Quels contrôles existent déjà ?
• Ces contrôles sont-ils réellement mis en œuvre et efficaces ?
• Quel risque subsiste ?
• Ce risque est-il compatible avec les critères de l’organisation ?
• Qui possède l’autorité pour prendre la décision ?

Ces questions constituent une première grille de lecture GRC.

Les prochains cours approfondiront progressivement chacune d’elles.

PARTIE XI

Exercice Pratique 01

29Analyser un service avec une logique GRC

Choisissez un service réel ou fictif : messagerie, Active Directory, application financière, portail web, plateforme cloud, système RH, infrastructure réseau ou autre service métier.

Commencez par expliquer en quelques paragraphes pourquoi ce service existe, qui l’utilise et quelle activité il supporte. Décrivez ensuite les conséquences possibles d’une indisponibilité d’une heure, d’une journée ou de plusieurs jours, ainsi que les principales informations traitées et les dépendances importantes.

Construisez ensuite trois à cinq scénarios de risque.

Évitez les formulations trop générales comme :

Malware.

Préférez une formulation complète :

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 et interrompre l’activité.

Pour chaque scénario, identifiez les contrôles existants et demandez-vous comment vous pourriez démontrer qu’ils fonctionnent réellement.

L’objectif n’est pas encore de réaliser une analyse complète comme celle que nous construirons dans le Cours 03. Il s’agit d’apprendre à replacer la technologie dans son contexte métier.

PARTIE XII

Livrable Portfolio 01

Fiche d’analyse GRC d’un service

Ce livrable permet d’appliquer immédiatement le modèle du cours à un service réel ou fictif. Il doit permettre à un lecteur de comprendre rapidement ce que fait le service, pourquoi il est important, quels risques principaux peuvent l’affecter, quels contrôles existent et quelles décisions restent éventuellement nécessaires.

A. Informations générales

B. Analyse des risques principaux

C. Conclusion de management

Terminez votre fiche par une synthèse courte répondant à trois questions :

Quel est le principal risque identifié ?

Le niveau de protection actuel paraît-il suffisant au regard du contexte ?

Quelle décision ou action devrait être priorisée ?

Cette synthèse est importante. Elle oblige à passer de l’inventaire des problèmes à une véritable conclusion GRC.

PARTIE XIV

Les Concepts À Savoir Expliquer Sans Notes

Avant de passer au Cours 02, vous devez pouvoir expliquer naturellement les notions suivantes :

GRC, gouvernance, management, opérations, actif, menace, vulnérabilité, scénario de risque, impact, vraisemblance, risque inhérent, risque résiduel, appétence au risque, tolérance au risque, Risk Owner, conformité, exigence, contrôle, preuve, assurance, défense en profondeur et modèle des trois lignes.

Mais la maîtrise du vocabulaire ne suffit pas.

Si quelqu’un vous présente une vulnérabilité critique, votre premier réflexe ne doit plus être uniquement :

« Quel patch devons-nous installer ? »

Vous devez également demander :

Quel service est concerné, quelles conséquences ce scénario pourrait-il avoir et qui doit prendre la décision ?

PARTIE XV

Références pour approfondir

Plusieurs référentiels accompagneront progressivement l’Académie.

ISO 31000 permettra d’aborder le management du risque à l’échelle de l’organisation.

ISO/IEC 27001 permettra de comprendre comment construire et piloter un système de management de la sécurité de l’information.

ISO/IEC 27005 approfondira l’appréciation et le traitement des risques liés à la sécurité de l’information.

NIST Cybersecurity Framework 2.0 apportera notamment une vision structurée de la gouvernance cyber et de la gestion du risque.

EBIOS Risk Manager permettra de construire des scénarios de risque numériques structurés.

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

Enfin, le Three Lines Model de l’Institute of Internal Auditors permettra d’approfondir la répartition des responsabilités entre management, fonctions apportant expertise et surveillance, et audit interne.

Le principe de l’Académie restera toujours le même :

RÉFÉRENTIEL ≠ OBJECTIF. RÉFÉRENTIEL = OUTIL.

Nous apprenons d’abord à raisonner. Les référentiels servent ensuite à structurer ce raisonnement.