Gouverner la cybersécurité : responsabilités, décisions et alignement métier.

INTRODUCTIONQuand tout le monde est responsable, personne ne l’est vraiment

Imaginons une organisation disposant d’une application essentielle à son activité. Une vulnérabilité critique est découverte sur le serveur qui héberge cette application. L’équipe cybersécurité recommande une correction rapide. L’équipe technique répond :

« Nous pouvons installer le correctif, mais l’application devra être interrompue pendant plusieurs heures. »

Le responsable métier refuse :

« Impossible cette semaine. Nous avons une activité importante. Reportons l’intervention au mois prochain. »

Quelques jours plus tard, l’application est compromise. La Direction générale demande alors :

« Qui avait décidé de laisser ce risque ouvert ? »

Le RSSI répond :

« Nous avions recommandé de corriger. »

La DSI répond :

« Le métier ne voulait pas interrompre le service. »

Le métier répond :

« Nous ne savions pas que le risque était aussi important. »

Et soudain, une question beaucoup plus difficile apparaît :

Qui était réellement responsable de la décision ?

Voilà un problème de gouvernance. L’organisation pouvait posséder un pare-feu performant, un EDR, un SIEM, des sauvegardes et des ingénieurs compétents. Pourtant, elle pouvait rester incapable de répondre à une question élémentaire :

Qui avait l’autorité pour accepter le risque ?

La cybersécurité ne devient réellement gouvernée que lorsque les responsabilités, les pouvoirs de décision, les mécanismes d’escalade et les obligations de rendre compte sont clairement établis. Le premier cours nous a appris à passer :

TECHNOLOGIE → RISQUE → MÉTIER → DÉCISION

Dans ce deuxième cours, nous allons nous concentrer sur le dernier élément :

LA DÉCISION.

• Qui décide ?
• Sur quelle base ?
• Avec quelle autorité ?
• À partir de quelles informations ?
• Qui exécute ensuite la décision ?
• Qui vérifie qu’elle a été appliquée ?
• Et qui doit rendre compte si le niveau de risque devient incompatible avec les objectifs de l’organisation ?
• C’est le cœur de la gouvernance cyber.

01Les objectifs du cours

À la fin de ce cours, vous devez être capable de comprendre comment la cybersécurité s’insère dans le système de gouvernance d’une organisation. Vous devrez notamment savoir distinguer les responsabilités de la Direction, des métiers, de la DSI, du RSSI, des propriétaires de risques, des propriétaires d’actifs et de l’audit. Vous devrez également comprendre les différences entre :

responsabilité d’exécution, obligation de rendre compte et autorité de décision.

Vous apprendrez à utiliser un RACI sans le réduire à un simple tableau administratif. Vous comprendrez pourquoi un professionnel de la cybersécurité peut recommander une mesure sans nécessairement disposer de l’autorité pour imposer une décision métier. Nous approfondirons également plusieurs principes essentiels :

• Risk Ownership ;
• séparation des responsabilités ;
• moindre privilège ;
• due care ;
• due diligence ;
• escalade ;
• reporting ;
• KPI, KRI et KCI ;
• indépendance de l’assurance.

Mais, comme dans le premier cours, l’objectif n’est pas de mémoriser du vocabulaire. L’objectif est d’apprendre à regarder une organisation et à vous demander :

Qui doit décider de quoi, et comment cette décision doit-elle être gouvernée ?

02De la sécurité technique à la gouvernance

Prenons une organisation qui souhaite protéger ses comptes administrateurs. L’équipe technique pourrait proposer :

• MFA ;
• comptes administrateurs séparés ;
• bastion d’administration ;
• PAM ;
• journalisation ;
• restrictions réseau.

Toutes ces mesures peuvent être pertinentes. Mais plusieurs questions apparaissent immédiatement. Qui décide que le MFA est obligatoire ? Qui définit les comptes concernés ? Qui finance éventuellement la solution ? Qui autorise une exception ? Qui vérifie que les administrateurs respectent la règle ? Qui reçoit l’information si 20 % des comptes privilégiés ne sont toujours pas protégés ? À partir de quel seuil la Direction doit-elle être alertée ? Voilà pourquoi une technologie de sécurité n’existe jamais totalement seule.

Derrière un contrôle se trouvent presque toujours :

une exigence, une responsabilité, une autorité et une décision.

Nous pouvons représenter la logique ainsi :

Le contrôle technique n’est donc qu’un maillon du système.

03Gouverner, ce n’est pas administrer

Le Cours 01 a distingué gouvernance, management et opérations. Retenons ici leur articulation concrète : la gouvernance fixe les résultats attendus et les limites de décision ; le management organise les moyens ; les opérations exécutent et remontent les informations utiles.

Une Direction peut, par exemple, décider qu’une plateforme de paiement ne doit pas rester indisponible plus de deux heures. Cette orientation ne prescrit aucune technologie, mais elle oblige le management à organiser la redondance, les sauvegardes, la reprise d’activité, les tests et, si nécessaire, les engagements fournisseurs.

La gouvernance ne configure pas les contrôles : elle définit ce qu’ils doivent permettre d’obtenir, qui en répond et quand une décision doit être escaladée.

04La gouvernance commence par la mission

