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

PARTIE I

COMPRENDRE CE QUE SIGNIFIE GOUVERNER LA CYBERSÉCURITÉ

La gouvernance n’est pas l’administration de la sécurité

Gouverner la cybersécurité ne signifie pas configurer un pare-feu, déployer un EDR, analyser des journaux ou appliquer un correctif. Ces activités sont nécessaires, mais elles se situent principalement au niveau du management et des opérations.

La gouvernance agit à un niveau différent. Elle permet de déterminer ce qui doit être protégé, pourquoi, dans quelles limites, avec quelles responsabilités et selon quels mécanismes de surveillance et de décision.

Une Direction peut par exemple décider qu’un service critique ne doit pas rester indisponible plus de deux heures. Cette orientation ne dit pas s’il faut utiliser de la réplication, un cluster, un second datacenter ou une architecture cloud. Elle définit un résultat attendu. Le management devra organiser les moyens permettant de l’atteindre et les opérations devront les mettre en œuvre.

La relation reste donc :

La maturité apparaît lorsque ces trois niveaux restent alignés.

La gouvernance commence par la mission

Une politique de sécurité n’est pas le point de départ de la gouvernance. Le point de départ est l’organisation elle-même : sa mission, ses objectifs, ses activités essentielles, ses obligations, ses parties prenantes et les conséquences qu’elle ne peut raisonnablement pas accepter.

Une banque cherchera notamment à préserver l’intégrité des transactions, la disponibilité des services financiers et la confiance de ses clients. Un hôpital donnera une importance particulière à la continuité des soins et à la fiabilité des informations médicales. Une administration publique pourra devoir assurer la continuité d’un service essentiel aux citoyens, protéger des informations sensibles et respecter des obligations de souveraineté ou de service public.

Les priorités cyber ne proviennent donc pas d’un catalogue d’outils. Elles doivent être dérivées des priorités de l’organisation.

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

La gouvernance donne ainsi un sens aux contrôles techniques.

La gouvernance est un système de décision

Une manière particulièrement utile de comprendre la gouvernance consiste à la considérer comme un système de droits de décision.

Pour chaque décision importante, l’organisation doit pouvoir répondre à quatre questions : quelle décision doit être prise ? Qui possède l’autorité pour la prendre ? De quelles informations cette personne a-t-elle besoin ? Comment la décision sera-t-elle suivie et réévaluée ?

Ces questions concernent aussi bien la validation d’une politique que l’acceptation d’un risque, l’autorisation d’une exception, l’engagement d’un budget, l’interruption d’un service critique ou l’escalade d’un incident majeur.

Une organisation gouvernée n’est donc pas celle dans laquelle la Direction décide de tout. C’est celle dans laquelle chaque décision peut être prise au niveau approprié, dans les limites d’une autorité définie, et être escaladée lorsque ces limites sont dépassées.

PARTIE II

ORGANISER LES RESPONSABILITÉS

La cybersécurité est une responsabilité distribuée

La cybersécurité ne peut pas être gouvernée exclusivement par le RSSI ou la DSI, car les conséquences des risques cyber dépassent largement la technique. Une compromission peut affecter la finance, les opérations, la réputation, les obligations réglementaires, les clients, les citoyens, les fournisseurs ou même la sécurité physique.

La Direction doit donc fournir les orientations et arbitrer les décisions relevant de son niveau. Les métiers apportent la compréhension de la criticité des activités et des conséquences. La DSI maîtrise l’architecture, l’exploitation et une grande partie des contrôles techniques. La fonction cybersécurité structure les exigences, analyse les risques, conseille, surveille et escalade. Les fonctions Risk et Compliance apportent leurs cadres de maîtrise. L’audit fournit une assurance indépendante.

La gouvernance cyber fonctionne précisément lorsqu’aucun de ces acteurs n’est considéré comme propriétaire de l’ensemble du problème.

Le rôle de la Direction

La Direction n’a pas besoin de savoir configurer un pare-feu. Elle doit en revanche être capable d’exercer les responsabilités correspondant à son niveau d’autorité.

