Les méthodes et le cadre global de la sécurité numérique ont peu évolué depuis 15 ans (ISO 2700x, EBIOS, MEHARI, …). De fait elles sont bien connues et cohérentes. Là où le bât blesse, c’est dans leur application. Que ce soit au niveau global du Système de Management de la Sécurité de l’Information (SMSI) ou de la sécurisation d’un actif informationnel (une application métier par exemple), la base de toutes les méthodes de sécurisation est une analyse de risques. On retrouve donc les difficultés inhérentes à la gestion des risques, que ce soit dans le cadre du pilotage d’un projet, ou de l’AMDEC d’un produit ou d’un processus industriel. La seule façon de faire une analyse de risques pertinente c’est de la faire en collaboratif avec des sachants (et notamment opérationnels de terrain) éventuellement avec une pointe d’expertise (à petite dose), et éventuellement avec le support d’une base de données capitalisant sur des risques ou facteurs de risques similaires. Un travail approfondi sur les activités métiers (procédures et enjeux) est nécessaire pour mener correctement cette analyse.
Hâtez-vous lentement, et sans perdre courage,
Vingt fois sur le métier remettez votre ouvrage,
Polissez-le sans cesse, et le repolissez,
Ajoutez quelquefois, et souvent effacez.Nicolas Boileau (1636-1711) – l’Art poétique
Non, toi non plus, tu n’as pas changé… (Julio Iglesias)
Je ne suis pas un spécialiste des sujets de sécurité numérique, mais ces problématiques sont souvent présentes ici ou là à la périphérie de mes missions de conseil en transformation. J’avais même réalisé pour une administration française, il y a 16 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é) à l’époque – en 2021 on parle de DICP (le T de Traçabilité s’est transformé en P pour Preuve) pour vous montrer que ça n’a pas fondamentalement changé. 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 16 ans mes clients de l’époque sont 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.
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 DICP) et hop on ressort avec une évaluation 4, 4, 4, 4 sur les axes DICP. 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
Mes recommandations :
- 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 ».
- 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.
- 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 !)