Nous avons déjà établi que la cybersécurité protège la mission de l’organisation. Dans la gouvernance, cette idée devient un critère d’arbitrage : avant d’approuver une politique, un investissement ou une acceptation de risque, il faut savoir quels objectifs, services et parties prenantes sont concernés.

• Une banque privilégiera notamment l’intégrité des transactions, la disponibilité des services et la confiance.
• Un hôpital placera la continuité des soins et la fiabilité des informations cliniques au premier plan.
• Une administration cherchera à maintenir les services essentiels rendus aux citoyens et à respecter ses obligations.

Les priorités cyber ne se déduisent donc pas d’un catalogue de technologies. Elles découlent du contexte, de la criticité des activités et des conséquences acceptables ou non pour l’organisation.

La première question n’est pas « Quel outil devons-nous acheter ? », mais « Que devons-nous absolument continuer à accomplir ? »

05De la mission aux exigences de sécurité

La gouvernance transforme une priorité métier en exigences vérifiables. La chaîne utile n’est pas une succession documentaire : elle relie une décision stratégique à des contrôles, des indicateurs et un responsable identifiable.

Si une démarche administrative en ligne ne peut rester indisponible plus de quatre heures, cette tolérance doit se traduire en exigences d’architecture, de continuité, de supervision et de reprise. Le reporting doit ensuite montrer si ces exigences sont respectées et signaler tout dépassement nécessitant un arbitrage. Le Cours 02 s’intéresse précisément à la dernière partie de cette chaîne : qui fixe la tolérance, qui met en œuvre les mesures, qui surveille les écarts et qui décide lorsque le risque dépasse le niveau autorisé ?

06Le double mouvement de la gouvernance

La gouvernance ne fonctionne pas uniquement du haut vers le bas. Elle fonctionne dans les deux sens. Du haut vers le bas circulent notamment :

orientations → priorités → politiques → autorités → ressources → exigences.

Du bas vers le haut remontent :

mesures → incidents → vulnérabilités → risques → indicateurs → exceptions → besoins d’arbitrage.

Imaginons que la Direction décide :

« Tous les comptes privilégiés doivent être fortement protégés. »

L’organisation transforme cette orientation en exigences. Le MFA est déployé. Quelques semaines plus tard, le reporting indique :

93 % des comptes privilégiés sont protégés.

Il reste 7 % d’exceptions. La gouvernance doit maintenant fonctionner dans l’autre sens.

• Pourquoi ces exceptions existent-elles ?
• Quel risque représentent-elles ?
• Qui les a autorisées ?
• Jusqu’à quand ?
• Faut-il accepter la situation ?
• Faut-il imposer une correction ?
• Le système fonctionne donc comme une boucle.
• Décider → mettre en œuvre → mesurer → rapporter → réévaluer → décider.

07Gouverner signifie aussi surveiller

Prendre une décision une fois ne suffit pas. Supposons qu’un risque ait été accepté pendant six mois. Six mois plus tard, le contexte peut avoir changé. Une nouvelle vulnérabilité peut avoir été découverte. Le système peut être devenu plus critique. Le nombre d’utilisateurs peut avoir augmenté. Une nouvelle réglementation peut être entrée en vigueur. Un incident similaire peut avoir touché une organisation du même secteur. L’ancienne décision n’est donc pas automatiquement toujours valable.

La gouvernance doit permettre de réexaminer les décisions lorsque le contexte évolue. C’est pour cette raison que nous pouvons retenir quatre verbes particulièrement utiles :

ÉVALUER → ORIENTER → SURVEILLER → COMMUNIQUER

Évaluer la situation et les besoins. Orienter l’organisation. Surveiller les résultats et les risques. Communiquer les informations nécessaires aux bonnes personnes. La gouvernance est donc dynamique.

08Qui gouverne réellement la cybersécurité ?

La réponse dépend de la structure de l’organisation. Une grande entreprise internationale, une PME, une administration publique et une banque ne possèdent pas nécessairement les mêmes organes. Mais un principe demeure :

La cybersécurité ne peut pas être gouvernée uniquement par l’équipe cybersécurité.

Pourquoi ? Parce que les décisions cyber peuvent affecter : les finances, les opérations, les ressources humaines, la réputation, les obligations juridiques, les clients, les citoyens, les fournisseurs et parfois la sécurité physique. La gouvernance cyber appartient donc au système global de gouvernance de l’organisation. Cela signifie que plusieurs acteurs interviennent.

09Le rôle de l’organe de gouvernance et de la Direction

Selon l’organisation, l’organe de gouvernance peut être un conseil d’administration, un comité, une autorité dirigeante ou une autre structure équivalente. La Direction générale joue également un rôle essentiel. Elle ne doit pas nécessairement connaître les commandes permettant de configurer un pare-feu. En revanche, elle doit pouvoir comprendre suffisamment les enjeux pour exercer ses responsabilités. Elle doit notamment pouvoir répondre à des questions telles que :

• Quels sont nos principaux risques cyber ?
• Quels services sont critiques ?
• Quel niveau de risque sommes-nous disposés à accepter ?
• Avons-nous suffisamment de ressources ?
• Quels risques dépassent actuellement nos tolérances ?
• Quels incidents pourraient affecter notre mission ?
• Nos obligations majeures sont-elles respectées ?
• Les décisions critiques nécessitent-elles notre arbitrage ?
• Une gouvernance mature ne demande donc pas à la Direction de devenir ingénieur sécurité.
• Elle lui demande de prendre les décisions qui relèvent de son niveau d’autorité.