Elle doit disposer d’une visibilité suffisante pour comprendre quels services sont critiques, quels risques significatifs menacent les objectifs, quels seuils sont dépassés, quelles obligations importantes ne sont pas satisfaites, quelles ressources sont nécessaires et quelles décisions nécessitent son arbitrage.

Une gouvernance mature ne transforme donc pas la Direction en équipe technique. Elle transforme l’information technique en information de décision.

Le rôle des métiers

Le métier ne doit pas être considéré comme un simple utilisateur du système d’information. Il possède une connaissance que ni la DSI ni le RSSI ne peuvent entièrement remplacer : la compréhension de l’activité.

Une équipe technique peut connaître parfaitement l’architecture d’une application financière. Mais la Direction financière saura mieux expliquer ce que représente une indisponibilité de plusieurs jours au moment de clôturer les comptes. De même, une équipe IT peut connaître l’architecture d’un système de production sans pouvoir décider seule des conséquences acceptables d’un arrêt industriel.

Cette connaissance métier est indispensable pour apprécier correctement les conséquences d’un risque et pour prendre certaines décisions.

Le rôle de la DSI et de la fonction cybersécurité

La DSI conçoit, exploite ou supervise une grande partie des systèmes nécessaires aux activités. Elle met en œuvre de nombreux contrôles : identité, sauvegardes, réseaux, correctifs, durcissement, changements, supervision ou continuité technique.

La fonction cybersécurité se situe généralement davantage dans la définition des exigences, l’identification et l’analyse des risques, la recommandation de contrôles, la surveillance, le conseil, le challenge et l’escalade.

Ces rôles sont complémentaires.

Le RSSI peut parfaitement recommander :

«  Ce risque ne devrait pas rester ouvert dans les conditions actuelles.  »

Mais cette expertise ne lui attribue pas automatiquement le pouvoir d’arrêter une usine, de suspendre un service national, de reporter une opération financière ou d’accepter les conséquences métier d’un scénario.

C’est l’une des distinctions fondamentales de ce cours :

L’expertise permettant d’éclairer une décision et l’autorité permettant de la prendre sont deux choses différentes.

Cette formulation est plus importante que la simple opposition entre capacité technique et autorité organisationnelle.

PARTIE III

RESPONSIBILITY, ACCOUNTABILITY ET AUTHORITY

Trois notions à ne pas confondre

La qualité d’une gouvernance dépend en grande partie de la clarté avec laquelle l’organisation distingue l’exécution, la responsabilité finale du résultat et l’autorité de décision.

Responsibility désigne généralement la responsabilité d’exécuter ou de piloter une activité. Un administrateur peut par exemple être responsable du déploiement d’un correctif.

Accountability désigne le fait de répondre du résultat. Une personne accountable n’effectue pas nécessairement elle-même toutes les tâches, mais elle doit pouvoir rendre compte du résultat obtenu.

Authority représente le pouvoir légitime de prendre une décision : accepter un risque, autoriser une exception, engager un budget, arrêter un service ou approuver une politique.

Nous pouvons donc retenir :

Ces trois dimensions doivent être cohérentes.

Responsabilité sans autorité : une faiblesse de gouvernance

Imaginons qu’un RSSI soit officiellement responsable du programme de cybersécurité, mais qu’il ne puisse ni accéder aux informations nécessaires, ni demander la correction d’une vulnérabilité, ni escalader un risque significatif, ni présenter directement une situation critique au niveau compétent.

Il porte une responsabilité formelle sans disposer des moyens permettant réellement de l’exercer.

À l’inverse, une personne disposant d’une autorité importante sans mécanismes de responsabilité, de contrôle ou de surveillance crée également un risque.

La logique recherchée est donc :

La gouvernance doit organiser cet équilibre.

PARTIE IV

PROPRIÉTÉ DU RISQUE ET DES ACTIFS

Le Risk Owner

