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)
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
Et maintenant.. comment sont appliqués ces bonnes pratiques dans la « vraie vie » ?
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 !)