Cybersécurité en trompe l’œil – Les failles de la sécurité SI – Episode 1

La cybersécurité et les sujets de Sécurité des Systèmes d’Information ont pris de l’ampleur depuis 20 ans et ont maintenant acquis une importance majeure. Je n’en suis pas du tout un spécialiste. En revanche j’ai été confronté au cours des 5 dernières années à des décisions, des arbitrages, des comportements… pris ou justifiés sur l’autel de la Sécurité par des Responsables de la Sécurité des Systèmes d’Informations (RSSI). J’ai tiré de ces décisions et comportements quelques étonnements et je me permets, en observateur candide et béotien, de suggérer quelques recommandations de bon sens car c’est bien là l’avantage du non spécialiste : il ne peut faire jouer que son bon sens paysan.
Cet article sera un article à épisode :
  1. Episode 1) RSSI, intéressez vous au métier de votre entreprise ou de votre administration… et pas que pour cocher une case dans la méthodologie « tartempion »
  2. Episode 2) RSSI, ne cédez pas à la facilité… La sécurité est parfois un parapluie bien trop commode…
  3. Episode 3) Trop de sécurité tue la sécurité
  4. Episode 4) Est-il possible de concilier Sécurité SI dans un grand groupe avec Innovation et Croissance ?
Episode 1)

Non, toi non plus, tu n’as pas changé… (Julio Iglesias)

Je connais un peu le sujet de la Sécurité SI quand même. J’avais réalisé pour une administration française, il y a 12 ans maintenant, un audit sur des sujets de sécurité. J’avais mobilisé à l’époque le responsable Sécurité SI du groupe Capgemini. Et nous avions alors fait une sensibilisation à la sécurité des SI en utilisant les référentiels de l’époque (EBIOS, ISO 27000 et Mehari). Sensibilisation, en bon paysan breton, ça veut dire… raisonner sur des cas concrets. Nous avions donc réalisé un atelier de sensibilisation et fait plancher notre client sur ses risques métiers avant de plonger dans les délices de l’évaluation DICT (Disponibilité, Intégrité, Confidentialité, Traçabilité). Cette analyse de risque est fondamentale puisqu’elle permet au métier d’ajuster ses besoins de sécurité à ses risques… ni plus ni moins. A condition qu’elle soit bien faite et c’est là où le bât blesse souvent à mon avis.
Pendant de nombreuses années, je n’ai plus été confronté à ce sujet. Je voyais bien de loin en loin, chez mes clients, des RSSI qui organisaient des sessions de sensibilisation à la sécurité, qui s’amusaient avec les antivirus, les cryptages de disque dur, les filtres d’écran… mais cela n’interférait jamais avec mon quotidien de consultant en organisation.
Puis au fil de mes missions j’ai été amené à travailler dans des environnements sensibles ou réputés tels, et forcément à devoir interagir avec des RSSI.
M’étonnant du comportement et des décisions de certains je m’étais dit que les pratiques et référentiels de sécurité avaient considérablement évolués et que j’étais simplement devenu un vieux schnock. Je me replongeai alors dans le RGS (Référentiel Général de Sécurité) de l’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI) et découvrit avec surprise que non, les principes n’avaient pas changé… bien au contraire. Les principes que j’avais utilisés pour sensibiliser il y a 12 ans mes clients de l’époque étaient toujours en vigueur. Ci-dessous 3 extraits de 3 documents différents : le guide de l’homologation de sécurité, le référentiel général de sécurité, la méthode de gestion des risques EBIOS. Je me suis permis d’y surligner en gras les points qui me paraissent mal gérés par les pratiques de sécurité actuelles.

Des guides, référentiels et méthodes cohérents et pragmatiques… mais alors cherchez l’erreur ?

Extrait 1 : source : « Le guide l’Homologation de sécurité, en neuf étapes simples » de l’ANSSI

En informatique, comme dans les autres domaines, le risque zéro n’existe pas. (NDLR : c’est un rappel toujours utile)
L’objectif de la démarche d’homologation d’un système d’information (SI) est de trouver un équilibre entre le risque acceptable et les coûts de sécurisation, puis de faire arbitrer cet équilibre, de manière formelle, par un responsable qui a autorité pour le faire. 
Cette démarche permet d’améliorer la sécurité pour un coût optimal, en évitant la « sur-sécurité », mais en prenant également en compte le coût d’un éventuel incident de sécurité. Elle permet de s’assurer que les risques pesant sur le SI, dans son contexte d’utilisation, sont connus et maîtrisés de manière active, préventive et continue. 

(NDLR : en évitant la sur-sécurité : c’est écrit dessus comme le Port-salut, mais quels garde fous contre cette sur-sécurité ? après tout les RSSI sont des êtres humains comme les autres, et ils gèrent leur carrière bien avant le graal de « l’équilibre entre le risque acceptable et les coûts de sécurisation »)

