Qu’est-ce que l’analyse des journaux ?
L’analyse des journaux est la pratique de collecter, interpréter, normaliser et interroger les enregistrements d’événements générés par les machines afin de répondre à une question opérationnelle ou de sécurité. Dans un SOC, cette question est généralement restreinte : ce compte s’est-il authentifié depuis une source inattendue, cet hôte a-t-il lancé un processus enfant inhabituel, quels appels d’API ont précédé le transfert de données.
Le matériau brut est hétérogène : canaux de sécurité Windows et Sysmon dans des fichiers .evtx, sorties auth.log et journald Linux, événements de pare-feu et proxy en CEF, et traces d’audit cloud telles que AWS CloudTrail ou les journaux de connexion Microsoft Entra ID exportés en JSON.
Un pipeline d’analyse des journaux opérationnel a quatre étapes :
- Collection. Exporter les événements de la source sans perdre de champs ou de horodatages.
- Normalisation. Mapper src_ip, IpAddress et sourceIPAddress sur un schéma commun.
- Détection. Exécuter des règles Sigma ou de fournisseurs et étiqueter chaque résultat avec les techniques MITRE ATT&CK.
- Corrélation. Regrouper les résultats liés dans une chronologie ou une chaîne d’attaque qu’un analyste peut valider.
Pourquoi l’analyse des journaux est importante pour la détection et la réponse
Les journaux sont souvent le seul enregistrement qui survit à une intrusion. La télémétrie EDR s’épuise, la mémoire est perdue au redémarrage, et la capture de paquets fonctionne rarement quand on en a besoin. Les IDs d’événements Windows 4624, 4672, et 4688, ou les appels CloudTrail tels que ConsoleLogin et CreateAccessKey, sont typiquement les preuves principales pour déterminer l’étendue d’un incident.
Trois pressions font de l’analyse des journaux une compétence fondamentale du SOC plutôt qu’une fonctionnalité du SIEM :
- Volume. Un seul incident peut produire des millions d’événements, et grep ne trouve que ce que vous savez déjà chercher.
- Lacunes de couverture. Les ordinateurs portables des sous-traitants, les segments OT, et les locataires SaaS que personne n’a connecté ne sont pas dans le SIEM, mais leurs journaux nécessitent encore une analyse.
- Gestion des données. Les journaux contiennent des noms d’utilisateur, des noms d’hôte, des IP, des cookies de session, et des tokens d’accès. Sous le RGPD, une grande partie de cela constitue des données personnelles, et un token compromis est un chemin d’accès actif.
Chaque journal attaché à un ticket de fournisseur ou collé dans un chat IA élargit le cercle de personnes et de juridictions qui peuvent lire les valeurs originales. Une bonne analyse des journaux répond à la question rapidement sans créer un deuxième incident.
Une brève histoire de l’analyse des journaux
Syslog, écrit par Eric Allman pour Sendmail au début des années 1980, a été standardisé plus tard dans la RFC 3164 (2001) et la RFC 5424 (2009). Pendant deux décennies, l’analyse des journaux signifiait grep et awk sur un serveur syslog central.
Windows est devenu structuré. Windows Vista a remplacé le format .evt hérité par le format .evtx basé sur XML et le modèle de canal encore utilisé aujourd’hui, et Sysmon (2014) a ajouté une télémétrie de processus et réseau de haute fidélité.
Les années 2000 ont apporté le SIEM. ArcSight, QRadar, et plus tard Splunk ont fait de la recherche centralisée et de la corrélation une catégorie de produit, et l’CEF d’ArcSight est toujours émis par la plupart des appareils réseau. Les années 2010 ont ajouté des piles ouvertes telles que ELK et des traces d’audit cloud telles que CloudTrail (2013).
En 2017, Sigma a offert aux défenseurs un format de règle indépendant des fournisseurs. La même année, SOC Prime a commencé à étiqueter les règles Sigma avec les techniques MITRE ATT&CK et a appliqué l’approche à l’enquête publique NotPetya. La cartographie ATT&CK est depuis devenue une attente standard pour le contenu de détection.
Vers où se dirige l’analyse des journaux
La détection se déplace en amont. Les équipes exécutent des règles Sigma sur les événements en streaming dans le pipeline avant que les données n’atteignent le SIEM, réduisant le coût de stockage et diminuant le temps moyen de détection de quelques heures à quelques minutes.
La corrélation surpasse les alertes uniques. Les correspondances isolées de faible fidélité sont du bruit. Une logique d’ordre supérieur qui relie des techniques à travers des hôtes et des fenêtres temporelles en chaînes d’attaque donne aux analystes des éléments à confirmer ou à clôturer.
Le triage par IA rencontre des limites de gestion des données. Les LLM expliquent bien les arbres de processus et résument des chronologies, mais envoyer de la télémétrie brute à un fournisseur de modèles soulève des questions de confidentialité et contractuelles, et les modèles avancés peuvent refuser directement le contenu de sécurité. Lors de la réponse incidente à HuggingFace en juillet 2026, une tentative d’envoi d’environ 17 000 événements aux modèles avancés a été bloquée par des garde-fous.
La pseudonymisation devient une étape du pipeline. Le masquage statique détruit la corrélation, et les hachages simples peuvent être inversés par des devinettes de dictionnaire. Les tokens HMAC avec clé conservent les relations intactes tout en supprimant les valeurs. Attendez-vous à cette étape devant chaque destination externe : services d’IA, support fournisseur, MSSP et lacs de données partagés.
Avantages de l’analyse des journaux
- Délimitation plus rapide pour les intervenants d’incidents. Une chronologie corrélée répond à « quels hôtes, quels comptes, depuis quand » en quelques minutes, ce qui entraîne un confinement et réduit le temps de séjour.
- Détections validées pour les ingénieurs. Rejouer des journaux contre la logique de règles montre quelles règles Sigma s’exécutent, lesquelles sont bruyantes, et quelles techniques ATT&CK ne sont pas couvertes.
- Preuve de conformité. La PCI DSS Exigence 10, la norme ISO/IEC 27001 contrôle A.8.15, et la NIS2 attendent tous que les événements de sécurité soient consignés et revus.
- Cause profonde pour les administrateurs. La sortie journalctl qui explique un service défaillant révèle souvent une mauvaise configuration qu’un attaquant pourrait exploiter.
- Coût SIEM réduit. Vous pouvez analyser une source éphémère une fois sans l’introduire.
- Collaboration plus sûre. Les journaux pseudonymisés permettent à un contractuel, un MSSP, ou un support TAC de groupe de cluster des hôtes et des utilisateurs sans voir les identités réelles.
Cas d’utilisation de l’analyse des journaux
Triage d’hôte non géré. Un ordinateur portable de sous-traitant sans EDR est suspecté de compromis. Exporter les journaux de sécurité, Sysmon, et PowerShell et vérifier les résultats de LogTotal pour l’accès aux informations d’identification (T1003), l’exécution de PowerShell (T1059.001), et les tâches planifiées (T1053.005) avant de réimager.
Prise de contrôle de compte cloud. Après une connexion ConsoleLogin inconnue, récupérer 72 heures de connexions CloudTrail et Entra ID et chercher de nouvelles clés d’accès, des changements de MFA, et des modifications de politique IAM.
Retainers IR externes et support TAC de fournisseur. Nettoyez les preuves avec une clé que vous gardez. Le tiers cluster toujours les hôtes et les utilisateurs par token, et vous mappez les tokens en interne.
Ingénierie de détection. Rejouer les journaux Atomic Red Team ou Caldera pour confirmer quelles règles s’exécutent, puis assainir les fixtures avant qu’elles n’atteignent Git ou les artefacts CI.
Vérifications de confidentialité. La pseudonymisation clé est une mesure technique documentable sous l’article 32 du RGPD : ce qui a été remplacé, comment les tokens ont été générés, qui détient la clé.
Comment effectuer une analyse des journaux : localiser et exporter les journaux par plateforme
Chaque procédure ci-dessous se termine dans un format que LogTotal lit nativement : EVTX, CEF, JSON/NDJSON, ou syslog. Corrigez d’abord la fenêtre temporelle UTC et la portée, et hachez chaque exportation (Get-FileHash ou sha256sum) pour la chaîne de garde.
Windows (EVTX). Requiert une console élevée en tant qu’administrateur local. Les fichiers .evtx actifs sous %SystemRoot%System32winevtLogs sont verrouillés par le service des journaux d’événements, donc exportez-les avec wevtutil :
wevtutil epl Security C:IRSecurity.evtx
wevtutil epl « Microsoft-Windows-Sysmon/Operational » C:IRSysmon.evtx
Ajoutez /q: »*[System[TimeCreated[timediff(@SystemTime) <= 86400000]]] » pour limiter l’exportation à 24 heures. Chemin GUI : eventvwr.msc → Windows Logs → Security → Enregistrer tous les événements sous…
Linux (syslog ou NDJSON). Nécessite root ou l’appartenance au groupe adm / systemd-journal. Copier /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL). Pour journald :
sudo journalctl –since « 2026-10-20 » –until « 2026-10-21 » –utc -o json > host01.ndjson
AWS CloudTrail (JSON). Requiert l’autorisation cloudtrail:LookupEvents. CloudTrail → Historique des événements → Télécharger les événements → Télécharger JSON couvre 90 jours d’événements de gestion. Depuis un bucket de trail (s3:GetObject, kms:Decrypt), aplatissez les enregistrements en NDJSON :
zcat ./ct/*.json.gz | jq -c ‘.Records[]’ > cloudtrail.ndjson
Microsoft Entra ID et Microsoft 365 (JSON). Centre d’administration Entra → Identité → Surveillance & santé → Journaux de connexion → Télécharger → JSON (rôle Lecteur de rapports). Pour les données d’audit Purview, ignorez l’exportation CSV et tirez directement le JSON (rôle Journaux d’audit) :
Search-UnifiedAuditLog -StartDate 2026-10-20 -EndDate 2026-10-21 -ResultSize 5000 |
Select-Object -ExpandProperty AuditData | Out-File .m365.ndjson -Encoding utf8
Appareils réseau (CEF). Switch the device to CEF (on FortiGate: config log syslogd setting → set format cef) and export lines containing CEF:0| from the syslog collector.
Offres de SOC Prime pour l’analyse des journaux
- Threat Detection Marketplace: plus de 1 000 000 de règles de détection natives Sigma, traduites dans les langues SIEM, EDR, et lac de données et étiquetées avec ATT&CK.
- Prime Hunt: scanne les données historiques SIEM, EDR, et du lac de données avec des règles pertinentes et en déduit des chaînes d’attaque à partir des résultats.
- Prime Detect: exécute des règles Sigma sur des événements en streaming avant le SIEM et les corrèle en chaînes d’attaque en temps réel.
- Uncoder.IO: traduit des règles Sigma et Roota en requêtes natives.
- LogTotal: analyse gratuite, sans inscription des fichiers journaux exportés avec une anonymisation dans le navigateur.
- logtotal-sanitizer: le moteur Apache 2.0 derrière LogTotal, en tant que bibliothèque Node.js et CLI pour une utilisation sur site ou en réseau isolé.
LogTotal couvre le cas dont traite ce guide : un fichier provenant d’une source externe à votre SIEM, ou un que vous ne pouvez pas partager brut. Chaque analyse s’exécute sur une instance dédiée et jetable du moteur DetectFlow de SOC Prime et est supprimée par la suite.
Comment fonctionne l’analyse des journaux avec LogTotal
LogTotal est gratuit, n’a besoin d’aucun compte, et anonymise les fichiers dans votre navigateur avant que quoi que ce soit ne soit téléchargé. SOC Prime ne conserve pas les journaux après analyse ni ne s’entraîne dessus.
- Ouvrir logtotal.com dans une version actuelle de Chromium, Firefox, ou Safari.
- Charger l’exportation. Déposer le fichier .evtx, .log, .json, ou .ndjson. Le format est détecté automatiquement.
- Revoir l’anonymisation. Les secrets, cookies, IDs de paiement, IPs, noms d’hôtes, noms d’utilisateur, et chemins de répertoires personnels deviennent des tokens HMAC-SHA-256 avec clé tels que <USER:…> ou <IP:…>. Les valeurs identiques obtiennent des tokens identiques, donc dix comptes répandus ressemblent toujours à dix utilisateurs.
- Télécharger la copie anonymisée pour votre dossier de cas. C’est exactement ce qui a été analysé.
- Exécuter l’analyse. Les événements sont vérifiés par rapport à environ 1 000 000 de règles de détection et 13 000 étiquettes, puis corrélés avec des règles Sigma d’ordre supérieur et une IA agentique. SOC Prime cite jusqu’à 1,7 million d’événements en moins d’une minute.
- Lire les résultats. Les détections sont cartographiées sur ATT&CK, groupées en chaînes d’attaques, et expliquées par l’IA. Un token qui apparaît à la fois dans les résultats d’accès aux informations d’identification et de mouvement latéral est votre compte à réinitialiser.
Pour plusieurs hôtes, ou lorsque les téléchargements de navigateur sont interdits, anonymisez localement avec le CLI open-source (Node.js 20+) et réutilisez une clé pour que les tokens correspondent à travers les fichiers :
npm install -g @socprime/logtotal-sanitizer
logtotal-sanitize ./dc01.log -o ./dc01.sanitized.log –print-key
logtotal-sanitize ./ws17.log -o ./ws17.sanitized.log –key « $KEY »
FAQ
Quels formats de journaux LogTotal accepte-t-il ?
EVTX, CEF, JSON/NDJSON, et syslog, détectés automatiquement. Convertissez d’abord les exports CSV en NDJSON.
Mes journaux bruts quittent-ils ma machine ?
Non. L’anonymisation s’exécute dans le navigateur, l’analyse s’exécute sur une instance jetable, et rien n’est conservé. Pour des politiques plus strictes, exécutez le sanitizer sur site ou dans un réseau isolé.
Combien d’événements une analyse peut-elle traiter ?
SOC Prime cite jusqu’à 1,7 million d’événements. Divisez les cas plus volumineux par hôte ou fenêtre temporelle et anonymisez chaque partie avec la même clé.
Puis-je mapper un token à la valeur réelle ?
Seulement avec votre clé : recalculez le HMAC pour une valeur connue et comparez. Sans la clé, les tokens résistent aux devinettes de dictionnaire.