Le Risk Owner est la personne ou l’entité disposant de la responsabilité et de l’autorité appropriées pour gérer un risque donné.

Il ne suffit pas d’inscrire un nom dans un registre. Le Risk Owner doit comprendre le scénario, les conséquences, les contrôles existants, les possibilités de traitement et le niveau de risque résiduel. Il doit également pouvoir prendre ou faire prendre les décisions qui relèvent de son périmètre.

La fonction cybersécurité peut rendre le risque intelligible et formuler une recommandation. Le Risk Owner doit permettre que le risque soit effectivement gouverné.

Ainsi :

Cette distinction évite de faire artificiellement du RSSI le propriétaire de toutes les conséquences cyber de l’organisation.

Asset Owner, Data Owner, System Owner, Process Owner et Custodian

Autour d’un même service, plusieurs formes de propriété peuvent coexister.

Le Process Owner porte la responsabilité d’un processus métier. Le Data Owner définit notamment les exigences métier concernant l’usage, l’accès ou la protection d’un ensemble de données. Le System Owner porte la responsabilité d’un système déterminé selon le modèle d’organisation adopté. L’Asset Owner assume la responsabilité définie par l’organisation sur un actif. Le Custodian, quant à lui, assure principalement la garde, l’administration ou l’exploitation opérationnelle.

Prenons une base de données RH. La Direction des ressources humaines peut être propriétaire métier des données et décider qui doit y accéder. La DSI peut exploiter l’infrastructure. L’administrateur de base de données peut techniquement créer les accès. Mais sa capacité technique à exécuter l’action ne lui donne pas automatiquement le droit de décider qui devrait disposer de cet accès.

C’est exactement le type de distinction qu’une gouvernance claire doit rendre explicite.

PARTIE V

SÉPARER LES POUVOIRS SANS PARALYSER L’ORGANISATION

Separation of Duties

La séparation des tâches cherche à éviter qu’une même personne puisse initier, autoriser, exécuter et contrôler seule une opération sensible.

Dans la gestion d’un accès privilégié, par exemple, le manager peut initier la demande, le Data Owner valider le besoin métier, l’administrateur créer techniquement l’accès et une fonction distincte participer à la revue périodique.

La logique ne consiste pas à créer de la bureaucratie. Elle vise à éviter qu’un pouvoir trop concentré permette une erreur, une fraude ou un abus sans possibilité raisonnable de détection.

La séparation doit cependant rester proportionnée. Une petite organisation ne disposera pas de la même capacité de séparation qu’une banque internationale. Lorsque certaines fonctions ne peuvent être séparées, des contrôles compensatoires doivent être envisagés.

Le moindre privilège s’applique aussi à l’autorité

Le principe de Least Privilege est généralement appliqué aux droits techniques : un utilisateur ne doit disposer que des privilèges nécessaires à son activité.

La même logique peut être appliquée aux droits de décision.

Un responsable local peut être autorisé à accepter un risque faible et temporaire dans son périmètre. Cela ne signifie pas qu’il devrait pouvoir accepter un risque susceptible d’interrompre une activité nationale critique ou de provoquer une conséquence financière majeure.

Nous obtenons donc une règle de gouvernance simple :

Cette logique constitue la base des matrices d’autorité et des seuils d’escalade.

PARTIE VI

RACI ET DROITS DE DÉCISION

Ce que le RACI permet réellement de faire

Le RACI distingue généralement :

R — Responsible : réalise l’activité.

A — Accountable : répond du résultat.

C — Consulted : contribue avant l’action ou la décision.

I — Informed : reçoit l’information nécessaire.

Un RACI peut être très utile pour mettre en évidence les ambiguïtés dans un processus. Mais il ne faut pas lui demander davantage que ce qu’il peut fournir.

Un RACI répond principalement à :

Qui intervient de quelle manière dans cette activité ?

Il ne suffit pas toujours à répondre précisément à :

Qui possède juridiquement ou organisationnellement le droit d’accepter ce risque ? Jusqu’à quel montant ou quel niveau ?

