Points clés
- La collecte de logs sans leur exploitation est l'un des investissements les plus coûteux et les moins efficaces en cybersécurité : l'organisation supporte les coûts de stockage et de collecte sans bénéficier de la valeur de détection.
- Target (2013) est l'exemple canonique : des logs d'alerte correctement générés par FireEye, non exploités par les équipes en charge, n'ont pas empêché la compromission.
- Les causes principales de la non-exploitation des logs sont : les volumes trop élevés pour une analyse manuelle, l'absence de processus de triage des alertes, le manque de ressources humaines qualifiées, et un taux de faux positifs trop élevé qui génère l'alert fatigue.
- PCI-DSS v4.0 Exigence 10.4 impose une revue quotidienne des logs — une exigence qui présuppose un processus d'exploitation des logs, pas seulement leur collecte.
Le paradoxe des logs non exploités est l'un des problèmes les plus fréquents et les moins discutés de la sécurité opérationnelle. Des organisations qui ont investi dans des solutions SIEM, des outils de collecte de logs et des processus de journalisation se retrouvent avec des téraoctets de logs accumulés — mais sans la capacité ou les processus pour les analyser de manière significative.
Ce paradoxe révèle que la journalisation n'est que la première étape d'une chaîne de valeur qui comprend également la centralisation, l'enrichissement, l'analyse, le triage des alertes et la réponse. Chaque étape de cette chaîne est indispensable — une chaîne qui s'arrête après la collecte ne produit aucune valeur de détection.
Les causes de la non-exploitation
La première cause est le volume. Les systèmes informatiques modernes génèrent des volumes de logs qui dépassent largement la capacité d'analyse manuelle. Un parc de 1 000 postes de travail avec Sysmon configuré génère plusieurs millions d'événements par jour. Sans automatisation de l'analyse (SIEM avec règles de corrélation, UEBA, Machine Learning), ce volume est ingérable. Les organisations qui collectent des logs sans SIEM pour les analyser se retrouvent avec une masse de données inanalysable.
La deuxième cause est le taux de faux positifs. Un SIEM mal configuré génère des centaines ou des milliers d'alertes par jour dont la grande majorité sont des faux positifs. Les équipes SOC qui doivent traiter ce volume d'alertes développent rapidement une alert fatigue — une tolérance inconsciente aux alertes qui conduit à ignorer les alertes réelles mélangées aux faux positifs. La configuration et la calibration du SIEM pour réduire le taux de faux positifs est un processus continu qui nécessite de l'expertise.
La troisième cause est le manque de ressources humaines qualifiées. L'analyse des logs de sécurité nécessite des compétences spécialisées qui sont rares et coûteuses. La pénurie mondiale de professionnels de la cybersécurité (estimée à 4 millions de postes non pourvus selon ISC2 2024) se traduit concrètement dans les équipes SOC : beaucoup d'organisations disposent d'infrastructure de supervision sans avoir les effectifs nécessaires pour l'exploiter pleinement. Cette pénurie conduit à la priorisation des alertes critiques au détriment de l'analyse des signaux faibles.
Les solutions à la non-exploitation
L'automatisation de l'analyse et de la réponse (SOAR) est la solution principale au problème de volume. En automatisant le triage des alertes de routine (investigation automatique, enrichissement avec des données de threat intelligence, escalade conditionnelle aux analystes humains), le SOAR réduit le volume d'alertes qui nécessitent une intervention humaine et permet aux analystes de se concentrer sur les cas complexes.
La réduction du volume de logs collectés à ceux qui ont une valeur de sécurité réelle est une approche alternative à l'accumulation. Plutôt que de collecter tous les logs disponibles, certaines organisations adoptent une approche "log what matters" qui définit précisément les événements à journaliser en fonction de leur valeur pour la détection — réduisant le volume et améliorant le rapport signal/bruit.
L'externalisation de la supervision vers un MSSP (Managed Security Service Provider) ou un SOC as a Service est une option pour les organisations qui ne disposent pas des ressources internes suffisantes. Les MSSP opèrent des SOC 24/7 avec des équipes d'analystes expérimentés, souvent à un coût inférieur à celui d'un SOC interne. L'externalisation transfère la responsabilité de l'exploitation des logs tout en maintenant la propriété des données.
L'obligation de revue des logs
PCI-DSS v4.0 Exigence 10.4 impose une revue quotidienne des logs des systèmes dans le périmètre PCI-DSS. Cette obligation signifie que la simple collecte ne suffit pas — une revue effective doit être documentée et démontrée lors des audits. Les organisations qui collectent des logs sans les revoir quotidiennement ne satisfont pas à cette exigence, quels que soient leurs volumes de collecte.
ISO 27001:2022 A.8.15 (Journalisation) et A.8.16 (Surveillance des activités) exigent conjointement la journalisation et la surveillance active — une combinaison qui implique un processus d'exploitation des logs, pas seulement leur archivage. Ces exigences font de l'exploitation des logs une obligation de conformité et non seulement une bonne pratique.
Target avait déployé FireEye, un système de détection avancée, qui a correctement alerté sur l'installation de malware sur les terminaux de paiement en novembre 2013. Ces alertes ont été reçues et ont déclenché des notifications automatiques vers le centre de supervision externalisé de Target en Inde, qui les a transmises à l'équipe de sécurité américaine. L'équipe a fait le choix de ne pas activer la suppression automatique du malware et n'a pas lancé d'investigation immédiate sur les alertes. Pendant trois semaines, des alertes quotidiennes ont été reçues et ignorées. L'intrusion a finalement été découverte par le Department of Justice, non par Target. L'audit post-incident du Sénat américain a conclu que si Target avait répondu aux premières alertes, la compromission aurait pu être stoppée avant le vol massif de données.
Atos a publié en 2022 une étude basée sur son expérience d'opération de SOC pour des clients européens. L'étude documente que les SOC qu'Atos opère reçoivent en moyenne 1 200 alertes par analyste par jour — un volume qui rend une investigation complète de chaque alerte impossible. Atos a développé des mécanismes d'automatisation (SOAR) qui traitent automatiquement 73 % des alertes selon des procédures prédéfinies, réduisant le volume d'alertes nécessitant une analyse humaine à 327 par analyste par jour. L'étude documente que sans cette automatisation, le taux d'investigation des alertes tombe en dessous de 15 % — un niveau jugé insuffisant par Atos pour maintenir une posture de détection efficace.
Les attaques du groupe Lazarus contre des banques utilisant le réseau SWIFT en 2016 ont inclus des tentatives délibérées de suppression des logs pour effacer les traces. À la Bangladesh Bank, les attaquants ont modifié des fichiers de logs SWIFT pour supprimer les enregistrements des transactions frauduleuses. À la RCBC aux Philippines, des logs des terminaux SWIFT avaient été partiellement effacés. Ces tentatives illustrent que les logs représentent une valeur pour les attaquants — qui cherchent à les supprimer — et la nécessité de les protéger dans un stockage immuable. L'investigation de BAE Systems a pu reconstruire partiellement les activités en utilisant des métadonnées alternatives et des logs réseaux qui n'avaient pas été effacés.