Skip to content

Être au rendez-vous de la directive NIS2

La sécurité des accès contribue directement à la conformité NIS2

RGPD, CSA, CRA, NIS (NIS 2), DORA, LPM, SOX, PCI-DSS, SOC2, HIPAA, TISAX, IEC42663, NIST800-53, ISO27001/27002, ANSSI PA022/PAMS, … Qu’elles soient légales, sectorielles ou de cybersécurité, les obligations réglementaires se démultiplient, et accroissent la pression sur un nombre croissant d’entreprises et d’organisations. C’est évidemment le cas de la directive NIS 2, dont la transposition nationale doit atterrir en octobre 2024, pour devenir applicable dans les mois et les années à venir. Dans cet article, nous décryptons la directive NIS2, et nous illustrons la manière dont l’offre cyberelements de Systancia contribuent à l’atteinte des objectifs fixés par cette directive.

Qu’y a-t-il de nouveau par rapport à « NIS 1 » ?

La directive NIS 2, c’est un long préambule de 150 paragraphes sur la situation de la cybersécurité en Europe, et une 50aine d’articles décrivant la gouvernance et le fonctionnement opérationnel de la cybersécurité en Europe.

C’est avant tout la mise en place d’un écosystème d’organisations coopérantes pour la résilience cyber européenne. La figure ci-jointe synthétise cet écosystème, avec des acteurs européens à gauche (à commencer par la commission européenne d’où « tout part »), des acteurs nationaux au centre (avec les acteurs nationaux de référence et les réseaux d’acteurs), et enfin les entreprises et les organisations concernées à droite (désormais appelées « entités essentielles » et « entités importantes »). La figure indique, de manière simplifiée, les types d’interactions entre ces organisations, et des numéros font référence aux articles de la NIS 2 qui établissent les rôles et interactions entre ces organisations.

NIS Compliance
Figure 1 : un écosystème européen pour la résilience cyber

Les autres aspects novateurs de la directive, et qui font l’objet de la plupart des communications à son sujet, sont :

  • Le nombre d’organisations désormais concernées et soumises aux obligations de la directive (en termes de secteurs et de tailles, que ce soit en termes RH ou financiers) : on passe de 15 000 opérateurs à plus de 100 000 au niveau européen ; de quelques centaines à des milliers au niveau national ;
  • La responsabilité personnelle des dirigeants de ces organisations ainsi que les pénalités potentielles en cas de « non-conformité » (en % du chiffre d’affaires) ;
  • Les obligations en matière de notifications d’incidents de sécurité (délais ramenés à 24 heures) et de divulgations des vulnérabilités connues ;
  • Le rôle des agences nationales (ANSSI) évolue, d’une part par rapport au rôle de l’agence européenne (ENISA), et d’autre part par rapport au rôle national (étant donné le nombre d’organisations concernées, l’ANSSI aura besoin de partenaires pour accomplir ses missions).

L’article charnière : l’article 21

Au niveau de la directive NIS 2, l’article qui prescrit les obligations les plus opérationnelles pour les entités concernées est l’article 21. Il présente les mesures que ces entités doivent mettre en œuvre pour satisfaire aux exigences de la NIS 2 : ces mesures sont ensuite déclinées en objectifs, selon quatre axes principaux :

  • Gouvernance: tout commence par une analyse des risques cyber ; la sensibilisation et la formation du personnel à la cybersécurité, et l’application de bonnes pratiques de cyber-hygiène, constituent « un socle de base » ; la sécurité de la chaîne d’approvisionnement, et notamment les exigences mises sur les fournisseurs et prestataires et le contrôle de ces derniers ; notamment dans le secteur numérique ou digital, où la divulgation des vulnérabilités connues est essentielle ; et enfin la mesure de l’efficacité des mesures prises.
  • Défense: toutes les mesures liées au traitement des incidents de sécurité.
  • Résilience: toutes les mesures liées à la continuité d’activité, incluant la gestion des sauvegardes et la reprise d’activité après un sinistre, ainsi que la gestion des crises.
  • Protection: tout ce qui concerne la cryptographie et le chiffrement (garantie de la confidentialité et de l’intégrité des données) ; les politiques de contrôle d’accès et de gestion des actifs ; enfin, l’utilisation de l’authentification multifactorielle et/ou de l’authentification continue. Nous noterons que cette dernière mesure est assez connotée « zero trust » : nous y reviendrons.