10Le rôle du management

La gouvernance définit les orientations. Le management les transforme en actions organisées. Supposons que la Direction décide :

« Les données sensibles doivent bénéficier d’un niveau de protection renforcé. »

Le management devra transformer cette orientation en dispositif. Il faudra peut-être : identifier les données sensibles ; définir une classification ; attribuer des propriétaires ; définir des règles d’accès ; mettre en place des contrôles ; organiser les revues ; définir des indicateurs ; traiter les écarts. Le management transforme donc :

une orientation en programme de travail.

11Le rôle des métiers

Le métier est parfois oublié dans les programmes cyber. C’est une erreur importante. Le métier sait généralement mieux que l’équipe technique : pourquoi un processus existe ; quelles conséquences provoquerait son interruption ; quelles informations sont essentielles ; quelles périodes sont critiques ; quelles dépendances sont indispensables ; quelles dégradations sont acceptables ou non. Prenons une application de facturation. L’équipe technique connaît son architecture.

Mais la Direction financière peut mieux expliquer ce que provoquerait une indisponibilité de cinq jours en fin de mois. Cette connaissance est indispensable pour évaluer le risque. Le métier n’est donc pas seulement un « utilisateur » du système d’information. Il est un acteur de la gestion du risque.

12Le rôle de la DSI

La DSI occupe une position centrale. Elle conçoit, exploite ou supervise une grande partie des systèmes qui supportent les activités. Elle met également en œuvre de nombreux contrôles : gestion des identités ; sauvegardes ; réseaux ; correctifs ; durcissement ; administration ; supervision ; continuité technique ; gestion des changements. Mais la DSI ne devrait pas être obligée de déterminer seule ce qui est acceptable pour le métier. Prenons une question :

Peut-on interrompre l’application financière pendant huit heures pour réaliser une maintenance de sécurité ?

La DSI peut expliquer les contraintes techniques. Le RSSI peut expliquer le risque. Mais le responsable métier doit également intervenir parce que les conséquences affectent son activité.

13Le rôle du RSSI ou de la fonction cybersécurité

Le RSSI joue généralement un rôle de pilotage, de conseil, de coordination, de surveillance et parfois d’escalade. Il peut notamment : définir ou proposer la stratégie cyber ; identifier les risques ; proposer des politiques ; recommander des contrôles ; suivre les vulnérabilités ; organiser la sensibilisation ; surveiller certains indicateurs ; conseiller les responsables métiers ; préparer les arbitrages ; rapporter les risques significatifs ; coordonner la réponse à certains incidents. Mais il existe une distinction capitale.

Conseiller une décision n’est pas nécessairement posséder l’autorité pour la prendre.

Le RSSI peut dire :

« À mon avis, ce risque est trop important pour rester ouvert. »

Mais si le risque concerne une activité stratégique, son acceptation peut relever d’un responsable métier, de la Direction ou d’une autre autorité définie par la gouvernance. Le RSSI doit cependant s’assurer que le risque est correctement présenté.

15Pourquoi l’autorité doit accompagner la responsabilité

Imaginons qu’un RSSI soit officiellement responsable du programme de cybersécurité. Mais il ne peut : ni imposer une exigence minimale ; ni accéder aux informations nécessaires ; ni demander la correction d’une vulnérabilité ; ni escalader un risque ; ni présenter un sujet à la Direction. Sur le papier, il possède une responsabilité. Dans la pratique, son autorité est insuffisante. Cela crée une gouvernance fragile. Le principe peut être formulé simplement :

Une responsabilité doit être accompagnée d’une autorité et de ressources cohérentes avec le résultat attendu.

Cela ne signifie pas donner un pouvoir illimité. Au contraire. Les limites de l’autorité doivent également être définies.

16Le Risk Owner

Nous avons introduit cette notion dans le Cours 01. Approfondissons-la. Le Risk Owner, ou propriétaire du risque, est la personne ou l’entité disposant de la responsabilité et de l’autorité appropriées pour gérer un risque donné. Il doit pouvoir comprendre : le scénario ; les conséquences ; les contrôles existants ; les options de traitement ; le risque résiduel ; les conséquences de l’acceptation. Prenons une plateforme RH. Un risque concerne l’exposition de données personnelles des employés. Plusieurs acteurs interviennent. La DSI exploite le système.

La cybersécurité évalue certaines menaces. Les RH connaissent l’usage et la sensibilité des données. La Direction peut devoir arbitrer certains investissements. Le Risk Owner doit être défini selon la gouvernance de l’organisation. Il ne doit pas être choisi uniquement parce que « le problème est informatique ».

17Le Risk Owner n’est pas nécessairement le RSSI

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

Un risque cyber produit souvent une conséquence métier. Dans une usine, le RSSI peut recommander l’arrêt d’un système industriel vulnérable sans disposer de l’autorité pour interrompre la production ; le responsable de production doit alors contribuer à l’arbitrage. De même, lorsqu’une application financière est concernée, le responsable financier apporte la compréhension des conséquences et peut porter la décision dans le périmètre défini par la gouvernance.

