Le règlement intérieur du centre commercial

Aux Arcades, le centre commercial qui sert de fil rouge à cette série, tout ne se joue pas au niveau des vigiles ni des caméras. Avant qu'un seul portique ne soit installé, quelqu'un a décidé des règles. La direction a rédigé un règlement intérieur : horaires d'ouverture, zones interdites au public, procédure d'évacuation, conduite à tenir en cas d'alerte à la bombe.

Ce règlement n'arrête personne à lui seul. Il dit qui est responsable de quoi. Le directeur sûreté répond de la sécurité physique. Le responsable des données clients veille au fichier de fidélité. Et une fois par an, une commission de sécurité extérieure passe vérifier que le centre respecte les normes des établissements recevant du public.

Cette commission ne vend rien, ne surveille aucun écran. Elle pose une seule question : les règles existent-elles, sont-elles tenues, et qui en répond ?

La gouvernance, c'est ce qui se décide avant la technique : qui fixe le cap, qui détient l'autorité, et qui rend des comptes quand quelque chose tourne mal.

Les billets précédents de cette série parlaient d'outils et de mécanismes : pare-feu, chiffrement, détection, reconnaissance offensive. On monte ici d'un cran. La question n'est plus « comment se protège-t-on ? » mais « qui décide de comment on se protège, et qui assume si ça échoue ? ».


Vue d'ensemble : gouverner, ce n'est pas opérer

Avant le détail, la carte du territoire. La gouvernance de la sécurité tient sur trois piliers, et il faut les distinguer dès le départ pour ne pas tout confondre.

  • Les rôles et les responsabilités. Qui porte la sécurité au plus haut niveau (le CISO), qui défend les données personnelles (le DPO), quels comités arbitrent et tranchent.
  • La gestion du risque. Le processus par lequel l'organisation décide ce qu'elle accepte, ce qu'elle réduit, ce qu'elle transfère. C'est le cœur de la décision.
  • Les frameworks d'organisation. Les référentiels qui structurent tout cela : NIST CSF, COBIT, ITIL. Ils ne sont pas interchangeables, et on verra pourquoi.

Une distinction est essentielle pour la suite. La gouvernance fixe le cap et désigne les responsables. La conformité, elle, vérifie qu'on respecte une norme ou une loi externe. Les deux se ressemblent mais ne se confondent pas : on peut être conforme sur le papier et mal gouverné dans les faits. La conformité (ISO 27001, RGPD, NIS2) fait l'objet du prochain billet de la série.

Gouverner, c'est décider et répondre. Opérer, c'est exécuter. Une organisation peut avoir d'excellents outils et une gouvernance défaillante : c'est précisément le scénario qui finit en incident majeur.

Les rôles : qui répond de quoi

Aux Arcades, personne ne cumule tout. Le directeur sûreté gère les vigiles et les accès. Le responsable des données clients protège le fichier de fidélité. Le directeur du centre arbitre quand les deux entrent en conflit, par exemple si installer plus de caméras revient à collecter trop de données personnelles. Chacun a un périmètre, et chacun rend compte à quelqu'un.

En entreprise, cette répartition porte des titres précis.

Le CISO (RSSI en français)

