Articles

Intervenant régulièrement pour la mise en place de systèmes de management de la sécurité de l’information, j’ai commencé comme tout le monde par me faire un tableur pour l’analyse de risques, permettant d’articuler les événements redoutés, les scénarios de survenue et les mesures de traitement.

Et comme tout le monde, je me suis vite retrouvé confronté à la pauvreté de l’information qu’on peut saisir dans un tel tableur et au problème de chaînage avec les procédures et les preuves. Passe encore quand on est en train de faire l’analyse pour la première fois, avec tous les tenants et aboutissants en tête, mais lorsqu’on y revient quelques mois plus tard cela relève de l’archéologie.

Il existe certes quelques bons outils commerciaux de support d’un SMSI, mais il est difficile d’attaquer une intervention auprès d’un nouveau client en lui expliquant qu’il va devoir souscrire à un service dont il n’imagine pas encore l’utilité.

Ma solution a finalement été d’inverser la perspective. Plutôt que d’essayer d’intégrer des informations textuelles riches, mais non structurées dans des cases ou des champs toujours trop petits, j’ai utilisé une extension à DokuWiki qui permet d’intégrer et de requêter quelques données structurées dans des pages de documentation.

J’y ai ajouté quelques lignes de développement avec une extension spécifique pour avoir la représentation graphique traditionnelle de la matrice des risques.

Je suis satisfait du résultat. De manière très souple, on peut ainsi au sein d’un site documentaire unique sous DokuWiki décrire les risques, scénarios et mesures, les lier à toutes les informations documentées du système de management, procédures ou enregistrements, produire le plan de traitement ou la déclaration d’applicabilité, chaîner les référentiels de certification avec les éléments de preuve, etc. Et évidemment, on conserve tous les bénéfices d’un Wiki pour le travail collaboratif et le partage des informations.

Restent en dehors la gestion des configurations (CMDB) et des demandes et incidents, pour lesquels ma référence reste l’excellent outil iTop de Combodo.

Un site exemple en lecture seule, peu garni mais suffisamment pour se faire une idée, peut être visité ICI.

Comme DokuWiki, les extensions utilisées sont en code source ouvert. L’installation complète d’un serveur selon cette procédure prend moins de deux heures.

La méthode est transposable à tous les systèmes fondés sur une analyse de risques, notamment les études d’impact sur la vie privée.

Si cela peut vous aider, servez-vous et faites-moi vos retours d’expérience.

A l’occasion d’interventions récentes, je me suis à nouveau retrouvé devant un thème qui a déjà fait couler (métaphoriquement) beaucoup d’encre : l’articulation entre le Délégué à la Protection des Données (DPD) et le Responsable de la Sécurité des Systèmes d’Information (RSSI).

Beaucoup ont proclamé l’incompatibilité de ces deux missions, sur la base de trois catégories d’arguments : les conflits d’intérêts, l’incompétence juridique des techniciens que seraient les RSSI, et le refus d’ajouter à leur charge déjà conséquente.

La question de la charge de travail prend le problème à l’envers. L’organisation doit déterminer les ressources, et non l’inverse.

Le procès en incompétence est douteux. Recenser les finalités, la pertinence des données, les durées de conservation nécessaire requiert plus un effort de collecte auprès des responsables métier qu’une culture juridique approfondie. Reste la gymnastique des conditions de licéité, sur laquelle une assistance juridique ponctuelle peut être bienvenue.

Sur les conflits d’intérêt, on trouve deux volets connexes : l’un étant que la mission du RSSI serait de défendre les intérêts de sa structure et non ceux des personnes concernées ; l’autre étant que contribuant à la définition des objectifs et des moyens du traitement de l’information il ne pourrait s’en abstraire dans la mission de DPD.

Pourtant, lorsque l’on pratique la mise en place de systèmes de management de la sécurité de l’information selon l’ISO 27001, on ne peut qu’être frappé par la convergence des travaux et des moyens. Inventorier les traitements de données personnelles ou les actifs informationnels, mener une étude d’impact sur la vie privée ou une analyse de risques sur l’information, notifier les violations de données personnelles ou mettre en œuvre la communication des incidents de sécurité : les termes changent mais les méthodes et les objets sont les mêmes.

Comme souvent dans les débats confus, cela me semble venir d’un problème de vocabulaire. Contrairement à celui de DPD, le terme de RSSI n’était pas vierge. Il correspond à une activité déjà portée, le plus souvent au sein des DSI, par un expert technique reconnu, qui n’a effectivement pas nécessairement d’appétence pour les raisons d’être des traitements qu’il est déjà fort occupé à sécuriser techniquement.

Par ailleurs, une seconde acceptation découle de la norme ISO 27001, qui impose de désigner un responsable pour la conformité du système de management de la sécurité de l’information (SMSI) à la norme et pour la restitution à la direction des performances de ce système. Ce rôle a été amalgamé au RSSI technique préexistant, alors qu’il s’agit plus ici d’un travail d’animation et de coordination.

