L'une des questions les plus concrètes autour de NIS2 est la suivante : que faut-il réellement journaliser ? Beaucoup d'organisations répondent de deux mauvaises façons. Soit elles collectent presque tout sans hiérarchie claire, soit elles laissent les journaux dans leurs réglages locaux par défaut en espérant que cela suffira en audit ou en incident. Dans les deux cas, le résultat est souvent décevant.
L'objectif n'est pas de produire le plus de données possible. L'objectif est de conserver les traces les plus utiles dans les systèmes qui apportent la plus forte valeur pour l'audit, la chronologie d'incident et la capacité à défendre une décision. C'est pourquoi la priorisation compte plus que le volume.
Ce contenu ne constitue pas un conseil juridique ni une liste définitive d'obligations. Il sert de cadre pratique pour définir un minimum de logging pertinent dans les environnements PME et intermédiaires.
Pour qui cette page est faite
Cette page s'adresse à :
- les responsables IT et infrastructure,
- les administrateurs externes et MSP,
- les directions qui doivent comprendre la priorité du logging,
- les équipes sécurité qui construisent un minimum utile pour l'audit et les incidents.
Ce que vous devez en retenir
Après lecture, vous devriez mieux voir :
- pourquoi la collecte priorisée vaut mieux que la collecte indiscriminée,
- quelles couches d'infrastructure comptent le plus au départ,
- comment distinguer une couche minimum d'une couverture étendue,
- comment prioriser avec un budget et des ressources limités,
- pourquoi les preuves critiques doivent vivre hors des systèmes sources.
Pourquoi "tout collecter" n'est pas la bonne réponse
Quand une organisation collecte sans prioriser, trois problèmes apparaissent souvent :
- elle se perd dans le volume,
- elle consomme du budget sur des données à faible valeur probante,
- elle rate malgré tout les traces les plus importantes sur l'identité, les privilèges ou les accès distants.
Pour une PME ou une structure intermédiaire, il est généralement plus utile de partir d'une question simple : quels systèmes et quels événements seront les plus importants lors d'un audit, d'un incident ou d'une enquête interne ?
Comment raisonner sur les systèmes critiques
Les systèmes les plus importants ne sont pas toujours les plus bruyants. Il faut prioriser ceux qui aident à répondre à des questions comme :
- qui a fait quoi,
- qui a obtenu ou utilisé un accès privilégié,
- d'où venait un accès distant,
- que s'est-il passé juste avant une panne ou une activité suspecte,
- quels systèmes permettent de confirmer ou d'infirmer une hypothèse d'incident.
Dans la pratique, un modèle à deux couches fonctionne bien :
- une couche minimum sans laquelle l'audit et l'analyse d'incident restent faibles,
- une couche étendue qui apporte plus de contexte et de profondeur analytique.
Couche minimum : identité et Active Directory
Si votre organisation utilise Active Directory ou une autre plateforme centrale d'identité, c'est presque toujours la priorité numéro un. Les données d'identité structurent souvent toute la piste de preuve.
Les traces importantes sont typiquement :
- les connexions réussies et échouées,
- les changements et réinitialisations de mot de passe,
- la création et suppression de comptes,
- les changements de groupes et de privilèges,
- les modifications sur les comptes administratifs,
- les événements MFA ou d'accès conditionnel lorsqu'ils existent.
Pourquoi c'est essentiel :
- l'identité permet de relier une action à un acteur,
- beaucoup d'attaques exploitent les identités,
- sans cette couche, l'escalade de privilèges et les changements d'administration deviennent plus difficiles à reconstituer.
Couche minimum : serveurs Windows et endpoints sélectionnés
Tous les postes de travail n'ont pas besoin d'entrer immédiatement dans la première vague. En revanche, certains systèmes oui :
- contrôleurs de domaine,
- serveurs de rebond,
- postes d'administration,
- serveurs applicatifs centraux,
- serveurs hébergeant des données sensibles ou des services critiques.
Les traces utiles incluent souvent :
- les ouvertures de session,
- les actions privilégiées,
- les changements de services et de tâches planifiées,
- la désactivation de contrôles de sécurité,
- les événements système liés à une anomalie.
Une grande partie de la chronologie d'incident provient de cette couche.
Couche minimum : firewalls, VPN et équipements réseau
La couche réseau est essentielle parce qu'elle montre :
- d'où sont venus les accès,
- quelles connexions distantes ont existé,
- comment des accès administratifs ont été réalisés,
- si des flux ou comportements ont changé,
- quand des règles ou configurations ont été modifiées.
Les sources prioritaires sont souvent :
- les firewalls,
- les passerelles VPN,
- les reverse proxies ou gateways en bordure,
- certains switches et routeurs,
- les contrôles de segmentation autour des systèmes critiques.
Sans cette couche, il devient plus difficile de comprendre la propagation, la surface touchée et l'origine probable d'un incident.
Couche minimum : hyperviseurs, NAS et appliances
La virtualisation, le stockage et les appliances d'infrastructure sont fréquemment sous-journalisés alors qu'ils contiennent des traces très précieuses.
On y trouve souvent :
- des connexions administratives,
- des changements de configuration,
- des créations, suppressions ou déplacements de machines virtuelles,
- des actions sur snapshots et datastores,
- des événements de sécurité et de fonctionnement de l'appliance elle-même.
Cette couche est particulièrement importante lorsque des services métier critiques reposent sur l'infrastructure virtualisée.
Couche minimum : cloud et SaaS
Beaucoup d'organisations n'exploitent plus leurs services critiques uniquement en on-premise. Sans traces cloud et SaaS, la vision d'audit et d'incident reste incomplète.
À prioriser le plus souvent :
- les événements d'identité et de connexion Microsoft 365 ou Google Workspace,
- les changements administratifs au niveau de l'instance cloud,
- les événements d'audit et de sécurité sur les plateformes cloud,
- les activités privilégiées dans des applications SaaS critiques,
- les événements de contrôle dans les environnements IaaS et PaaS.
Ignorer cette couche revient à créer un angle mort sérieux.
Ce que les organisations sous-estiment le plus souvent
Les oublis ne portent pas toujours sur les serveurs métiers évidents, mais sur les points de contrôle autour d'eux :
- interfaces de management des firewalls et appliances,
- comptes administratifs dans le cloud,
- changements de configuration VPN,
- événements hyperviseur et stockage,
- traces provenant d'outils de téléadministration utilisés par des équipes internes ou des prestataires.
Ce sont souvent ces couches qui expliquent comment une attaque ou une erreur d'administration s'est réellement propagée.
Couche étendue : où il est pertinent d'aller plus loin
Une fois la couche minimum stabilisée, l'organisation peut élargir de manière fondée sur le risque. Cela peut inclure :
- une couverture endpoint plus large,
- les logs applicatifs de systèmes internes importants,
- une télémétrie réseau plus riche,
- des appliances de sécurité spécialisées,
- des corrélations et analyses sur un historique plus long.
Cette couche étendue doit répondre à de vrais cas d'usage, pas à l'envie abstraite de "tout collecter au cas où".
Comment prioriser avec un budget limité
Quand les moyens sont contraints, un filtre simple aide beaucoup.
1. Cette source aide-t-elle à comprendre qui a fait quoi ?
Si oui, priorité élevée.
2. Cette source aide-t-elle à reconstituer une chronologie d'incident ?
Si oui, priorité élevée.
3. Cette source aide-t-elle à soutenir une affirmation en audit ?
Si oui, priorité élevée.
4. Cette source est-elle particulièrement risquée parce que ses traces n'existent aujourd'hui qu'en local ?
Si oui, elle doit remonter dans la liste.
Cette logique conduit souvent à la même première vague : identités, firewalls, VPN, serveurs centraux et identités cloud.
Une bonne priorisation implique aussi de renoncer à certaines choses au départ. Une erreur fréquente consiste à charger très tôt une télémétrie endpoint très large ou des volumes massifs de données réseau, avant même de pouvoir répondre correctement aux questions de base sur l'identité, les privilèges et l'historique d'accès.
Pourquoi les logs doivent être centralisés hors des systèmes sources
Même les bonnes sources restent d'une utilité limitée si leurs traces demeurent uniquement locales. Lors d'une compromission, les attaquants tentent souvent de modifier, supprimer ou rendre inaccessibles les journaux locaux. Les logs critiques doivent donc être envoyés vers un emplacement distinct du système compromis.
La centralisation hors des systèmes sources réduit nettement le risque :
- de perdre les traces critiques,
- d'accepter un historique manipulé,
- d'écraser des événements importants,
- de ne plus avoir accès à la preuve au moment d'un incident.
L'angle audit et défendabilité est détaillé dans Audit, traçabilité et preuve.
À quoi ressemble un minimum pratique pour PME et organisations intermédiaires
Si vous voulez démarrer de manière pragmatique, un minimum utile signifie souvent :
- centraliser les logs d'identité, de firewall, de VPN et des serveurs clés,
- ajouter les identités cloud et les logs d'administration SaaS importants,
- vérifier que les sources remontent réellement,
- conserver la preuve hors des systèmes sources,
- pouvoir rechercher rapidement par heure, système et identité.
C'est souvent bien plus précieux qu'un projet plus large mais mal priorisé.
La vérification opérationnelle est tout aussi importante. Une source n'est pas réellement couverte simplement parce qu'elle apparaît dans une configuration. Il faut savoir :
- que les traces arrivent de manière cohérente,
- qu'elles restent lisibles dans le temps,
- qu'on peut retrouver un login, un changement ou une alerte concrets,
- qu'une panne de collecte est détectée rapidement,
- que la preuve critique n'existe pas seulement dans des fichiers locaux sur les systèmes touchés.
Recommandations pratiques
Si vous voulez structurer rapidement le sujet :
- listez vos services et systèmes critiques,
- définissez, par couche, les traces les plus utiles pour l'audit et l'incident,
- fixez le minimum de la phase 1,
- assurez une conservation centralisée hors des systèmes sources,
- vérifiez qu'un scénario concret peut être reconstitué à partir des données.
Si vous avez besoin du cadre stratégique plus large, revenez à NIS2 et conservation des logs.
FAQ
Faut-il collecter tous les événements Windows ?
Généralement non. Il faut commencer par les événements qui apportent le plus de valeur sur l'identité, les privilèges, les changements et les anomalies de sécurité.
Quelle est la première priorité avec un budget limité ?
Pour la plupart des organisations : identité, firewalls, VPN et serveurs centraux. Ce sont souvent les sources qui déterminent à la fois la qualité d'audit et la compréhension d'un incident.
Est-ce suffisant si nous pouvons extraire les logs des équipements quand nécessaire ?
Cela reste un modèle faible. En cas de compromission ou d'indisponibilité, les données peuvent être trop tardives, incomplètes ou déjà altérées.
Liens internes
- Retour à la vue d'ensemble NIS2
- Votre organisation relève-t-elle de NIS2 ?
- NIS2 pour la direction
- Audit, traçabilité et preuve
Prochaine étape
- Obtenir le standard minimal de logging pour les PME et organisations intermédiaires.
- Obtenir une évaluation de préparation sur les sources prioritaires et la rétention.
- Demander une consultation initiale pour cartographier la première vague de logging utile à l'audit et aux incidents.