Supervision et NIS2 : détection, journalisation, incidents
Ce que la directive (UE) 2022/2555 demande pour la gestion des incidents, la détection et la journalisation, ce qu'elle ne dit pas, et la part qu'un outil de supervision comme FirstSI peut prendre
La directive (UE) 2022/2555, dite NIS2, fixe des obligations de cybersécurité à un grand nombre d'organisations européennes. Ce guide résume ce que le texte dit de la gestion des incidents, de la détection et de la journalisation, puis la part qu'un outil de supervision peut prendre.
Il ne remplace ni le texte, ni la loi qui le transpose dans votre pays, ni l'avis de votre autorité nationale.
Qui est concerné
La directive vise des « entités essentielles » et des « entités importantes », dans les secteurs listés par ses annexes I et II. L'annexe I couvre notamment l'énergie, les transports, la banque, la santé, l'eau, les infrastructures numériques, les fournisseurs de services gérés et l'administration publique. L'annexe II couvre notamment les services postaux, la gestion des déchets, la chimie, l'alimentation, la fabrication, les fournisseurs numériques et la recherche.
En règle générale, elle s'applique à partir de la taille d'une moyenne entreprise, au sens de la recommandation 2003/361/CE. L'article 2 prévoit des exceptions, dans les deux sens.
Chaque État membre transpose la directive dans sa loi. Les obligations exactes, le calendrier et l'autorité compétente dépendent donc de votre pays. En France, l'ANSSI publie les informations sur la transposition et sur les organisations concernées.
Ce que le texte demande
Article 21 : des mesures de gestion des risques
L'article 21 impose des mesures « appropriées et proportionnées ». Son paragraphe 2 en liste dix. Plusieurs touchent directement la supervision :
| Point | Mesure | Lien avec la supervision |
|---|---|---|
| a | politiques d'analyse des risques et de sécurité des systèmes d'information | indirect |
| b | gestion des incidents | détecter, qualifier, traiter, garder une trace |
| c | continuité des activités, dont la gestion des sauvegardes et la reprise après sinistre, et gestion de crise | savoir que les sauvegardes réussissent |
| e | sécurité de l'acquisition, du développement et de la maintenance des systèmes, dont le traitement des vulnérabilités | connaître les failles du parc |
| f | évaluation de l'efficacité des mesures | mesurer dans le temps |
| g | hygiène informatique de base et formation | indirect |
| i | sécurité des ressources humaines, contrôle d'accès et gestion des actifs | inventaire, comptes à privilèges, départs |
| j | authentification multifacteur ou continue, communications sécurisées | savoir qui l'utilise |
Les points d (sécurité de la chaîne d'approvisionnement) et h (cryptographie et chiffrement) relèvent surtout de la politique et des contrats.
Article 23 : déclarer les incidents importants
Un incident est « important » s'il a causé ou peut causer une perturbation grave des services ou une perte financière, ou s'il a touché d'autres personnes en leur causant un dommage considérable. Il se déclare au CSIRT ou à l'autorité compétente, en plusieurs temps :
| Étape | Délai |
|---|---|
| Alerte précoce | sans retard injustifié, et au plus tard 24 heures après en avoir eu connaissance |
| Notification d'incident | au plus tard 72 heures après en avoir eu connaissance |
| Rapport intermédiaire | à la demande du CSIRT ou de l'autorité |
| Rapport final | au plus tard un mois après la notification |
Le rapport final décrit l'incident, sa gravité et son impact, la menace ou la cause profonde, et les mesures prises. Pour tenir 24 heures, il faut d'abord voir l'incident, puis réunir vite les faits : machines, comptes, chronologie.
Article 20 : la direction est responsable
Les organes de direction approuvent les mesures de l'article 21, supervisent leur mise en œuvre et peuvent être tenus pour responsables. Leurs membres doivent suivre une formation.
Ce que le texte ne dit pas
- Il ne cite pas d'outil : ni SIEM, ni antivirus, ni produit particulier.
- Il ne fixe pas de durée de conservation des journaux.
- Il ne décrit pas l'organisation de la détection (équipe interne, prestataire, astreinte).
Pour certaines entités du numérique (informatique en nuage, centres de données, services gérés, services de sécurité gérés, entre autres), le règlement d'exécution (UE) 2024/2690 détaille ces exigences, dont la surveillance et la journalisation. Pour les autres, la loi nationale et les recommandations de l'autorité précisent les attentes.
Ce qu'il faut pouvoir montrer
Lors d'un contrôle ou après un incident, les mêmes questions reviennent :
- Quels événements surveillez-vous, et sur quelles machines ?
- Combien de temps gardez-vous les journaux, et qui peut les effacer ?
- Comment un incident est-il détecté, qualifié, suivi et clos ? Qui l'a traité, et quand ?
- Vos sauvegardes réussissent-elles, et l'avez-vous vérifié ?
- Qui a des droits d'administration, et qui a validé cette liste ?
- Quelles vulnérabilités connues restent ouvertes sur le parc ?
Pour chacune, une procédure écrite ne suffit pas. Il faut aussi la trace de son application, sous forme d'export, d'historique ou de décision datée.
Ce que FirstSI couvre
FirstSI fournit une partie des preuves techniques. Il ne fait pas la déclaration à l'autorité, ne rédige pas votre analyse de risques et ne remplace ni la formation ni la gouvernance.
| Attente | Dans FirstSI |
|---|---|
| Détection (art. 21, b) | règles de corrélation du SIEM, alertes de l'Active Directory, persistance sur les serveurs, fuites Microsoft 365, exposition vue d'Internet |
| Suivi des incidents (art. 21, b ; art. 23) | incidents numérotés, cycle de vie de l'ouverture à la clôture, qualification à la résolution, délais (SLA), historique des actions, export CSV ou PDF |
| Sauvegardes (art. 21, c) | sauvegardes et contrôles d'intégrité des bases SQL Server (Tâches de fond des bases), heartbeats des scripts de sauvegarde (HostMonitor) |
| Vulnérabilités (art. 21, e) | inventaire logiciel rapproché des CVE chaque nuit, failles activement exploitées signalées, fins de support (AssetMonitor) |
| Efficacité (art. 21, f) | score de posture de l'annuaire tracé sur 180 jours, score de sécurité du parc tracé sur 90 jours (État de sécurité des machines) |
| Contrôle d'accès, actifs (art. 21, i) | revue des accès aux groupes sensibles exportable en CSV, départs, inventaire des machines |
| Authentification forte (art. 21, j) | méthodes de double authentification d'un compte Microsoft 365, double authentification exigible pour la console FirstSI (Sécurité du client et SSO) |
| Journalisation | conservation réglable de 1 à 365 jours, changements de l'annuaire gardés 3 ans au moins, journal d'audit de la console (Données, RGPD et audit) |
L'Active Directory, la persistance, les tâches de fond des bases et les fuites Microsoft 365 ouvrent leurs incidents sans règle à activer, une fois leur collecte en place. Les règles de corrélation du SIEM, elles, s'installent désactivées. Activez celles qui correspondent à vos modules. Voir SIEM : corrélation et incidents de sécurité.
Par où commencer
- Vérifiez auprès de votre autorité nationale si votre organisation est concernée, et à quel titre.
- Listez vos systèmes critiques, ceux dont l'arrêt bloque l'activité.
- Pour chacun, répondez aux six questions ci-dessus avec une preuve, pas une intention.
- Écrivez la procédure de déclaration : qui décide qu'un incident est important, qui déclare, avec quels éléments, sous 24 heures.
- Testez-la une fois par an sur un incident fictif.
Pour aller plus loin
- Directive (UE) 2022/2555 sur EUR-Lex : le texte, articles 20, 21 et 23 en particulier.
- Règlement d'exécution (UE) 2024/2690 sur EUR-Lex : les exigences détaillées pour certaines entités du numérique.
- ANSSI : la transposition en France et les organisations concernées.
- Vérifier la sécurité de son Active Directory : contrôle d'accès et comptes à privilèges, en pratique.
Présentation : SIEM pour PME et ETI : détection d'incidents
Source : · Docs FirstSI · mis à jour le 11/10/2026