Université Paris Dauphine : Externaliser le risque cyber

Philippe Werle : L’université de Paris Dauphine PSL est un établissement pluridisciplinaire, orienté essentiellement vers l’économie / gestion, la science des organisations et l’informatique.

Nous sommes sur un schéma assez classique d’université. Il y a bien sûr une partie enseignement, une très grande offre de formation continue avec de nombreux MBA proposés, ainsi qu’un département recherche et une administration.

Ce sont ces domaines d’activités intriquées (enseignement, recherche et administration), que l’on retrouve traditionnellement dans une université d’un point de vue information et donc sécurité des systèmes d’information (SSI) et conformité réglementaire.

Jean-Christophe Gay : Je suis pour ma part à la Direction du numérique (DNum), en tant que RSSI suppléant de l’établissement. À côté de cela, je suis également responsable de l’intégration des systèmes à l’université au sein de la DNum. Avant cela, j’ai occupé des postes de RSSI à plein temps ou encore de directeur technique au sein de l’université.

Philippe Werle : Je suis arrivé à l’université juste avant le covid pour prendre un poste de RSSI gouvernance (GRC). Avant cela, j’ai occupé successivement les postes de RSSI à plein temps à l’Université de Bordeaux et à l’Université Sorbonne Paris Nord où je cumulais également les fonctions de Correspondant informatique et libertés et de directeur technique à la direction informatique. C’est un mélange dysfonctionnel de responsabilités. A Dauphine, je suis fonctionnellement et directement rattaché au président de l’université. Je ne suis donc pas rattaché à une direction informatique. Il est important de le souligner.

En tant que RSSI titulaire (Philippe) et RSSI suppléant (Jean-Christophe) nous accompagnons la gouvernance, mettons en œuvre l’organisation et contrôlons la déclinaison opérationnelle de la politique de sécurité des systèmes d’information de Dauphine.

Philippe Werle : Cette organisation de la SSI est inscrite dans le schéma directeur de la sécurité des systèmes d’information du ministère de l’Enseignement supérieur et de la Recherche depuis 2005.

Pour écarter toute ambigüité, ce positionnement a fait l’objet d’une fiche « AQSSI/RSSI » émise par le Haut fonctionnaire de défense et de sécurité (HFDS) et Secrétaire général du MESRI. Elle rappelle le cadre réglementaire et rappelle le rôle du chef d’établissement comme autorité juridiquement qualifiée (AQSSI) et le rôle du RSSI, AMOA en matière de SSI avec un rattachement direct à l’AQSSI. La responsabilité d’AQSSI n’est pas délégable.

Il est important de rappeler ces fondamentaux inscrits dans les textes et qui s'appuient sur des normes internationales de gouvernance de la sécurité. De très nombreux établissements traitent par méconnaissance la sécurité de l’information, le numérique et l’informatique dans un grand “fourre-tout” technologique.

Philippe Werle : Parce que nous devons avoir une politique de sécurité qui prend en compte la sécurité des systèmes d’information de manière transversale dans l’établissement, au niveau de toutes les directions métiers, de l’ensemble des unités de recherche et des partenaires, numériques ou non. La SSI pilote la sécurité de l’information et doit être doté de moyens propres, indépendants des autres directions.

Nommer le RSSI de l’établissement dans la direction informatique, est une pratique erronée, aujourd’hui devenue dangereuse, héritée des années 90 et qui engendre les dégâts qui font aujourd’hui le quotidien des médias en matière de « catastrophes numériques ».

Il est tout à fait souhaitable d’avoir un RSSI à la direction informatique ou toute autre direction métier, un RSSI opérationnel pour cette direction et ses SI. Cela ne peut se concevoir sans avoir également un RSSI gouvernance qui pilote la stratégie d’ensemble auprès de l’autorité.

Le numérique étant omniprésent et interconnecté, face à la menace, il est impératif que la politique sécurité des SI soit transversale et portée au plus haut niveau.

Avec un RSSI d’établissement directement rattaché à une direction informatique, les mesures de sécurité opérationnelles mises en œuvre sont limitées au périmètre des SI dont elle a en charge la production. Il ne met pas en œuvre des mesures de sécurité spécifiques aux laboratoires ou pour toute autre structure créée par l’université pour laquelle elle n’est pas décisionnaire. Il n’a pas la légitimité pour le faire.