La transposition de la directive NIS 2 en loi nationale devrait se concentrer sur la déclinaison de ces mesures en objectifs et en règles à satisfaire. Y aura-t-il beaucoup de règles ou d’objectifs nouveaux par rapport à « NIS  1 » ? Depuis « NIS 1 », beaucoup a été fait, et des normes comme ISO 27001 ou des guides de l’ANSSI comme le PA022 ou le PAMS ont déjà apporté beaucoup de recommandations de déclinaison de ces mesures en exigences opérationnelles à respecter. La figure ci-jointe illustre la correspondance des thèmes adressés par les différentes directives et normes : NIS2, LPM, ISO 27001, ANSSI PA022 et PAMS. On observe une similitude et une cohérence des thèmes adressés : toute organisation certifiée ISO 27001 ou qui met en œuvre les recommandations de l’ANSSI dans leurs différents guides est déjà très bien préparée pour une conformité à la directive NIS 2.

Figure 2 : correspondance entre les différentes directives et normes

La protection par la gestion des identités et des accès

La gestion des identités et des accès est essentielle dans la protection des « Systèmes d’Information Réglementés » (SIR) (on appelle ainsi les systèmes d’information ‘métier’ ou de production des entités essentielles ou importantes). C’est un domaine central de l’axe « protection » des objectifs de la directive NIS2. Il peut se décliner en 3 thèmes principaux :

  • Un thème sur l’architecture du SIR,
  • Un thème pur « IAM » (Identity and Access Management), sur l’identification, l’authentification et les droits d’accès des utilisateurs des SIR,
  • Un thème sur l’administration des SIR, plutôt centré sur ce qu’on appelle les « accès à privilèges » (Privileged Access Management, PAM).

Une architecture qui protège

Un mot clé émerge comme principe architectural : le cloisonnement. L’entité doit cloisonner le SIR des autres SI, physiquement ou logiquement, et de même pour chaque sous-système du SIR. L’entité doit aussi mettre en œuvre des « passerelles entrantes » et des « passerelles sortantes » pour l’interconnexion du SIR avec d’autres SI. La sécurisation des accès distants est également un sujet de préoccupation, avec la mise en œuvre de mécanismes de chiffrement (tout ce qui est en dehors du SIR doit être chiffré) et de mécanismes d’authentification renforcés (dits « multifactoriels »). La protection du SIR contre l’intrusion de codes malveillants doit être assurée, avec une attention particulière portée à tous les dispositifs (matériel & logiciel) en interconnexion avec le SIR. Le SIR ne doit contenir que des ressources indispensables à son activité, et n’accepter que des connexions indispensables à son activité.

L’IAM : pierre angulaire de la protection

L’entité doit connaître et cartographier toutes les personnes et toutes les applications qui utilisent le SIR, et doit s’assurer que chacune y accède à l’aide de comptes individuels. Les comptes inutilisés doivent être désactivés, et les secrets d’authentification associés inopérants. Pour ce qui concerne l’authentification aux ressources du SIR, les mécanismes multifactoriels sont privilégiés (politique de gestion des facteurs), et un soin tout particulier doit être apporté aux secrets d’authentification (politique de gestion des secrets d’authentification, comme leur robustesse, leur complexité et leur changement fréquent). Toute tentative d’accès à une ressource du SIR doit être tracée. L’entité n’attribue de droits d’accès qu’à des utilisateurs (personnes ou applications) qui en ont besoin, qu’aux ressources dont ils ont besoin, et que pour la durée d’utilisation nécessaire. Ce sont les principes de base du zero-trust : l’accès aux ressources doit être octroyé sur la base du besoin d’en connaître, avec le plus faible niveau de privilège nécessaire pour réaliser la tâche, pour la durée de réalisation de la tâche, sans laisser de droit résiduel après la réalisation de la tâche. Il est aussi recommandé de réaliser régulièrement des campagnes de revue des droits d’accès sur les ressources du SIR.