Ce malaise terminologique, je le retrouve dans le guide des indicateurs des prérequis du socle commun du programme HOP’EN, édité par la DGOS en juillet 2019. Dans son prérequis P2.4, trois termes différents sont utilisés pour cette même fonction : responsable sécurité, RSSI et référent sécurité. Ainsi, la description faite dans le recensement des indicateurs mentionne « Positionnement fonctionnel du RSSI en dehors de la DSI », tandis que la fiche détaillée explicite « L’exigence concerne l’existence d’une fonction de référent sécurité au sein de l’établissement, fonction qui n’est pas exercée nécessairement à temps plein et dont le positionnement fonctionnel est en dehors de la DSI (il pourrait, par exemple, être attaché à la cellule qualité de l’établissement/GHT). »

Si l’on décorrèle ces termes, en laissant au RSSI son positionnement historique d’expert technique au sein de la DSI et en chargeant le référent sécurité des tâches spécifiques au fonctionnement du système de management, on dégage pour ce dernier un rôle de pilotage et d’animation totalement compatible des missions du DPD :

• Cartographie des données et des traitements,
• Cotation avec les directions métier de l’impact des pertes de confidentialité, disponibilité, intégrité sur ces biens essentiels, avec l’établissement d’objectifs argumentés sur la perte de disponibilité (indicateur P2.2 des prérequis HOP’EN)
• Animation annuelle d’une analyse des risques inter-directions pour déterminer les scénarios pouvant entrainer ces événements redoutés, et sélectionner ceux qui requièrent des actions de mitigation prioritaire (P2.4).
• Consolidation de l’ensemble des mesures de mitigation de haut niveau en une politique de sécurité de l’information (P2.4). Ces mesures sont ensuite déclinées opérationnellement dans chaque direction concernée, dont principalement la DSI.
• Animation de réunions périodiques de suivi de l’avancement des actions, des retours d’expérience sur les incidents rencontrés, sur les résultats des audits, et de mise à niveau en conséquence de l’analyse des risques et du plan d’actions.
• Conduite des actions de sensibilisation des personnels de l’établissement, notamment sur la base des retours d’expérience.
• Organisation des routines de communication interne et externe, et particulièrement de la notification des incidents de sécurité.
• Consolidation et publication régulière des indicateurs de fonctionnement du système de management de la sécurité, parmi lesquels l’indicateur P2.2 de disponibilité des applicatifs.
• Organisation des audits internes et des tests d’intrusion (indicateur P2.5)
• Restitution semestrielle à la direction des résultats et performances du SMSI (P2.4).

Avec ce périmètre, il recouvre à 80% ce que l’on attend d’un DPD. Il convient d’y ajouter le cadrage initial des traitements en termes de licéité et de minimisation, la mise en place des circuits d’information et d’exercice des droits des personnes concernées, et l’on a un périmètre cohérent.

Cette cohérence permet, comme l’affirme la fiche n°6 de la boîte à outils de l’ANAP pour l’atteinte des prérequis HOP’EN, de faire porter les rôles de RSSI (ou plus exactement, si on utilise les termes définis ici, de référent sécurité) et de DPD par une même personne. 

La personne ou l’équipe qui porte cette mission a bien le niveau d’indépendance requis tant d’un DPD que d’un référent sécurité. Son rôle est de médiation, d’objectivation, de synthèse et de communication entre les utilisateurs, les Directions supports et la Direction générale. Il n’est nullement en contradiction avec celui du RSSI historique, auquel elle fournit des objectifs explicites et assumés, facilitant son travail de recherche des solutions les plus efficaces.

Les compétences requises sont généralistes : capacité de synthèse, d’animation et de vulgarisation, un peu de culture informatique et juridique, et surtout beaucoup de bon sens, de rigueur et de patience. Pour désamorcer un autre débat récurrent, elles ne préjugent pas que l’expérience initiale du titulaire soit juridique ou technique. Un conseil que j’ai reçu lorsque j’étais débutant m’a toujours servi avec profit : pour marcher, il faut un pied d’appui et un pied qui avance.

Un consortium formé par le groupe JOUVE, SYADEM, CIMBIOSE et IPSOS vient d’être retenu par l’agence CHAFEA de la Commission Européenne après avoir répondu à l’appel d’offres pour évaluer la faisabilité d’un carnet de vaccination européen.

Il s’agit, sur la base d’une cartographie des carnets de vaccination existants, d’élaborer, de tester et d’évaluer trois modèles d’un carnet de vaccination commun aux citoyens de l’UE qui tienne compte des différents calendriers de vaccination nationaux, qui soit interopérable avec les systèmes d’information sur la vaccination des États membres de l’UE, qui soit commun à tous ces États et utilisable au-delà des frontières. Les modèles auront une conception duale (physique et numérique), devront être capables d’augmenter la couverture vaccinale et contribuer à résoudre les difficultés liées au déplacement de citoyens européens dans différents pays au sein de l’UE.

Ces modèles seront élaborés par JOUVE, puis testés par IPSOS auprès de 75.000 citoyens dans 10 pays.

Notre offre reprend de MesVaccins.net le principe de distinguer entre un historique vaccinal portable et sa projection via un système de recommandations personnalisées dans le cadre des règles et pratiques propres à chaque pays, ainsi que la nomenclature unifiée des vaccins nécessaire pour pouvoir représenter des traces vaccinales anciennes et hétérogènes.