La principale vulnérabilité de l’organisation est à tous les échelons l’humain. C’est une cible. Un RSSI de la direction informatique n’a pas le bon positionnement pour impliquer la DRH. Qu’en est-il des services hébergés contractualisés par les directions métiers ? Qui contrôle la validité réglementaire de ces contrats, leur PSSI, leur respect du RGPD ?

Les mesures de sécurité opérationnelles doivent être une déclinaison de la politique de sécurité des SI de l’établissement portée par son autorité qualifiée. L’autorité qualifiée de la sécurité des systèmes d’information est la personne juridiquement responsable, décisionnaire des budgets et des organisations, c’est le chef d’établissement.

Le RGS (Référentiel général de Sécurité) de 2010, la PSSI de l’État de 2015 et le RGPD de 2018 sont venus renforcer les exigences de cette organisation. Du côté de certaines directions, on peut encore observer une certaine difficulté à assimiler une réglementation mise en place pour protéger nos concitoyens et la nation alors que l’Etat exprime une forte volonté politique à la dématérialisation.

Après l’avènement du RGPD toujours en cours d’assimilation, l’Europe a émis le version 2 de sa directive NIS, NIS2. Sa retranscription dans le droit national est en passe d’aboutir et cela concerne directement nos établissements.

A l’avenir, chaque direction métier pourrait être désignée juridiquement responsable de la sécurité des systèmes d'information de son SI. Pour cela, nous devons intégrer cette idée au plus tôt et petit à petit dans la culture générale de l’organisation.

Philippe Werle : Nous avons dans les universités, du fait de la recherche publique, une réglementation particulière appelée “la protection du potentiel scientifique et technique de la Nation” ou PPST.

Beaucoup de laboratoires dans les universités sont des unités mixtes de recherche hébergeant des équipes composées de personnels universitaires et provenant d'autres tutelles comme le CNRS ou l’INSERM ou un CHU. Les équipes se forment en fonction des thématiques de recherche. La sensibilité des thématiques, la nécessité pour les chercheurs de se déplacer à l’étranger ou de recevoir des chercheurs ou des post doctorants d’autres pays, la continuité entre activités de recherche, activités académiques et activités administratives contribuent à environnement extrêmement complexe.

Le dispositif interministériel de protection du potentiel scientifique et technique de la nation (PPST) vise à prévenir certaines atteintes aux intérêts fondamentaux de la Nation en empêchant les tentatives de captation de savoirs et savoir-faire stratégiques par des prédateurs technologiques ou économiques, ainsi que le détournement de savoirs et savoir-faire identifiés comme sensibles pour les risques de prolifération, de dissémination ou de terrorisme. Il a pour but de protéger, au sein des établissements publics et privés (laboratoire de recherche, entreprise, etc.), l’accès à leurs savoirs et savoir-faire ainsi qu’à leurs technologies sensibles. Le dispositif est piloté par le secrétaire général de la défense et de la sécurité nationale (SGDSN), rattaché à la première ministre. L’ANSSI, rattachée au SGDSN, coordonne l'action gouvernementale en matière de défense des systèmes d'information, anime l'écosystème national de cybersécurité, concourt à la diffusion des bonnes pratiques, pilote la politique de la sécurité des systèmes d’information (PSSIE) de l’Etat.

Cette PPST implique la nomination auprès de l’autorité de chaque université d’un fonctionnaire de sécurité et de défense (FSD), inscrit dans une chaîne fonctionnelle incluant le Haut fonctionnaire de défense et de sécurité du ministère.

Le RSSI est inscrit dans une chaîne fonctionnelle SSI, rend compte à l’autorité, le président d’université, et au fonctionnaire SSI du service du HFDS du ministère qui rend compte à l’ANSSI.

Concernant les données à caractère personnel, très présentes dans les activités de recherche, d’enseignement et administratives, l’université doit se conformer au RGPD. L’université a l’obligation de nommer un/une Déléguée à la protection des données (DPO). Notre DPO est donc également rattachée à l’autorité et rend compte à la CNIL et doit être très attentive à la sécurité des informations traitées.

