NIS2 exige de mettre en œuvre des mesures de gestion des risques et d’être capable de notifier les incidents significatifs dans des délais précis. Longtemps considérés comme de simples ressources techniques, les logs étaient conservés pour diagnostiquer une panne, comprendre un comportement anormal, rechercher la cause d’un incident ou disposer d’un historique lorsque quelque chose ne fonctionne plus comme prévu.
Cet article fait le point sur les nouvelles exigences de NIS2 et vous aide à identifier vos prochaines actions.
NIS2 : pourquoi les équipes ITOps sont directement concernées ?
Pour rappel, qu’est-ce que NIS2 ?
La directive NIS2 (UE 2022/2555) remplace la première directive NIS de 2016 et élargit fortement le nombre d’organisations entrant dans son champ d’application.
Elle couvre 18 secteurs et distingue deux grandes catégories d’organisations : les entités essentielles et les entités importantes, selon notamment leur secteur et leur taille.
Selon les estimations, d’environ 300 entités régulées auparavant en France, le périmètre de NIS2 passerait à un ordre de grandeur de 10 000 à 15 000 organisations.
Pour les équipes IT, l’un des changements majeurs tient au fait que NIS2 ne traite pas uniquement de prévention. Elle impose également la capacité à gérer les incidents et à les notifier. Autrement dit, votre organisation doit pouvoir comprendre ce qui s’est produit et réunir rapidement des éléments factuels.
Or, une fois un incident détecté, ce sont notamment les logs qui vont permettre de retrouver les événements, de les dater et de reconstituer leur chronologie.
Rappelons que le Log Management consiste précisément à collecter et centraliser des logs provenant de sources diverses, puis à les analyser grâce à des filtres, des requêtes ou des tableaux de bord.
À retenir : NIS2 donne une nouvelle portée à une problématique que les ITOps connaissent déjà bien : la capacité à transformer une masse de données techniques en informations exploitables lorsqu’un incident survient.
1er changement de prisme : maîtriser les logs plutôt que de les conserver
Votre organisation doit savoir quels journaux sont disponibles, quelles informations ils contiennent et comment ils peuvent être exploités en cas d’incident.
Quelles sont les sources de logs critiques et est-on certain de les collecter ?
Il faut pouvoir identifier les systèmes concernés, savoir où leurs logs sont stockés et vérifier que les événements nécessaires à une investigation sont effectivement disponibles. Cette cartographie permet également d’identifier les angles morts : une application critique dont les journaux ne remontent pas, un équipement réseau dont l’historique est insuffisant ou encore des sources dispersées auxquelles seules quelques personnes savent accéder.
À retenir : L’enjeu n’est plus de « faire du log » à tout prix et partout mais de maîtriser la chaîne qui va de la production du log jusqu’à son exploitation.
2ème évolution : définir une politique de rétention plutôt que chercher une « durée NIS2 »
C’est probablement l’un des sujets sur lesquels il faut être le plus précis : NIS2 ne fixe pas une durée universelle de conservation des logs applicable à toutes les organisations.
Avec NIS2, les mesures mises en œuvre doivent être proportionnées aux risques.
Le règlement d’exécution (UE) 2024/2690, qui concerne certaines catégories d’entités fournissant des infrastructures ou services numériques, demande notamment une durée de rétention prédéfinie, sans imposer un seuil unique.
Une politique de rétention devient une décision à formaliser et à justifier. Elle peut différer selon la nature des journaux et leur criticité.
À retenir : L’objectif est donc de disposer d’une politique documentée précisant, pour chaque catégorie de logs, la durée de conservation retenue, sa justification et les modalités de suppression à échéance.
3ème changement : les logs doivent être exploitables ET fiables
Lorsqu’un log sert uniquement à dépanner rapidement une application, la question de son intégrité peut sembler secondaire. Lorsqu’il doit contribuer à reconstituer un incident, son intégrité devient fondamentale.
Un journal susceptible d’être modifié ou supprimé ne constitue pas une preuve fiable.
Cela suppose de s’intéresser non seulement au contenu du log, mais également à toute sa chaîne de conservation. Les journaux sensibles doivent notamment être protégés contre l’altération ou la suppression non autorisée. Des mécanismes techniques tels qu’un stockage en écriture unique, une signature ou un scellement cryptographique peuvent contribuer à atteindre cet objectif.
La centralisation joue également un rôle important. Conserver exclusivement les logs sur le système qui les produit crée une faiblesse évidente : si ce système est compromis, ses traces peuvent l’être également.
C’est le principe retenu par Centreon Log Management : les logs sont centralisés hors des systèmes qui les produisent et stockés en écriture unique (WORM), sans modification ni suppression possibles.
À retenir : pour les ITOps, l’intégrité des logs devient donc un véritable sujet d’architecture.
4ème point clé : l’horodatage des logs devient critique
Imaginons un incident qui touche successivement une application, une base de données, un serveur et un équipement réseau, dont les horloges ne sont pas synchronisées.
Vous disposez alors de quatre sources individuellement exploitables, mais beaucoup plus difficiles à corréler. Or la capacité à reconstituer une chronologie est précisément l’une des clés d’une investigation efficace.
La synchronisation des horloges sur une source de temps fiable devient une composante clé de la qualité des logs.
L’objectif est très opérationnel. Il faut être capable de répondre avec suffisamment de précision à la question fondamentale : Qui a fait quoi, et quand ? Cette question concerne notamment les accès, les authentifications et les actions réalisées avec des privilèges élevés.
À retenir : vous devez vous assurer que vos horloges sont synchronisées pour disposer d’une donnée fiable.
Dernier point d’attention : les logs doivent être accessibles aux bonnes personnes. Et seulement à elles.
Les mesures de NIS2 intègrent notamment les politiques de contrôle d’accès ainsi que le recours à la cryptographie et au chiffrement parmi les mesures de gestion des risques prévues par son article 21. Une gestion des droits fondée sur les rôles (RBAC pour Role-Based Access Control) permet par exemple de limiter l’accès aux logs aux personnes qui en ont réellement besoin. Centreon Log Management intègre nativement ce contrôle d’accès par rôle, ainsi que le chiffrement des données.
Mais la logique doit aller plus loin : l’accès aux logs doit lui-même être traçable. Qui a consulté les données ? Qui les a exportées ? Qui dispose de droits d’administration ?
Et au-delà de vos équipes, qui peut accéder à vos logs chez vos fournisseurs ?
NIS2 impose aussi d’évaluer la sécurité de vos fournisseurs, y compris ceux qui hébergent vos logs. Or, ce qui compte n’est pas seulement l’endroit où sont stockées vos données, mais le droit auquel votre fournisseur est soumis. Le CLOUD Act américain permet par exemple d’exiger d’un fournisseur relevant de la juridiction américaine qu’il communique des données, même hébergées en Europe.
À retenir : concrètement, une organisation doit être capable de déterminer qui peut consulter, exporter ou administrer ses journaux, en interne comme chez ses fournisseurs.
Le défi majeur de NIS2 ? Être capable de retrouver l’information dans les délais
C’est probablement ici que NIS2 produit l’effet le plus concret sur l’exploitation quotidienne et sur vos équipes. La directive prévoit, pour les incidents significatifs, plusieurs jalons de notification, qui courent à partir du moment où l’organisation a connaissance de l’incident :
- une alerte précoce sous 24 heures,
- une notification d’incident sous 72 heures,
- un rapport final dans le mois qui suit la notification.
Autrement dit, l’horloge tourne dès la prise de connaissance de l’incident, et elle ne s’arrête pas le temps que vos équipes retrouvent les bons fichiers de logs. Centreon Log Management répond à cet enjeu : son explorateur de logs a été conçu pour rechercher et filtrer les données afin d’investiguer les problèmes et d’en rechercher les causes profondes.
À retenir : la vraie mesure de maturité n’est donc plus seulement le volume de logs conservés mais aussi le temps nécessaire pour obtenir une information exploitable.
NIS2 ne doit pas transformer votre gestion des logs en projet juridique
Intégrer les exigences de NIS2 ne signifie pas transformer vos équipes d’exploitation en juristes ni créer une gestion des logs parallèle destinée uniquement aux audits.
Une approche consistant à stocker certains journaux « pour la conformité » dans un dispositif séparé du fonctionnement quotidien risquerait de créer un nouveau silo et pourrait se révéler improductif. L’enjeu consiste plutôt à renforcer les pratiques opérationnelles existantes.
À retenir : les capacités nécessaires à la conformité sont aussi celles qui permettent aux équipes ITOps d’améliorer leur efficacité opérationnelle et potentiellement de réduire leur MTTR.
Par où commencer pour préparer votre log management à NIS2 ?
Avant de chercher un nouvel outil, commencez par tester votre dispositif actuel.
Prenez un incident fictif et posez-vous une question volontairement simple : si cet incident se produisait aujourd’hui, combien de temps faudrait-il réellement à notre équipe pour reconstituer ce qui s’est passé ?
Ce test est probablement beaucoup plus révélateur qu’une simple question du type « conservons-nous nos logs ? ». NIS2 fait passer les organisations d’une logique de possession à une logique de capacité.
À retenir : avoir les données ne suffit plus. Il faut pouvoir s’en servir.
Passez de la contrainte NIS2 à une gestion plus efficace de vos incidents
Conformité documentaire ou capacité réelle ?
C’est l’occasion de se demander, au-delà de savoir si les logs sont conformes à NIS2, si leur gestion permet réellement de comprendre et documenter un incident dans les délais imposés par NIS2.
La différence entre les deux formulations est importante. La première peut conduire à une démarche de conformité documentaire. La seconde oblige à tester la réalité opérationnelle.
Vous souhaitez aller au-delà des principes et évaluer concrètement votre dispositif actuel ?
Le guide Centreon « NIS2 et DORA : ce que la réglementation exige de vos logs » détaille les exigences applicables aux logs, les délais de notification, les enjeux de souveraineté et propose un plan d’action étape par étape ainsi qu’une checklist pour évaluer votre niveau de préparation.
Téléchargez dès maintenant notre guide et identifiez les actions prioritaires pour faire évoluer votre gestion des logs.
Besoin de repenser votre gestion des logs ? Contactez nos équipes pour une démo personnalisée.
FAQ : NIS2 et gestion des logs
Combien de temps faut-il conserver ses logs avec NIS2 ?
NIS2 ne fixe pas de durée de conservation unique. La directive impose des mesures proportionnées aux risques et son règlement d’exécution (UE) 2024/2690, qui ne vise que certains fournisseurs d’infrastructures et de services numériques, demande une durée prédéfinie sans imposer de seuil. Chaque organisation doit donc définir et justifier sa durée de rétention par type de journal.
Quels sont les délais de notification d’incident imposés par NIS2 ?
Pour un incident significatif, l’article 23 de NIS2 prévoit trois jalons : une alerte précoce sous 24 heures, une notification d’incident sous 72 heures, puis un rapport final dans le mois qui suit la notification. Les délais courent à partir du moment où l’organisation a connaissance de l’incident.
NIS2 impose-t-il des logs immuables ?
NIS2 n’impose pas de technologie précise, mais un résultat : les journaux doivent pouvoir servir de preuve fiable, donc être protégés contre l’altération et la suppression. En pratique, cela passe par un stockage en écriture unique (WORM), une signature ou un scellement cryptographique, et une centralisation des logs hors des systèmes qui les produisent.