Partager

EBIOS RM dans la pratique

Dans une analyse des risques EBIOS Risk Manager, le socle de sécurité est constitué de :

  • Mesures d’hygiène de base,
  • et de Mesures obligatoires

… identifiés dans une approche par conformité

… conformité à un Référentiel qui sert comme base pour mon Socle de Sécurité.

  • Comment choisir ce référentiel qui sert comme base pour mon socle de sécurité ?
  • Sur la base de quels critères ? – Lesquels sont recommandés ?
  • Lesquels sont à éviter ?
  • Faut-il retenir l’intégralité des mesures du référentiel dans le socle de sécurité ?
  • Sinon, quel est le critère de sélection des mesures ?
  • Faut-il se limiter aux mesures du référentiel ?
  • Comment gérer la « zone grise » entre le socle de sécurité et l’approche “par les risques” ? 
  • Est-ce une bonne pratique de considérer les mesures existantes comme socle de sécurité ? 

Des réponses à toutes ces questions sont dans la vidéo ci-dessous :

Sommaire :

  • 0:00 – Introduction
  • 0:53 – Rappel – Définition du socle de sécurité
  • 2:08 – Rappel – Utilité du socle de sécurité dans une étude EBIOS RM
  • 2:51 – Rappel – Contenu d’un socle de sécurité my
  • 3:50 – Rappel – Mode opératoire d’élaboration d’un socle de sécurité
  • 4:42 – Problématique – Quel référentiel utiliser ?
  • 5:52 – Cas 1 – Un référentiel obligatoire existe
  • 8:06 – Cas 1-bis – Multiples référentiels obligatoires existent
  • 9:44 – Cas 2 – Il n’existe pas de référentiel obligatoire
  • 11:14 – Faut-il retenir l’intégralité des mesures du référentiel dans le socle de sécurité ?
  • 13:25 – Est-ce une bonne pratique de considérer les mesures existantes comme socle de sécurité

Transcription de la Vidéo

L’objectif de cet épisode est de répondre à la question : quel référentiel utilisé comme base pour mon socle de sécurité ? C’est parti. Commençons par quelques rappels de ce que nous avons vu précédemment. D’abord, qu’est-ce qu’un socle de sécurité ? Dans une étude EBIOS RM, un socle de sécurité est défini au préalable de l’analyse des risques et est constitué de mesures dont la nécessité relève de l’évidence et qui ne nécessite pas de risque formalisé pour le justifier.

Contrairement au risque dont la pyramide de gestion des risques, le socle de sécurité est constitué de principes de base et d’hygiène, plutôt de mesures obligatoires issues de réglementations, de normes, d’obligations contractuelles, voire de politique interne. Attention, je ne dis pas que les mesures du socle ne couvrent pas de risque, mais plutôt que ces risques sont tellement évidents qu’ils ne nécessitent pas d’être formalisés explicitement. Par exemple, faut-il vraiment un risque formalisé pour conclure qu’il faut une authentification à minima par mot de passe ? Pour moi, ce n’est pas le cas. Bah, je mets cette authentification dans mon socle de sécurité. Au contraire, peut-être qu’une authentification forte n’est pas aussi évidente que ça. Dans quels cas je formalise un risque qui est mis en avant, les limites de l’authentification par mot de passe et qui met en avant les dégâts en cas de contournement de cette authentification. Voyons maintenant un deuxième rappel de quelle est l’utilité du socle de sécurité. Voyons ça de manière schématisée. Ici à gauche, j’ai une analyse des risques sans socle de sécurité identifié au préalable. Comme on le voit, on finit par un nombre important de scénarios de risque à traiter, ce qui impacte la qualité de l’analyse des risques. C’était par exemple le cas avec EBIOS RM en 2010. À droite, j’ai une analyse des risques avec un socle de sécurité identifié au préalable. Et comment on le voit, cela permet d’éliminer un nombre important de risques, en particulier ceux les plus basiques, et cela permet de finir avec un nombre limité de risques à traiter, ce qui permet de gagner en temps et en pertinence.

