Directive NIS2 : Guide de conformité étape par étape

Besoin d’un guide en profondeur sur la conformité avec NIS2 ? Nous avons passé en revue la législation et créé un plan d’action pour mieux préparer la nouvelle directive européenne.

La transposition de la directive NIS2 en droit national par les États membres est attendue pour septembre 2024 au plus tard. Néanmoins, il existe déjà de nombreuses lignes directrices sur les actions à mener, et leur mise en œuvre devrait prémâcher une bonne partie du travail, si ce n’est la totalité.

Nous avons donc établi une liste des bonnes pratiques à adopter pour assurer la conformité avec la directive NIS2.

Elle s’adresse principalement aux Responsables de la Sécurité des Systèmes d’Information (RSSI), mais peut aussi être utile aux Délégués à la protection des données (DPO) et aux services juridiques.

Par ailleurs, précisons que cette liste est le résultat d’un travail personnel et se base sur le texte final de la NIS2 et le briefing du 16 juin 2022 – qui seront régulièrement cités comme sources. Toutefois, elle ne se veut pas exhaustive et est susceptible d’évoluer au fur et à mesure que la législation se précise. Il appartient donc à chacun de veiller à sa mise en conformité, et en particulier au regard des futures lois nationales. En effet, la transposition de la directive à l’échelle nationale devrait également apporter son lot de nuances dans son application.

Qu’est-ce que la directive NIS2 ?

La directive NIS2 est un texte législatif de l’Union européenne sur la cybersécurité. Elle remplace la directive NIS première du nom (Network and Information Security), adoptée en juillet 2016.

La directive NIS2 renforce les exigences en matière de sécurité au sein de l’UE grâce à :

• un élargissement de son champ d’application à plus de secteurs et d’entités
• une prise en compte de la sécurité des chaînes d’approvisionnement
• une rationalisation des obligations de reporting
• l’introduction de mesures de surveillance
• des exigences d’exécution plus strictes
• une notion de responsabilité des organes de direction au sein des entreprises
• une harmonisation et un durcissement des sanctions au sein de tous les États membres

Quand la directive NIS2 entrera-t-elle en vigueur ?

Octobre 2024 au plus tard. La directive NIS2 a été publiée au Journal Officiel de l’UE le 27 décembre 2022. À partir de cette date, les États membres ont 21 mois pour transposer la directive dans leur droit national, c’est-à-dire en octobre 2024.

Toutefois, il convient de noter qu’il s’agit de la date limite de transposition en droit national pour les États membres, et non de la date de mise en conformité pour les entités soumises au NIS2. Celles-ci disposeront très probablement d’un délai supplémentaire pour se conformer à la directive dès qu’elle sera appliquée dans leurs pays respectifs.

NIS2: un renforcement du rôle du RSSI

La NIS2 est une occasion en or pour tous les RSSI de renforcer leur position au sein de l’entreprise. La directive amène une notion de responsabilité de la direction en matière de gestion du risque, ainsi que de lourdes sanctions pour les contrevenants. Le RSSI n’est ici pas un simple conseiller, mais bien un guide et leader sur les décisions à prendre, aussi bien sur des sujets techniques que business. Avec NIS2, le CISO devient également un formateur pour les cadres supérieurs, un évangéliste des lignes de conduite et des bonnes pratiques en matière de cybersécurité.

En jouant ses cartes correctement, chaque RSSI devrait accompagner cette responsabilisation d’une hausse de son budget et de son champ d’action. Avec à la clé toujours le même objectif : une meilleure sécurité globale.

Reste maintenant à savoir quelles sont les actions à mener. En tant que RSSI, votre plan d’action de mise en conformité avec NIS2 se concentra autour de 3 axes principaux :

• La gouvernance
• La détection et la réponse aux incidents
• La sécurisation et le contrôle des périmètres et des actifs

1. Déterminez si vous êtes affecté par NIS2

NIS2 vient élargir le champ d’application de la directive NIS, en incluant davantage de secteurs et de typologies d’entités privées et publiques. Avant toute chose, il est donc essentiel de savoir si vous êtes concerné par le texte.

Déterminez si vous êtes une Entité Essentielle (EE) ou une Entité Importante (IE)

La première directive NIS s’applique aux DSP (Digital Services Providers) et aux OES (Operators of Essential Services). Ces terminologies disparaissent avec la NIS2 – même si concrètement, les entités visées par NIS le sont aussi avec NIS2.

Pour son champ d’application, la directive NIS2 distingue deux types d’entités :

• les Entités Essentielles (EE), détaillées dans l’Annexe I du texte NIS2
• les Entités Importantes (IE), détaillées dans l’Annexe II du texte NIS2

Les Entités Essentielles (EE) visent les secteurs :

• de l’énergie
• du transport
• de la banque
• des infrastructures des marchés financiers
• de la santé
• de l’eau potable
• des eaux usées
• des infrastructures numériques – fournisseurs de services de cloud computing, de data centers, de DNS, etc.
• de la gestion des services TIC (interentreprises), soit les Fournisseurs de services gérés et Fournisseurs de services de sécurité gérés
• des administrations publiques
• de l’espace

Les Entités Importantes (IE) visent les secteurs :

• des services postaux et des services de courrier ;
• de la gestion des déchets ;
• de la fabrication, production et distribution de produits chimiques ;
• de la production, transformation et distribution de denrées alimentaires ;
• de la fabrication de :
  • de dispositifs médicaux et de dispositifs médicaux de diagnostic in vitro
  • de produits informatiques, électroniques et optiques
  • d’équipements électriques
  • de machines et d’équipements n.c.a.
  • de véhicules à moteur, de remorques et de semi-remorques
  • d’autres équipements de transport
