Il y a de cela quelques années (15 ans tout au plus), la sécurité des systèmes d’information reposait essentiellement sur des solutions techniques, déployées sur les couches d’infrastructures, plateformes hardware ou middleware. Souvent réservée aux grandes entreprises, car pour garantir un bon niveau de sécurité, il fallait bénéficier d’un budget conséquent, et assez loin des services DSI (qui n’existaient peut-être pas encore au profit des services informatiques). Désormais, la sécurité ne doit plus seulement reposer sur l’exploitation et l’usage d’équipements et d’outils techniques qui génèrent de nombreuses informations, mais doit s’appuyer sur tout un écosystème bien défini et organisé, appelé le Système de Management de la Sécurité de l’Information (SMSI) dans l’ISO 27k1. La sécurité est donc l’affaire de tous et doit être prise en considération dès lors qu’il est fait usage de l’informatique ou de tout média support d’informations, que ce soit pour une administration, une entreprise ou même une association. Evidemment, les enjeux sont très différents et la gestion de la sécurité sera menée en adéquation avec cette dimension.

La toute première action pour engager un SMSI, est de définir un cadre général de la sécurité des SI ; cela passe donc par l’élaboration de la Politique de Sécurité des Systèmes d’Information dont je vais vous parler dans ce point de vue.

Ce que nous enseigne les normes et les bonnes pratiques sur la sécurisation des systèmes d’information aujourd’hui, c’est qu’il faut s’inscrire dans une démarche d’amélioration PDCA. C’est le cas de l’ISO et dernièrement de la version mise à jour d’Ebios RM (2018) qui fixe là aussi un processus basé sur l’itération des étapes, telle une roue de Deming.

Comment tout cela se construit-il à partir de ces principes ? De quoi vais-je partir ? Comment cela fonctionne-t-il et vers où dois-je aller ?

Le point de départ sera la Politique de Sécurité des Systèmes d’Information qui permet de formaliser le cadre et de fixer le schéma directeur que doit suivre l’organisation pour atteindre les objectifs tels qu’une PSSI initiée et poussée par la direction générale et des exigences théoriques techniquement réalisables. Ce cadre sécuritaire fait référence à des politiques et des directives détaillées. La PSSI tient compte des contraintes métiers. Il s’agit d’un référentiel déterminant pour les chantiers et projets de sécurité à mener. Son contenu doit traduire les valeurs de l’entreprise. Une PSSI de Groupe communique les valeurs et les axes stratégiques de l’entreprise vers les entités qui elles-mêmes déclineront leur propre PSSI locale.

L’intérêt de rédiger la PSSI d’entreprise

A tous niveaux hiérarchiques et quelles que soient les responsabilités que l’on nous confie, chacun d’entre nous, au sein d’une petite organisation ou d’une grande entreprise, pense et agit selon les situations dans lesquelles il se trouve. Nos idées et notre interprétation de la sécurité divergent parfois et malgré un comportement responsable et de bon sens, il est possible d’aller à l’encontre des objectifs fixés par la direction.

Sans politique clairement définie, chacun est donc libre d’apprécier et d’exécuter des activités liées à la sécurité de l’information comme il l’a décidé. Il peut par exemple, gérer un projet sans tenir compte de la sécurité, considérant qu’il n’y a aucun risque en phase projet, utiliser le poste informatique de l’entreprise pour des activités personnelles, utiliser un espace de partage privé pour y stocker des informations professionnelles afin d’y avoir accès en télétravail ou les partager avec des partenaires… autant d’exemples à citer. Bref, il faut comprendre que la politique de sécurité du système d’information permet à la direction de communiquer sur des exigences de sécurité définies pour tous et applicables par tous.

Engager la rédaction de la PSSI d’entreprise

Avant d’élaborer la PSSI d’entreprise, il faut au préalable recueillir les enjeux de l’organisation auprès de la direction, identifier et cadrer les besoins de sécurité avec les métiers, définir une organisation pour gérer la sécurité du système d’information et enfin évaluer puis apprécier les risques auxquels est exposé le système d’information de l’entreprise. Il en découle 3 catégories de risques qui sont des mesures et des directives stratégiques, techniques et opérationnelles. Ce sont les risques dits « génériques » auxquels nous sommes tous exposés, les risques réglementaires, propres à l’organisation et aux réglementations dont elle dépend et les risques spécifiques, évalués en fonction des enjeux de l’organisation et des besoins de sécurité des métiers. Il faut aussi définir des objectifs de sécurité réalisables à atteindre à court et moyen termes et évaluer l’échéance d’applicabilité de cette politique et la période de révision.