La fonction cybersécurité rend le risque intelligible et formule une recommandation. Le Risk Owner répond de la décision et de son suivi. Confondre ces rôles concentre artificiellement la responsabilité sur le RSSI et affaiblit l’appropriation métier du risque.

18Asset Owner, Data Owner, System Owner et Custodian

Plusieurs rôles peuvent coexister autour d’un même actif. Ils ne doivent pas être confondus.

Asset Owner

Le propriétaire d’un actif est responsable de la manière dont cet actif doit être protégé et utilisé selon le cadre de l’organisation.

Data Owner

Le Data Owner possède une responsabilité métier sur un ensemble de données. Il peut notamment contribuer à déterminer : leur classification ; les personnes qui doivent y accéder ; les règles de conservation ; les exigences de protection.

System Owner

Le System Owner est responsable d’un système ou service déterminé. Selon l’organisation, il peut être métier ou technique.

Custodian

Le Custodian, ou dépositaire, assure davantage la garde ou l’administration opérationnelle de l’actif. Prenons une base de données RH. La Direction RH peut être propriétaire métier des données. La DSI peut en assurer l’hébergement et l’administration. L’administrateur de base de données peut être Custodian. Ces rôles n’ont pas nécessairement la même autorité.

19Pourquoi cette distinction est importante

Imaginons qu’un administrateur système reçoive la demande suivante :

« Donnez à cet utilisateur l’accès à toutes les données salariales. »

L’administrateur possède techniquement la capacité de créer l’accès. Mais possède-t-il l’autorité métier pour décider qui peut consulter les salaires ? Non, pas nécessairement. Nous découvrons ici une distinction essentielle :

Capacité technique ≠ autorité organisationnelle.

Un administrateur peut techniquement supprimer une base de données. Cela ne signifie pas qu’il est autorisé à décider de sa suppression. Cette distinction protège l’organisation contre les erreurs, les abus et les décisions prises au mauvais niveau.

20Séparation des responsabilités et conflits d’intérêts

Une bonne gouvernance évite autant que possible qu’une même personne contrôle tout un processus sensible. Imaginons qu’une personne puisse : créer un fournisseur ; valider ce fournisseur ; saisir une facture ; autoriser le paiement ; modifier les journaux. Le risque de fraude devient évident. En cybersécurité, le même principe existe. Il peut être dangereux qu’une personne puisse : créer son propre compte privilégié ; lui attribuer des droits ; utiliser le compte ; effacer les traces ; et approuver elle-même la revue de ses accès.

C’est pourquoi la gouvernance cherche à répartir certaines responsabilités.

21Separation of Duties

Ce principe est souvent appelé Separation of Duties, ou séparation des tâches. L’objectif est de réduire le risque qu’une seule personne puisse réaliser seule une action sensible de bout en bout. Exemple : Demande d’accès → manager Validation métier → Data Owner Création technique → administrateur Revue périodique → responsable indépendant du demandeur La séparation des tâches peut prévenir : les erreurs ; les abus ; les fraudes ; les conflits d’intérêts ; les modifications non autorisées. Mais elle doit rester proportionnée.

Une organisation de dix personnes ne pourra pas appliquer exactement la même séparation qu’une banque internationale. Lorsque la séparation parfaite n’est pas possible, des contrôles compensatoires peuvent être nécessaires.

22Least Privilege appliqué à la gouvernance

Le principe du Least Privilege, ou moindre privilège, est souvent présenté comme un principe technique. Un utilisateur ne doit disposer que des privilèges nécessaires à ses fonctions. Mais le raisonnement peut également être appliqué à l’autorité organisationnelle. Une personne ne devrait pas posséder un pouvoir de décision beaucoup plus large que ce dont son rôle a besoin. Par exemple, un responsable d’application peut être autorisé à accepter certains risques faibles.

Mais un risque susceptible d’interrompre un service national critique peut nécessiter une autorité supérieure. Nous obtenons donc une logique :

niveau du risque ↑ → niveau d’autorité requis ↑

C’est une manière simple de construire une matrice d’autorité.

23Le RACI : utile, mais seulement s’il clarifie réellement les décisions

Le RACI distingue quatre contributions complémentaires. Pour une activité donnée, le rôle A — Accountable doit être attribué sans ambiguïté et, en principe, rester unique.

L’exemple suivant applique cette logique à la gestion d’une vulnérabilité critique. Il est volontairement simplifié : la répartition réelle dépend de la structure, des délégations et des seuils d’autorité de l’organisation.

La matrice doit permettre de répondre immédiatement à quatre questions : qui exécute, qui répond du résultat, qui contribue avant la décision et qui doit ensuite être informé ?

24Le piège du RACI

Un RACI peut donner une illusion de gouvernance lorsqu’il devient un tableau de centaines de lignes que personne ne consulte. Sa valeur ne réside pas dans le nombre de cases remplies, mais dans les ambiguïtés qu’il élimine sur les activités et décisions réellement sensibles.

• Qui agit ?
• Qui décide et répond du résultat ?
• Qui doit être consulté avant la décision ?
• Qui doit être informé après la décision ?