• des fournisseurs de services numériques suivants :
  • les marketplace en ligne
  • les moteurs de recherche
  • les plateformes de services de réseaux sociaux
• de la recherche, soit les organismes de recherche au sens de “une entité dont l’objectif premier est de mener des activités de recherche appliquée ou de développement expérimental en vue d’exploiter les résultats de cette recherche à des fins commerciales, à l’exclusion des établissements d’enseignement.” (Article 6(41))

Déterminez si la taille de votre entité vous assujettit à NIS2

La directive NIS2 concerne uniquement les moyennes et grandes entreprises. En effet, la NIS2 introduit dans son Article 2 une notion de taille des entités qui n’existait pas avec la première itération. A noter que les micros et petites entreprises au sens de la Commission Recommendation 2003/361/EC ne sont pas concernées par la législation.

Liste des exceptions, quelle que soit la taille de l’entité

Mais attention, il existe des exceptions. Certaines entités sont assujetties à NIS2 peu importe leur taille, si l’une des conditions suivantes est remplie :

• les services sont fournis par :
  • des réseaux de communications électroniques publics ou des services de communications électroniques accessibles au public
  • des prestataires de services de confiance (cf. Annexe I)
  • des registres de noms de domaine TLD ou des fournisseurs de DNS

• l’entité est une administration publique ;
  • des pouvoirs publics centraux tels qu’ils sont définis par un État membre ;
  • ou au niveau régional, tel qu’il est défini par un État membre conformément au droit national, qui, à la suite d’une évaluation basée sur les risques, fournit des services dont la perturbation pourrait avoir un impact important sur des activités sociétales ou économiques critiques.

• l’entité est le seul prestataire d’un service dans un État membre ;
• une perturbation potentielle du service fourni par l’entité pourrait avoir un impact sur la sûreté publique, la sécurité publique ou la santé publique ;
• une perturbation potentielle du service fourni par l’entité pourrait induire des risques systémiques, en particulier pour les secteurs où cette perturbation pourrait avoir un impact transfrontalier ;
• l‘entité est critique en raison de son importance spécifique au niveau régional ou national pour le secteur ou le type de service particulier, ou pour d’autres secteurs interdépendants dans l’État membre ;
• l’entité est identifiée comme critique au titre de la Directive (UE) 2022/2557 – alias la Directive sur la résilience des entités critiques (CER). Les entités critiques au regard de cette directive sont détaillées dans son Article 6 et son Annexe. Spoiler : ce sont à peu de chose près les mêmes que les entités critiques au sens de NIS2.

La NIS2 prévoit que chaque État membre devra dresser une liste des entités nationales visées par les points ci-dessus.

Vérifier si vous relevez d’une autre législation spécifique à votre secteur

Certains secteurs d’activité, notamment les plus critiques, sont soumis à d’autres législations ayant trait à la cybersécurité. Elles viennent parfois compléter la directive NIS2, voire la supplanter en vertu du principe de “lex specialis” – une loi spécifique prime sur une loi généraliste. Il est donc important de savoir si vous êtes concerné par d’autres législations.

On peut trouver quelques pistes dans le Rapport d’évaluation d’impact qui accompagne la proposition de directive NIS2 (Document 3/3, page 46). Ce dernier explique que :

• Pour le secteur financier, le règlement DORA (Digital Operational Resilience Act) est dit “lex specialis” par rapport à la directive NIS2, en “établissant des exigences consolidées, simplifiées et améliorées en matière de risques liés aux TIC dans l’ensemble du secteur financier”. Au besoin, voici un lien vers notre guide de conformité DORA pour le secteur financier ;
• Pour le secteur de l’énergie, c’est la Risk Preparedness Regulation qui est citée comme complément de la NIS2. Il en va de même pour la Régulation (EU) 2017/1938 visant à garantir la sécurité du gaz ;
• Pour le secteur du transport, plusieurs initiatives européennes sont citées, notamment pour l’aviation et le transport maritime ;
• Pour les réseaux et services de communications électroniques, c’est le Code Européen des Communications Électroniques (EECC) qui est largement détaillé.

2. Sensibilisez le top management aux sanctions et amendes prévues par NIS2

La directive NIS2 se veut bien plus dissuasive que son aînée. Pour se faire entendre, elle prévoit deux axes de sanctions :

• des amendes administratives lourdes et chiffrées ;
• une responsabilité des hauts responsables et des cadres de niveau C au sein des organisations.

Il est du ressort du RSSI – mais pas seulement – de faire connaître clairement au personnel dirigeant les sanctions prévues par la directive NIS2. Pour dire les choses clairement, cette épée de Damoclès devrait aider les RSSI à faire accepter leurs décisions et les inhérentes hausses du budget afférentes.

A titre d’information, toutes les sanctions et amendes décrites plus avant sont explicitées le Chapitre VII, Supervision et Exécution (Articles 32, 33 et 34).

Des amendes jusqu’à “au moins” 10M€ ou 2% du CA annuel mondial

NIS2 précise et renforce les amendes prévues par la loi en cas de non respect :

• des obligations de reporting, prévues à l’Article 23
• des mesures de gestion du risque de cybersécurité, prévues à l’Article 21

L’Article 34(4) de la Directive NIS2 prévoit des amendes administratives en cas de manquement à ces obligations (ndlr : nous y reviendrons plus loin dans cet article). Ces amendes sont différentes selon que l’entité est Importante ou Essentielle :

