Le management de la sécurité de l’information : Analyse critique.

1. Les systèmes de management

L’Organisation internationale de normalisation, ou International organization for standardization en anglais (ISO pour la forme abrégée) est une organisation internationale, créée en 1947, composée de représentants des organismes de normalisation nationaux d’environ 150 pays, qui produit des normes internationales dans des domaines industriels et commerciaux.

L’ISO a entrepris d’encadrer par des normes les systèmes de management, et pour ce faire a commencé par en donner une définition, qui fait l’objet de la norme IS (pour International Standard) 9000 ; un système de management est un système qui permet :

 d’établir une politique ;
 de fixer des objectifs ;
 de vérifier que l’on a atteint les objectifs fixés.

Plus concrètement, un système de management comporte un ensemble de mesures organisationnelles et techniques destinées à mettre en place un certain contexte organisationnel et à en assurer la pérennité et l’amélioration. L’idée cruciale au coeur de cette problématique est que le système de management repose sur un référentiel écrit, et qu’il est donc vérifiable, au moyen d’un audit qui consistera à comparer le référentiel à la réalité pour relever les divergences, nommées écarts ou non-conformités.

Il existe actuellement (en 2006) trois normes relatives aux systèmes de management :

 la norme IS 9001 consacrée aux systèmes de management de la qualité et aux exigences associées ;
 la norme IS 14001 consacrée aux systèmes de management de l’environnement ;
 la norme IS 27001 consacrée aux systèmes de management de la sécurité de l’information ; c’est cette dernière qui nous intéressera plus particulièrement ici.

Pour couronner cet édifice remarquable, la norme IS 19001 formule les directives à respecter pour la conduite de l’audit d’un système de management.

2. Le système de management de la sécurité de l'information

La norme IS 27001 est destinée à s’appliquer à un système de management de la sécurité de l’information (SMSI) ; elle comporte notamment un schéma de certification susceptible d’être appliqué au SMSI au moyen d’un audit.

Comme toutes les normes relatives aux systèmes de management, IS 27001 repose sur une approche par processus, et plus précisément sur le modèle de processus formulé par W.E. Deming, du MIT, et nommé roue de Deming, ou PDCA, comme Plan, Do, Check, Act, ou en français normalisé et donc obligatoire PAVC comme Planification, Action, Vérification, Correction :

 phase Planification : définir le champ du SMSI, identifier et évaluer les risques, produire le document (Statement of applicability, SOA) qui énumère les mesures de sécurité à appliquer ;
 phase Action : affecter les ressources nécessaires, rédiger la documentation, former le personnel, appliquer les mesures décidées, identifier les risques résiduels ;
 phase Contrôle : audit et revue périodiques du SMSI, qui produisent des constats et permettent d’imaginer des corrections et des améliorations ;
 phase Correction : prendre les mesures qui permettent de réaliser les corrections et les améliorations dont l’opportunité a été mise en lumière par la phaseContrôle, préparer une nouvelle itération de la phase Planification.

Le SMSI a pour but de maintenir et d’améliorer la position de l’organisme qui le met en oeuvre du point de vue, selon les cas, de la compétitivité, de la profitabilité, de la conformité aux lois et aux règlements, et de l’image de marque. Pour cela il doit contribuer à protéger les actifs (assets) de l’organisme, définis au sens large comme tout ce qui compte pour lui.

Pour déterminer les mesures de sécurité dont la phase Plan devra fournir une énumération, la norme IS 27001 s’appuie sur le catalogue de mesures et de bonnes pratiques proposé par la norme IS 27002 (ex-17799), « International Security Standard », plus volumineuse et au contenu plus technique.

IS 27001 impose une analyse des risques, mais ne propose aucune méthode pour la réaliser : l’auteur du SMSI est libre de choisir la méthode qui lui convient, à condition qu’elle soit documentée et qu’elle garantisse que les évaluations réalisées avec son aide produisent des résultats comparables et reproductibles. Un risque peut être accepté, transféré à un tiers (assurance, prestataire), ou réduit à un niveau accepté.

Un exemple de méthode d’analyse de risque utilisable dans le cadre d’IS 27001 est la méthode EBIOS® (Expression des Besoins et Identification des Objectifs de Sécurité), qui « permet d’apprécier et de traiter les risques relatifs à la sécurité des systèmes d’information (SSI). Elle permet aussi de communiquer à leur sujet au sein de l’organisme et vis-à-vis de ses partenaires afin de contribuer au processus de gestion des risques SSI. »

L’ISO prépare une norme d’analyse de risque, IS 27005. Pour un inventaire commenté de toutes ces normes on se reportera avec profit à la présentation qu’en a faite Hervé Schauer.

