NIS2 : ce que vous devez pouvoir prouver
Le difficile avec NIS2 n’est pas d’acheter des produits de sécurité. C’est de produire la preuve que les mesures existaient avant l’incident, sous une forme lisible par quelqu’un d’extérieur à votre équipe informatique.
NIS2 impose aux organisations concernées de disposer d’une gestion des risques, d’un traitement des incidents, d’une continuité d’activité, d’une sécurité de la chaîne d’approvisionnement et d’un contrôle d’accès, et de notifier un incident significatif dans les 24 heures suivant sa connaissance. La direction en répond personnellement.
La conséquence pratique, c’est de la documentation. Des politiques écrites qui correspondent à ce qui se passe réellement, des journaux conservés assez longtemps pour reconstituer un incident, et un rapport qu’un conseil peut lire sans traduction.
Même si vous n’êtes pas directement concerné, attendez-vous aux questionnaires. Les fournisseurs d’organisations concernées sont entraînés par contrat, et c’est ainsi que la plupart des entreprises de taille intermédiaire rencontrent NIS2 pour la première fois.
Êtes-vous concerné ?
NIS2 couvre les entités essentielles et importantes dans des secteurs comme l’énergie, les transports, la banque, la santé, l’eau potable, l’infrastructure numérique, l’administration publique, les services postaux, les déchets, la chimie, l’alimentation, l’industrie manufacturière et les fournisseurs numériques. Des seuils de taille s’appliquent, mais la liste des secteurs est assez large pour que beaucoup d’entreprises de taille intermédiaire y tombent.
La seconde porte d’entrée est contractuelle. Si vous fournissez une organisation concernée, ses obligations sur la chaîne d’approvisionnement deviennent les vôtres par le contrat. D’expérience, c’est ainsi que la plupart des entreprises l’apprennent : un client envoie un questionnaire de sécurité qui n’existait pas l’an dernier.
Les cinq choses qu’il demande réellement
| Exigence | Preuve attendue |
|---|---|
| Gestion des risques | Une analyse de risques écrite, avec responsables et dates, revue au moins une fois par an |
| Traitement des incidents | Une procédure, une chaîne de contacts et un journal des incidents réels avec les heures |
| Continuité d’activité | Des délais de reprise convenus et un test de restauration daté qui les a tenus |
| Sécurité de la chaîne d’approvisionnement | Une liste des fournisseurs critiques et ce que vous avez vérifié pour chacun |
| Contrôle d’accès | Le multifacteur partout, et la preuve que les partants perdent l’accès sans délai |
Notez que chaque ligne est un document, pas un produit. Vous pouvez posséder le meilleur pare-feu du marché et échouer malgré tout sur la paperasse.
L’horloge des 24 heures
Un incident significatif doit faire l’objet d’une alerte précoce dans les 24 heures suivant sa connaissance, d’une notification plus complète à 72 heures et d’un rapport final au bout d’un mois. Vingt-quatre heures paraît généreux jusqu’à ce qu’on réalise que l’horloge démarre à la connaissance, c’est-à-dire généralement au milieu de la nuit ou un samedi.
Ce qui rend ce délai tenable, c’est de décider à l’avance qui déclare un incident, qui rédige la notification et où se trouvent les preuves. Ces trois réponses écrites sur une page valent plus que beaucoup d’outillage.
La journalisation, là où la plupart échouent
On ne reconstitue pas un incident qu’on n’a pas enregistré. L’échec courant, ce sont des journaux qui existent mais seulement sur sept ou quatorze jours, soit moins que le temps qu’il faut d’ordinaire pour repérer une intrusion.
Nous visons une rétention suffisante pour répondre à la question d’un enquêteur : quand cela a-t-il commencé, à quoi d’autre le compte a-t-il touché, et quelque chose est-il sorti. En pratique cela veut dire des journaux centralisés, conservés des mois plutôt que des jours, avec quelqu’un qui regarde les alertes. Nous utilisons Splunk et Grafana pour cela, comme décrit sous infogérance.
L’ordre dans lequel nous procéderions
NIS2 ne dit pas par où commencer, voici donc la séquence qui retire le plus d’exposition pour l’effort consenti, tout en produisant des preuves au passage.
- Le multifacteur sur tout. Le contrôle le moins coûteux, le plus efficace, et prouvable immédiatement.
- Une sauvegarde immuable avec un test de restauration daté. Couvre l’exigence de continuité et le pire scénario d’un coup. Voir sauvegarde et continuité.
- Une journalisation centralisée avec rétention. Sans cela, vous ne pouvez pas tenir honnêtement les délais de notification.
- Une procédure d’incident écrite, avec des noms dedans. Une page, testée une fois.
- Un registre des fournisseurs. Qui peut atteindre vos systèmes, ce que vous avez vérifié, quand.
- Ensuite le travail de pare-feu et de segmentation. Important, mais plus tard que ne le placent la plupart des gens.
Ce qu’il faut demander à votre propre prestataire
Retournez le questionnaire. Un prestataire qui gère vos systèmes devrait pouvoir répondre sans délai : quelles certifications détenez-vous et qui les a auditées, comment traitez-vous un incident sur notre environnement, quels sont vos délais de réponse par écrit, et où sont installés vos techniciens.
Nos processus sont audités par un tiers selon ISO 9001, ISO/IEC 27001 et ISO 14001. Les nuits et les week-ends sont assurés en équipe par nos propres collaborateurs, donc rien de votre environnement n’est confié à un tiers. Cela ne vous rend pas conforme à soi seul, mais votre auditeur obtient une réponse claire sur un maillon de votre chaîne.
Faites de la preuve un sous-produit
Les organisations pour qui NIS2 est douloureux sont celles qui produisent des preuves quand on les leur demande. Celles pour qui c’est gérable les produisent de toute façon chaque mois, parce que le rythme de reporting existe déjà.
C’est toute l’idée derrière la gouvernance de service : un seul jeu de chiffres, un seul cycle de revue, un seul point de responsabilité. Quand le questionnaire arrive, la réponse est un document que vous avez déjà.
Ce qu’on nous demande à ce sujet
Ce que demande la direction quand NIS2 arrive à l’ordre du jour.
Quand un incident doit-il être notifié au titre de NIS2 ?
Une alerte précoce dans les 24 heures suivant la connaissance d’un incident significatif, une notification plus complète à 72 heures et un rapport final au bout d’un mois. L’horloge démarre à la connaissance et non au moment de la compromission, c’est pourquoi savoir qui déclare un incident compte plus que l’outillage.
Comment savoir si nous sommes concernés ?
Par le secteur et par la taille, mais aussi par contrat. La liste des secteurs est large et beaucoup d’entreprises de taille intermédiaire y tombent ; et si vous fournissez une organisation concernée, ses obligations sur la chaîne d’approvisionnement vous parviennent par le contrat. En pratique, le premier signal est souvent un questionnaire de sécurité envoyé par un client.
Faut-il une certification pour être conforme à NIS2 ?
Aucune certification n’est exigée. ISO/IEC 27001 couvre une large part de ce que demande NIS2 et facilite la production des preuves, mais c’est un moyen et non une obligation. Ce qui est exigé, c’est que les mesures existent et puissent être montrées.
Combien de temps faut-il pour être prêt ?
Pour une organisation de taille intermédiaire partant d’une base raisonnable, trois à six mois pour avoir les contrôles principaux et la documentation en place. Le travail technique va généralement plus vite que la paperasse, ce qui est l’inverse de ce que l’on attend.
Où cela s’inscrit dans notre travail
Les services sur lesquels cela s’appuie.
Envie qu’on regarde où vous en êtes ?
Une demi-heure au téléphone suffit généralement à savoir si nous sommes le bon interlocuteur, et nous le dirons si ce n’est pas le cas.