Troisième rappel très important aujourd’hui, l’objectif est de définir un processus de choix d’un référentiel qui sert comme base pour mon socle de sécurité. Mais attention, le socle de sécurité ne doit pas être constitué d’exigences génériques cochées dans ce référentiel, mais plutôt de mesures dites « linéaires » et de ses exigences contextualisées pour le système d’information en question et décrites sans ambiguïté. Par exemple, si je prends la mesure 25 du guide d’hygiène informatique, qui dit : « Sécuriser les interconnexions réseau avec les partenaires », il ne faut pas simplement la cocher de manière générique cette mesure dans le référentiel. Il faut plutôt la décliner de manière opérationnelle. Et pour ce faire, il faudra identifier les partenaires un par un. Pour chaque partenaire, j’identifie et coche toutes les interconnexions. Et après, pour chaque interconnexion, je définis les règles et mécanismes de filtrage qui sont en place.

Maintenant, à notre appel du mode opératoire que nous avons vu précédemment et qui permet d’obtenir un tel résultat. D’abord, première étape indispensable consiste à connaître et maîtriser le système d’information, et cela passe en particulier par une cartographie du système d’information. Ensuite, on viendra réaliser un audit de cybersécurité qui a pour but l’identification de mesures en place et aussi des recommandations de mesures à mettre en place. Les mesures en place et les mesures à mettre en place constituent un ensemble, notre socle de sécurité. Ici, une recommandation, un conseil que je recommande fortement, c’est que chaque fois que j’ajoute une mesure à mon socle de sécurité, à ce moment-là, je réfléchis à ses limites et aux menaces qui peuvent exploiter ses limites. Ensuite, ces menaces devront être considérées dans l’étude des risques.

Après ces quelques rappels importants, revenons au vif du sujet d’aujourd’hui. Pour ce faire, regardons l’étape 2 du mode opératoire, qui dit de réaliser un audit de sécurité. Une question qui se pose ici, ces audits par rapport à quel référentiel ? Et là, on se rend compte qu’il manquait en effet une étape dans notre mode opératoire, qui consistait d’abord à identifier le référentiel qui va servir comme base pour mon socle de sécurité. Donc, dans cette vidéo, nous allons creuser cette étape. Et pour ce faire, nous allons répondre à ces questions-là :

  • comment choisir le référentiel qui va servir comme base pour mon socle ?
  • Sur la base de quels critères ?
  • Lesquels sont recommandés ?
  • Lesquels sont à éviter ?
  • Faut-il, une fois que j’ai choisi mon référentiel, faut-il en retenir l’intégralité des mesures de ce référentiel pour mon socle de sécurité ?
  • Si ce n’est pas le cas, quelles mesures là sont retenues ou pas ?
  • Selon quels critères ?
  • Et comme d’habitude, il y a toujours une zone grise, et nous allons voir comment la limiter voire l’éliminer la zone grise entre le socle de sécurité et l’approche par les risques.

Enfin, une approche assez courante consiste à considérer les mesures existantes comme stock de sécurité. Et nous allons voir si c’est une bonne pratique du choix du référentiel qui va servir comme base pour mon socle de sécurité. Nous allons distinguer deux cas qui concernent la deuxième couche constituée des mesures obligatoires. En effet, un cadre de conformité obligatoire peut exister, comme il peut ne pas exister. Regardons dans un premier temps le cas où un référentiel obligatoire existe.

D’abord, qu’est-ce qu’un référentiel obligatoire ?

Celui-ci peut être une obligation légale ou réglementaire, une norme certifiante, une obligation contractuelle, ou même une politique interne applicable en transversal à mon organisme et qui devient une obligation pour mon périmètre. Ok, maintenant, j’ai un référentiel obligatoire qui existe. Est-ce que je dois l’utiliser systématiquement comme base pour mon socle de sécurité ? Pas forcément le cas, et nous allons voir cela dans un arbre de décision. Première question qu’il convient de se poser : est-ce que ce référentiel contient des mesures concrètes et opérationnelles ? Par exemple, c’est le cas pour la LPM ou la directive NIS qui parlent d’authentification, de cloisonnement, de filtrage, etc. Contrairement aux RGPD, par exemple, qui sont plutôt pour la partie cyber des principes généraux.

Dans ce deuxième cas, le référentiel en question n’est pas utilisable comme base pour le socle de sécurité, mais sera considéré dans l’étude. Il sera considéré dans la définition des objectifs et aussi dans la définition et la qualification des impacts associés au risque. Donc, si mon référentiel ne comprend pas de mesures concrètes et opérationnelles, je passe au cas 2. Comme si je n’ai pas de référentiel obligatoire qui existe, et nous allons voir cela plus tard. Ok, maintenant, j’ai un référentiel obligatoire avec des mesures concrètes et opérationnelles.

