Points clés
- La journalisation est souvent perçue comme une contrainte technique à coût élevé, sans retour direct visible — une perception qui conduit à des configurations insuffisantes révélées lors des incidents.
- Le coût de stockage des logs est souvent surestimé, tandis que le coût de l'absence de logs lors d'un incident est systématiquement sous-estimé avant qu'il ne survienne.
- Target (2013) disposait d'un système de surveillance des logs (FireEye) qui a détecté l'intrusion en temps réel — mais les alertes n'ont pas été traitées. L'enjeu n'est pas seulement la journalisation, c'est l'exploitation des logs.
- ISO 27001:2022 A.8.15 et NIST SP 800-92 définissent les principes de journalisation efficace : événements à journaliser, protection des logs, durée de conservation, revue périodique.
La journalisation des événements informatiques est souvent traitée comme un sujet technique de second rang — une obligation réglementaire à satisfaire au minimum, un coût de stockage à minimiser, une fonctionnalité activée par défaut sans réflexion sur sa configuration. Cette sous-estimation est documentée dans les investigations post-incident comme l'un des facteurs les plus fréquents aggravant l'impact des cyberincidents.
Les raisons de cette sous-estimation sont multiples : les coûts directs (stockage, traitement) sont visibles et immédiats, tandis que la valeur des logs n'est évidente qu'au moment d'un incident — quand il est trop tard pour les avoir configurés correctement. Cette asymétrie temporelle entre le coût et la valeur conduit à des décisions d'investissement sous-optimales.
Les raisons de la sous-estimation
La premierè raison est l'invisibilité de la valeur ex ante. La journalisation ne protège pas directement contre les attaques — elle ne prévient pas l'intrusion, elle ne bloque pas le malware. Sa valeur est post-facto : elle permet de comprendre ce qui s'est passé. Dans un cadre d'investissement orienté prévention, les logs sont souvent perçus comme moins urgents que les pare-feux, les antivirus ou les systèmes de détection d'intrusion.
La deuxième raison est le coût perçu versus le coût réel. Le stockage des logs a un coût que les équipes IT peuvent facilement chiffrer. Le coût d'une investigation forensique sans logs suffisants — consultants spécialisés, reconstruction laborieuse, délais d'identification prolongés, sanctions réglementaires — est un coût hypothétique que personne ne calcule avant l'incident. Le rapport coût-bénéfice de la journalisation n'est généralement pas présenté à la direction avant qu'un incident ne force la question.
La troisième raison est la complexité de la configuration. Une journalisation efficace n'est pas un simple switch on/off. Elle nécessite de définir quels événements journaliser (tous les événements ? seulement les événements de sécurité ?), comment centraliser les logs de sources multiples, comment les protéger contre la suppression malveillante, comment les conserver pendant les durées réglementaires, et comment les exploiter en temps réel. Cette complexité décourage les organisations qui ne disposent pas des ressources ou de l'expertise nécessaires.
Le paradoxe des logs non exploités
De nombreuses organisations disposent de logs mais ne les exploitent pas. Target (2013) est l'exemple le plus cité de ce paradoxe : l'entreprise avait investi dans FireEye, un système de détection avancée, qui avait correctement alerté sur l'intrusion initiale. Ces alertes ont été ignorées par les équipes de sécurité de Target et par le prestataire de sécurité externalisé. L'intrusion s'est poursuivie pendant plusieurs semaines, conduisant au vol de 40 millions de numéros de cartes bancaires.
Ce cas illustre que la valeur de la journalisation n'est pas dans l'existence des logs, mais dans leur exploitation active. Un log non lu n'alerte pas. Un SIEM (Security Information and Event Management) dont les alertes sont ignorées n'apporte pas de protection. La journalisation est une condition nécessaire mais pas suffisante — elle doit être accompagnée d'un processus d'exploitation des logs, d'un triage des alertes et d'une réponse aux anomalies identifiées.
La Ponemon Institute "State of Log Management" 2023 documente que 43 % des organisations collectent plus de logs qu'elles n'en traitent, et que les équipes SOC traitent en moyenne moins de 30 % des alertes générées par leurs systèmes de supervision. Cette statistique révèle un problème de dimensionnement et de prioritisation des alertes qui conduit à des angles morts dans la supervision.
Les principes d'une journalisation efficace
NIST SP 800-92 (Guide to Computer Security Log Management) définit les principes d'une journalisation efficace : identifier les sources de logs prioritaires (les systèmes les plus critiques et les plus exposés), définir les événements à journaliser pour chaque source (authentifications, accès aux données sensibles, modifications de configuration, erreurs système), centraliser les logs dans un référentiel protégé, et définir les procédures de revue et d'alerte.
La protection des logs contre la modification ou la suppression est une exigence particulièrement importante pour la valeur forensique. Un attaquant sophistiqué qui a accès à un système cherchera à supprimer ou modifier les logs pour effacer ses traces. Les logs doivent être envoyés vers un système centralisé (SIEM) auquel l'attaquant n'a pas accès, et idéalement conservés dans un stockage immuable qui empêche la suppression même par des comptes administrateurs compromis.
Target avait investi 1,6 million USD dans un système FireEye de détection avancée des menaces, déployé en mai 2013 — six mois avant l'intrusion de novembre 2013. FireEye a correctement alerté sur l'intrusion initiale et les installations de malware sur les terminaux de paiement. Ces alertes ont été reçues par le centre de sécurité externalisé de Target en Inde, qui les a transmises à l'équipe de sécurité de Target aux États-Unis. L'équipe de Target a fait le choix de ne pas activer la fonctionnalité automatique de suppression du malware, et les alertes n'ont pas donné lieu à une investigation immédiate. L'audit post-incident du Sénat américain a cité ce cas comme illustration de l'inutilité d'une journalisation sans processus d'exploitation des alertes.
La compromission de la base de données Starwood, qui avait démarré en 2014 et n'a été découverte qu'en 2018, illustre le risque de logs insuffisants dans un contexte de fusion. Starwood disposait de logs partiels sur les accès à sa base de données de réservations, mais ces logs n'avaient pas été intégrés dans le système de supervision de Marriott lors de l'acquisition. Pendant quatre ans, des accès non autorisés à la base de données ont eu lieu sans déclencher d'alertes. L'enquête de l'ICO britannique a établi que l'insuffisance de supervision des logs dans l'environnement Starwood était un facteur déterminant du délai de détection. Marriott a reçu une amende RGPD de 18,4 millions GBP.
La compromission de SingHealth en 2018, qui a exposé les données de santé de 1,5 million de patients dont le Premier ministre singapourien, a démarré des mois avant sa détection. La commission d'enquête a établi que les logs disponibles sur les systèmes compromis n'avaient pas été configurés pour capturer les accès à la base de données de dossiers médicaux, ce qui a empêché une détection précoce. Les logs existants auraient permis de détecter l'activité anormale si l'organisation avait mis en place un processus de revue régulière. La commission a recommandé des exigences renforcées de journalisation pour tous les fournisseurs de soins de santé agréés à Singapour.