Le CISO (Chief Information Security Officer), ou RSSI (Responsable de la Sécurité des Systèmes d'Information), est le directeur sûreté du système d'information. C'est lui qui porte la stratégie de sécurité, fixe les politiques, arbitre les priorités et rend compte à la direction générale.

Point souvent mal compris : le CISO ne décide pas seul du niveau de risque acceptable. Il l'éclaire, le formule, mais la décision finale d'accepter un risque appartient à la direction. Le CISO conseille, alerte, propose. La direction tranche et assume.

Le DPO

Le DPO (Data Protection Officer, ou délégué à la protection des données) est le pendant du responsable des données clients aux Arcades. Son rôle est défini par le RGPD : veiller à la conformité du traitement des données personnelles, conseiller l'organisation, servir de point de contact avec l'autorité de contrôle (la CNIL en France).

Le DPO n'est pas un subalterne du CISO. Les deux fonctions se recoupent (protéger des données) mais répondent à des logiques différentes : le CISO protège l'information de l'entreprise, le DPO défend les droits des personnes dont on traite les données. Le RGPD impose d'ailleurs au DPO une indépendance : il ne doit pas recevoir d'instructions sur la manière d'exercer sa mission.

Comités et lignes de défense

Au-dessus des rôles individuels, des comités arbitrent. Un comité de sécurité (ou comité des risques) réunit périodiquement direction, métiers et sécurité pour valider les politiques, examiner les incidents majeurs et décider des investissements.

Pour clarifier qui fait quoi, beaucoup d'organisations s'appuient sur le modèle des trois lignes de défense, formalisé par l'Institute of Internal Auditors.

Ligne Qui Rôle
Première ligne Les métiers, les équipes opérationnelles Possèdent et gèrent le risque au quotidien
Deuxième ligne Fonctions sécurité, conformité, risque (CISO, DPO) Définissent le cadre, surveillent, conseillent
Troisième ligne Audit interne Vérifie de façon indépendante que les deux premières font leur travail

L'intérêt de ce modèle est d'éviter le mélange des genres. Celui qui prend le risque n'est pas celui qui le contrôle, et celui qui contrôle n'est pas celui qui audite. La commission de sécurité qui passe une fois par an aux Arcades joue exactement le rôle de la troisième ligne : un regard extérieur qui ne dépend pas de ceux qu'il évalue.

Une gouvernance saine sépare ceux qui prennent le risque, ceux qui le surveillent et ceux qui le vérifient. Quand les trois se confondent, l'angle mort est garanti.

La gestion du risque comme processus de décision

Le règlement des Arcades ne traite pas tous les dangers de la même façon. Un vol à l'étalage occasionnel est toléré comme un coût normal d'exploitation : on ne ferme pas le centre pour autant. Un risque d'incendie, lui, déclenche des investissements lourds (sprinklers, issues de secours, formation du personnel) parce que l'impact est sans commune mesure. Quelque part, quelqu'un a décidé où placer le curseur.

Ce curseur a un nom : l'appétit pour le risque. C'est le niveau de risque qu'une organisation accepte de courir pour atteindre ses objectifs. Le définir est une décision de gouvernance, pas un calcul technique.

Le premier billet de la série posait le risque comme le produit d'une probabilité par un impact. La gouvernance s'appuie sur cette base pour décider quoi faire de chaque risque identifié. Quatre traitements possibles, classiques :

  • Réduire le risque en ajoutant des contrôles (chiffrer, segmenter, former).
  • Transférer le risque, typiquement via une assurance ou un contrat.
  • Éviter le risque en renonçant à l'activité qui l'engendre.
  • Accepter le risque tel quel, en connaissance de cause, quand le coût de traitement dépasse l'enjeu.

Ces décisions ne vivent pas dans la tête des gens. Elles sont consignées dans un registre des risques : un document vivant qui liste les risques identifiés, leur niveau, le traitement choisi, et surtout le propriétaire de chaque risque, la personne nommément responsable.

Risque Impact Traitement décidé Propriétaire
Fuite du fichier clients Élevé Réduire (chiffrement, contrôle d'accès) DPO
Indisponibilité du site e-commerce Élevé Réduire et transférer (redondance, assurance) Directeur technique
Phishing ciblant les employés Moyen Réduire (formation, filtrage) CISO
Panne d'un outil interne non critique Faible Accepter Métier concerné

Ce qui transforme une liste de bonnes intentions en gouvernance, c'est la colonne « propriétaire ». Un risque sans propriétaire est un risque que personne ne traite et dont personne ne répond. On verra dans le scénario Equifax ce que coûte un risque mal attribué.

Un risque accepté n'est pas un risque ignoré. C'est une décision documentée, datée et assumée par une personne identifiée. Toute la différence se joue là.

Les frameworks : structurer la gouvernance

Aux Arcades, la commission de sécurité ne réinvente pas ses critères à chaque visite. Elle s'appuie sur un référentiel établi, les normes des établissements recevant du public, qui dit ce qu'il faut vérifier et comment. Personne n'a à improviser une définition de « sécurité acceptable ».

En sécurité de l'information, plusieurs référentiels jouent ce rôle de cadre commun. Trois reviennent constamment, et ils ne servent pas à la même chose.

Le NIST CSF (Cybersecurity Framework) est centré sur le risque cyber. Sa version 2.0, publiée par le NIST, organise la sécurité autour de fonctions de haut niveau et reste volontairement agnostique sur les outils.

COBIT, maintenu par l'ISACA, est plus large : c'est un cadre de gouvernance et de gestion de l'informatique dans son ensemble, qui aligne l'IT sur les objectifs de l'entreprise. Il dépasse la seule sécurité.

ITIL, géré par AXELOS et PeopleCert, ne parle pas de gouvernance de sécurité à proprement parler. C'est un référentiel de gestion des services informatiques : gestion des incidents, des changements, des problèmes. Il croise la sécurité par ses processus opérationnels.

Framework Objet Focus Quand l'utiliser
NIST CSF 2.0 Gestion du risque cyber Sécurité, langage commun de la posture Structurer et communiquer sa posture de cybersécurité
COBIT Gouvernance et gestion de l'IT Alignement IT et objectifs métier Cadrer la gouvernance globale du SI, pas seulement la sécurité
ITIL Gestion des services IT Processus opérationnels (incidents, changements) Industrialiser l'exploitation des services, sécurité incluse

Ces référentiels ne s'opposent pas. Une organisation mûre utilise souvent NIST CSF pour cadrer sa posture sécurité, COBIT pour la gouvernance IT d'ensemble, et ITIL pour ses opérations quotidiennes. Le piège serait de croire qu'adopter un framework dispense de réfléchir : un référentiel structure la pensée, il ne la remplace pas.

Le NIST CSF 2.0 mérite un mot de plus, car sa version récente a introduit une nouveauté qui parle directement de gouvernance. Il s'organise désormais autour de six fonctions.

flowchart TD govern["GOVERN
fixer la stratégie et les responsabilités"] identify["IDENTIFY
connaître ses actifs et ses risques"] protect["PROTECT
mettre en place les protections"] detect["DETECT
repérer les événements"] respond["RESPOND
réagir à un incident"] recover["RECOVER
rétablir l'activité"] govern --> identify govern --> protect govern --> detect govern --> respond govern --> recover identify --> protect protect --> detect detect --> respond respond --> recover classDef governcls fill:#8a4d16,stroke:#5f5e5a,color:#f5f2ec classDef opscls fill:#b5651d,stroke:#5f5e5a,color:#f5f2ec classDef lightcls fill:#d89253,stroke:#5f5e5a,color:#1a1a1a class govern governcls class identify,protect,detect opscls class respond,recover lightcls

La fonction GOVERN est l'ajout phare de la version 2.0. Elle ne flotte pas à côté des autres : elle les chapeaute toutes. Le NIST a fait de la gouvernance le socle qui oriente l'identification, la protection, la détection, la réponse et la reprise. C'est une reconnaissance officielle de ce que cette série martèle : la technique sans gouvernance est aveugle.

Un framework n'est pas une case à cocher. C'est un langage partagé qui permet à la direction, à la sécurité et aux auditeurs de parler de la même chose sans se méprendre.

Equifax : quand la gouvernance défaille

La théorie devient limpide quand on regarde un cas où la gouvernance a manqué. L'incident Equifax de 2017 en est l'un des plus documentés, précisément parce qu'il ne s'explique pas par la seule technique.

En 2017, l'agence de crédit américaine Equifax a subi une intrusion massive ayant exposé les données personnelles de dizaines de millions de personnes. Le point d'entrée technique était une vulnérabilité connue dans un composant logiciel, pour laquelle un correctif existait déjà. Jusque-là, c'est une histoire de patch manquant.

Mais l'enquête officielle a montré que le problème dépassait largement la vulnérabilité. Le rapport GAO-18-559 du Government Accountability Office américain pointe des défaillances de gouvernance : une gestion des correctifs où la responsabilité d'appliquer le patch n'était pas clairement attribuée, une communication interne défaillante sur l'alerte de sécurité, et un dispositif de surveillance du trafic chiffré rendu aveugle parce qu'un certificat de surveillance était expiré depuis des mois, ce qui a laissé l'exfiltration de données passer inaperçue pendant une longue période.

Aucun de ces points n'est un problème d'outil sophistiqué. Le patch existait. Le système de surveillance existait. Ce qui manquait, c'était la réponse à des questions de gouvernance : qui est responsable d'appliquer ce correctif ? Qui vérifie que les certificats de surveillance sont valides ? Qui relaie une alerte de sécurité jusqu'à l'action ?

Equifax n'a pas échoué faute de technologie. L'organisation a échoué parce que les responsabilités étaient floues et que personne ne répondait de tâches pourtant connues. C'est une défaillance de gouvernance, pas de pare-feu.

C'est exactement le scénario inverse du registre des risques avec sa colonne « propriétaire ». Quand chaque risque a un responsable nommé, la question « qui devait appliquer ce patch ? » a une réponse. Chez Equifax, elle n'en avait pas de claire, et c'est ce vide qui a coûté si cher.


Points clés

  • La gouvernance décide et désigne les responsables ; elle se distingue de la conformité, qui vérifie le respect d'une norme externe (sujet du prochain billet).
  • Le CISO (RSSI) porte la stratégie de sécurité et conseille, mais la décision d'accepter un risque revient à la direction ; le DPO défend les droits des personnes et reste indépendant.
  • Le modèle des trois lignes de défense sépare ceux qui prennent le risque, ceux qui le surveillent et l'audit indépendant qui vérifie les deux.
  • La gestion du risque s'appuie sur un appétit pour le risque défini, quatre traitements (réduire, transférer, éviter, accepter) et un registre où chaque risque a un propriétaire nommé.
  • NIST CSF, COBIT et ITIL ne se substituent pas l'un à l'autre : risque cyber, gouvernance IT globale, gestion des services. NIST CSF 2.0 a fait de GOVERN la fonction qui chapeaute toutes les autres.
  • Le cas Equifax (2017) montre qu'une responsabilité floue et un suivi défaillant transforment une vulnérabilité corrigeable en désastre : la gouvernance compte autant que la technique.

Dans la série

Palier 3 : Tenir la galerie. Domaine : Gouvernance & conformité.

Pour aller plus loin