Deuxième question qu’il convient de se poser : est-ce que ce référentiel est exhaustif par rapport à l’état de l’art ?

Entre parenthèses, par exemple, on sait que la LPM ne couvre pas certaines thématiques d’état de l’art. Ça ne parle pas explicitement de la sécurité des communications, ni de sécurité physique, ni des sauvegardes, etc. Dans ce cas-là, il convient de compléter par un référentiel de l’état de l’art. Si, par contre, j’ai un référentiel que je considère comme exhaustif par rapport à l’état de l’art, je peux l’utiliser tel quel. Regardons maintenant le cas que j’ai appelé ici « qu’à 1 bis » ou pas de référentiel obligatoire qui existe, mais plusieurs cas, c’est fréquent.

Regardons quelques cas d’usage. Je peux avoir un même système auquel s’appliquent plusieurs obligations, suffit juste d’avoir d’un côté une politique interne à mon organisme, et de l’autre côté une réglementation qui s’applique spécifiquement à mon périmètre. Je peux aussi avoir un système auquel s’appliquent multiples réglementations. C’est aussi le cas. Donc, quand on souhaite créer un modèle de socle de sécurité uniforme qui sera utilisable dans plusieurs projets différents et dans différents contextes réglementaires et normatifs, c’est par exemple le cas pour des projets internes de gros groupes ou des cabinets de conseil pour leurs projets clients. Ici, j’ai deux solutions.

Une première solution consiste à choisir parmi ces référentiels obligatoires celui qui est le plus complet, et puis établir des correspondances entre ce référentiel et les autres. On peut aussi le compléter si nécessaire. Deuxième solution, qui est ma préférée et que j’ai longuement pratiquée, c’est de créer une trame interne personnalisée. Et après, on vient établir des correspondances entre cette trame et les référentiels applicables. Cette solution présente l’avantage de donner plus de liberté. Je peux adapter la granularité que je souhaite, la structure que je souhaite. Et aussi, cette trame évolue et je peux ainsi l’enrichir sans être lié à un référentiel.

Regardons maintenant le deuxième cas où il n’existe pas de référentiel obligatoire. Deux solutions se présentent : soit choisir et utiliser un référentiel de l’état de l’art, soit utiliser et construire une trame interne personnalisée. Comme nous venons de voir, regardez maintenant comment choisir un référentiel de l’état de l’art. Il faut veiller à quelques critères de choix. D’abord, le référentiel doit contenir des mesures suffisamment directives et opérationnelles. Et ces mesures doivent être assez fines et moins sujettes à interprétation. À ce titre, je conseille d’éviter autant que possible l’annexion à ISO 27001 ou au CISF. Pourquoi ? Parce que ces deux référentiels contiennent des mesures assez vagues et qui nécessitent beaucoup d’interprétations, ce qui peut rendre l’exercice assez complexe.

Autre critère, il faut veiller autant que possible à utiliser un référentiel adapté à la typologie du système d’information. Par exemple, si j’ai un SI industriel, je dois me tourner vers un référentiel adapté. Même chose si j’ai une implication dans l’administration. Faut aussi veiller à utiliser un référentiel avec une taille raisonnable, juste pour des aspects pratiques et pour éviter de passer trop de temps là-dessus. Voilà, ça doit être exhaustif. Voilà quelques exemples de référentiels que je trouve adaptés pour un socle de sécurité : le guide d’hygiène de l’informatique de l’ANSSI, les 6 axes contre 11 ou pour les SI industriels, le référentiel de l’ANSSI Cybersécurité des systèmes industriels.

Ok, maintenant que j’ai choisi mon référentiel qui va servir comme base pour mon socle de sécurité, une question qui se pose : est-ce que je suis dans l’obligation de retenir l’intégralité des mesures de ce référentiel dans mon socle ? La réponse est non. Faut pas oublier, on est bien dans le cas 2, dans lequel il n’existe pas de référentiel obligatoire. Le référentiel de l’état de l’art que nous avons choisi sert plutôt de fil conducteur au catalogue, dans lequel on viendra puiser des mesures à décliner pour notre système d’information. C’est pour ça qu’il ne devient pas obligatoire. Maintenant, alors selon quels critères on va retenir ou ne pas retenir des mesures de ce référentiel ? La réponse : on va retenir les mesures évidentes, celles qui ne font pas débat, en lien avec l’objectif de la définition du socle de sécurité. Il sera constitué de mesures dont la nécessité est évidente et qui ne nécessite pas d’être justifiée par des risques.