Le PAM : une protection incontournable

On pourrait dire que le principe architectural de cloisonnement s’applique également à l’administration des SIR. Le Système d’Information d’Administration (SIA) d’un SIR doit être d’une certaine manière séparé du SIR : toutes les ressources utilisées pour l’administration du SIR (postes, réseaux, serveurs, infrastructures, etc.) doivent être exclusivement dédiées à l’administration du SIR, et ne peuvent pas être utilisées à d’autres fins. Il faut donc séparer les comptes d’administration des comptes utilisateurs, et les secrets d’authentification des administrateurs doivent être différents de ceux des utilisateurs « métier », quand il s’agit de la même personne (rôles différents). Il est interdit d’octroyer des droits d’administration à un utilisateur « métier », ou qu’un administrateur réalise des actions d’administration depuis son poste « utilisateur métier ». Les mêmes principes de base du zero-trust s’appliquent au SIA. Autant que faire se peut, on assurera une séparation des connexions réseaux sur les ressources entre la connexion utilisée pour l’administration de la ressource et celle utilisée pour son usage « métier ». Lorsque, pour des besoins d’administration (comme la mise à jour logicielle d’une ressource), des fichiers ou des données doivent être transférées dans le SIR, il conviendra de mettre en œuvre une architecture de « zones d’échange » de telle sorte que la zone d’échange accessible depuis le SIR ne soit pas accessible depuis une autre zone d’échange, et que le transfert de données entre zones d’échange procède par « diodes » de transferts de données sécurisées.

Figure 3 : SIA et SIR

L’apport de Systancia à l’atteinte des objectifs NIS2

La conformité à la directive NIS2 n’est évidemment pas qu’une affaire de solution technologique. C’est avant tout une question de gouvernance, de pilotage, d’organisation, de processus, de pratiques, … Mais quand on considère les objectifs de l’axe « Protection », on peut voir que les technologies de sécurisation des accès au SIR peuvent y contribuer directement, qu’il s’agisse de

  • la gestion des identités et des habilitations (IGA, Identity Governance and Administration),
  • l’authentification des utilisateurs (AM, Access Management ; UA, User Authentication ; SSO, Single Sign On ; MFA ; Multi-Factor Authentication),
  • l’accès distant sécurisé (VPN, Virtual Private Network ; ZTNA, Zero Trust Network Access) ou
  • l’accès à privilèges (PAM, Privileged Access Management).

Toutes ces technologies contribuent directement à la satisfaction de ces exigences. En reprenant chacun des domaines de l’axe « Protection », illustrons comment certaines capacités ou fonctionnalités des produits participent à l’effort de conformité à la directive NIS2 :

Architecture

  • Architecture à double barrière avec tunnels cryptés de bout en bout ;
  • Cloisonnement organisationnel (multi-tenants) et réseau (passerelles avec flux sortants sans ouverture de ports réseaux) ;
  • Accès prestataire sans client sur le poste avec rupture protocolaire ;
  • Protection contre les attaques grâce aux ports volatiles et aléatoires, à la réécriture d’url, à l’isolation par déport d’affichage ;
  • L’intégration avec les outils de gestion des informations et des événements de sécurité.