Pour cette deuxième question, une matrice d’autorité ou de délégation peut être nécessaire.

C’est une distinction importante : RACI et matrice d’autorité sont complémentaires, mais ils ne sont pas synonymes.

Construire un RACI utile

Prenons la gestion d’une vulnérabilité critique.

Cette matrice reste un exemple. La bonne répartition dépend de l’organisation, de ses délégations et de ses responsabilités.

Un bon RACI doit supprimer des ambiguïtés. S’il produit uniquement un tableau de plusieurs centaines de lignes que personne n’utilise lorsqu’une décision réelle doit être prise, il est devenu un exercice documentaire.

PARTIE VII

APPÉTENCE, TOLÉRANCES ET ESCALADE

De l’appétence aux seuils de décision

Une phrase telle que :

«  Nous avons une faible appétence pour les cyberattaques.  »

est trop générale pour orienter une décision opérationnelle.

Elle doit être traduite en limites plus exploitables. Une organisation peut par exemple définir qu’aucun compte privilégié accessible à distance ne doit fonctionner sans MFA, qu’une vulnérabilité critique exploitable sur un service critique doit être corrigée dans un délai donné ou qu’une indisponibilité dépassant quatre heures doit être escaladée.

La chaîne devient :

La gouvernance transforme ainsi une orientation générale en mécanisme concret de décision.

Matrice d’autorité

Prenons une échelle pédagogique de risques de 1 à 5. L’organisation pourrait définir que les risques 1 et 2 sont traités au niveau opérationnel, qu’un niveau 3 nécessite une validation métier, qu’un niveau 4 doit être présenté au comité de risques et qu’un niveau 5 nécessite une décision de la Direction générale.

Ce modèle n’est pas universel. Il illustre seulement le principe suivant :

La décision doit être prise au niveau le plus bas disposant réellement de l’autorité nécessaire, mais elle doit être escaladée dès que le risque dépasse cette autorité ou les tolérances définies.

Cela évite les deux extrêmes : tout faire remonter à la Direction, ce qui paralyse l’organisation, ou laisser des risques majeurs être acceptés au niveau opérationnel, ce qui affaiblit la gouvernance.

PARTIE VIII

ACCEPTATIONS ET EXCEPTIONS

Accepter un risque est une décision formelle

Un risque non traité n’est pas automatiquement un risque accepté.

Dire :

«  Nous n’avons pas eu le budget  »

ou :

«  Nous avons reporté le correctif  »

ne constitue pas à lui seul une acceptation mature.

Une véritable acceptation doit permettre de comprendre le scénario concerné, le niveau de risque, les conséquences, les contrôles existants, le risque résiduel, la justification, l’autorité qui accepte, la durée de la décision et les conditions éventuelles de révision.

La logique est :

L’acceptation doit donc être une décision consciente, et non la conséquence silencieuse de l’inaction.

Gérer les exceptions de sécurité

Une organisation peut exiger que tous les comptes administrateurs utilisent le MFA. Mais un ancien système peut ne pas supporter cette exigence.

Deux comportements sont alors possibles.

Le premier consiste à ignorer discrètement l’écart et laisser le compte fonctionner sans MFA.

Le second consiste à gérer formellement une exception.

Une exception mature doit documenter la raison pour laquelle l’exigence ne peut être satisfaite, le risque supplémentaire créé, les contrôles compensatoires, l’autorité qui l’autorise, sa durée et la date de réévaluation.

Le cycle peut être résumé ainsi :

Une exception n’est donc pas la suppression d’une règle. C’est une dérogation gouvernée.

PARTIE IX

DUE CARE ET DUE DILIGENCE

Prendre des mesures raisonnables ne suffit pas : il faut les maintenir

Les notions de Due Care et de Due Diligence permettent d’introduire une idée essentielle de gouvernance.

Dans le cadre pédagogique de ce cours, le Due Care correspond au fait de prendre les précautions raisonnablement attendues compte tenu du contexte et des risques connus.

