Elaboration d'une PSSI au sein d'une unité propre du CNRS :
Utilisation de la méthode EBIOS
Martine Culioli
Laboratoire de Mécanique et d'Acoustique (LMA)
Maurice Libes
Centre d'Océanologie de Marseille (COM)
Thierry Mouthuy
Centre de Physique des Particules de Marseille (CPPM)
Michel Kourilsky
Délégation Régionale Provence et Corse (DR12)
La présentation porte sur l'élaboration de la Politique de Sécurité des Systèmes d'Information (PSSI) dans une unité propre de recherche du CNRS en utilisant la méthode d'analyse de risques EBIOS. Il s'agit d'un projet pilote, destiné à préparer la réalisation des PSSI d'unités CNRS en Délégation CNRS Provence et Corse (DR12).
Nous exposons l'utilisation de la méthode EBIOS en passant rapidement en revue les étapes.
Nous poursuivons en présentant le déroulement du projet, la façon dont nous avons exploité les résultats issus de l'analyse de risques, pour arriver au choix et à l'écriture des principes de sécurité à partir de la norme ISO/CEI 27002, et enfin à la rédaction de la politique de sécurité du laboratoire.
Nous terminons par une analyse des difficultés rencontrées. Au terme de notre étude et avec l'expérience acquise, nous faisons des propositions pour aider les Administrateurs Systèmes et Réseaux (ASR) des unités de la Délégation souhaitant procéder à la mise en place de leur PSSI d'unité.
Mots clefs
Sécurité informatique, analyse de risques, EBIOS, ISO/CEI 27000, Politique de Sécurité des Systèmes d'Information, PSSI.
Initié au cours du premier trimestre 2008 sur la Délégation CNRS Provence et Corse (DR12), le projet porte sur l'élaboration de la PSSI du laboratoire de Mécanique et d'Acoustique, UPR du CNRS, institut INST2I.
Il s'agit d'un projet pilote animé par la cellule CRSSI (cellule de Coordination Régionale de la Sécurité des Systèmes d'Information) de la DR12, pour prendre en main et maîtriser l'utilisation d'une méthode d'analyse de risques (EBIOS en l'occurrence) dans le but de préparer l'élaboration des PSSI d'unités en DR12.
Nous avons souhaité rendre compte du déroulement du projet et de l'utilisation de la méthode EBIOS, avec ses avantages et inconvénients pour éviter à nos collègues ASR les difficultés auxquelles nous avons été confrontés. Nous proposons dans nos conclusions des améliorations possibles dans la conduite de tels projets, particulièrement chronophages.
Nous présentons notre travail en quatre parties:
Le choix du laboratoire, la constitution des groupes de travail et la méthode utilisée
Le déroulement de la méthode EBIOS jusqu'à l'expression des besoins et l'évaluation des risques
Écriture des principes de sécurité et couverture des risques.
Conclusion : l'intérêt de cette démarche, les difficultés rencontrées et les écueils à éviter.
Le laboratoire pilote choisi pour l'élaboration de la PSSI d'unité est le Laboratoire de Mécanique et d'Acoustique à Marseille. C'est une unité propre de recherche dépendant de la seule tutelle CNRS, située sur le campus de la Délégation CNRS Provence et Corse et rattachée à l'institut INST2I.
Composé de 130 membres (dont 48 chercheurs, 24 ITA et 40 doctorants), le laboratoire a de fortes collaborations industrielles et mène des activités de recherche nécessitant parfois une haute confidentialité. Les chercheurs sont habitués aux contraintes liées à cette confidentialité et mieux préparés à adhérer à une démarche de PSSI visant à formaliser un corpus de règles de sécurité. Le futur déménagement du Laboratoire sur un nouveau site, dans de nouveaux locaux est l'occasion d'intégrer la Sécurité des Systèmes d'Information au projet.
La conduite de ce projet a été animée par la cellule CRSSI (les auteurs de l'article) de la DR12. Lors d'une assemblée générale de l'unité, nous avons présenté et commenté la PSSI cadre du CNRS, et expliqué la nécessité de la mettre en place, en l'adaptant, dans chaque unité CNRS. Un texte explicatif complémentaire a été mis en ligne sur l'intranet du laboratoire, et nous avons lancé un appel à candidature interne pour créer un comité de pilotage PSSI.
Ce comité est composé de neuf membres : 1 membre de la Direction (Directeur adjoint), 2 ITA, 2 chercheurs et la cellule CRSSI-DR12 (4 personnes).
Une Politique de Sécurité des Systèmes d'Information est un ensemble de règles et de principes que l'unité doit suivre pour assurer sa sécurité. Pour les obtenir, il faut analyser les besoins de sécurité, les menaces pesant sur le Système d'Information (SI), évaluer les risques encourus, et les impacts sur le laboratoire.
Cette démarche est obtenue à l'aide d'une méthode d'analyse de risques. Nous avons choisi d'utiliser la méthode d'analyse de risques EBIOS pour différentes raisons :
compétences locales : L'université de la Méditerranée utilise cette méthode pour l'élaboration de sa propre PSSI, et nous avons pu bénéficier de leur expertise, tout d'abord par une formation à la méthode, ensuite, par la fourniture de divers documents utilisés pour l'audition des experts,
c'est une méthode gouvernementale diffusée par l'ANSSI (ex. DCSSI), très bien documentée et accompagnée d'un logiciel de traitement des informations.
Le travail a été réalisé à deux niveaux :
la cellule CRSSI a pris en charge la totalité de la conduite du projet et le déroulement de la méthode,
le comité de pilotage PSSI du LMA a été consulté régulièrement pour les vérifications, modifications et validations du travail réalisé par la cellule CRSSI.
Ce mode de fonctionnement convient à notre contexte dans lequel la Direction et les chercheurs n'ont qu'une disponibilité restreinte et peu de temps à consacrer à l'élaboration d'une PSSI.
Brièvement, la méthode EBIOS repose sur cinq étapes:
Elle comprend trois parties :
i) L'étude de l'entité à sécuriser : cette étape est essentielle pour exprimer les missions de l'unité, ses valeurs propres, ses axes stratégiques et ses enjeux ainsi qu'une description fonctionnelle de l'organisme.
ii) La détermination du périmètre à sécuriser et la réalisation d'un inventaire exhaustif des "éléments essentiels" (terminologie EBIOS qui désigne les données et les fonctions du SI qu'on veut protéger).
iii) La détermination de la cible de l'étude : les entités (locaux, matériels, logiciels, personnels...) composant le SI et qui portent les données et les fonctions.
Terminée et validée par le comité de pilotage en Juillet 2008, cette partie de la méthode nous semble être une étape fondamentale dans la réflexion globale du laboratoire sur la prise en compte de la sécurité impliquant des aspects techniques, organisationnels et politiques.
Il s'agit dans cette étape de formaliser le contexte et d'analyser de manière exhaustive les données et les actifs qu'il est nécessaire de protéger pour assurer les missions essentielles de l'unité.
Dans cette seconde étape, nous avons été amenés à :
Établir une échelle des besoins en terme de disponibilité, intégrité, confidentialité (établie à partir de celle donnée par la PSSI cadre du CNRS [1]).
Déterminer les impacts significatifs que le laboratoire veut éviter (pertes financières, perte d'image de marque, atteintes aux règlements, etc). La méthode EBIOS aide au choix de ces impacts en proposant une liste.
Évaluer, pour chaque élément essentiel (données, fonctions) du laboratoire, les besoins de sécurité avec cette échelle des besoins, et en fonction des impacts retenus.
L'étape a nécessité l'audition d'experts-métier pour inventorier les éléments essentiels qu'ils manipulent (données et fonctions) ainsi que les besoins de sécurité associés à ces éléments. Nous avons consulté cinq membres du laboratoire représentatifs des chercheurs, des ingénieurs et administratifs.
La consultation s'est déroulée en deux parties :
une première partie d'environ trente minutes pendant laquelle nous présentions succinctement le cadre du projet PSSI du CNRS, la démarche EBIOS et ce que nous attendions de leur audition,
une seconde partie d'environ deux heures et demi, pour inventorier les fonctions et les données nécessaires au métier de la personne auditionnée et évaluer les besoins de sécurité associés.
Un guide de conduite d'entretien et une feuille de recueil de besoins, fournis par l'université de la Méditerranée et adaptés par nos soins pour le laboratoire, nous ont été particulièrement utiles.
Cette étape a été menée en parallèle à celle de l'expression des besoins. Elle a été réalisée par la cellule CRSSI et consiste à sélectionner les menaces (choisies dans une liste fournie par la méthode) pesant sur les entités du laboratoire.
Nous avons :
choisi les méthodes d'attaque les plus plausibles dans le contexte étudié (incendie, écoute passive, vol...),
sélectionné les vulnérabilités des entités dans la liste fournie par la méthode EBIOS (pas de portes coupe-feu, bureaux ouverts ...),
évalué des niveaux de vulnérabilité (représentant la possibilité de réalisation des méthodes d'attaque),
rédigé explicitement les menaces en prenant en compte l'élément menaçant.
Exemple de rédaction des menaces :
L'absence de cloisonnement anti-feu (vulnérabilité) dans les locaux du laboratoire (entité) pourrait (possibilité) aggraver les conséquences d'un incendie (méthode d'attaque), déclenché de manière délibérée ou accidentelle (élément menaçant), en facilitant sa propagation.
Le faible contrôle d'accès aux bureaux et salles de manipulation du laboratoire peut permettre à un individu non autorisé d'effectuer des écoutes passives (accès à des postes de travail non protégés, pose de matériel d'écoute, etc).
Le risque est défini dans EBIOS comme "l'opportunité de l’exploitation de vulnérabilités existantes sur des entités, par un élément menaçant employant une méthode d’attaque".
Dans cette étape il s'agit de :
déterminer les risques en confrontant les menaces aux besoins de sécurité,
exprimer et hiérarchiser les risques de manière à préparer un plan d'action pour sécuriser le SI,
déterminer les objectifs de sécurité, un objectif pouvant couvrir plusieurs risques.
Cette étape est l'aboutissement de l'étude :
une entité présente des vulnérabilités exploitables par des éléments menaçants (§ 3.3),
cette même entité est le support d'éléments essentiels (fonctions et données) pour lesquels nous avons exprimé des besoins de sécurité (§ 3.2).
Si une menace pèse sur une entité, elle compromet la sécurité des données qui y sont stockées. L'opération de croisement consiste à rapprocher les menaces qui pèsent sur les entités et les besoins exprimés sur les éléments essentiels. On en déduit les risques encourus et donc les impacts potentiels pour l'unité (en terme d'affaiblissement ou de perte de disponibilité, intégrité, confidentialité).
Cette opération représente, dans notre étude, un traitement de données considérables saisies à l'aide du logiciel fourni par EBIOS. Les tableaux résultant sont impossibles à manipuler ou à imprimer. De ce fait, il n'a pas été possible d'utiliser le logiciel pour poursuivre le déroulement de la méthode.
Nous avons donc exploité les données, exprimé et évalué les risques d'une manière différente :
Nous avons tout d'abord largement réduit la quantité d'informations, en regroupant les « éléments essentiels (données et fonctions) » et les entités (matériels, logiciels, locaux...) du laboratoire dans des classes génériques.
Nous avons par la suite analysé les données réduites de la manière suivante :
Pour chaque « élément essentiel » du SI (sur lesquels nous avons exprimé les besoins de sécurité en disponibilité, confidentialité, intégrité), nous listons les entités susceptibles de porter cet élément (Tableau 1).
|
Classe d'éléments essentiels (données ou fonctions) |
Classes d'entités |
|
communication : accueil public, administration |
personnel, organisation interne |
|
contenu web |
serveur, logiciels et progiciels, ASR, organisation interne |
|
journaux de traces |
ASR, serveur |
|
fichiers utilisateurs (/home, /var/spool) |
ASR, serveurs, PC portables |
|
données de configuration |
ASR, serveurs |
|
gestion des authentifications |
ASR, organisation interne |
|
gestion des sauvegardes |
ASR, matériel,support amovible |
|
gestion du réseau |
ASR, matériel |
|
documentaliste |
personnel, organisation interne |
|
... |
… |
Tableau 1: Exemple de mise en rapport d'éléments essentiels avec les entités qui les portent.
Pour chaque classe d'entité, nous listons les menaces et vulnérabilités (Tableau 2).
|
Classe entité :PC portable |
Menaces retenues sur PC portable |
Vulnérabilité |
|
|
Écoute passive |
... |
|
|
Écoute passive: wifi |
... |
|
|
Vol de supports, vol de matériel. |
|
|
|
Matériel mis au rebut |
... |
|
|
Piégeage du logiciel (tout OS) |
... |
|
|
Utilisation illicite des matériels (vols identifiants, récupération données) |
... |
|
|
Abus (ASR) ou usurpation (non ASR) de droits |
... |
Tableau 2 : Exemple des menaces et vulnérabilités retenues pour l'entité PC portable.
Avec ces tableaux, nous avons alors évalué un niveau de risque, tel que préconisé dans la norme ISO/CEI 27005[4], en tenant compte :
du niveau de besoin exprimé (en terme de Disponibilité, Intégrité, Confidentialité, 0 < DIC < 3),
de la Probabilité d'Occurrence de chaque Méthode d'attaque pour chaque entité (1 < POM < 4, 1=très peu probable),
de la Facilité d'Exploitation des Vulnérabilités de l'entité (0 < FEV < 2, 2= très facile) par la formule :
Niveau risque = DIC * (POM + FEV)
Ainsi, pour une entité donnée (ex. PC portable), une méthode d'attaque fortement probable (ex. POM=4 pour le vol) qui présente une vulnérabilité facilement exploitable (FEV=2), donne un risque très élevé pour les éléments essentiels (DIC=3) portés par cette entité.
Exemple de calcul de niveau de risque :
Élément essentiel : données d'expérimentation
Entité : PC portable
Besoins en confidentialité = 3 (Maximum)
|
Méthode d'attaque |
POM |
FEV |
Niveau de Risque=DIC*(POM + FEV) |
|
Vol de support, vol de matériel |
4 |
2 |
18 |
Ce calcul permet de mettre en évidence les risques les plus élevés par type d'élément essentiel et donc de pouvoir les hiérarchiser en vue de la mise en place d'un futur plan d'action.
A ce point du déroulement de notre étude, les risques sont hiérarchisés et exprimés clairement afin d'en faciliter la communication auprès du comité de pilotage
Exemple d'expression du risque concernant le vol de support/PC portable (niveau 18) :
Le vol de supports ou de matériels est fortement probable compte tenu du faible contrôle d'accès aux locaux, du manque de sensibilisation du personnel et de l'utilisation de ces supports ou matériel à l'extérieur. Ceci porterait atteinte à la confidentialité des informations contenues sur ces supports ou ces matériels et pourrait entraîner une infraction aux lois et règlements et une perte d'image de marque pour le laboratoire.
Il est important d'avoir à l'esprit la différence entre l'élaboration d'une PSSI qui doit définir la politique du laboratoire visant à sécuriser le SI et un plan d'action qui prend en charge les risques pour les réduire.
L'évaluation des risques, faite ci-dessus, ne sert qu'à établir des priorités dans la mise en place d'un plan d'action ultérieur. Dans le cadre de l'élaboration de la PSSI, nous nous attachons à édicter des principes adaptés à la sécurisation du SI de l'unité. De ce fait, nous considérons tous les risques, y compris ceux de niveau faible (qu'on ne prendrait pas en compte immédiatement dans un plan d'action), ainsi que ceux qui sont déjà couverts au moment de l'étude.
Par exemple, l'analyse a montré que le risque lié à un accès non authentifié au SI de l'unité était faible (base d'authentification centralisée, serveurs bien sécurisés...). En dépit de ce risque faible, la PSSI de l'unité doit bien entendu contenir un principe de protection indiquant que tout accès au SI doit être authentifié.
Pour ce faire, nous avons utilisé la norme ISO/CEI 27002[3] ("Code de bonne pratique pour la gestion de la sécurité de l'information") pour sélectionner les mesures nécessaires à la sécurisation de l'unité.
Nous avons examiné la liste des mesures de sécurité et avons sélectionné celles qui étaient pertinentes dans notre contexte.
Exemples de mesures de sécurité que nous avons retenues pour couvrir le risque de vol:
« Des précautions doivent être prises quant à l’emplacement et à la protection des matériels d'expérimentation et informatiques vis-à-vis des événements environnementaux ou extérieurs (ex. Incendie, défaut de distribution électrique, vol). »
« L’accès aux bâtiments de l’unité en dehors des heures d'ouverture du laboratoire est restreint aux personnels autorisés et contrôlé par badge. Les badges sont personnels et non cessibles »
Nous avons, ensuite, rédigé notre PSSI en suivant les grandes sections que l'on retrouve dans la norme ISO/CEI 27002[3] et dans la PSSI cadre du CNRS. Dans une ultime étape, nous avons vérifié que les risques que l'on souhaite traiter sont bien couverts par l'ensemble des mesures sélectionnées, et donc par notre PSSI.
La méthode d'analyse de risques EBIOS, agréée par l'ANSSI (ex DCSSI), est extrêmement détaillée et rigoureuse. Sa documentation riche et précise est un facteur positif sur lequel nous avons pu nous appuyer (listes des menaces, des vulnérabilités, des impacts, etc).
La première partie, "Étude du contexte", est extrêmement enrichissante pour le groupe de réflexion et pour l'unité. Elle permet d'établir un inventaire exhaustif des biens lors de l'énumération des "éléments essentiels" et engage une réflexion intéressante sur les enjeux, les missions et les valeurs propres de l'unité. C'est une étape de communication et de concertation importante.
Lors de l'étape "Expression des besoins", l'audition des experts-métier du laboratoire, bien que difficile à planifier et à réaliser, valide ou complète les informations que le groupe CRSSI avait pressenties. C'est également une étape de communication interne : elle permet aux personnes auditionnées de s'inscrire plus facilement dans la démarche de la SSI engagée par le laboratoire.
La méthode manipule de nombreux concepts et terminologies avec lesquels nous avons eu du mal à nous familiariser. L'appropriation de la démarche est longue et laborieuse. Certaines réunions de travail ont donné lieu à des débats interminables pour partager la même définition d'un terme, d'un coefficient à évaluer. Cette complexité a beaucoup ralenti notre travail et a grandement pesé sur la motivation du groupe de pilotage à s'impliquer dans l'opération.
De ce fait, nous avons choisi de travailler la plupart du temps au sein de la cellule CRSSI et le comité de pilotage (laboratoire, Direction et chercheurs), moins sollicité, s'est investi uniquement lors de rares réunions de validation.
Un autre inconvénient, plus technique celui-ci, est le très grand nombre d'informations générées par la méthode EBIOS. Nous avons analysé le contexte de l'unité de manière extrêmement précise et détaillée aussi bien pour la liste des éléments essentiels, que pour les entités et les menaces. Ainsi, dans cette étape, chaque service sur chaque machine serveur a été répertorié. En effet, la méthode demande de prime abord une analyse et un inventaire très exhaustif des actifs (entités, données) qui génère ainsi une masse importante de données à traiter. Le volume trop important de données recueillies ne nous a pas permis de poursuivre l'utilisation du logiciel EBIOS lors de l'étape de synthèse (croisement des besoins de sécurité et des menaces pour obtenir les objectifs de sécurité). Nous avons dû regrouper toutes ces informations en classes pour pouvoir exprimer les risques et les hiérarchiser.
Comment améliorer cette étude pour faire en sorte que la rédaction d'une PSSI dans une unité CNRS soit plus facile et moins chronophage ? Cette étude,que nous avons conduite pendant un an et demi, représente environ 350 heures/homme au rythme moyen d'une réunion par quinzaine. Cette durée peut paraître acceptable dans le cas d'un projet pilote chargé d'investiguer et de se familiariser avec la méthode. Il est absolument nécessaire de la réduire si on veut réussir un déploiement plus large des PSSI au sein des unités de la Délégation. Il nous paraît donc nécessaire de proposer une aide, des conseils et une démarche claire et concise aux laboratoires, ce qui permettrait de réduire le temps passé à six mois au maximum.
Les unités n'ont pas les moyens humains pour s'engager sans aide sur le déroulement complet d'une méthode d'analyse de risque. D'autre part, les unités CNRS ne peuvent pas reprendre "in extenso" la PSSI cadre du CNRS sur laquelle elles apposeraient juste leur nom, sans avoir mené une réflexion sur leurs besoins propres de sécurité. Il faut donc trouver une solution rapide, efficace et adaptée aux besoins des unités.
Lors de notre étude, nous avons réduit les entités et éléments essentiels en les groupant en classes. Après réflexion, il nous semble que ces classes pourraient en grande partie être communes aux unités de recherche (ex. la classe des serveurs, la classes des locaux, etc). De la même manière nous avons choisi des menaces, des impacts et vulnérabilités qui pourraient être communs à un grand nombre d'unités. Le groupe CAPSEC [6] avait fait il y a quelques années une démarche d'adaptation similaire, et nous conforte dans cette idée.
Tous ces éléments pourraient faire partie d'une « boite à outils » fournie aux unités qui pourrait contenir :
des classes génériques pour les éléments essentiels, les entités, les menaces et vulnérabilités,
une échelle générique des besoins en DIC en 0,3....,
un formulaire de conduite d'entretien pour exprimer les besoins auprès d'experts-métier,
une liste d'impacts communs à toutes les unités (perte d'avantages scientifiques, atteintes aux règlements...),
la PSSI cadre CNRS,
etc...
Ces classes génériques devraient être étudiées et validées par des experts SSI du CNRS et fournies aux unités pour faciliter leur propre étude. Une fois ces informations validées et mutualisées, il appartiendrait aux unités de s'attacher à traiter leurs spécificités.
Nous proposons une méthode d'analyse de risque allégée, avec une boite à outils PSSI CNRS, et la présence d'experts SSI en délégation pour jalonner et valider le travail des entités.
La réalisation d'une PSSI d'unité pourrait se dérouler selon un certain nombre d'étapes plus concises :
étude du contexte (périmètre, enjeux, missions, valeurs propres..) :
inventaire exhaustif des entités (matériels, locaux..),
inventaire exhaustif des données (informatiques et matérialisées),
regroupement des données et entités en classes proposées par la boîte à outils,
audit : recueil des besoins auprès d'experts-métier en utilisant les formulaires de la boite à outils,
choix et validation des menaces et des vulnérabilités proposée dans la boite à outils,
optionnellement, calcul des niveaux de risque avec les coefficients POM et FEV pour les hiérarchiser et pour préparer un plan d'action,
choix des mesures de sécurité à prendre dans la norme ISO/CEI 27002,
mise en forme et rédaction de la PSSI avec les mesures de sécurité sélectionnées et en accord avec la PSSI cadre du CNRS.
Bibliographie
[1] J. Illand, Politique de sécurité des systèmes d'information (PSSI), Novembre 2006.
[2] J. Illand, Guide d'élaboration d'une PSSI opérationnelle d'unité, Avril 2008.
[3] Norme internationale ISO/CEI 27002:2005,Technologies de l'information-Techniques de sécurité-Code de bonne pratique pour la gestion de la sécurité de l'information, 2005
[4] Norme internationale ISO/CEI 27005:2008.Technologies de l'information — Techniques de sécurité — Gestion du risque en sécurité de l'information, 2008
[5] Documentations EBIOS. Sur le site de l'Agence nationale de la sécurité des systèmes d’information (ANSSI) anciennement DCSSI, http://www.ssi.gouv.fr/site_article45.html
[6] N. Dausque, A. Facq, G. Feltin, F. Gazelle et O. Servas, Pourquoi et comment adapter une Politique de Sécurité pour les entités du CNRS. Dans Actes du congrès JRES2005, http://2005.jres.org/articles/112.pdf