IAM

  • Application d’une politique d’accès zero-trust ;
  • Provisioning et de-provisioning automatique des comptes et des droits à partir de règles d’habilitations centralisées ;
  • Coffre-fort de secrets d’authentification, orientés ressources et orientés utilisateurs, et application de politiques de mots de passe et de rotations de mots de passe ;
  • Gestion de revues de droits (campagnes de certifications) et assurance de la séparation des pouvoirs (« segregation of duty », SoD) ;
  • Workflows de demandes d’accès, avec traçabilité des demandes (accès « juste à temps ») ;
  • Authentification primaire renforcée (multi-facteurs) et authentification secondaire transparente, non divulgation de mots de passe ;
  • Analyse du contexte et du comportement de l’utilisateur et de son terminal.

PAM

  • Bastion unique et dédié pour l’accès depuis le réseau d’entreprise par les administrateurs internes et depuis Internet par les prestataires ;
  • Connexion SIA-SIR via tunnels cryptés et accès conditionnels zero-trust ;
  • Traçabilité détaillée dans des journaux d’audit et enregistrement de toutes les actions et de toutes les sessions d’accès aux ressources critiques ;
  • Le cas échéant, respect d’une organisation de l’annuaire en silos (« AD tiering ») et de l’accès sécurisé à la Privileged Access Workstation (PAW) sans protocole entrant ;
  • Protection et non-divulgation des secrets d’authentification (mots de passe, clés, certificats), également ceux utilisés par les applications, les scripts et d’autres identités non humaines dans les chaînes DevOps et CI/CD.

La meilleure préparation à NIS2 consiste à engager ou poursuivre les efforts avec un programme corporate de cybersécurité à 360°. On sait désormais que les aspects organisationnels et technologiques s’entremêlent et doivent être gérés de concert. Chacune des mesures à mettre en œuvre s’appuie sur un socle technologique pour atteindre les objectifs de cybersécurité attendus, qu’il s’agisse de l’analyse de risques, de l’évaluation de sa posture de sécurité (comprenant l’analyse de la surface d’attaque), de la sensibilisation et de la formation du personnel, de la gestion des incidents de sécurité, etc. Pour ce qui concerne le domaine de la protection, plus spécifiquement adressé dans cet article, une attention particulière sera portée sur les aspects suivants :

  • L’adoption d’une approche zero trust, que ce soit du point de vue fonctionnelle ou du point de vue architecturel. Les approches classiques considérant le réseau d’entreprise comme le périmètre de sécurité, avec des politiques d’accès relativement statiques, ne sont pas adaptées dans un monde où « Internet devient le réseau de l’entreprise » (environnement de travail hybride, accès prestataires, services cloud, y compris « les réseaux en services cloud » (SD-WAN), …)
  • Dans ce monde post-périmétrique, le nouveau périmètre de sécurité est dynamique et défini par la règle d’accès qui tient compte du contexte de l’utilisateur et de la tâche qu’il doit réaliser sur la ressource à l’instant t. Il s’agit donc de surcharger les règles d’habilitations avec des conditions d’accès, et d’implémenter une politique d’accès zero trust ET de déployer une infrastructure d’accès zero trust.
  • La protection contre l’intrusion de charges malveillantes n’est pas qu’une affaire de surveillance et de détection : c’est aussi une affaire d’empêchement et de barrage, et cela passe par des caractéristiques de l’infrastructure d’accès, et de toute la chaîne d’accès de bout en bout, depuis le terminal de l’utilisateur jusqu’à la ressource à laquelle il se connecte. Si le code malveillant n’a aucun moyen de passer, il n’y a plus besoin de le détecter.
  • La protection spéciale des comptes à privilèges. Ce sont les comptes qui, s’ils sont usurpés, vont donner le plus de possibilités aux cyberacteurs. Il faut gérer ces comptes de manière très stricte (les limiter, donc les provisionner et les dé-provisionner, éviter les comptes orphelins, réduire la durée des secrets liées à ces comptes, etc.).