Points clés
- La mise en place des logs est souvent défaillante non pas dans sa conception, mais dans son exécution : journalisation incomplète, logs non protégés, durées de conservation insuffisantes, sources critiques omises.
- La journalisation des authentifications seules est insuffisante : les accès aux données, les modifications de configuration et les transferts de données doivent également être journalisés pour permettre l'investigation forensique.
- Mauvaise horloge système (clock skew) : des logs avec des timestamps incorrects perdent leur valeur forensique, car la reconstruction de la chronologie d'un incident devient impossible.
- NIST SP 800-92 et ISO 27001:2022 A.8.15 définissent les événements minimaux à journaliser et les exigences de protection et de conservation des logs.
La journalisation des événements informatiques est une pratique bien documentée dans les référentiels de sécurité, mais sa mise en œuvre effective est souvent lacunaire. Les organisations qui ont formellement mis en place une politique de journalisation découvrent lors des audits ou des investigations post-incident que les logs disponibles sont insuffisants pour répondre aux questions posées. Ces lacunes résultent d'erreurs de conception, d'implémentation ou de maintenance de la journalisation.
Identifier et corriger les erreurs les plus fréquentes dans la mise en place des logs est une priorité qui peut être réalisée sans investissement majeur — les lacunes sont souvent des erreurs de configuration plutôt que des absences d'infrastructure.
Les erreurs de périmètre
La journalisation incomplète — certains systèmes critiques ne génèrent pas de logs, ou génèrent des logs qui ne sont pas collectés — est l'erreur la plus fréquente. Dans les environnements complexes (cloud, on-premise, SaaS), il est facile d'oublier des sources de logs importantes : les équipements réseau (commutateurs, routeurs), les applications métier (ERP, CRM), les bases de données, les environnements cloud (AWS CloudTrail, Azure Monitor, GCP Cloud Logging), les équipements de sécurité (firewalls, proxies).
La journalisation des événements insuffisants est une deuxième erreur de périmètre. Journaliser uniquement les échecs d'authentification sans journaliser les succès empêche de détecter des connexions légitimes mais suspectes (heure inhabituelle, localisation géographique anormale, volume d'accès inhabituel). Journaliser les connexions sans journaliser les accès aux données empêche de déterminer quelles données ont été consultées lors d'une investigation. NIST SP 800-92 définit une liste minimale d'événements à journaliser : authentifications (succès et échecs), accès aux données sensibles, modifications de configuration, démarrage et arrêt des services, erreurs système et de sécurité.
L'omission des accès privilegiés est une erreur particulièrement grave. Les comptes administrateurs ont accès à l'ensemble du système d'information — leurs actions doivent être journalisées de manière exhaustive et leurs logs doivent être protégés de manière renforcée. Une journalisation insuffisante des activités des comptes privilégiés empêche de détecter des abus ou des compromissions de ces comptes critiques.
Les erreurs de configuration
La non-synchronisation des horloges (NTP) est une erreur de configuration qui semble mineure mais qui a des conséquences majeures sur la valeur forensique des logs. Lorsque les serveurs n'ont pas leur horloge synchronisée, les logs de différentes sources ont des timestamps décalés qui rendent impossible la reconstruction chronologique précise d'un incident. Une différence de quelques minutes peut suffire à empêcher la corrélation des événements entre deux systèmes. NIST SP 800-92 impose explicitement la synchronisation NTP de toutes les sources de logs.
L'absence de protection des logs est une erreur qui compromet leur valeur forensique et leur valeur de conformité. Si un attaquant qui a compromis un système peut modifier ou supprimer les logs de ce système, il peut effacer ses traces et rendre l'investigation impossible. Les logs doivent être envoyés en temps réel vers un système centralisé (SIEM) auquel l'attaquant n'a pas accès, et idéalement stockés dans un format immuable (Write Once, Read Many — WORM).
Les durées de conservation insuffisantes sont une erreur de configuration fréquente. PCI-DSS Exigence 10.7 impose 12 mois de conservation avec 3 mois disponibles immédiatement. ISO 27001:2022 A.8.15 n'impose pas de durée spécifique mais demande que la durée soit définie en fonction des exigences légales et contractuelles. De nombreuses organisations conservent leurs logs 30 à 90 jours, ce qui est insuffisant pour détecter les compromissions longues durée — des attaquants comme APT28 ou APT41 restent souvent dans les systèmes compromis pendant plusieurs mois avant d'être détectés.
Les erreurs de gestion
L'absence de revue régulière des logs est une erreur de gestion qui rend la journalisation inefficace pour la détection en temps réel. Des logs non surveillés n'alertent pas. La revue manuelle des logs est impraticable au-delà d'une certaine volumétrie — un SIEM (Security Information and Event Management) est nécessaire pour automatiser la corrélation des événements et la génération d'alertes. PCI-DSS Exigence 10.4 impose une revue quotidienne des logs des systèmes dans le périmètre PCI.
L'absence de tests de la journalisation est une erreur de maintenance. Une configuration de journalisation qui était correcte peut devenir défaillante après une mise à jour système, une migration vers le cloud, ou un changement d'infrastructure. Des tests périodiques qui vérifient que les événements attendus sont bien journalisés et que les logs sont bien transmis au SIEM permettent de détecter ces défaillances avant un incident.
L'investigation de l'attaque SolarWinds Sunburst par FireEye et Microsoft a révélé que les attaquants avaient pris soin de rester dans les limites des activités normales des systèmes compromis pour éviter de déclencher des alertes de log. Les attaquants avaient connaissance des patterns de journalisation des victimes et avaient calibré leurs activités pour ne pas dépasser les seuils d'alerte. Cette sophistication illustre que les logs ne sont utiles que si les événements qu'ils capturent et les seuils d'alerte sont correctement configurés. L'investigation a également révélé que de nombreuses organisations victimes n'avaient pas de logs sur les accès à leurs systèmes Office 365 et Azure AD, créant des angles morts majeurs.
En 2013, Vodafone Allemagne a découvert une compromission interne qui avait conduit au vol des données personnelles de 2 millions de clients. L'investigation a établi que l'accès non autorisé aux bases de données avait eu lieu pendant plusieurs semaines sans déclencher d'alertes, parce que les accès étaient réalisés par un compte interne légitime (apparemment compromis) dont les activités n'étaient pas anormales sur le plan des volumes. Les logs existants journalisaient les connexions mais pas le contenu des requêtes SQL sur les bases de données clients. Cette lacune dans les événements journalisés a empêché la détection précoce. Vodafone a depuis investi dans une solution de surveillance des accès aux bases de données (DAM — Database Activity Monitoring).
Le braquage de la Bangladesh Bank via le réseau SWIFT, qui a conduit au détournement de 81 millions USD, a inclus une tentative de manipulation des logs de supervision. Les attaquants ont sabordé les imprimantes liées aux terminaux SWIFT pour empêcher l'impression des confirmations de transaction, et ont tenté de modifier les journaux d'audit des transactions SWIFT. L'investigation de BAE Systems a établi que les journaux SWIFT disponibles n'avaient pas été configurés pour être transmis en temps réel vers un système externe, ce qui a permis aux attaquants de tenter de les modifier directement sur le système local. Cet incident a conduit SWIFT à imposer dans son CSP des exigences de journalisation externe et immuable pour tous les membres.