Monter un capteur réseau, indexer ses événements, tracer des courbes : tout cela peut ressembler à une occupation de laboratoire. Ça ne l'est pas. Depuis l'entrée en vigueur de la directive NIS2, ces capacités sont devenues des obligations pour un grand nombre d'organisations — et la question n'est plus « faut-il détecter ? » mais « savez-vous prouver que vous détectez ? ».
Ce que NIS2 change
La directive européenne NIS2, transposée dans les droits nationaux, élargit considérablement le périmètre de la précédente : au-delà des opérateurs critiques historiques, elle couvre l'énergie, les transports, la santé, l'eau, le numérique, les administrations publiques, la gestion des déchets, l'agroalimentaire, la fabrication — y compris des entités de taille moyenne.
Trois exigences y touchent directement au sujet de cette série :
- la gestion des incidents — être capable de les détecter, de les qualifier, de les traiter ;
- la notification dans des délais courts — une alerte précoce sous 24 heures, une notification sous 72 heures, un rapport final sous un mois ;
- la responsabilité des dirigeants — la conformité n'est plus déléguée à la seule équipe technique.
Pourquoi le délai de 24 heures change tout
C'est l'exigence la plus structurante, et elle mérite qu'on la prenne au sérieux. Notifier un incident significatif sous 24 heures suppose de l'avoir détecté — ce qui est loin d'être acquis : dans les faits, beaucoup d'intrusions sont découvertes des semaines plus tard, souvent par un tiers.
Et détecter ne suffit pas : il faut qualifier. Quelle machine ? Depuis quand ? Quelles données ont pu partir ? Sans historique consultable, ces questions restent sans réponse, et l'on notifie « quelque chose s'est passé » — ce qui n'est ni utile ni conforme.
D'où la chaîne décrite dans cette série : un capteur qui voit, un moteur qui conserve et qui cherche, des tableaux de bord qui donnent l'alerte. Ce n'est pas de l'outillage pour le plaisir, c'est la matière première d'une notification.
Détecter, conserver, chercher, restituer : quatre fonctions distinctes, et toutes nécessaires pour tenir un délai de notification.
La logique de sécurité qui en découle
1. On ne protège que ce que l'on voit
C'est le principe fondateur. Un réseau sans point d'observation est un réseau dont on ne peut rien affirmer — ni qu'il est sain, ni qu'il ne l'est pas. Identifier les points de passage obligés et y placer des capteurs est le préalable à toute politique de détection.
2. Observer avant d'agir
Le passage de la détection au blocage est une décision d'exploitation, pas une case à cocher. On observe, on comprend le bruit propre à son réseau, on ajuste — puis on bloque, progressivement. Une organisation qui active un IPS sans cette phase finira par le désactiver après le premier incident de production, et se retrouvera avec ni prévention, ni détection.
3. Conserver pour pouvoir revenir en arrière
La valeur d'un journal se révèle après coup. Le jour de l'incident, la question sera « qu'a fait cette machine il y a trois semaines ? ». Une rétention trop courte rend l'investigation impossible ; une rétention infinie coûte cher et pose des questions de protection des données. C'est un arbitrage à documenter, pas à subir.
4. Séparer la détection de la présentation
Le capteur détecte, le moteur d'indexation conserve et cherche, l'outil de visualisation restitue. Cette séparation — celle du lab — permet de remplacer un étage sans reconstruire les autres, et surtout d'ajouter des sources : journaux système, authentification, pare-feu. C'est ainsi qu'on passe d'un capteur isolé à une véritable capacité de corrélation.
5. Une alerte non traitée ne vaut rien
Le point le plus souvent négligé : détecter suppose que quelqu'un regarde, sache quoi faire, et dispose du temps pour le faire. Peu d'alertes, mais toutes actionnables, valent mieux qu'un tableau de bord saturé que plus personne n'ouvre. C'est un sujet d'organisation autant que de technique.
Ce qu'un lab apporte à ce sujet
On peut lire la directive et rédiger des procédures. On peut aussi monter la chaîne complète sur quatre machines virtuelles, générer du trafic suspect et regarder ce qui remonte — puis constater le nombre de faux positifs, le volume de journaux produit par un seul poste, et le temps nécessaire pour reconstituer une chronologie.
Cette expérience change la nature des discussions : on cesse de parler de conformité en termes abstraits, et l'on commence à parler de rétention en jours, de règles à désactiver et de qui regarde les alertes le lundi matin. C'est très exactement ce que NIS2 attend d'une organisation — et c'est l'objet des cinq articles pratiques de cette série.
La série « détection réseau »
Cinq articles pour comprendre, cinq pour construire :
- Qu'est-ce qu'un IDS ?
- Qu'est-ce qu'un IPS ?
- Suricata, le moteur
- OpenSearch, le socle analytique
- Détection réseau et NIS2 : la logique de sécurité — vous y êtes
- Lab (1) : architecture et passerelle
- Lab (2) : OpenSearch et Grafana
- Lab (3) : Suricata en mode IDS
- Lab (4) : la chaîne d'ingestion
- Lab (5) : les tableaux de bord