Sous l’autorité du président de l’université, j’ai formalisé un comité Gouvernance risques et conformité, rattaché au président, constitué du RSSI, de la DPO et du FSD. Nous avons ainsi un point d’entrée unique pour tout ce qui concerne la protection organisationnelle, juridique et technique de la donnée pour l’ensemble des activités de l’établissement.

Toujours sous l’autorité du président de l’université, j’ai constitué un Comité stratégique SSI (CoStra SSI) dans lequel sont présents le Président, la Directrice générale des services, le VP Num, le VP Finance, le VP CFVE (étude et vie étudiante), le Directeur de la DNum, les RSSI titulaire et suppléant, la DPO et le FSD. Le CoStra SSI définit la politique, l’organisation, les moyens financiers, suit les chantiers et arbitre les priorités permettant à l’établissement de sécuriser ses SI et de se mettre en conformité.

Avec Jean-Christophe, RSSI suppléant, nous avons mis en place une chaîne fonctionnelle SSI interne avec un correspondant SSI par unité mixte de recherche et par service.

Cette organisation permet de déployer sur l’ensemble des composantes de l’établissement des mesures de sécurité en fonction d’une politique cohérente et conforme à celle de l’Etat, de remonter et gérer les incidents, de piloter les crises avec l’aide du ministère, de faire appliquer les consignes, instructions, injonctions de l’Etat comme les postures VigiPirate qui incluent des mesures numériques.

Philippe Werle : Là où LockPass rentre en ligne de compte, c’est sur la partie opérationnelle de nos serveurs. Afin de diminuer la surface d’attaque et la surface d’exposition à l’internet public, nous avons mis en place une politique de mise à jour des serveurs, et avons revu notre politique de gestion des mots de passe concernant l’administration de ceux-ci.

C’est une mesure qui a été prise au niveau organisationnel, impactant notre manière globale de travailler, qui a ensuite entraîné une répercussion très concrète d’un point de vue opérationnel sur le choix et la mise en œuvre de l’outil.

Nous avons ainsi décidé de mettre en place un gestionnaire de mots de passe et avons sélectionné LockPass ensemble. Ensuite, Jean-Christophe s'est occupé de la mise en place opérationnelle.

Nous utilisons aujourd’hui LockPass pour partager un ensemble de mots de passe en tant que ressource commune.

Jean-Christophe Gay : Nous recherchions un produit qualifié, certifié, ayant obtenu un avis favorable de l’ANSSI. C’est une exigence du RGS (Référentiel Général de Sécurité).

L’intérêt pour nous de prendre un produit avec un visa ou une qualification est d’externaliser le risque. C’est une protection juridique.

Jean-Christophe Gay : D’un point de vue usagers nous n’avions rien, mais au sein de la DNum nous avions 3 ou 4 fichiers KeePass qui étaient partagés entre les collaborateurs d’une même équipe.

Nous avions un fichier pour la partie réseaux, un pour l’équipe de production, etc… En récupérant la charge des trois équipes production, réseaux et intégration, il nous a semblé essentiel de centraliser l’ensemble. Mais tout mettre au même endroit imposait de partager l’ensemble des accès à tous les collaborateurs.

Nous nous sommes ainsi rendu compte que KeePass ne satisfaisait pas à nos exigences d’utilisation.

Nous voulions pouvoir partager de manière sereine, sécurisée, facilement accessible et au plus proche de l’outil de travail de chacun (c’est-à-dire le navigateur web ou la console Linux), nos différents accès.

Nous avons testé Bitwarden en self-hosted, mais cela a eu du mal à prendre du fait d’un manque de motivation au changement de l’ensemble de l’équipe.

Nous avons ensuite pris LockPass de LockSelf, et pour la 1ère fois nous avons eu une véritable demande avec un ordre de la gouvernance d’avoir un outil commun, sécurisé, qui réponde à un certain nombre de critères.

Nous avons ainsi déployé LockPass, démocratisé son utilisation auprès de toutes les personnes de la direction et nous avons attendu que l’effet “boule de neige” prenne.

Aujourd’hui nous avons 33 utilisateurs enregistrés et qui utilisent l’outil au quotidien.

Nous sommes désormais dans une phase de réflexion pour commencer à ouvrir LockPass à d’autres directions qui en font la demande.