Un bon RACI simplifie les décisions. Un mauvais RACI ajoute de la bureaucratie.

25De l’appétence au risque aux décisions opérationnelles

Le Cours 01 a défini l’appétence au risque comme la nature et le niveau de risque que l’organisation est disposée à poursuivre ou à conserver pour atteindre ses objectifs. Dans ce cours, l’enjeu est de la rendre exploitable : une déclaration générale doit être traduite en tolérances, limites et seuils permettant de décider.

• Aucun compte administrateur exposé à Internet ne fonctionne sans MFA.
• Toute vulnérabilité critique exploitable sur un système critique exposé à Internet est corrigée dans le délai autorisé.
• Toute interruption prévisible supérieure à quatre heures d’un service critique est escaladée à la Direction.

Ces formulations ne constituent pas des seuils universels. Elles montrent comment une orientation de gouvernance devient une règle mesurable, attribuée à un responsable et reliée à un niveau d’autorité.

26Tolérance, seuils et escalade

Supposons qu’une organisation utilise une échelle de risque de 1 à 5. Elle peut définir : Risques 1–2 : traitement au niveau opérationnel. Risque 3 : validation par le responsable métier. Risque 4 : escalade au comité de risques. Risque 5 : décision de la Direction générale. Ce n’est qu’un exemple. L’important est le principe.

Tous les risques ne nécessitent pas le même niveau de décision.

Sinon, deux problèmes apparaissent. Si tout remonte à la Direction, elle devient un goulot d’étranglement. Si rien ne remonte, des risques majeurs peuvent être acceptés par des personnes ne disposant pas de l’autorité nécessaire. La gouvernance doit donc définir des seuils d’escalade.

27L’acceptation d’un risque est une décision de gouvernance

ACCEPTER UN RISQUE ≠ NE PAS AVOIR EU LE TEMPS DE LE TRAITER

Accepter un risque ne signifie pas :

« Nous n’avons pas eu le temps de le traiter. »

Ce n’est pas non plus :

« Le budget n’a pas été accordé, donc le risque est automatiquement accepté. »

Une acceptation correcte doit idéalement préciser :

• le risque concerné
• son niveau
• les conséquences potentielles
• les contrôles existants
• la justification de l’acceptation
• le décideur habilité qui accepte
• la durée de l’acceptation
• les éventuelles conditions
• la date de révision.
• Pourquoi une date ?
• Parce qu’une acceptation ne devrait pas nécessairement devenir permanente.

28Les exceptions de sécurité

Une organisation peut avoir une règle :

« Tous les comptes administrateurs doivent utiliser MFA. »

Mais un ancien système peut être techniquement incompatible.

• Que faire ?
• Ignorer silencieusement l’exigence serait une mauvaise pratique.
• Une approche plus mature consiste à gérer une exception.
• L’exception doit répondre à plusieurs questions :
• Pourquoi la règle ne peut-elle pas être appliquée ?
• Quel risque supplémentaire apparaît ?
• Existe-t-il des contrôles compensatoires ?
• Qui autorise l’exception ?
• Pendant combien de temps ?
• Quand la situation sera-t-elle réexaminée ?
• Une exception bien gouvernée n’est donc pas une permission permanente de contourner la sécurité.
• C’est une décision temporaire, documentée et surveillée.

31Due Care et Due Diligence ensemble

Prenons un exemple complet. Une organisation identifie un risque de ransomware. Elle décide de mettre en place des sauvegardes. C’est une mesure de prudence. Mais elle ne teste jamais les restaurations. Après une attaque, elle découvre que les sauvegardes sont inutilisables. Le contrôle existait. Mais la surveillance du contrôle était insuffisante. Une démarche plus mature aurait inclus : sauvegardes régulières ; surveillance des échecs ; protection des sauvegardes ; tests de restauration ; revues périodiques ; correction des anomalies.

Nous retrouvons alors notre logique :

DÉCIDER → PROTÉGER → VÉRIFIER → CORRIGER.

32Politique de sécurité et autorité

Une politique n’est pas simplement un document bien présenté. Elle exprime une orientation de l’organisation. Pour être réellement utile, elle doit être soutenue par une autorité appropriée. Supposons qu’une politique indique :

« Les accès privilégiés doivent être revus trimestriellement. »

Mais personne ne sait :

• qui réalise la revue
• qui fournit la liste
• qui valide
• que faire des écarts
• qui suit les corrections.
• La politique existe.
• La gouvernance reste faible.
• Une bonne politique doit donc s’intégrer à un système de responsabilités.

33La gouvernance par les politiques

Une architecture documentaire cohérente relie l’autorité qui fixe la règle à la preuve qui permet d’en surveiller l’application.

Politique

Les accès aux informations sensibles sont limités aux personnes autorisées.

Standard

Tous les comptes privilégiés sont protégés par MFA.

Procédure

Décrit la création et l’activation d’un compte administrateur.

Contrôle

Rend la configuration MFA obligatoire.

Preuve

Identifie les comptes effectivement protégés.

Mesure

Établit, par exemple, un taux de couverture de 98 %.

Décision

Traiter les 2 % restants ou autoriser formellement des exceptions temporaires.