• Pour les Entités Importantes (EI), la directive NIS2 prévoit “des amendes administratives d’un montant maximal s’élevant à au moins 7 millions d’euros ou à au moins 1,4% du chiffre d’affaires annuel mondial total de l’exercice précédent de l’entreprise à laquelle l’entité importante appartient, le montant le plus élevé étant retenu.”
• Pour les Entités Essentielles (EE), ce sont “des amendes administratives d’un montant maximal s’élevant à au moins 10 millions d’euros ou à au moins 2% du chiffre d’affaires annuel mondial total de l’exercice précédent de l’entreprise à laquelle l’entité essentielle appartient, le montant le plus élevé étant retenu.”

Oui, vous avez bien lu, “au moins”. Le texte provisoire de NIS2 prévoyait des amendes “jusqu’à” 7 M€ pour les EI et 10 M€ pour les EE, mais le texte final de NIS2 prévoit des amendes de “au moins” 7 et 10 millions respectivement.

Par ailleurs, les États membres sont autorisés à assortir ces amendes de leurs propres lois et sanctions nationales.

Une responsabilité des “organes de direction” en matière de la gestion du risque de cybersécurité

La directive NIS2 amène une notion de responsabilité du top management en matière de sécurité – et plus précisément des “organes de direction” selon le texte final. L’objectif ici est clair : induire l’appropriation du risque par les cadres supérieurs et le conseil d’administration pour garantir une meilleure gouvernance. La perspective de sanctions est plus efficace lorsque les individus sont clairement identifiés comme responsables.

Le rapporteur au Parlement européen, M. Bart Groothuis, nous a expliqué :

“La différence la plus importante entre NIS2 et NIS1 mais aussi les législations d’autres pays est, comme on dit en Allemagne, le Chefsache. C’est une affaire de chef, de conseil d’administration. La cybersécurité, ça ne peut plus être de dire à un informaticien : “OK, peu importe, fais ce que tu veux“.

Le PDG et le conseil d’administration doivent être au courant des dernières évolutions sur ce qu’il faut faire, comment prendre le contrôle, où ils en sont en tant qu’organisation. Par conséquent, il y a une amende personnelle pour le PDG. Cette amende a été définie de 1,4 à 2% pour les Entités Essentielles. Pourquoi ? Parce que les groupes de ransomware, lorsqu’ils piratent un réseau, demandent 1,4 à 2 %.

C’est donc une façon d’influencer le calcul, en disant : voulez-vous payer des groupes de ransomware, voulez-vous payer une amende, ou voulez-vous simplement investir une petite somme d’argent dans la cybersécurité ? Je m’attends à ce que si le PDG devient parfaitement responsable, il veillera à ce que ce soit la dernière solution.”

– M. le député Bart Groothuis

NIS2: les sanctions prévues pour le top management

Très concrètement, NIS2 permet aux autorités des États membres d’ordonner aux entités contrevenantes :

• de rendre publics les aspects de non-conformité avec la directive ;
• de faire une déclaration publique qui identifie la ou les personnes physiques et morales responsables de la violation, et la nature de cette violation ;

Dans le cadre d’une Entité Essentielle (EE), ces sanctions peuvent aller jusqu’à :

• la suspension des certifications et autorisations concernant les services ou activités fournis par l’organisation ;
• une interdiction temporaire d’exercer des fonctions de direction au sein de l’entité pour toute personne exerçant des responsabilités de direction à un niveau de directeur général ou de représentant légal.

Il convient de préciser que ces dernières mesures d’exécution ne sont pas applicables aux entités de l’administration publiques qui relèvent de la présente directive.

3. Éduquez et formez les cadres supérieurs à la gestion du risque en matière de cybersécurité

Heureusement, la directive ne se cantonne pas à faire planer des sanctions sur le top management. NIS2 préconise la formation et la responsabilisation des dirigeants en matière de gestion des risques. En tant que RSSI, vous êtes l’un des mieux placés pour endosser ce rôle au sein de l’entreprise – ou du moins pour orienter le choix du prestataire de formation.

Des obligations de formations régulières pour les top managers

En matière de gouvernance, l’Article 20 dispose que les organes de direction des entités essentielles et importantes doivent :

• approuver les mesures de gestion du risque de cybersécurité prises par ces entités ;
• superviser leur mise en œuvre (et répondre des manquements) ;
• suivre “des formations, sur une base régulière”, afin d’acquérir des compétences suffisantes pour déterminer les risques et évaluer les pratiques de gestion des risques en matière de cybersécurité et leur impact sur les services fournis par l’entité. La directive encourage également une formation similaire pour les employés sur une base régulière.

NIS2 : quelle formation choisir ?

Après une lecture du texte final de bout en bout, nous n’avons malheureusement pas la réponse. NIS2 ne précise pas le contenu de ces formations, ni les conditions pour prouver qu’elles ont été suivies.

Cela étant dit, il y a de nombreux sujets à considérer si l’on veut “acquérir des connaissances et des compétences suffisantes pour appréhender et évaluer les risques de cybersécurité et les pratiques de gestion“. Principes de zero-trust, cyber-menaces, techniques de phishing et d’ingénierie sociale, obligations de conformité, il y a du pain sur la planche !

De plus, il existe d’ores et déjà plusieurs moyens de sensibiliser les collaborateurs de tous niveaux à la gestion du risque en cybersécurité, ainsi qu’aux bonnes pratiques les plus élémentaires. En France par exemple, on pense notamment au MOOC de l’ANSSI qui couvre les bases en matière de sécurité numérique. Ce dispositif est gratuit et débouche sur une attestation de réussite (la formation n’est cependant pas certifiante). Ce dispositif est gratuit et débouche sur une attestation de réussite (la formation n’est cependant pas certifiante).