Jean-Christophe Gay : La 1ère direction a en avoir fait la demande et qui sera sans nul doute la prochaine à l’employer, est la bibliothèque universitaire qui dispose de ses propres agents informatiques. Ils sont très demandeurs et informatiquement autonomes, ce qui devrait faciliter le déploiement.

La bibliothèque universitaire dispose de son propre parc de machines, s’appuie sur ses propres serveurs et à un système d’information extrêmement riche puisqu’elle offre des ressources qui peuvent être nationales (ouvrages, thèses…), qui sont très importantes pour les étudiants qui font leurs études ou leurs recherches. Ils ont ainsi une équipe d’informaticiens qui ne dépendent pas de la direction du numérique. (L’université ne fonctionne pas comme une entreprise qui aurait un seul service informatique, il y a une organisation beaucoup plus transverse.)

Nous avons récemment découvert que des secrets étaient stockés dans leurs navigateurs. C’est de ce constat qu’est née leur demande de pouvoir administrer leurs serveurs via un stockage des mots de passe liés à ceux-ci dans LockPass.

LockPass sera ensuite déployé à la présidence et aux personnes à risque dans l’université. Cela risque d’être un tout petit peu plus long pour cette typologie de personnes non-technophiles, du fait d’un besoin d’accompagnement plus grand, même si l’outil reste très simple d’utilisation.

Jean-Christophe Gay : Côté KeePass, nous devions partager chaque fichier individuellement à tout le monde pour que chacun puisse accéder aux mots de passe. Impossible de gérer correctement les droits d’accès de cette façon.

Côté Bitwarden c’est la conformité qui a manqué. Bitwarden est une entreprise américaine hébergée aux Etats-Unis, là où LockPass est une société française, avec le visa de l’ANSSI, hébergé chez un fournisseur français, dans un environnement conforme “SecNumCloud”, physiquement localisé en France. Philippe, notre RSSI gouvernance, a ainsi opté pour LockPass, pour une question évidente de souveraineté de la donnée et de conformité au RGPD. Fonctionnellement il n’y avait pas de différence majeure entre les deux solutions.

Autre avantage de LockPass sur Bitwarden est le fait que le stockage et l’accès à nos mots de passe ne soient pas dépendants de notre infrastructure. C’est-à-dire qu’avec LockPass, même si notre infrastructure tombe, nous aurons toujours accès aux mots de passe qui permettent d’y accéder. C’est un vrai plus non-négligeable.

LockPass de LockSelf cochait vraiment toutes les cases que l’on voulait et que l’on devait cocher. En plus, chez LockSelf, vous avez également d’autres produits très intéressants comme LockTransfer et LockFiles.

Bonus supplémentaire : travailler avec une entreprise française nous donne l’opportunité de discuter en français et ça c’est très plaisant !

Philippe Werle : Nous attendons les instructions du ministère. Une matinale autour de la directive a déjà été organisée par notre FSSI à destination des RSSI. Il s’agit également d’en informer les directions des établissements en rappelant le positionnement du RSSI. En effet, à terme, chaque direction métier deviendra responsable juridiquement des analyses de risques de son système d’information. Cette responsabilisation devient impérative.

Cela aura un impact aussi dans la conformité au RGPD et sur la DPO dont le rôle devrait évoluer avec un volet sécurité plus important.

Cela aura un impact opérationnel, mais aussi un impact organisationnel, sur les analyses de risque, sur la sensibilisation et la formation.

Le maillon faible de la chaîne reste l’humain. Il est essentiel de le former et de le sensibiliser. On remarque par exemple que les directions métiers qui manipulent des données à caractère personnel ou les chercheurs n'ont pas toujours pas le bon niveau de formation en sécurité de l’information par rapport au niveau de criticité des données qu’ils traitent.

Aujourd’hui, sur la partie formation, nous avons une offre en place. Nous proposons des formations ludiques. Elles sont très peu suivies du fait qu'elles ne soient pas obligatoires, contrairement à d’autres, étonnement. La formation des personnels à la cybersécurité et au RGPD est pourtant une obligation réglementaire.

Nous espérons qu’avec NIS2, plus de contrôles à la conformité réglementaire seront menés, à l’instar de celle au RGPD et de ceux de la CNIL.