Le Due Diligence correspond à l’effort continu permettant de vérifier que ces précautions restent effectivement mises en œuvre et suffisamment efficaces.

Supposons qu’une organisation identifie un risque de ransomware et mette en place des sauvegardes. Elle démontre qu’elle a pris une mesure de protection. Mais si elle ne surveille jamais les échecs, ne protège pas les copies contre l’altération et ne teste aucune restauration, elle peut découvrir après une attaque que ses sauvegardes sont inutilisables.

La logique complète est donc :

Il faut rester prudent avec ces termes lorsqu’ils sont utilisés dans un contexte juridique : leur portée exacte dépend du cadre applicable. Ici, nous les utilisons avant tout comme principes de comportement responsable et de suivi dans la durée.

PARTIE X

POLITIQUES, COMITÉS ET MÉCANISMES DE GOUVERNANCE

Une politique tire sa force de l’autorité qui la porte

Une politique de sécurité ne doit pas être considérée comme un document produit par le RSSI puis déposé sur un intranet.

Elle exprime une orientation de l’organisation et doit être soutenue par une autorité appropriée.

Si une politique exige une revue trimestrielle des comptes privilégiés, il faut savoir qui fournit la liste des comptes, qui effectue la revue, qui valide les suppressions, qui traite les écarts et à qui sont remontés les retards.

Une politique devient réellement gouvernante lorsqu’elle est reliée à :

Le comité n’est pas la gouvernance

Un comité cyber ou un comité de risques peut être utile lorsque les décisions nécessitent plusieurs perspectives : Direction, métiers, DSI, cybersécurité, Risk, Compliance, juridique, continuité ou protection des données.

Mais créer un comité ne signifie pas automatiquement créer de la gouvernance.

Un comité utile doit disposer d’un mandat, d’un périmètre, d’un niveau d’autorité, d’informations pertinentes et d’un mécanisme permettant de tracer les décisions et suivre les actions.

La question n’est donc pas :

Combien de réunions avons-nous tenues ?

mais :

Quelles décisions ont été prises, par qui, avec quel suivi et quels résultats ?

PARTIE XI

REPORTING ET INFORMATION DE DÉCISION

KPI, KRI et KCI

La gouvernance a besoin d’indicateurs, mais tous les indicateurs ne répondent pas à la même question.

Un KPI — Key Performance Indicator mesure principalement la performance d’une activité. Par exemple : le pourcentage de correctifs critiques appliqués dans le délai fixé.

Un KRI — Key Risk Indicator cherche à donner une visibilité sur l’évolution d’une exposition au risque. Par exemple : le nombre de systèmes critiques dépassant le délai maximal de correction d’une vulnérabilité critique.

Un KCI — Key Control Indicator renseigne sur l’état ou l’efficacité d’un contrôle. Par exemple : le pourcentage de comptes administrateurs réellement protégés par MFA.

Ces catégories peuvent parfois se chevaucher selon la conception retenue. La question la plus importante reste :

Quelle décision cet indicateur doit-il aider à prendre ?

Un tableau de bord de Direction doit éclairer les décisions

Présenter à la Direction «  14 000 événements SIEM, 927 IOC et 84 alertes EDR  » peut être techniquement exact sans lui fournir l’information nécessaire pour exercer son rôle.

La Direction a davantage besoin de savoir quels risques augmentent, quels services critiques sont concernés, quelles tolérances sont dépassées, quelles mesures sont en retard, quelles exceptions sont ouvertes, quel niveau de risque résiduel demeure et quelles décisions nécessitent son intervention.

Le reporting de gouvernance doit donc transformer l’activité cyber en information d’arbitrage.

Une formulation technique comme :

«  14 serveurs présentent une vulnérabilité CVSS 9.8 avec RCE non authentifiée  »

peut ainsi devenir :

Quatre systèmes concernés supportent le processus de facturation, dont deux sont exposés à Internet. Une exploitation pourrait permettre une prise de contrôle à distance et provoquer une interruption ou une altération du service. La correction nécessite une interruption estimée à deux heures et une décision doit être prise avant vendredi.