Nous vous conseillons également de vous rapprocher des cabinets de conseil présents dans votre pays, qui ne manqueront pas d’offrir des séminaires et formations répondant aux exigences de NIS2, de DORA et de l’EU Cyber Resilience Act.

Les Live Hacking Events, une formation de terrain pour les équipes opérationnelles

Chez Yogosha, nous aimons les approches de terrain. C’est pourquoi nous organisons des Live Hacking Events ; des événements de hacking en direct qui réunissent le temps de quelques jours les équipes internes du client et des hackers de la Yogosha Strike Force.

Disons-le d’emblée, les Live Hacking Events ne sont probablement pas la meilleure approche pour sensibiliser le top management à la gestion des risques. En revanche, c’est une excellente opportunité de formation pour les équipes opérationnelles, que ce soit les développeurs ou les équipes de sécurité.

Organiser un Live Hacking Event permet de mettre ses équipes au défi dans des conditions réelles, avec une véritable philosophie Red Team contre Blue Team. Nos hunters découvrent des vulnérabilités, et vos équipes travaillent à la remédiation en temps réel.

4. Planifiez et chiffrez l’augmentation du budget

La directive NIS2 va inévitablement engendrer une hausse des dépenses pour les entreprises concernées. En tant que RSSI, il peut être bienvenu de planifier cette augmentation dès aujourd’hui. Cela vous apportera de la visibilité sur votre champ d’action, et vous permettra de faire valider vos décisions au plus tôt par le conseil d’administration.

Il n’existe évidemment aucune formule magique universelle pour calculer cette hausse du budget, tant elle dépendra du niveau de maturité et de gouvernance déjà existant dans chaque organisation. Néanmoins, le briefing de la directive NIS2 donne quelques indications chiffrées sur les augmentations à prévoir.

NIS2 : les chiffres prévisionnels pour l’augmentation du budget TIC

Dans les 3 à 4 ans suivant la mise en œuvre du NIS2, on prévoit que les dépenses en matière de sécurité augmenteront en moyenne de :

• 12 % pour les secteurs déjà couverts par NIS ;
• jusqu’à 22 % pour les secteurs et types de services ajoutés au champ d’application de NIS2.

Dans le même temps, la directive NIS2 réduirait le coût global des incidents de cybersécurité de 11,3 milliards d’euros.

Pour les budgets nationaux et les administrations, une augmentation estimée à environ 20-30% des ressources serait à prévoir à court et moyen terme.

Source : Ces projections sont détaillées dans l’Impact Assessment Report 1/3, p.77. Des projections des coûts sectoriels moyens sont données pages 72 et 73.

Renseignez-vous sur les aides financières auxquelles vous pourriez être éligible

Une partie des coûts pour les organisations peuvent être supportés par différentes aides financières. Il existe des aides à l’échelle européenne, comme le Programme pour une Europe numérique (DIGITAL) qui prévoit 7,5 milliards d’euros de financement pour 2021 à 2027.

En France, les organisations peuvent bénéficier du soutien financier du plan France Relance. Pour information, les opérations de sécurité menées avec Yogosha permettent de bénéficier de ces financements.

A titre d’exemple, nous avons mené une opération de bug bounty mutualisée pour les collectivités territoriales françaises, financée à hauteur de 70% par le volet cybersécurité du plan France Relance et avec le soutien de l’ANSSI. 50 des meilleurs hackers de la Yogosha Strike Force ont ainsi pu tester les 15 logiciels les plus utilisés par les villes françaises, avec une seule et même dépense pour les collectivités.

Lire aussi : La sécurité collaborative pour protéger les collectivités et les administrations publiques

5. Passez en revue les 10 mesures de gestion du risque de cybersécurité exigées par la directive NIS2

Si chaque CISO ne devait retenir qu’un seul point de cet article, ce serait celui-là.

Le texte définitif de la NIS2 indique clairement que les Entités Essentielles et Importantes doivent prendre :

“les mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées pour gérer les risques qui menacent la sécurité des réseaux et des systèmes d’information que ces entités utilisent dans le cadre de leurs activités ou de la fourniture de leurs services, ainsi que pour éliminer ou réduire les conséquences que les incidents ont sur les destinataires de leurs services et sur d’autres services.” – NIS2, Article 21

Selon la législation (Article 21), les EE et les EI doivent appliquer à minima les 10 mesures suivantes :

• des politiques relatives à l’analyse des risques et à la sécurité des systèmes d’information ;
• traitement des incidents (prévention, détection et réponse aux incidents) ;
• la gestion des crises et la continuité des activités, comme la gestion des sauvegardes et la reprise des activités ;
• la sécurité de la chaîne d’approvisionnement, y compris les aspects liés à la sécurité concernant les relations entre chaque entité et ses fournisseurs ou prestataires de services directs ;
• la sécurité de l’acquisition, du développement et de la maintenance des réseaux et des systèmes d’information, y compris le traitement et la divulgation des vulnérabilités ;
• des politiques et procédures (tests et audits) visant à évaluer l’efficacité des mesures de gestion des risques liés à la cybersécurité ;
• des pratiques de base en matière de cyberhygiène et la formation à la cybersécurité ;
• des politiques et des procédures relatives à l’utilisation de la cryptographie et, le cas échéant, du chiffrement ;
• la sécurité des ressources humaines, des politiques de contrôle d’accès et la gestion des actifs ;
• l’utilisation de solutions d’authentification à plusieurs facteurs ou d’authentification continue, de communications vocales, vidéo et textuelles sécurisées et de systèmes sécurisés de communication d’urgence au sein de l’entité, selon les besoins.