Le document devient vivant lorsque les écarts mesurés déclenchent une décision, un suivi et, si nécessaire, une révision de la règle.

34Le comité de cybersécurité ou comité de risques

Toutes les décisions ne doivent pas être prises par une seule personne. Un comité peut être utile pour les sujets nécessitant plusieurs perspectives. Il peut réunir, selon l’organisation : Direction ; DSI ; cybersécurité ; métiers ; juridique ; risques ; conformité ; continuité ; protection des données ; audit en qualité appropriée. Mais un comité ne doit pas devenir un endroit où les décisions disparaissent. Un bon comité doit avoir : un mandat ; un périmètre ; des responsabilités ; une fréquence ; des informations pertinentes ; des décisions tracées ;

des responsables d’actions ; des délais ; un mécanisme d’escalade. Le but n’est pas de tenir des réunions. Le but est de prendre et suivre des décisions.

35Escalade et droit à la décision

Le professionnel cyber doit savoir quand un problème dépasse son niveau d’autorité. Imaginons qu’un administrateur découvre une vulnérabilité critique. Il la signale à son responsable. Le responsable décide de reporter le correctif. Le RSSI estime que le risque devient inacceptable. Que faire ? La gouvernance doit prévoir un chemin d’escalade. Par exemple :

Le chemin exact dépend de l’organisation. Mais il doit exister. Sinon, un risque majeur peut rester bloqué au niveau opérationnel.

37Un bon tableau de bord ne raconte pas toute la technique

Imaginez un tableau de bord présenté à la Direction :

• 12 418 événements SIEM ;
• 3 428 scans ;
• 928 IOC ;
• 147 CVE ;
• 84 alertes EDR ;
• 52 Go de logs.

Ces chiffres peuvent être utiles à une équipe opérationnelle. Mais la Direction peut demander :

« Très bien. Sommes-nous davantage en danger qu’il y a trois mois ? »

Et le tableau ne répond pas nécessairement. Un reporting de gouvernance doit aider à comprendre : quels risques augmentent ; quels services sont concernés ; quels seuils sont dépassés ; quelles décisions sont nécessaires ; quelles actions sont en retard ; quel risque résiduel demeure. Le niveau de détail doit donc être adapté au destinataire.

39Le modèle des trois lignes approfondi

Le Cours 01 a introduit le modèle des trois lignes. Approfondissons-le.

Première ligne

La première ligne réalise les activités et gère directement les risques associés. Elle comprend notamment les métiers et les équipes opérationnelles. Elle ne doit pas penser :

« Le risque appartient au Risk Manager. »

Elle doit gérer les risques liés à ses activités.

Deuxième ligne

La deuxième ligne apporte :

• expertise
• cadres
• méthodes
• support
• surveillance
• challenge.
• Les fonctions Risk, Compliance ou certaines fonctions cybersécurité peuvent exercer des rôles de deuxième ligne selon l’organisation.

Troisième ligne

L’audit interne fournit une assurance indépendante et objective sur la gouvernance, la gestion des risques et les contrôles. La troisième ligne ne doit normalement pas devenir propriétaire des risques qu’elle devra ensuite auditer.

40Pourquoi l’indépendance compte

Supposons qu’un auditeur interne :

• conçoive le processus de gestion des accès
• choisisse les contrôles
• les mette en œuvre
• les exploite
• puis réalise l’audit du processus.
• Peut-il encore fournir le même niveau d’assurance indépendante ?
• Son objectivité devient difficile à préserver.
• C’est pourquoi il faut distinguer :
• faire
• et
• évaluer indépendamment ce qui est fait.
• Cette distinction est fondamentale dans la gouvernance.

41Indépendance et objectivité ne signifient pas isolement

L’audit peut communiquer avec les métiers. La cybersécurité peut travailler avec la DSI. Risk peut conseiller les opérationnels. Les fonctions doivent collaborer. L’objectif du modèle des trois lignes n’est pas de construire des murs. Il cherche à clarifier : qui gère le risque ; qui apporte expertise et surveillance ; qui fournit une assurance indépendante. La bonne gouvernance combine donc :

RESPONSABILITÉ + COLLABORATION + INDÉPENDANCE.

42CAS PRATIQUE — Une vulnérabilité critique que le métier refuse de corriger immédiatement

Prenons maintenant une situation complète. L’organisation NOVACOM exploite une plateforme permettant à ses clients de déposer et suivre leurs demandes en ligne. Cette plateforme est considérée comme critique. L’équipe sécurité découvre une vulnérabilité importante sur un composant du serveur web. Une exploitation à distance est possible. Le fournisseur a publié un correctif. L’équipe infrastructure peut l’installer. Mais le correctif nécessite un redémarrage et environ deux heures d’indisponibilité. Nous sommes lundi. Le Directeur métier indique :

« Cette semaine correspond à notre période la plus importante de l’année. Je refuse toute interruption avant lundi prochain. »

L’administrateur demande au RSSI :

« Est-ce que je patch quand même ? »

Voilà une situation de gouvernance.

43Première erreur : répondre immédiatement par la technique

Une réponse possible serait :

« La vulnérabilité est critique. Installez immédiatement le patch. »

Peut-être que cette décision sera finalement la bonne. Mais nous n’avons pas encore suffisamment analysé la situation. Le professionnel GRC doit d’abord comprendre :