La transformation est claire :

PARTIE XII

TROIS LIGNES, INDÉPENDANCE ET ASSURANCE

Séparer gestion du risque et assurance

Le modèle des trois lignes introduit au Cours 01 prend ici une dimension plus concrète.

La première ligne réalise les activités et gère les risques associés. La deuxième ligne apporte des cadres, des méthodes, du conseil, de la surveillance et du challenge. La troisième ligne, principalement l’audit interne, fournit une assurance indépendante et objective sur la gouvernance, la gestion des risques et les contrôles.

L’objectif n’est pas de créer des silos. Les fonctions doivent collaborer.

Mais collaboration ne signifie pas confusion des rôles.

Si une fonction conçoit un contrôle, le met en œuvre, l’exploite puis certifie elle-même de manière indépendante son efficacité, la qualité de l’assurance devient discutable.

Nous pouvons donc retenir :

PARTIE XIV

LE MODÈLE MENTAL DU COURS

Les neuf questions de gouvernance

Lorsqu’une décision cyber significative apparaît, reconstruisez systématiquement ce raisonnement :

1. Quel objectif métier est concerné ?
2. Quel scénario de risque menace cet objectif ?
3. Quelle décision doit réellement être prise ?
4. Quelles informations sont nécessaires pour décider ?
5. Qui apporte l’analyse et la recommandation ?
6. Qui possède l’autorité pour décider ?
7. Le niveau de risque dépasse-t-il une tolérance ou une délégation ?
8. Comment la décision sera-t-elle documentée et suivie ?
9. Quand devra-t-elle être réévaluée ?

Le Cours 01 nous a appris à comprendre le risque dans la logique GRC.

Ce Cours 02 nous apprend à gouverner la décision.

Le Cours 03 approfondira ensuite l’analyse sur laquelle cette décision doit reposer.

PARTIE XV

EXERCICE PRATIQUE 02

Cartographier la gouvernance d’un service

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

Commencez par identifier le processus métier supporté et son propriétaire, le responsable technique, le Data Owner lorsqu’il est pertinent, le Risk Owner, la fonction cybersécurité et l’autorité de Direction susceptible d’intervenir.

Choisissez ensuite cinq décisions importantes liées au service : validation d’un accès privilégié, traitement d’une vulnérabilité, acceptation d’un risque, gestion d’un incident majeur ou autorisation d’une exception.

Pour chacune, identifiez qui exécute, qui répond du résultat, qui doit être consulté, qui doit être informé et surtout qui possède réellement l’autorité permettant de prendre la décision.

Terminez l’exercice par une question simple :

Existe-t-il dans cette organisation une responsabilité importante qui n’est pas accompagnée d’une autorité suffisante, ou au contraire une autorité importante sans mécanisme suffisant de responsabilité et de contrôle ?

Vous venez alors de passer du simple RACI à une véritable analyse de gouvernance.

PARTIE XVIII

CE QU’IL FAUT SAVOIR EXPLIQUER SANS NOTES

À la fin de ce cours, vous devez pouvoir expliquer naturellement les notions suivantes : gouvernance cyber, Responsibility, Accountability, Authority, Risk Owner, Process Owner, Asset Owner, Data Owner, System Owner, Custodian, RACI, matrice d’autorité, Separation of Duties, Least Privilege, appétence au risque, tolérance, seuil d’escalade, acceptation du risque, exception, Due Care, Due Diligence, KPI, KRI, KCI, trois lignes, indépendance et assurance.

Mais la véritable compétence ne consiste pas à réciter ces termes.

Face à une situation réelle, vous devez être capable de demander :

Quelle décision doit être prise, qui possède l’autorité pour la prendre, sur quelles informations cette décision doit-elle reposer et comment sera-t-elle suivie ?

Si vous savez construire cette réponse, vous commencez réellement à raisonner en gouvernance cyber.