6. Rationalisez la réponse aux incidents

NIS2 renforce les obligations de réponse aux incidents et réduit certains délais. En tant que RSSI, cela devrait être l’une de vos premières priorités.

Rédigez et documentez votre plan de réponse aux incidents

La première chose à faire est de rédiger (ou réviser) et documenter votre plan de réponse aux incidents. La mise en place de procédures et de politiques de réponse aux incidents vous aidera à accélérer le processus lorsque vous serez confronté à une obligation de réponse.

Si vous ne savez pas par où commencer, voici un guide intéressant de HyperProof sur la conception d’un plan de réponse aux incidents de cybersécurité. Pour ce qui est des obligations de réponse spécifiques à NIS2, nous vous invitons à poursuivre votre lecture.

NIS2 : Incidents et cybermenaces

Le critère du “nombre d’utilisateurs touchés” utilisé dans la première directive NIS a été abandonné. En ce qui concerne les obligations de réponse aux incidents, la directive NIS2 est basée sur deux concepts distincts :

1. les incidents : c’est-à-dire “un événement compromettant la disponibilité, l’authenticité, l’intégrité ou la confidentialité des données stockées, transmises ou faisant l’objet d’un traitement, ou des services que les réseaux et systèmes d’information offrent ou rendent accessibles” selon l’Article 6(6);
2. les cybermenaces : c’est-à-dire “toute circonstance, événement ou action potentiels susceptibles d’endommager, de perturber ou de nuire d’une autre manière aux systèmes de réseau et d’information, aux utilisateurs de ces systèmes et à d’autres personnes”, aux termes de l’Article 2(8) du Cybersecurity Act, lui-même mentionné à l’Article 6(10) de NIS2.

L’article 23 prévoit qu’un incident est considéré comme important si :

1. il a causé ou est susceptible de causer une perturbation opérationnelle grave des services ou des pertes financières pour l’entité concernée ;
2. l’incident a affecté ou a le potentiel d’affecter d’autres personnes physiques ou morales en causant des pertes matérielles ou non matérielles substantielles.

Que faire en cas d’incident important ou de cybermenace ?

En cas de cybermenace ou d’incident important, les entités essentielles et importantes doivent notifier, sans délai injustifié :

• les autorités compétentes ou le CSIRT national, en veillant également à communiquer toute information permettant de déterminer un éventuel impact transfrontalier de l’incident ;
• le cas échéant, les destinataires de leurs services si l’incident est susceptible de porter atteinte à la fourniture de ce service ;
• le cas échéant, les destinataires de la menace elle-même. Dans le cadre d’une cybermenace importante, il convient également de notifier les mesures ou remèdes qui peuvent être adoptés en réponse.

En ce qui concerne les obligations de réponse aux autorités compétentes ou au CSIRT, les entités doivent rapporter :

1. une notification initiale dans les 24 heures après avoir pris connaissance de l’incident, en indiquant si celui-ci est vraisemblablement causé par des actes illicites ou malveillants ou s’il pourrait avoir un impact transfrontière ;
2. dans les 72 heures après avoir eu connaissance de l’incident important, une notification d’incident qui, le cas échéant, met à jour les informations précédentes et fournit une évaluation initiale de l’incident important, y compris de sa gravité et de son impact, ainsi que des indicateurs de compromission, lorsqu’ils sont disponibles ;
3. à la demande d’une autorité compétente ou d’un CSIRT, un rapport intermédiaire sur les évolutions pertinentes de la situation ;
4. un rapport final au plus tard un mois après la remise du premier rapport, incluant au moins les éléments suivants :
   • une description détaillée de l’incident, de sa gravité et de son impact ;
   • le type de menace ou la raison qui a probablement déclenché l’incident ;
   • les mesures correctives appliquées et en cours ;
   • le cas échéant, l’impact transfrontière de l’incident.
5. Si l’incident est toujours en cours au moment de la présentation du rapport final, les entités doivent fournir un rapport d’étape puis un rapport final dans un délai d’un mois à compter du traitement de l’incident.

NIS2: Qui sont les “autorités compétentes” ?

Les États membres disposent de leurs propres CSIRT (Computer Security Incident Response Teams) auxquels les incidents peuvent être signalés. Certains pays ont également des autorités compétentes désignées. En ce qui concerne la directive NIS actuelle, ce sont l’ANSSI en France, le CCB en Belgique et le BSI en Allemagne.

7. Évaluez la sécurité de la chaîne d’approvisionnement

La sécurité de la chaîne d’approvisionnement était un angle mort de la première directive NIS. La NIS2 vient combler cette lacune. Le préambule 85 du texte final explique :

“Il est tout particulièrement important de répondre aux risques découlant de la chaîne d’approvisionnement d’une entité et de ses relations avec ses fournisseurs […] vu la prévalence d’incidents dans le cadre desquels les entités ont été victimes de cyberattaques et où des acteurs malveillants ont réussi à compromettre la sécurité des réseaux et systèmes d’information d’une entité en exploitant les vulnérabilités touchant les produits et les services de tiers. Les entités essentielles et importantes devraient donc évaluer et prendre en compte la qualité et la résilience globales des produits et des services, les mesures de gestion des risques en matière de cybersécurité qui y sont intégrées et les pratiques de cybersécurité de leurs fournisseurs et prestataires de services, y compris de leurs procédures de développement sécurisées. Les entités essentielles et importantes devraient en particulier être encouragées à intégrer des mesures de gestion des risques en matière de cybersécurité dans les accords contractuels conclus avec leurs fournisseurs et prestataires de services directs. Ces entités pourraient prendre en considération les risques découlant d’autres niveaux de fournisseurs et de prestataires de services.”