• Le système est-il exposé à Internet ?
• Existe-t-il une exploitation connue ?
• Le code d’exploitation est-il disponible ?
• Quelles données sont présentes ?
• Quels contrôles compensatoires existent ?
• Quelle serait la conséquence d’une compromission ?
• Quelle serait la conséquence d’une interruption de deux heures ?
• Peut-on réduire l’interruption ?
• Existe-t-il une redondance ?
• Peut-on isoler temporairement le service ?
• Peut-on renforcer la surveillance ?
• Quel niveau de risque résiduel resterait jusqu’à lundi ?
• Nous devons comparer les risques.

44Deux risques existent

Le premier risque est cyber :

Un attaquant exploite la vulnérabilité avant l’installation du correctif et compromet la plateforme.

Le second risque est opérationnel :

L’installation immédiate du correctif provoque une interruption pendant une période métier critique.

La gouvernance doit arbitrer entre plusieurs conséquences. C’est précisément pourquoi la cybersécurité n’est pas seulement une question technique.

45Qui doit prendre la décision ?

L’administrateur ne devrait pas porter seul l’arbitrage. Il apporte la faisabilité technique ; le RSSI qualifie le risque cyber ; le métier expose les conséquences opérationnelles ; le Risk Owner décide dans les limites de son autorité. Si le risque dépasse la tolérance ou le seuil défini, la décision remonte à la Direction ou au comité compétent.

La qualité de la décision dépend donc moins d’un acteur unique que de la réunion des bonnes informations au bon niveau d’autorité.

46Ce que le professionnel GRC doit faire

Il doit rendre la décision possible. Il doit expliquer : le scénario ; l’exposition ; les impacts ; les contrôles existants ; les options ; les avantages et limites de chaque option ; le risque résiduel ; la durée de l’exposition ; le niveau d’autorité requis. Il peut proposer plusieurs options.

Option A — Corriger immédiatement

Risque cyber fortement réduit. Impact opérationnel immédiat.

Option B — Reporter avec contrôles compensatoires

Renforcement temporaire de la surveillance. Restriction de certains accès. Éventuelle segmentation supplémentaire. Protection applicative renforcée. Correction lundi. Le risque cyber reste plus élevé jusqu’à la correction.

Option C — Suspendre temporairement certaines fonctionnalités

Impact métier partiel. Surface d’attaque réduite.

Option D — Accepter temporairement le risque

Possible uniquement si le niveau d’autorité et les règles de l’organisation le permettent. Le rôle GRC est d’éclairer l’arbitrage.

47Ce qu’il ne doit pas faire

Le professionnel GRC ne doit pas :

• minimiser le risque pour éviter un conflit
• exagérer artificiellement le risque pour forcer la décision
• accepter lui-même un risque qu’il n’a pas autorité à accepter
• cacher l’absence de traitement
• considérer qu’un courriel informel suffit toujours à transférer la responsabilité
• laisser une exception sans échéance
• confondre recommandation et décision.
• Il doit rester professionnel.
• Son rôle n’est pas de gagner un débat.
• Son rôle est d’aider l’organisation à prendre une décision informée et traçable.

48Une décision informée

Une décision de risque est réellement informée lorsque le décideur comprend suffisamment :

• ce qui peut arriver ;
• pourquoi cela peut arriver ;
• ce qui sera affecté ;
• la gravité potentielle ;
• les protections existantes ;
• les options disponibles ;
• les conséquences de chaque option ;
• le risque qui restera.
• Faire signer un document à une personne qui ne comprend pas le risque n’est pas une gouvernance mature.
• La signature constitue une trace.
• La compréhension constitue la véritable décision.

50EXERCICE PRATIQUE 02 — Cartographier les responsabilités cyber

Choisissez un service réel ou fictif. Par exemple : une messagerie ; un Active Directory ; une application financière ; une plateforme de paiement ; un portail web ; une base de données RH ; une infrastructure réseau. Commencez par identifier : le propriétaire métier ; le responsable technique ; le propriétaire des données ; le Risk Owner ; la fonction cybersécurité ; la Direction compétente ; la fonction d’audit. Choisissez ensuite cinq activités importantes. Par exemple : validation des accès ; gestion des vulnérabilités ; acceptation d’un risque ;

gestion d’un incident majeur ; validation d’une exception. Pour chaque activité, déterminez : qui réalise ; qui rend compte ; qui doit être consulté ; qui doit être informé. Enfin, posez une dernière question :

La personne qui porte la responsabilité possède-t-elle réellement l’autorité nécessaire ?

Si la réponse est non, vous venez probablement d’identifier une faiblesse de gouvernance.

51LIVRABLE PORTFOLIO 02 — Matrice de gouvernance et d’autorité cyber

Ce deuxième livrable doit pouvoir être utilisé comme base dans une véritable organisation.

A. Identification du service

B. Matrice RACI

C. Matrice d’autorité

D. Mécanisme d’escalade

Décrivez simplement :

E. Conclusion

Terminez le livrable par une courte analyse répondant à quatre questions :

