Skip to main content

Table of Contents

À ce jour, le texte final de la directive NIS2 n’a pas encore été rendu public. Il est donc impossible de se prononcer définitivement sur les obligations qu’elle introduit. Néanmoins, il existe déjà de nombreuses lignes directrices sur les actions à mener en vue de la NIS2, 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 provisoire 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 devrait-elle entrer en vigueur ?

L’application de la directive NIS2 est attendue pour fin 2023 au plus tôt, et plus vraisemblablement courant 2024. Le Parlement et le Conseil européens ont provisoirement approuvé le texte de la NIS2 avant l’été 2022, mais il doit maintenant être adopté officiellement. Les États membres auront alors 21 mois pour transposer la directive en droit national.

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) 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.
  • 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
Source: Factsheet – Revised Directive on Security of Network and Information Systems (NIS2)

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.

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 ;
  • 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 ;

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” ;
  • 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 dans les Articles 29, 30 et 31 du texte provisoire de NIS2.

Des amendes pouvant aller jusqu’à 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 18
  • des mesures de gestion du risque de cybersécurité, prévues à l’Article 20

En cas de manquement à ces obligations (NDLR : on y revient plus bas dans cet article), la directive NIS2 prévoit des amendes administratives d’un montant maximal de 10 millions d’euros ou jusqu’à 2% du chiffre d’affaires annuel mondial total de l’entreprise à laquelle appartient l’entité au cours de l’exercice précédent. Le montant le plus élevé étant celui retenu.

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 provisoire. 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 ayant des responsabilités de directeur général ou de représentant légal, et de toute autre personne physique tenue pour responsable d’une violation.

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 17 du texte provisoire 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 spécifiques, sur une base régulière”, afin d’acquérir des connaissances et des compétences suffisantes pour appréhender et évaluer les risques de cybersécurité et les pratiques de gestion, ainsi que leur impact sur les opérations de l’entité.

NIS2 : quelle formation choisir ?

Le texte définitif de NIS2 est encore inconnu. A ce jour, il est donc impossible de dire quel doit être le contenu de ces “formations spécifiques”, et encore moins quelles seront les conditions pour prouver qu’elles ont bien été suivies.

Néanmoins, 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, 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).

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 7 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 projet de texte de la NIS2 indique clairement que :

“Les États membres veillent à ce que les entités essentielles et importantes prennent les mesures techniques 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 la fourniture de leurs services.” – NIS2, Article 18

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

  • analyse des risques et politiques de sécurité des systèmes d’information ;
  • traitement des incidents (prévention, détection et réponse aux incidents) ;
  • continuité des activités et gestion de crise ;
  • 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 tels que les fournisseurs de services de stockage et de traitement des données ou de services de sécurité administrés ;
  • 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 ;
  • les politiques et procédures (tests et audits) visant à évaluer l’efficacité des mesures de gestion des risques liés à la cybersécurité ;
  • l’utilisation de la cryptographie et du cryptage.

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 “tout événement compromettant la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données stockées, transmises ou traitées, ou de services connexes offerts par les systèmes de réseaux et d’information ou accessibles par leur intermédiaire”, aux termes de l’Article 4(5)
  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 4(7) de NIS2.

L’article 20 prévoit qu’un incident est considéré comme significatif si :

  1. l’incident a causé ou a le potentiel de causer une perturbation opérationnelle ou des pertes financières substantielles 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 significatif ou de cybermenace ?

En cas de cybermenace ou d’incident significatif, 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 une action illégale ou malveillante ;
  2. à la demande d’une autorité compétente ou d’un CSIRT, un rapport intermédiaire sur les évolutions pertinentes de la situation ;
  3. 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.

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 43 du projet de texte explique :

“Il est tout particulièrement important de répondre aux risques de cybersécurité 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 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 devraient donc évaluer et prendre en compte la qualité globale des produits et des pratiques de cybersécurité de leurs fournisseurs et fournisseurs de services, y compris de leurs procédures de développement sécurisées. ”

– NIS2, Préambule 43 (Texte provisoire)

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 44 du texte provisoire met particulièrement l’accent sur les MSSPs dans les domaines :

La NIS2 enjoint donc les organismes à faire preuve d’une diligence accrue dans leurs choix de MSSPs. A ce titre, précisons que Yogosha sera probablement visé par ces exigences de diligence. Nous prenons d’ores et déjà nos dispositions pour justifier de la bonne sécurité de nos environnements – la certification ISO 27001 est par exemple en chemin.

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.

Représentation graphique d'un Vulnerability Operations Center.

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 aux cadres supérieurs.

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 NIS2 n’est pas prévu pour demain, 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 21(3) du texte provisoire 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 28 du texte provisoire 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 en matière de cybersécurité. Les entités qui mettent au point de tels systèmes 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 signalées (divulguées) par des tiers (les entités effectuant le signalement), le fabricant de produits 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 29417 fournissent des orientations sur la gestion des vulnérabilités et la divulgation des vulnérabilités respectivement. En ce qui concerne la divulgation des vulnérabilités, la coordination entre les entités effectuant le signalement et les fabricants ou les fournisseurs de produits ou de services TIC est particulièrement importante. La divulgation coordonnée des vulnérabilités consiste en un processus structuré dans lequel les vulnérabilités sont signalées aux organisations 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 28.

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 :

En résumé

La mise en application de NIS2 n’est pas prévue pour demain. 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 7 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 7 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

C’est à peu près tout pour le moment. Nous veillerons à mettre à jour cet article au fur et à mesure que le texte final de la directive NIS2 se précisera.

Et si, entre-temps, vous avez des questions sur nos opérations ou si vous souhaitez une démonstration de notre VOC, n’hésitez pas à nous contacter.