La directive NIS en application, volet SSI, partie II

A priori, le découpage en 22 règles ne détonne pas : on y retrouve l’esprit des normes ISO 27001 et suivantes ainsi que celui du fameux guide des mesures d’hygiène de l’Anssi : on est donc en terrain connu. Mais dès la première règle (obligation de mettre en œuvre des analyses de risques, ce qui est normal en soi), on s’interroge. La règle est valable pour les systèmes d’information essentiels (SIE), et l’on comprend qu’elle ne vaut que pour les sous-systèmes du SI de l’OSE qui sont estimés « essentiels ». Il y a donc de fortes chances que le serveur Web de l’amicale de la pétanque des retraités du CHU ne soit pas concerné par la directive NIS, mais il y a de fortes chances aussi que la plupart des autres sous-systèmes le soient : Samu, bloc opératoire, mais également salles de réveil, logistique en lien direct avec le support aux soins, etc. Autant dire, dans un hôpital, tout ou presque à part la paye.

Les trois premières règles (analyse de risques, PSSI et homologations SSI) comportent des éléments qui ne sont pas spécialement triviaux, mais qui restent dans le domaine du faisable. À partir de la règle 4 (indicateurs), tout se complexifie méchamment. On se demande par exemple comment on va faire pour mesurer « le pourcentage de ressources dont les éléments secrets ne peuvent pas être modifiés par l’opérateur » : la mesure concerne-t-elle les middlewares, les OS, uniquement les serveurs ou aussi les PC, les PC au biomed rentrent-ils dans le calcul ?, etc. Pour un autre des indicateurs, là, on reste totalement interdit devant l’énormité de la tâche : « Pourcentage des ressources administrées dont l’administration est réalisée à partir d’un compte non spécifique d’administration. » Selon le sens donné à chaque terme de la phrase, le calcul peut prendre cinq minutes… ou trois mois.

À partir de la règle 6 et des suivantes, selon une rapide estimation, les mesures demandées sont impossibles à mettre en œuvre en totalité. Même leur mise en œuvre partielle va exiger une masse de travail considérable, et l’acquisition de systèmes matériels ou logiciels, voire les recrutements, est totalement impensable dans le contexte budgétaire que l’on sait. On trouve la sempiternelle mesure selon laquelle il ne faut installer dans un OS que la liste des services strictement indispensables au fonctionnement d’un système. Les paris sont ouverts : quelle est l’administration qui éteint les services non indispensables des OS de ses photocopieurs multifonctions ? De ses imprimantes départementales ? De ses serveurs de fichiers ? On enquille ensuite, dans les 16 règles qui suivent, toute la panoplie du parfait petit RSSI avec les mesures de cloisonnement, la sécurité de l’administration, la gestion des identités (même pour un établissement qui a déployé de l’IAM, plus de la moitié des mesures de cette section sont non opérationnelles, voire non envisageables), le maintien en condition opérationnelle, etc. Une bonne partie des mesures techniques précisées sont tout simplement impossibles à interpréter, sans parler de leur application.

À ce stade, trois questions se posent. D’abord, quels seront les heureux élus qui émargeront à la liste des OSE ? S’il s’agit des CHU uniquement, seuls ceux qui ne sont pas déjà OIV seront concernés. S’il s’agit d’étendre la liste à tous les établissements de santé qui disposent d’un service d’urgence et/ou d’un bloc opératoire, cela fait pas mal de monde et pas mal de « petits » établissements dans le lot : on trouve des établissements d’à peine 70 millions d’euros de budget annuel qui seraient éligibles, alors qu’ils disposent d’une DSI de moins de dix personnes. Ensuite, quelle sera la marge d’appréciation de la directive : doit-elle être envisagée comme un guide ou est-on dans le comminatoire ? Et dans la seconde hypothèse, quelles sont les amendes encourues en cas de non-respect ? À ce stade, l’analyse du juriste va être déterminante, et je me tourne vers mon coauteur. Les dernières pages de l’arrêté listent les délais accordés aux OSE pour se mettre en conformité en fonction de la nature des règles et, globalement, on a entre un et trois ans, autant dire rien. La troisième question est plus pragmatique. La directive NIS reprend, peu ou prou, les obligations de la LPM (loi de programmation militaire) déjà applicable aux OIV. Des CHU qui sont OIV, aucun ne respecte la moitié des dispositions de la directive NIS, et donc a fortiori de la LPM : quelles seront les incitations, pour les OSE (et les OIV existants) à respecter une directive V2 (NIS) dont la V1 (LPM) n’a pas été appliquée au sein des établissements de santé OIV ?

Si la directive est interprétée à la lettre et à la virgule par des pouvoirs publics tatillons, elle rejoindra la longue cohorte des textes qui sont rapidement passés aux oubliettes, telle l’authentification forte (3 % des établissements la respectent, chiffre issu de l’Asip), la messagerie sécurisée, et j’en passe. Et ce sera une belle occasion manquée, pour tout le monde. Si, en revanche, elle est vue par les pouvoirs publics comme un guide et que l’on s’en tient aux têtes de chapitre (les mesures techniques détaillées n’étant à apprécier que comme exemples), les RSSI y verront un outil de plus (comme le RGPD) pour faire progresser l’établissement. Et les RSSI vont y adhérer massivement, à commencer par votre serviteur.

[1] /article/3100/la-directive-nis-en-application-volet-ssi-partie-i.html 

[2] /article/3101/la-directive-nis-volet-juridique-partie-1.html