Extrait 2 : source : « Référentiel Général de Sécurité V2.0 »

2.1 Analyse des risques
L’analyse de risques précise les besoins de sécurité du système d’information en fonction de la menace et des enjeux. La démarche d’analyse de risques consiste à identifier les évènements qui peuvent affecter la sécurité du système, d’en estimer les conséquences et les impacts potentiels puis de décider des actions à réaliser afin de réduire le risque à un niveau acceptable. Les menaces à prendre en compte sont celles qui pèsent réellement sur le système et sur les informations qu’il traite, transmet et stocke, dans l’environnement dans lequel il se situe.

Extrait 3 : source « Expression des Besoins et Identification des Objectifs de Sécurité (EBIOS) – Méthode de gestion des risques »

L’enjeu : atteindre ses objectifs sur la base de décisions rationnelles
Née dans le domaine financier dans les années 50 et étendue à de nombreux autres domaines tels
que la gestion de projet, la sécurité des personnes, la sûreté de fonctionnement, le marketing,
l’environnement ou encore la sécurité de l’information, la gestion des risques a toujours eu pour
objectif de rationaliser des situations pour aider à une prise de décision éclairée.
Les choix effectués par les décideurs peuvent ainsi être faits au regard des éléments fournis par les
risk managers. Et ces choix peuvent autant guider l’organisme vers l’atteinte de ses objectifs que faire
évoluer sa stratégie.
 
2.1 Comment EBIOS permet-elle de gérer les risques ?
L’établissement du contexte
Un contexte bien défini permet de gérer les risques de manière parfaitement appropriée, et ainsi de
réduire les coûts à ce qui est nécessaire et suffisant au regard de la réalité du sujet étudié.
 
Une démarche itérative en cinq modules
La méthode formalise une démarche de gestion des risques découpée en cinq modules représentés
sur la figure suivante :
La démarche est dite itérative. En effet, il sera fait plusieurs fois appel à chaque module afin d’en
améliorer progressivement le contenu, et la démarche globale sera également affinée et tenue à jour
de manière continue.

En synthèse de ces références de bonnes pratiques :

Tous les référentiels et méthodes professent donc les mêmes recommandations

  • effectuer une analyse de risque, contextualisée, basée sur des menaces réelles et l’évaluation des conséquences
  • dans l’objectif d’éviter la sur-sécurité
  • dans l’objectif d’arbitrer / équilibrer entre les coûts de la sécurisation / risque acceptable
  • se baser sur une démarche itérative

Bref... 3 trucs à retenir. C'est bête comme chou.

Bref… 3 trucs à retenir. C’est bête comme chou.

Et maintenant.. comment sont appliqués ces bonnes pratiques dans la « vraie vie » ?

Dans la réalité, ce que j’ai observé c’est que les référentiels et les méthodes sont utilisées comme un parapluie par la Sécurité SI pour dire « OK c’est bon, on l’a fait, on a respecté la méthode ». Mais sur le fond le travail n’est pas fait. Seule une apparence de démarche est respectée. Des responsables métiers qui ne comprennent pas la démarche et ses conséquences sont interviewés par des consultants qui ne comprennent pas le métier de leur client ou du client de leur client. L’analyse de risque n’est pas réalisée ou plus généralement est réduite à l’expression de menaces génériques (exemple : l’exploitation des failles du top ten Owasp) – OK c’est mieux que rien, mais on est parfois loin de menaces réelles (certes, ça peut, et d’ailleurs ça doit, se discuter) mais surtout il n’y a aucune évaluation des conséquences. En effet pour évaluer les conséquences il faudrait comprendre l’activité de leur client ! et pas superficiellement mais au contraire dans le détail. Sur ce que j’ai vu, on en est très loin et l’analyse des besoins est souvent réduite à la question « Je vous en mets combien ma bonne dame ? » c’est à dire je vous mets combien entre 1 et 4 sur l’échelle DICT) et hop on ressort avec une évaluation 4, 4, 4, 4 sur les axes DICT. Et on s’apprête à construire un système aussi sécurisé qu’une centrale nucléaire quand on avait juste besoin d’enregistrer des bons de commande dans un tableur.
Mais le RSSI est content : il est couvert, il peut donner l’impression d’avoir fait son métier. Il a appliqué la méthode recommandée par l’ANSSI, il est en phase avec le RGS. Et sur le fond il est content également, il n’est pas près d’être au chômage puisque les métiers ont validé des objectifs de sécurité maximaux, ils vont en baver les pauvres (la maîtrise d’œuvre SI aussi) mais ils ne le savent pas encore.
Heureusement EBIOS précise bien que la démarche est itérative… Sauf que dans la réalité, ça ne fonctionne pas comme ça. Dans une grande entreprise ou l’administration, vous ne trouverez aucun courageux pour dire qu’il souhaite revenir en arrière, qu’il n’avait pas compris les conséquences de son évaluation (même si en l’occurrence ce n’est pas lui qui est à blâmer, mais le RSSI ou le consultant qui a bêtement appliqué une méthode pourtant correcte dans l’esprit).
Encore une belle mission de sécurisation réussie