• 1. Les responsabilités sont-elles clairement définies ?
• 2. Existe-t-il des responsabilités sans autorité suffisante ?
• 3. Existe-t-il des conflits d’intérêts ou une concentration excessive de pouvoirs ?
• 4. Les risques importants peuvent-ils réellement être escaladés jusqu’au bon décideur ?
• Ce document constituera la deuxième pièce de votre portfolio GRC.

52Quiz de validation

53LES PIÈGES À ÉVITER

À ce stade, plusieurs erreurs doivent devenir immédiatement visibles.

Croire que « cyber » signifie automatiquement « responsabilité de la DSI »

Le risque cyber peut affecter directement un objectif métier. La DSI est essentielle, mais elle n’est pas nécessairement propriétaire de toutes les conséquences.

Confondre expertise et autorité

Le meilleur expert technique de l’organisation ne possède pas automatiquement l’autorité pour accepter un risque métier.

Donner une responsabilité sans pouvoir

Demander à une personne de garantir un résultat sans lui donner les moyens, l’accès ou l’autorité nécessaires crée une responsabilité théorique.

Faire du RACI pour faire du RACI

Le RACI doit résoudre des ambiguïtés. S’il n’aide personne à savoir qui agit et qui décide, il n’apporte presque aucune valeur.

Accepter implicitement un risque

Un risque qui reste ouvert parce que personne n’a pris de décision n’est pas nécessairement un risque correctement accepté.

Confondre signature et compréhension

Une signature prouve qu’une personne a signé. Elle ne prouve pas automatiquement qu’elle comprenait le risque.

Laisser les exceptions devenir permanentes

Une exception sans date de révision peut progressivement devenir la nouvelle règle informelle.

Remonter toute décision à la Direction

La gouvernance ne consiste pas à centraliser toutes les décisions. Elle consiste à attribuer chaque décision au niveau approprié.

Ne jamais escalader

L’extrême inverse est tout aussi dangereux. Lorsqu’un risque dépasse l’autorité ou la tolérance définie, il doit pouvoir remonter.

Confondre audit et management

L’audit apporte une assurance indépendante. Il ne devrait pas devenir propriétaire de ce qu’il devra ensuite évaluer.

54Les concepts à savoir expliquer sans notes

Avant de passer au Cours 03, vous devez pouvoir expliquer ces notions avec vos propres mots et les appliquer à une décision concrète.

Qui doit prendre cette décision, et pourquoi cette personne possède-t-elle l’autorité nécessaire ?

Si vous savez répondre à cette question en reliant objectif métier, risque, responsabilité, seuil et mécanisme de suivi, vous avez compris l’essentiel du cours.

55RÉFÉRENCES POUR APPROFONDIR

Ce cours repose sur des principes que nous retrouverons dans plusieurs référentiels majeurs.

NIST Cybersecurity Framework 2.0

Le NIST CSF 2.0 accorde une place explicite à la fonction GOVERN. Cette fonction traite notamment du contexte organisationnel, de la stratégie de gestion des risques, des rôles, responsabilités et autorités, des politiques, de la supervision et des risques liés aux chaînes d’approvisionnement. Nous reviendrons régulièrement sur ce cadre.

ISO/IEC 27014 — Governance of Information Security

ISO/IEC 27014 apporte une vision spécifiquement consacrée à la gouvernance de la sécurité de l’information. Elle permet notamment d’approfondir la manière dont l’organisation évalue, oriente, surveille et communique les questions relatives à la sécurité de l’information.

ISO/IEC 27001

ISO/IEC 27001 nous permettra plus tard de transformer plusieurs principes étudiés ici en véritable système de management de la sécurité de l’information. Les notions de leadership, responsabilités, politiques, objectifs, évaluation de la performance et amélioration y prendront une importance particulière.

ISO 31000

ISO 31000 nous aidera à replacer le risque cyber dans le système global de gestion des risques de l’organisation. Nous verrons que le risque ne doit pas être traité comme un sujet isolé de la gouvernance générale.

NIST Risk Management Framework

Le RMF apportera une autre perspective sur l’attribution des responsabilités, la sélection des contrôles, leur évaluation, l’autorisation et la surveillance continue.

COBIT

COBIT nous aidera à approfondir la distinction entre gouvernance et management des systèmes d’information et à relier davantage les objectifs de l’organisation aux objectifs de gouvernance et de management.

Three Lines Model — Institute of Internal Auditors

Le modèle des trois lignes permet d’approfondir les relations entre organe de gouvernance, management, fonctions apportant expertise et surveillance sur le risque, et audit interne. L’objectif n’est toujours pas de mémoriser ces référentiels. Nous les utilisons pour consolider une manière de raisonner.

57Passerelle vers le Cours 03

Nous savons désormais pourquoi la GRC existe, comment la cybersécurité se rattache à la mission, comment organiser les responsabilités et comment attribuer les décisions relatives aux risques. Une question demeure : sur quelle analyse le décideur doit-il s’appuyer ?

Le prochain cours montrera comment identifier un risque, construire un scénario, évaluer impact et vraisemblance, distinguer risque inhérent et risque résiduel, prioriser les traitements et structurer un registre des risques.

Cours 03 — Identifier, analyser, évaluer et traiter les risques cyber

Ce passage de l’autorité vers l’analyse ouvre le Module 02 consacré à l’analyse et au traitement des risques cyber.