Élaboration et mise en place du SMSI

La norme IS 27001 précise la démarche qui doit être suivie pour élaborer et mettre en place le SMSI : sans entrer trop dans les détails, ce qui risquerait d’enfreindre les droits des organismes de normalisation qui vendent fort cher les textes des normes, disons que l’organisme désireux de se voir certifier devra :

 définir le champ du SMSI ;
 en formuler la politique de management ;
 préciser la méthode d’analyse de risques utilisée ;
 identifier, analyser et évaluer les risques ;
 déterminer les traitements qui seront appliqués aux différents risques, ainsi que les moyens d’en vérifier les effets ;
 attester l’engagement de la direction de l’organisme dans la démarche du SMSI ;
 rédiger le Statement of Applicability (SOA) qui sera la charte du SMSI et qui permettra de le soumettre à un audit.

Suivi et application du SMSI

Ici la norme précise que, une fois que le SMSI a été formulé, il faut faire ce qu’il stipule, vérifier que c’est fait, identifier les erreurs dans son application, les failles qui s’y manifestent, les modifications du contexte de nature à nécessiter sa mise à jour ou sa modification.

Tâches de direction et d’encadrement

À la direction de l’organisme, dont il a déjà été dit qu’elle devait s’engager activement dans la démarche, incombent d’autres obligations : vérifier que tout est bien fait selon les règles, affecter à la démarche du SMSI des ressources suffisantes en personnel et en moyens matériels, déterminer les besoins qui en résultent en termes de compétence et de formation, fournir les efforts qui conviennent en termes de sensibilisation et de formation, effectuer le contrôle des effets de ces efforts. Il faut aussi organiser des revues et des exercices, etc., tout cela afin d’assurer l’amélioration continue du SMSI. Cette vision idyllique d’un univers en marche vers le Bien, le Beau, le Juste ne saurait manquer de soulever l’enthousiasme du lecteur !

Un modèle de maturité ?

La norme ISO/IEC 21827 propose un « Modèle de maturité de capacité » : qui peut traduire ce jargon invraissemblable ?

3. Critères communs

Les Critères Communs (norme ISO/IEC 15408) sont étrangers ou plutôt parallèles à la démarche IS 27001 ; ils se proposent de servir de base pour l’évaluation des propriétés de sécurité des produits et des systèmes de traitement de l’information.

4. Faut-il adhérer aux normes de sécurité de l'information ?

L’auteur de ces lignes n’est pas entièrement convaincu du caractère souverain de ces remèdes à l’insécurité que sont les normes évoquées à la section précédente ; ces méthodes sont d’une grande lourdeur, leur seul apprentissage est d’une ampleur propre à absorber une énergie considérable, or une fois que l’on connaît par coeur les critères communs et que l’on sait appliquer EBIOS les pieds au mur, on n’a pas mis en place une seule mesure concrète de SSI, on est seulement capable, en principe, d’évaluer les mesures que d’autres auront éventuellement mises en place.

Ce qui frappe le lecteur, c’est que la vérification formelle de conformité à ces normes peut presque être effectuée par un auditeur dépourvu de compétence technique : il suffit de lire les documents obligatoires et de vérifier que les mesures mentionnées ont bien été appliquées, ce qui doit être écrit dans un autre document. On pourrait presque imaginer un audit par ordinateur : il serait sans doute mauvais, mais formellement conforme. Reste à écrire le compilateur de normes et le compilateur de SOA. Évidemment, pour réaliser un bon audit, l’intuition de l’auditeur, nourrie par son expérience, jouera un rôle important. Certains collègues dont je tairai les noms de crainte de leur attirer des ennuis vont jusqu’à dire que l’adoption d’une démarche telle que celle proposée par IS 27001 ou IS 21827 est nuisible, elle empêcherait les gens de penser correctement, de se poser les bonnes questions. Si j’osais je serais d’accord avec eux, mais je suis trop respectueux des normes et des autorités pour cela. En fait, les auteurs de ces normes semblent croire que l’univers peut être décrit de façon adéquate par un tableau de cases à cocher, analogue à un questionnaire à choix multiples : on se demande pourquoi les grands nigauds nommés Aristote, Descartes, Newton, Kant et Einstein n’y ont pas pensé, ils auraient épargné bien de la fatigue cérébrale à eux-mêmes et aux étudiants des siècles suivants !

Cela dit il ne convient pas d’ignorer que dans les grandes structures bureaucratisées ce type de démarche est devenu à peu près inévitable, un peu comme ISO 9001. Les procédures destinées à évaluer des travaux techniques deviennent une charge de travail plus lourde que ce qu’elles servent à évaluer, les procédures de gestion demandent plus de travail que les activités qu’elles servent à gérer, bref ce qui devrait être une aide pour l’action devient un fardeau, de surcroît ennuyeux.