Merci à Alain, Benjamin, David, Estelle, Fabienne, Jean-Louis, Jérémie, Mariane, Marion, Sylvie, et tous les autres qui ont contribué à monter ce dossier.

Que ce soit pour une certification 27001, une étude d’impact sur la vie privée au titre du RGPD, ou un marquage CE Médical, on se retrouve systématiquement à devoir faire une analyse des risques, ce qui n’est pas réellement compliqué, mais fastidieux et difficile à tenir à jour.

Pour gagner du temps dans ces tâches, j’ai développé quelques macros dans un classeur Excel qui facilitent la réalisation et l’entretien d’une analyse de type EBIOS 2010 légèrement simplifiée.

Des menus contextuels spécifiques permettent de naviguer rapidement entre risques, scénarios et mesures, ainsi que de lancer le calcul des niveaux de risque. Pour ceux-ci, je me suis inspiré du tableur précédemment réalisé par l’excellent site Qualitiso et détaillé dans cette présentation.

L’outil est disponible ici , et son manuel d’utilisation là. Il faut pour s’en servir le télécharger sous Excel, puis accepter l’activation du contenu et des macros.

Si vous l’utilisez ou l’améliorez, merci de me le faire savoir.

Pour tous ceux qui, ayant longuement bataillé sur l’amélioration d’images plus ou moins bruitées, soupirent à chaque fois que le zoom magique est utilisé dans une série policière, voici un grand ancêtre de 1967.

IMF – Saison 2 Episode 4

L’annonce faite lors du congrès de l’APSSIS de l’abandon de la certification pour les activités d’administration et d’exploitation d’un SI contenant des données de santé à fait grand bruit dans notre petit monde.

Au risque de surprendre, je dirais qu’il me semble que c’était la seule sortie possible du bourbier dans lequel on pataugeait depuis des années.

Certes, j’avais dans un article précédent sur LinkedIn fait état de la décision inverse en avril 2018, après avoir convenu avec la Délégation à la Stratégie des Systèmes d’Information de Santé que puisqu’ils ne voulaient pas en démordre, il valait mieux que nous ayons une communication coordonnée sur le sujet (communication qui n’est jamais venue de leur côté).

Mais on n’en n’était pas plus avancés, car il était impossible de tracer une délimitation dans le continuum qui va du dépannage occasionnel du poste de travail du généraliste de Saint Flour à l’administration du dossier patient d’un CHU, et personne ne pouvait imaginer sérieusement imposer la certification à l’ensemble des acteurs susceptibles d’être concernés. Tout au plus pouvait-on espérer qu’on laisserait les plus petits voler tranquillement en dessous des radars.

Alors, mieux vaut sans doute abandonner l’obligation que de plonger délibérément une fois encore (qu’on se rappelle le décret Confidentialité) la majorité des acteurs dans l’illégalité.

Mais évidemment, ce rétropédalage ne va pas sans mal. L’article de Sana Bakfalouni paru sur le JDN en est une bonne illustration. On peut aussi s’attendre à des réactions outragées des anciens hébergeurs agréés qui avaient espéré faire de cette certification un argument pour s’intercaler entre leurs clients et les clouds publics.

Là où je pense que l’indignation est mal placée, c’est qu’en réalité il n’y a plus grand chose à perdre en matière de sécurité après le remplacement de l’agrément par la certification. La règle du jeu est désormais qu’il appartient au responsable de traitement de composer un bouquet complet et cohérent de prestations certifiées entre les différents offreurs de service : infrastructure cloud, administration réseau, administration système, administration fonctionnelle ou technique de l’application, intégrateurs, éditeurs, prestataires variés d’acheminement de messages ou de flux, chacun porteur d’un fragment de certification sur un périmètre qu’il définit à son gré. L’exercice serait déjà redoutable pour un architecte informatique chevronné, il est juste inenvisageable pour un professionnel de santé.

Essayer de défendre la certification dans ce cadre, c’est un combat d’arrière garde. S’il y a un espoir de voir les conditions de sécurité des données de santé s’améliorer, c’est désormais au travers des obligations du RGPD, objectivées par les mythiques référentiels opposables de la PGSSI-S, et mobilisées grâce à un réveil tardif des associations de patients.

Parce que le nom de domaine était libre, bien sûr, mais aussi pour une belle richesse d’associations d’idées.

Les points cardinaux, savoir conserver l’orientation générale même lorsqu’on traite des détails.

Les vertus cardinales, prudence, tempérance, courage et justice. Voilà qui fait une belle ligne de conduite.

Avec un peu d’étymologie, du cœur et de l’énergie.

Pourquoi pas Richelieu et Mazarin, certes beaucoup décriés, mais dont on ne peut contester le sens du bien commun.

Un peu de mathématiques fondamentales, pour la gymnastique de l’esprit.

La couleur, histoire de créer une unité d’aspect des supports. C’est la limite de mes ambitions en termes de graphisme, ce site en témoigne.

Il y a aussi un petit bestiaire (oiseau, poisson, insectes) dont je ne sais que faire.