– NIS2, Préambule 85

Très concrètement, c’est un effet ricochet. Les organisations qui fournissent certains services aux entités visées par NIS2 vont de facto être amenées à renforcer leur sécurité numérique, quand bien même elles ne seraient pas explicitement incluses dans le champ d’application de la directive. En tant que RSSI, il est donc crucial d’évaluer la bonne sécurité de la chaîne d’approvisionnement.

Les EE et EI doivent mener une évaluation des risques poussée de leur chaîne d’approvisionnement, à commencer par leurs fournisseurs directs. Le Préambule 86 met particulièrement l’accent sur les MSSPs dans les domaines :

• de la réponse aux incidents ;
• des tests d’intrusion ;
• des audits de sécurité ;
• et du conseil.

La NIS2 enjoint donc les organismes à faire preuve d’une diligence accrue dans leurs choix de MSSPs.Précisons ici que puisque Yogosha propose des Pentests as a Service, nous serons probablement soumis à ces exigences de diligence accrue. Nous prenons d’ores et déjà nos dispositions pour justifier de la bonne sécurité de nos environnements – la certification ISO 27001 par exemple.

Yogosha : un Vulnerability Operations Center pour impliquer les équipes métiers des partenaires

Yogosha est un VOC, un Vulnerability Operations Center. Le VOC est à la sécurité offensive ce que le SOC est à la sécurité défensive. Et puisque la sécurité ne se fait jamais seule, notre plateforme est avant tout un espace de collaboration.

Le VOC permet à nos clients de réunir leurs propres équipes de développements et de sécurité, mais aussi celles de leurs partenaires. La technologie Yogosha permet d’impliquer concrètement les équipes métiers des fournisseurs dans une sécurité proactive et responsabilisante. Si un client a un partenaire qui a lui-même des Red Teamers ou des pentesters, il peut les embarquer sur la plateforme – pour mener des tests d’intrusion conjoints par exemple.

Le VOC Yogosha peut donc aider à superviser la sécurité de la chaîne d’approvisionnement grâce à :

• une collaboration accrue entre les équipes de terrain des différentes entités ;
• la possibilité de mener des opérations de sécurité conjointes ;
• une gestion des vulnérabilités fluide et transparente pour tous les acteurs impliqués ;
• une aide à la cartographie des risques des différentes entités
• des supports de reporting orientés data pour monitorer la sécurité globale de l’écosystème.

Lire aussi : C’est quoi, un Vulnerability Operations Center (VOC) ?

8. Assurez-vous qu’il y a un plan de continuité d’activité et de gestion de crise

La directive NIS2 fait clairement référence à la “continuité des activités et à la gestion des crises” dans ses mesures de gestion des risques. Soyons clairs, les enjeux sont ici stratégiques et business, et cette responsabilité devrait incomber à tous les C-Levels.

Néanmoins, un RSSI digne de ce nom se doit d’être un minimum impliqué dans le processus. Parmi les mesures que vous pouvez prendre, citons la formation des employés aux bonnes pratiques en matière de sécurité ou la mise à l’épreuve des capacités de résilience de votre entreprise. Il peut également être judicieux de se synchroniser avec les équipes de communication, de marketing et juridiques sur la posture publique à adopter en cas de brèche, ainsi que sur les processus et templates à implémenter. La mise en place d’un SMSI peut également s’avérer très précieuse. Ce qui nous amène au point suivant.

9. Implémentez un SMSI en tenant compte de NIS2

Se doter d’un système de management de la sécurité de l’information (SMSI) permet de réduire les risques numériques, en structurant la gestion de la sécurité de l’information de l’entité par une approche systémique. En clair, l’adoption d’un tel cadre vous permettra de mieux contrôler et gérer les niveaux de risque de sécurité dans votre entreprise.

ISO27001, une norme internationale pour la création d’un SMSI

Si vous ne savez pas par où commencer, la norme ISO27001 est un bon choix. Il s’agit de la norme internationale pour la mise en place d’un SMSI, et elle est largement utilisée par les entreprises du monde entier.

La norme ISO27001 est également largement mentionnée dans les directives officielles de l’ENISA sur l’évaluation de la sécurité des DSP et de la conformité des OES par rapport aux exigences de sécurité de la première directive NIS. Bien que les concepts de DSP et d’OES disparaissent avec NIS2, tout porte à croire que les normes et frameworks recommandés pour le contrôle de la sécurité de l’information ne changeront pas du tout au tout.

La certification ISO27001 peut prendre un certain temps, suivant le niveau actuel de maturité et de gouvernance de votre entité. Même si l’entrée en vigueur de NIS2 n’est pas prévue avant 2024, il s’agit d’un chantier important qui doit être entrepris dès que possible.

NIS2 : vers un cadre de certification européen en matière de cybersécurité

Avec NIS2, l’Union européenne se dirige lentement mais sûrement vers des schémas de certification souverains en matière de cybersécurité. Les modalités sont toujours à préciser, mais l’Article 24(3) du texte dispose que l’ENISA peut être chargée du projet par la Commission européenne.