Pour résumer cette analyse en une formule : toutes ces normes et ces procédures n’ont qu’une finalié : permettre à des incompétents de diriger.

Un autre défaut de ces procédures d’évaluation, c’est qu’elles ne sont pas uniquement construites en fonction des buts à atteindre, mais aussi, sinon surtout, en fonction de ce qui, dans les processus étudiés, se prête bien à l’évaluation, parce que par exemple il est facile d’y adapter une métrique. Conformément au proverbe, pour celui qui ne dispose que d’un marteau, tout ressemble à un clou, et les normalisateurs de la sécurité n’ont pas toujours échappé à ce travers.

Le RSSI qui aura pu échapper à la lourdeur de ces carcans normalisés aura à coeur d’élaborer une politique et des règles de sécurité raisonnables, sobres, les plus simples possible, et adaptées à la situation locale. Le présent ouvrage se veut un guide pour rédiger une politique de sécurité. Le lecteur pourra aussi se reporter avec profit au livre bénéfiquement concis de Scott Barman.

De toutes les façons il faut savoir que des règles de sécurité complexes seront simplement inappliquées, parce que trop difficiles à comprendre. La simple lecture des critères communs et des manuels EBIOS représente des milliers de pages : autant dire que leur étude détaillée est antinomique de toute politique réelle de sécurité. Leur fonction principale ne serait-elle pas de donner du travail aux cabinets de consultants spécialisés, à condition que leur clientèle soit (très) solvable ?

5. La sécurité procédurale n'est pas la solution

Nous terminerons ce tour d’horizon des normes de sécurité basées sur des procédures administratives en faisant appel aux travaux de Jean-Pierre Dupuy, dont les analyses jettent une lumière vive aussi bien sur toutes ces normes relatives aux systèmes de management que sur la mode récente du principe de précaution.

Pour décrire ces systèmes de pensée, Dupuy introduit la notion de « rationalité procédurale », qui procéderait de réunions de comités d’experts, éventuellement à l’écoute de la société civile, et qui serait la forme consensuelle de la démocratie contemporaine. Ce modèle peut facilement être transposé à la gestion des entreprises, notamment par les méthodes de conduite de projet. « Dire que la rationalité est procédurale, c’est dire qu’une fois l’accord réalisé sur les justes et bonnes procédures, ce qu’elles produiront sera ipso facto, par propriété héritée en quelque sorte, juste et bon. C’est donc renoncer à chercher, indépendamment de et antérieurement à toute procédure, les critères du juste et du bien... » [nous pourrions ajouter : du vrai].

Les normes de systèmes de management (IS 9001 pour le management de la qualité, 14001 pour l’environnement, 27001 pour la sécurité de l’information) sont des outils à produire de la rationalité procédurale. Les normalisateurs eux-mêmes le revendiquent : disposer d’une organisation certifiée IS 9001 ne prouve en rien que l’organisation soit d’une qualité supérieure, cela signifie uniquement que les règles de fonctionnement de cette organisation sont documentées conformément à la norme (qui impose des règles dans certains domaines précis), et que des procédures existent pour vérifier que les règles sont appliquées, mais l’objet de ces procédures n’est en aucun cas de chercher à savoir si les décisions qui ont engendré ces règles étaient judicieuses. On peut dire la même chose des normes IS 14001 et 27001, chacune dans son domaine.

Pour continuer avec Dupuy : « La rationalité procédurale a du bon, sauf lorsqu’elle se construit au prix du renoncement à toute rationalité substantielle. » La sociologie des entreprises et l’évolution des rapports de pouvoir au sein des organisations techniques telles que les directions des systèmes d’information des entreprises, que j’ai décrites dans un ouvrage précédent, donnent à penser que c’est bien au renoncement à toute rationalité substantielle que conduisent les normes de système de management IS 9001 et IS 27001. En effet, pour un dirigeant paresseux, la grande supériorité de la rationalité procédurale sur sa cousine substantielle, c’est qu’elle dispense de toute compétence sur son objet, et surtout de toute compétence technique, ce qui dans notre beau pays est une vertu cardinale, tant la compétence technique y est méprisée. Grâce aux systèmes de management, de simples cadres administratifs pourront exercer le pouvoir sur des ingénieurs compétents, puisqu’il leur suffira pour cela de cocher dans un tableur les cases qui correspondent aux étapes des procédures, et de prendre en défaut les acteurs opérationnels qui n’auront pas rempli toutes les cases, cependant qu’eux-mêmes ne seront bien sûr jamais exposés à telle mésaventure. Une caractéristique aussi attrayante rend inévitable le triomphe de ces normes, d’autant plus que la lourdeur des opérations de constitution des feuilles de tableur et de cochage des cases (il existe aussi un marché lucratif de logiciels spécialisés) permettra le développement numérique de la caste administrative et le renforcement de son hégémonie, sans oublier l’essor des cabinets spécialisés qui pourront vendre à prix d’or la mise en place de ces systèmes, puis la rédaction de rapports vides de tout contenu « substantiel ».