Plusieurs méthodes permettent d’engager les travaux afin d’apporter ces sources d’informations. Les plus simples et les plus efficaces sont :

  • Un audit global du SI : basé si possible sur un référentiel officiel (ISO, COBIT, CIS, NIST, RGS…), il rend visible les écarts de sécurité entre l’existant et les bonnes pratiques,
  • Un audit de l’organisation : cet état des lieux de l’organisation est essentiel. Il donne une vue synthétique de l’organisation actuelle et sera probablement remis en cause lors de la définition des éléments qui composeront la gouvernance de la sécurité, notamment quant à la définition des rôles et des responsabilités des parties prenantes, là ’identification des instances de gouvernance (comités, réunions, revues…) et à l’estimation des ressources nécessaires pour construire et maintenir le système de management.
  • Une analyse de risque du SI : idéalement basée sur une méthodologie officielle (Mehari, ISO, Ebios…), cette opération fixe les besoins de sécurité, les scénarios de menaces des actifs et permet de lister les risques auxquels s’expose l’entreprise.

Les erreurs à éviter dans l’élaboration d’une PSSI

Lorsque nous intervenons dans le cadre de la rédaction ou de la révision de PSSI, nous rencontrons parfois quelques écueils liés à l’utilisation ou l’application de la politique. Voici quelques conseils pour les éviter :

  1. La PSSI reste un cadre sécuritaire général,
  2. Les activités ou procédures opérationnelles ne doivent pas apparaître dans une PSSI. On peut toutefois y faire référence (politiques spécifiques, directives, procédures techniques…),
  3. Une PSSI doit traduire les valeurs et les objectifs de l’entreprise ; elle ne doit pas se limiter à un simple copier/coller d’une PSSI d’entreprise voisine,
  4. Les contraintes métiers doivent être respectées. La politique doit être élaborée en collaboration avec les métiers pour ne pas mentionner des mesures qui bloqueraient leurs activités,
  5. S’agissant d’un document d’entreprise général, il est essentiel que la direction approuve son contenu,
  6. Une PSSI doit être auditable, les exigences pouvant alors constituer une matrice d’audit en vue d’assurer qu’elles ont été mises en œuvre,
  7. Une PSSI a vocation à évoluer dans le temps, selon les modifications informatiques, les changements des besoins métiers, le développement de l’entreprise – rachat, carve-out, plan de restructuration… Il faut donc réviser son contenu, périodiquement ou à chaque événement important.

Et après la PSSI ?

Après avoir élaboré et fait valider la PSSI par la Direction, il faut passer aux phases suivantes du PDCA, qui sont Do et Check afin de mettre en œuvre les règles applicables puis vérifier qu’elles ont bien été implémentées. Et ce, en suivant le cadre stratégique de la PSSI, au travers des instances et des indicateurs prévus à cette fin.

Pour passer à l’étape transitoire entre la PSSI validée et sa mise en œuvre, il est conseillé d’établir une cartographie permettant de suivre l’état d’avancement de la bonne application des exigences et des règles.

Rappelons aussi que toute PSSI est destinée à évoluer par une revue à fréquence régulière. Par conséquent, la toute première politique ne doit contenir que des règles dont la faisabilité reste possible, compte tenu des ressources à solliciter, des capacités fonctionnelles et opérationnelles et surtout des choix budgétaires et financiers. Si elle ne contient pas l’ensemble des règles qui couvrent la totalité des risques de l’organisation, elle doit a minima spécifier les règles qu’il est possible de mettre en œuvre lors de la première échéance de son existence. Elle sera ensuite enrichie au fil des années en vue d’aboutir à une couverture plus large et toujours évolutive avec les changements d’organisation, la transformation des normes et réglementations, de nouveaux besoins de sécurité des métiers, etc.

 

__________
Frédéric Renau est Risk & Conformity Dpt Manager chez I-TRACING