À ce sujet, le rapporteur du Parlement européen, M. Bart Groothuis, nous a confié :

“C’est aux États membres d’en décider, mais je pense que ce que nous voulons, c’est une approche harmonisée autant que possible. Nous voulons que les mêmes règles soient appliquées, de sorte que nous ayons les mêmes schémas en Roumanie qu’aux Pays-Bas, qu’en Espagne… Pourquoi ? Évidemment, parce que le marché intérieur est la base de ce texte législatif. L’ENISA va proposer cinq à huit nouveaux schémas par an, voilà ce qu’il va se passer. […]

Et ensuite, la question est de savoir à quel rythme cela va se faire. Il faudra peut-être des années avant d’avoir des certifications dans toute l’Europe, ce n’est pas pour tout de suite. En attendant, nous pourrions utiliser d’autres schémas internationaux. Il y en existe tellement !”

– M. le député Bart Groothuis

10. Encouragez les méthodes de développement sécurisé

NIS2 s’aligne sur le EU Cybersecurity Act de juin 2019, qui appelle à une culture de la cybersécurité par design. Autrement dit, une sécurité intégrée aux produits et services dès leur conception.

Évidemment, former les développeurs aux pratiques et aux frameworks de développement sécurisé n’est pas le rôle d’un RSSI. Mais rien ne vous empêche d’en faire un peu plus et de sensibiliser les gens à ce sujet. Il peut même s’agir d’un effort conjoint avec le CTO, les équipes SOC ou simplement les férus de sécurité en interne.

En plus des éventuelles formations, vous pouvez organiser des workshops ou des CTF (Capture The Flag) au sein de l’entreprise. L’organisation d’un Bug Day mensuel ou trimestriel avec les équipes de développement peut aussi être une bonne approche.

Un VOC pour rassembler les équipes de développement et de sécurité

En complément, notre VOC contribue lui aussi à la sensibilisation aux pratiques de développement sécurisé, en fédérant toutes les communautés :

• vos équipes de sécurité ;
• vos équipes techniques, comme les développeurs ;
• les équipes de vos partenaires, comme leurs red teamers ou pentesters ;
• les hunters de la Yogosha Strike Force.

Le VOC permet de faire converger les métiers, et de faire en sorte que tous ces individus puissent communiquer entre eux. Peut-être nos hackers peuvent-ils aider vos devs à corriger une faille ? Ou peut-être pourriez-vous inviter les red teams de vos partenaires à participer à une opération de bug bounty. Voire même organiser un Live Hacking Event pour que tout ce beau monde se rencontre dans la vraie vie. Les possibilités sont nombreuses.

11. Mettez en place une politique de divulgation des vulnérabilités (VDP)

La directive NIS2 met l’accent sur le traitement et la divulgation des vulnérabilités, en particulier concernant les réseaux et des systèmes d’information. Parmi les mesures de gestion du risque de cybersécurité exigées par la NIS2 (cf. le point 6 de cet article), on peut lire :

• la sécurité dans l’acquisition, le développement et la maintenance des réseaux et des systèmes d’information, y compris le traitement et la divulgation des vulnérabilités ;

Le Préambule 58 explore un peu plus le sujet :

“Puisque l’exploitation des vulnérabilités dans les réseaux et les systèmes d’information peut causer des perturbations et des dommages considérables, l’identification et la correction rapide de ces vulnérabilités est un facteur important de la réduction du risque. Les entités qui mettent au point ou administrent des réseaux et systèmes d’information devraient dont établir des procédures appropriées pour gérer les vulnérabilités découvertes.

Puisque les vulnérabilités sont souvent découvertes et divulguées par des tiers, le fabricant de produits TIC ou le fournisseur de services TIC devraient également mettre en place les procédures nécessaires pour recevoir les informations relatives aux vulnérabilités communiquées par les tiers. À cet égard, les normes internationales ISO/CEI 30111 et ISO/CEI 29147 fournissent des orientations sur la gestion des vulnérabilités et la divulgation des vulnérabilités. Le renforcement de la coordination entre les personnes physiques et morales effectuant le signalement et les fabricants de produits ou les fournisseurs de services TIC est particulièrement important pour faciliter le cadre volontaire de divulgation des vulnérabilités.

La divulgation coordonnée des vulnérabilités consiste en un processus structuré dans lequel les vulnérabilités sont signalées au fabricant ou au fournisseur de produits TIC ou de services TIC potentiellement vulnérables, de manière à leur donner la possibilité de diagnostiquer la vulnérabilité et d’y remédier avant que des informations détaillées à ce sujet soient divulguées à des tiers ou au public.”

– NIS2, Préambule 58.

Le message est clair : il est important que les organisations – et en particulier les fabricants et fournisseurs de produits et services TIC – puissent recevoir des signalements de vulnérabilités rapportées par des personnes extérieures. Et ce processus a un nom : la politique de divulgation des vulnérabilités (VDP) – parfois également appelée politique de divulgation responsable.

La VDP : un canal sécurisé pour collecter les rapports de vulnérabilités

Une Politique de Divulgation des Vulnérabilités (VDP) est un canal structuré fourni par une organisation pour que quiconque puisse lui signaler un problème de sécurité numérique. En d’autres termes, il s’agit d’un moyen sûr pour que les tiers sachent où et comment signaler des vulnérabilités à une entité.

Créer sa VDP soi-même

Il est tout à fait possible de rédiger et mettre en place une politique de divulgation des vulnérabilités par soi-même. Il existe de nombreuses ressources pour vous guider, comme par exemple :