Encore une belle mission de sécurisation réussie

Mes recommandations :

  1. Faire une analyse de risques avec un tropisme métier fort : c’est à dire évaluer les conséquences et les probabilités d’occurrence des facteurs de risque correctement. Arrêtez d’appliquer la méthode bêtement sans comprendre, pour cocher les cases. Ça ne coûte pas plus cher d’appliquer la méthode intelligemment. On peut faire 10 fois moins d’interviews et avoir un résultat 10 fois meilleur simplement en ayant compris les finalités de ce que l’on fait. Mais pour les RSSI, la DSI ou ses consultants Sécurité, cela semble au-delà de leurs forces : pensez donc, il faut s’intéresser dans le détail au métier de leurs clients, voire pire il faut les écouter, voire pire encore il faut leur expliquer et leur faire comprendre ce qu’est un risque, un impact… bref faire de la pédagogie, challenger les évaluations de leurs clients et pour cela essayer de les comprendre, bref sortir de sa zone de confort et « aller à la mine ».
  2. Dès le démarrage et tout au long de l’étude des objectifs de sécurité, expliciter, même à grosse maille, les conséquences des objectifs de sécurité en terme financier (la sécurité ce n’est pas gratuit, ça peut même coûter très très cher), en terme d’usages pour les utilisateurs finaux (eh oui la sécurité ce n’est pas toujours transparent, et ça peut finir par avoir des conséquences très lourdes pour les utilisateurs), et en terme d’exploitabilité (eh oui pour les exploitants de la DSI ou les architectes techniques, cela peut également avoir de très lourdes conséquences en terme de compétences, d’expertise, de capacité à intervenir, de capacité à supporter les infrastructures techniques et applicatives) et on reboucle sur les conséquences économiques / financières de ces objectifs de sécurité. Cette nécessaire évaluation des conséquences sur les axes économiques, usages, exploitabilité n’est peut-être pas conforme à la beauté théorique de la méthode, mais il faut rester pragmatique. Il n’y a qu’en étant confronté aux conséquences de ses choix qu’on se pose vraiment les bonnes questions. Sinon tant qu’on joue à la roulette avec l’argent des autre… on continue à jouer.
  3. Rendre la démarche itérative cela revient à donner le droit à l’erreur. C’est compliqué dans les entreprises traditionnelles où erreur = sanction. Les conséquences sur la sécurité sont dramatiques : tout le monde sécurise tout, à commencer par sa carrière, et ne voudra jamais itérer (itérer ça veut dire qu’on a pas fait les choses parfaitement du premier coup : c’est mal !)

Prochains épisodes :

  1. Episode 2) RSSI, ne cédez pas à la facilité… La sécurité est parfois un parapluie bien trop commode…
  2. Episode 3) Trop de sécurité tue la sécurité
  3. Episode 4) Est-il possible de concilier Sécurité SI dans un grand groupe avec Innovation et Croissance ?

Eric Villesalmon

Associé fondateur d’ISlean consulting en 2008, Éric Villesalmon, 47 ans, possède une double formation d’Ingénieur de l’Ecole Supérieure d’Ingénieurs en Electrotechnique et Electronique et un MBA CAAE de l’IAE de Paris.Il est entré chez Bossard Consultants en 1996. Depuis lors il accompagne ses clients DSI et Directeurs Généraux dans le diagnostic et la mise en œuvre d’actions de progrès, de grande ampleur (ruptures ou réorganisation) ou du domaine de l’amélioration continue (Lean Six Sigma).Il a accompagné des grandes entreprises / ETI / PME dans leur transformation métier et de leur organisation SI, notamment la production informatique.


Eric Villesalmon

Associé fondateur d’ISlean consulting en 2008, Éric Villesalmon, 47 ans, possède une double formation d’Ingénieur de l’Ecole Supérieure d’Ingénieurs en Electrotechnique et Electronique et un MBA CAAE de l’IAE de Paris.Il est entré chez Bossard Consultants en 1996. Depuis lors il accompagne ses clients DSI et Directeurs Généraux dans le diagnostic et la mise en œuvre d’actions de progrès, de grande ampleur (ruptures ou réorganisation) ou du domaine de l’amélioration continue (Lean Six Sigma).Il a accompagné des grandes entreprises / ETI / PME dans leur transformation métier et de leur organisation SI, notamment la production informatique.

Leave A Comment