Troisième point : il ne faut pas être borné par le référentiel qu’on a choisi. On peut aller plus loin et ajouter au socle des mesures qui ne sont pas dans ce référentiel, du moment qu’on juge qu’elles sont évidentes pour le contexte du projet en question. Voyons cela de manière plus concrète dans le mode opératoire. Nous avons dit que l’étape 2 consiste à réaliser un audit de sécurité qui conduit à l’identification de mesures en place et à des recommandations de mesures à mettre en place. Les mesures en place et les mesures à mettre en place constituent notre socle de sécurité.

Ici, une précision à apporter : on ne va pas retenir toutes les préconisations de l’audit, mais plutôt celles qui ne font pas débat. Concrètement, nous allons mettre tous les acteurs autour de la table, on déroule les recommandations une par une. Si une recommandation ne fait pas de bruit et est en accord avec le socle de sécurité, on la retient. Par contre, si elle génère des questions, par exemple, « C’est complexe, est-ce vraiment nécessaire ? Quel est le risque ? » alors ça passe dans l’approche par les risques.

Enfin, une pratique assez courante consiste à utiliser les mesures existantes comme socle de sécurité. Et nous allons voir si c’est une bonne pratique du choix du référentiel qui va servir comme base pour mon socle de sécurité. Nous allons distinguer deux cas qui concernent la deuxième couche constituée des mesures obligatoires. En effet, un cadre de conformité obligatoire peut exister, comme il peut ne pas exister. Regardons dans un premier temps le cas où un référentiel obligatoire existe.

D’abord, qu’est-ce qu’un référentiel obligatoire ? Celui-ci peut être une obligation légale ou réglementaire, une norme certifiante, une obligation contractuelle, ou même une politique interne applicable en transversal à mon organisme et qui devient une obligation pour mon périmètre. Ok, maintenant, j’ai un référentiel obligatoire qui existe. Est-ce que je dois l’utiliser systématiquement comme base pour mon socle de sécurité ? Pas forcément le cas, et nous allons voir cela dans un arbre de décision. Première question qu’il convient de se poser : est-ce que ce référentiel contient des mesures concrètes et opérationnelles ? Par exemple, c’est le cas pour la LPM ou la directive NIS qui parlent d’authentification, de cloisonnement, de filtrage, etc. Contrairement aux RGPD, par exemple, qui sont plutôt pour la partie cyber des principes généraux.

Dans ce deuxième cas, le référentiel en question n’est pas utilisable comme base pour le socle de sécurité, mais sera considéré dans l’étude. Il sera considéré dans la définition des objectifs et aussi dans la définition et la qualification des impacts associés au risque. Donc, si mon référentiel ne comprend pas de mesures concrètes et opérationnelles, je passe au cas 2. Comme si je n’ai pas de référentiel obligatoire qui existe, et nous allons voir cela plus tard. Ok, maintenant, j’ai un référentiel obligatoire avec des mesures concrètes et opérationnelles. Deuxième question qu’il convient de se poser : est-ce que ce référentiel est exhaustif par rapport à l’état de l’art ?

Entre parenthèses, par exemple, on sait que la LPM ne couvre pas certaines thématiques d’état de l’art. Ça ne parle pas explicitement de la sécurité des communications, ni de sécurité physique, ni des sauvegardes, etc. Dans ce cas-là, il convient de compléter par un référentiel de l’état de l’art. Si, par contre, j’ai un référentiel que je considère comme exhaustif par rapport à l’état de l’art, je peux l’utiliser tel quel. Regardons maintenant le cas que j’ai appelé ici « qu’à 1 bis » ou pas de référentiel obligatoire qui existe, mais plusieurs cas, c’est fréquent.

Regardons quelques cas d’usage. Je peux avoir un même système auquel s’appliquent plusieurs obligations, suffit juste d’avoir d’un côté une politique interne à mon organisme, et de l’autre côté une réglementation qui s’applique spécifiquement à mon périmètre. Je peux aussi avoir un système auquel s’appliquent multiples réglementations. C’est aussi le cas. Donc, quand on souhaite créer un modèle de socle de sécurité uniforme qui sera utilisable dans plusieurs projets différents et dans différents contextes réglementaires et normatifs, c’est par exemple le cas pour des projets internes de gros groupes ou des cabinets de conseil pour leurs projets clients. Ici, j’ai deux solutions.