• le site Disclose.io, qui propose un générateur de politique de divulgation des vulnérabilités ;
• le site securitytxt.org, qui aide à créer des fichiers security.txt

En effet, il est de bon ton d’indiquer le moyen de contact prévu par votre VDP dans une notice security.txt, disponible à l’adresse www.siteweb.tld/.well-known/security.txt. A titre d’exemple, voici le security.txt du site Yogosha.

Créer et mettre en place une VDP avec Yogosha

Une autre solution est de faire appel à une plateforme spécialisée pour créer et héberger votre VDP. Un exercice auquel nous sommes habitués chez Yogosha, puisque nous proposons des VDP à nos clients depuis 2015.

Yogosha accompagne les organisations dans la mise en place de leur VDP :

• en accompagnant la rédaction de la politique de divulgation – scope, règles de divulgation, directives, clauses juridiques et dites “Safe Harbor”, etc. ;
• en offrant une plateforme sécurisée pour collecter les rapports de vulnérabilités envoyés par les hackers éthiques. Tous les rapports sont centralisés sur la plateforme Yogosha, et vous pouvez harmoniser et rationaliser votre gestion des vulnérabilités en connectant vos outils ;
• en proposant une prise en charge du triage des rapports afin que vous puissiez vous concentrer sur l’essentiel : la remédiation.

12. Effectuez des tests et des audits de sécurité réguliers

Cela peut sembler évident, mais des tests de sécurité réguliers sont essentiels pour garantir que les périmètres sont convenablement protégés. La directive NIS2 vient mettre les points sur les i en exigeant des EE et des IE qu’elles appliquent :

• “des politiques et procédures (tests et audits) visant à évaluer l’efficacité des mesures de gestion des risques liés à la cybersécurité” ;

Les audits de sécurité sont aussi nombreux que variés et, en tant que RSSI, vous êtes a priori déjà familier avec le sujet.

Précisons tout de même qu’en tant que Vulnerability Operations Center, Yogosha propose différentes approches pour réduire les risques numériques :

• Vulnerability Disclosure Programs – VDP
• Pentest as a Service
• Bug Bounty

Lire aussi : Audits de sécurité – Le bon test au bon moment

Pentest as a Service

Notre plateforme permet la digitalisation des activités de pentesting, avec des résultats en temps réel et des lancements plus rapides qu’avec un audit traditionnel.

1. Notre technologie rend la discipline plus efficace et plus fluide, que vous ayez des red teams en interne ou que vous meniez des pentests pour vos clients.
2. En plus de notre technologie, nous réalisons des tests d’intrusion avec les membres de la Yogosha Strike Force ; une communauté privée et sélective de chercheurs en sécurité, chacun ayant sa propre expertise et ses propres compétences.

Bug Bounty

Lorsqu’un niveau de sécurité suffisamment avancé est atteint, les tests d’intrusion montrent leurs limites. Le Bug Bounty permet alors de se confronter à la réalité, en demandant à des hackers éthiques de tester la sécurité d’un système. Le Bug Bounty prône une logique de paiement au résultat, tout en permettant de découvrir des vulnérabilités complexes et à haut risque qui échappent aux autres audits.

Nous pourrions vous parler de bug bounty pendant des heures. Mais cet article est déjà assez long comme ça, alors disons simplement ceci :

• Nous nous appuyons sur une communauté de hunters d’élite, où chaque membre a été soigneusement sélectionné – contrairement à la plupart des plateformes de bug bounty qui sont publiques.
• Notre Vulnerability Operations Center (VOC) peut être SaaS ou auto-hébergé, ce qui le rend adapté aux systèmes sensibles et critiques.

En résumé

Les Etats Membres ont encore jusqu’à Septembre 2024 pour transposer NIS2 en loi nationale. Mais comme dit le proverbe, mieux vaut prévenir que guérir. Nous conseillons donc à tous les RSSI des entités dans le scope de la directive de commencer à travailler sur la mise en conformité dès maintenant, une partie des tâches pouvant prendre un certain temps.

Le gros du travail devrait être organisé autour de trois axes principaux : la gouvernance, la détection et la réponse aux incidents, et les tests de sécurité. Vos actions devraient s’articuler autour des 10 mesures de gestion des risques de cybersécurité requises par la directive NIS2 (voir également le point 5 de cet article) :

Ensuite, voici un rappel des différentes étapes clés de notre plan d’action recommandé pour la mise en conformité avec NIS2 :

1. Déterminez si vous êtes affecté par NIS2
2. Sensibilisez le top management aux sanctions et amendes prévues par NIS2
3. Éduquez et formez les cadres supérieurs à la gestion du risque en matière de cybersécurité
4. Planifiez et chiffrez l’augmentation du budget
5. Passez en revue les 10 mesures de gestion du risque de cybersécurité exigées par la directive NIS2
6. Rationalisez la réponse aux incidents
7. Évaluez la sécurité de la chaîne d’approvisionnement
8. Assurez-vous qu’il y a un plan de continuité d’activité et de gestion de crise
9. Implémentez un SMSI en tenant compte de NIS2
10. Encouragez les méthodes de développement sécurisé
11. Mettez en place une politique de divulgation des vulnérabilités (VDP)
12. Effectuez des tests et des audits de sécurité réguliers

N’hésitez pas à nous contacter si vous avez un besoin de conformité avec certaines exigences NIS2. Que ce soit pour des tests de sécurité, la divulgation des vulnérabilités, ou une démo de notre Vulnerability Operations Center pour configurer un espace de travail commun à vos équipes internes, vos partenaires ou vos fournisseurs.