Il peut sembler hasardeux de formuler un jugement aussi négatif sur les méthodes désormais classiques de conduite de projet et sur les normes de système de management : si pratiquement tous les directeurs de système d’information les adoptent, c’est qu’il doit y avoir de bonnes raisons à cela, qu’ils doivent constater les avantages qui en résultent. La réponse tient en trois points :

 Le succès de ces méthodes de management et des normes qui les accompagnent n’est pas uniforme à l’échelle internationale, par exemple l’engouement pour IS 9001 semble bien être une spécificité française.
 Les dirigeants qui adoptent des méthodes administratives de management des activités techniques en tirent des avantages, ceux que j’ai décrits ci-dessus, notamment en termes de renforcement du pouvoir administratif et de diminution des exigences en termes de compétence.
 Jean-Pierre Dupuy (p. 70) a emprunté à Friedrich von Hayek une théorie qui est de plus en plus utilisée par les économistes, et qui étudie les phénomènes d’imitation au sein de l’économie de marché. Alors que l’économie néo-classique se représente un homo oeconomicus autosuffisant et indépendant, parfaitement informé et rationnel dans des choix censés le mener à un optimum qui, à l’échelle du marché, produirait un équilibre, Hayek met en évidence, après Adam Smith et Keynes, le rôle central de l’imitation dans les phénomènes collectifs dont le marché est le cadre. Le rôle de l’imitation semble particulièrement important dans les situations de choix entre techniques rivales, et aucun mécanisme ne garantit que la technique qui va l’emporter sera la meilleure. En effet, dans le jeu de miroirs qui précède l’engouement mimétique, une simple rumeur peut orienter quelques acteurs vers la cible, ce qui déclenchera un effet d’avalanche : « [l'imitation généralisée] suscite des dynamiques auto-renforçantes qui convergent si résolument vers leur cible qu’il est difficile de croire que cette convergence n’est pas la manifestation d’une nécessité sous-jacente... ». Nous ne saurions écarter l’hypothèse que le succès universel des méthodes de gestion de projet pourrait résulter d’un phénomène mimétique de ce type : dit en d’autres termes, pour citer un proverbe du réseau, « 100 000 lemmings ne peuvent pas avoir tort ».

De ce qui précède peut-on déduire qu’il faut forcément être ingénieur informaticien pour devenir directeur du système d’information ? Non, mais un DSI (et d’ailleurs tout dirigeant) devra posséder, pour remplir ses fonctions, un certain nombre de compétences, et il ne pourra pas faire face aux problèmes qui se posent à lui avec des procédures administratives normalisées. Le rôle de l’informatique dans le monde contemporain est tel que nul ne peut plus se passer d’en connaître les techniques de base.

Dans le contexte français où l’absence de compétence technique est devenue un atout déterminant pour l’accès aux postes de direction des systèmes d’information, les méthodes de management de système selon les normes IS 9001 et IS 27001 acquièrent la propriété de prédictions autoréalisatrices : pour les raisons évoquées ci-dessus de nombreux DSI ont d’ores et déjà emprunté cette démarche, et leurs collègues en retard, qui n’ont pour boussole dans cet univers que l’air du temps et le qu’en dira-t-on, trouveront facilement auprès de leurs pairs la confirmation que c’est bien dans cette voie qu’il faut aller. Les sommes considérables englouties par ces méthodes n’apparaissent pas forcément comme des inconvénients, puisqu’elles renforcent l’importance et le prestige de celui qui les ordonne, et donnent satisfaction à la direction générale, qui dispose en général de fort peu de moyens pour se former une opinion sur le sujet.

Quant à nous, nous nous efforcerons au cours des chapitres suivants de dispenser les principes de sécurité substantielle qui nous semblent le socle de ce que doit être aujourd’hui un système sûr, et que plus grand monde ne peut se permettre d’ignorer totalement, que ce soit dans l’entreprise ou dans l’usage privé des ordinateurs et des réseaux.

 source : Laurent Bloch et Christophe Wolfhugel Sécurité informatique, principes et méthode, Éditions Eyrolles  disoinible sur http://www.laurentbloch.org

                                                                                             acceuil