Une première solution consiste à choisir parmi ces référentiels obligatoires celui qui est le plus complet, et puis établir des correspondances entre ce référentiel et les autres. On peut aussi le compléter si nécessaire. Deuxième solution, qui est ma préférée et que j’ai longuement pratiquée, c’est de créer une trame interne personnalisée. Et après, on vient établir des correspondances entre cette trame et les référentiels applicables. Cette solution présente l’avantage de donner plus de liberté. Je peux adapter la granularité que je souhaite, la structure que je souhaite. Et aussi, cette trame évolue et je peux ainsi l’enrichir sans être lié à un référentiel.

Regardons maintenant le deuxième cas où il n’existe pas de référentiel obligatoire. Deux solutions se présentent : soit choisir et utiliser un référentiel de l’état de l’art, soit utiliser et construire une trame interne personnalisée. Comme nous venons de voir, regardez maintenant comment choisir un référentiel de l’état

de l’art. Il faut veiller à quelques critères de choix. D’abord, le référentiel doit contenir des mesures suffisamment directes et opérationnelles. Ces mesures doivent être suffisamment détaillées et moins sujettes à interprétation. À ce titre, je conseille d’éviter autant que possible l’annexe à l’ISO 27001 ou le NIST CSF, pourquoi ? Parce que ces deux référentiels contiennent des mesures assez génériques et qui nécessitent beaucoup d’interprétations, ce qui peut rendre l’exercice assez complexe.

Un autre critère important est de choisir un référentiel adapté à la typologie du système d’information. Par exemple, si j’ai un SI industriel, je devrais me tourner vers un référentiel adapté à ce contexte. De même, si j’ai un SI impliquant des données sensibles, ou un SI industriel d’administration, je devrais également veiller à utiliser un référentiel approprié.

Enfin, il est important de choisir un référentiel de taille raisonnable pour des raisons pratiques, afin d’éviter de passer trop de temps sur cette étape. Il faut éviter d’utiliser un référentiel qui serait trop volumineux pour être géré efficacement.

Voilà quelques exemples de référentiels que je trouve adaptés pour un socle de sécurité : le guide d’hygiène de l’informatique de l’ANSSI, le CIS de l’ANSSI, ou pour les SI industriels, le référentiel de l’ANSSI « Cybersécurité des systèmes industriels ».

Maintenant que j’ai choisi mon référentiel qui servira de base pour mon socle de sécurité, une question se pose : suis-je dans l’obligation de retenir l’intégralité des mesures de ce référentiel dans mon socle de sécurité ? La réponse est non. Comme nous l’avons vu, nous sommes dans le cas où il n’existe pas de référentiel obligatoire. Le référentiel de l’état de l’art que nous avons choisi sert plutôt de fil conducteur au catalogue, dans lequel nous viendrons puiser des mesures à décliner pour notre système d’information. Il ne devient donc pas obligatoire.

Maintenant, selon quels critères allons-nous retenir ou ne pas retenir des mesures de ce référentiel ? La réponse est que nous allons retenir les mesures évidentes, celles qui ne font pas débat, en lien avec l’objectif de la définition du socle de sécurité. Il sera constitué de mesures dont la nécessité est évidente et qui ne nécessite pas d’être justifiée par des risques.

Troisième point : il ne faut pas être borné par le référentiel que nous avons choisi. Nous pouvons aller plus loin et ajouter au socle des mesures qui ne sont pas dans ce référentiel, du moment que nous jugeons qu’elles sont évidentes pour le contexte du projet en question.

Voilà, c’est tout pour cet épisode. J’espère qu’il vous a été utile. Je vous donne rendez-vous au prochain épisode. À bientôt.

✅ “EBIOS-RM dans la pratique” est une série qui a pour objectif de partager une longue expérience terrain avec la méthode EBIOS (2010 et Risk Manager)

✅ Un résumé de la méthode EBIOS Risk Manager est disponible dans cet article.

✅  L’intégralité des articles de la série est disponible par 👉 ici

✅ Si souhaitez vous former à EBIOS RM, nous proposons une formation pour apprendre la méthode par la pratique, 👉 Cliquer ici pour en savoir plus. Formation Certifiante éligible aux financements publics CPF, OPCO.

Avez-vous trouvé cet article utile?