La journalisation de sécurité est la collecte, le transport, le stockage et l'analyse de traces techniques produites par les systèmes et les applications, avec pour objectif la détection d'incidents, l'investigation forensique, la conformité réglementaire et l'amélioration continue de la posture de sécurité. Cinq piliers structurent une journalisation mature en 2026 : quoi logger (7 familles d'événements prioritaires), comment structurer (JSON + schémas ECS ou OCSF), comment collecter et transporter (Fluentd/Vector/Filebeat + TLS), où stocker avec quelle rétention (hot/warm/cold selon conformité NIS2, PCI DSS, DORA), et comment protéger les logs eux-mêmes (intégrité, contre l'injection, anonymisation des PII). Cet article couvre chaque pilier avec les standards actuels, les outils de référence, les exigences légales et les pièges fréquents pour construire une journalisation de sécurité solide sans exploser les coûts.
Pourquoi la journalisation sécurité est critique
3 objectifs convergents
1. Détection d'incidents en temps réel
Sans logs consolidés dans un SIEM, pas de détection cross-host
pas de corrélation temporelle, pas de threat hunting
2. Investigation forensique post-incident
Reconstitution de la kill chain sur les 30-90 derniers jours
Timeline précise des actions attaquant pour rapport et remédiation
3. Conformité réglementaire
NIS2, DORA, PCI DSS, HDS, ISO 27001 exigent la traçabilité
Sans logs retenus, défaut démontrable lors d'audit3 coûts d'une journalisation défaillante
- Impossibilité de prouver l'impact d'un incident : sans logs, la CNIL ou l'ANSSI exige souvent l'hypothèse du pire (toutes les données compromises).
- Amendes administratives : jusqu'à 10 M€ ou 2 % du CA mondial sous NIS2 pour manquements graves.
- Perte de confiance : clients, régulateurs, assurance cyber réduisent leur couverture ou la refusent.
Que logger : les 7 familles d'événements prioritaires
Une journalisation de sécurité minimale et efficace se concentre sur sept familles, dans l'ordre de priorité.
| Famille | Exemples d'événements | Priorité |
|---|---|---|
| 1. Authentification | Login success/fail, MFA, SSO SAML, OAuth | Critique |
| 2. Autorisation et rôles | Assume-role, privilege escalation, policy changes | Critique |
| 3. Opérations sur données sensibles | CRUD PII, dossiers médicaux, transactions | Haute |
| 4. Opérations administratives | Création/suppression utilisateurs, config changes | Haute |
| 5. Appels API externes | Sortants vers tiers, taux d'erreur, payload (pas PII) | Moyenne |
| 6. Événements réseau critiques | Firewall block/allow, nouveau port, scan détecté | Moyenne |
| 7. Erreurs applicatives | Exceptions, 5xx, auth bypass tentés | Faible mais utile |
Format recommandé : JSON structuré + corrélation
{
"@timestamp": "2026-04-24T09:14:32.451Z",
"event.category": "authentication",
"event.action": "user.login.success",
"event.dataset": "webapp.auth",
"user.id": "u_8h2kqr",
"user.email_hash": "b3d7f...",
"source.ip": "203.0.113.42",
"source.geo.country_iso_code": "FR",
"user_agent.original": "Mozilla/5.0...",
"http.request.method": "POST",
"url.path": "/api/auth/login",
"http.response.status_code": 200,
"trace.id": "7f1c9e3a...",
"service.name": "webapp-api",
"service.version": "1.42.3"
}Points clés de ce format :
@timestampen ISO 8601 UTC.- Champs préfixés selon un schéma (ici ECS - Elastic Common Schema).
- Pas de PII en clair (hash de l'email, pas de nom).
trace.idpour corrélation cross-services (OpenTelemetry compatible).- Service identifié par name + version pour debugging.
Standards et formats 2026
Hiérarchie des standards
Transport :
Syslog RFC 5424 (+TLS RFC 5425) : standard historique, toujours dominant
HTTP/HTTPS JSON : REST-based
gRPC / Protobuf : OpenTelemetry OTLP
Format de contenu :
JSON structuré : standard 2026
CSV : legacy, fragile
Plain text : à proscrire pour nouveaux systèmes
Protobuf : très performant, OpenTelemetry
Schéma sémantique :
ECS (Elastic Common Schema) : écosystème Elastic, ~900 champs
OCSF (Open Cybersecurity Schema) : cross-vendor, AWS/Splunk 2022
CEF (Common Event Format) : ArcSight, legacy
LEEF (Log Event Extended Format) : IBM QRadar, legacy
OpenTelemetry Logs : moderne, unifié avec traces/metricsElastic Common Schema (ECS)
ECS est le schéma le plus adopté en 2026 dans l'écosystème Elastic (Beats, Elastic Agent, Logstash) et par défaut dans plusieurs plateformes MDR. Environ 900 champs standardisés répartis en catégories : event, source, destination, user, http, url, dns, file, process, network, threat (indicateurs de compromission STIX).
OCSF (Open Cybersecurity Schema Framework)
Lancé en août 2022 par AWS et Splunk avec 17 autres acteurs (CrowdStrike, Cloudflare, Trend Micro, IBM, Palo Alto, Salesforce, etc.). Vise à normaliser les événements cybersécurité cross-vendor. Version 1.3 en 2026. Adopté massivement par AWS Security Lake, Databricks, Snowflake Security, plusieurs plateformes cloud native.
CEF et LEEF (legacy)
CEF (Common Event Format, ArcSight) et LEEF (IBM QRadar) sont des formats texte-délimités encore vus en environnement enterprise avec SIEM historique. Tolérables en transit mais pas recommandés pour nouveaux systèmes.
Pipeline de collecte et transport
Architecture type 2026
Sources (endpoints, apps, cloud)
│
▼
Shippers / Agents
├── Filebeat / Winlogbeat (Elastic)
├── Fluent Bit (CNCF, Kubernetes default)
├── Vector (Datadog, Rust, très rapide)
├── Fluentd (CNCF, plus lourd mais riche)
├── NXLog (Windows avancé)
└── Cloud-native (CloudWatch Agent, AMA, Google Ops Agent)
│ TCP 6514 + TLS (syslog secure) ou HTTP/gRPC
▼
Log aggregator / Pipeline
├── Logstash (Elastic)
├── Fluentd (dispatcher)
├── Vector (pipelines natifs)
├── Cribl Stream / LogStream (dédié routing)
└── Kafka en tant que buffer central
│
├──▶ SIEM chaud (Splunk, Sentinel, Elastic Security, QRadar, Chronicle)
├──▶ Data lake (S3 + Athena, Databricks, Snowflake)
└──▶ Archivage froid (Glacier, Azure Archive)Comparatif shippers 2026
| Shipper | Force | Overhead | Cas d'usage optimal |
|---|---|---|---|
| Vector | Performance Rust, multi-output | Très faible | Hosts, moderne, multi-sink |
| Fluent Bit | Léger, Kubernetes native | Très faible | K8s DaemonSet, IoT |
| Fluentd | Plugin-rich, mature | Moyen | Agrégation cross-source |
| Filebeat | Elastic native, ECS | Faible | Écosystème Elastic |
| Winlogbeat | Windows Event Log, ECS | Faible | Endpoints Windows |
| NXLog | Windows + rare logs | Moyen | Windows enterprise legacy |
| CloudWatch Agent | AWS native | Faible | Workloads AWS EC2 |
Exemple Vector - pipeline minimal
# vector.toml - collecter logs Docker, enrichir, envoyer vers Elastic
[sources.docker]
type = "docker_logs"
[transforms.parse]
type = "remap"
inputs = ["docker"]
source = '''
.@timestamp = .timestamp
.event.category = "container"
.service.name = .container_name
del(.timestamp)
'''
[sinks.elastic]
type = "elasticsearch"
inputs = ["parse"]
endpoints = ["https://es.example.internal:9200"]
auth.strategy = "basic"
auth.user = "vector-writer"
auth.password = "${ELASTIC_PASSWORD}"
index = "security-logs-%Y.%m.%d"
tls.enabled = trueSécurisation du transport
Exigences 2026 pour un pipeline de logs de sécurité :
Chiffrement in-transit : TLS 1.2 minimum, TLS 1.3 recommandé
Authentification mutuelle : mTLS pour shippers en environnement sensible
Intégrité : signatures HMAC sur les messages (RFC 5848)
Ségrégation réseau : VLAN dédié logs + firewall restrictif
Monitoring du pipeline : alerter si un shipper arrête d'émettre
(panne silencieuse = angle mort SIEM)Stockage : hot / warm / cold et rétention
Modèle de tiering
Hot (accès temps réel, cher)
Durée : 7 à 30 jours typiquement
Stockage : SSD, mémoire indexée
Usage : détection SIEM, queries fréquentes
Coût : très élevé (Splunk ~2500 USD/GB/an)
Warm (accès minute, modéré)
Durée : 30 à 180 jours
Stockage : SSD moins rapide ou HDD rapide
Usage : investigations post-incident, searches occasionnelles
Coût : 5-10x moins cher que hot
Cold (accès lent, compliance)
Durée : 6 mois à 7 ans selon cadre
Stockage : object storage (S3, GCS, Azure Blob), tape
Usage : audit, forensics anciens, ediscovery
Coût : très bas (S3 Glacier ~1 USD/GB/an)Tiering moderne 2026
Les plateformes Elastic, Splunk, Sentinel et Chronicle intègrent nativement le tiering. Exemple Elastic :
# Index Lifecycle Management Elastic
PUT _ilm/policy/security-logs-policy
{
"policy": {
"phases": {
"hot": { "min_age": "0ms", "actions": { "rollover": { "max_age": "7d" } } },
"warm": { "min_age": "7d", "actions": { "forcemerge": { "max_num_segments": 1 } } },
"cold": { "min_age": "90d", "actions": { "searchable_snapshot": { "snapshot_repository": "s3-backup" } } },
"delete":{ "min_age": "395d", "actions": { "delete": {} } }
}
}
}Rétention et conformité : les chiffres 2026
| Cadre | Rétention minimale | Exigences spécifiques |
|---|---|---|
| NIS2 | 12 mois | Logs d'accès, incidents, actions admin |
| DORA | 5-7 ans (financier) | Logs de transactions et incidents |
| PCI DSS v4.0 | 12 mois (3 mois hot) | Accès cardholder data |
| HDS (santé France) | 3 ans | Traces accès données santé |
| RGPD | 6-12 mois (techniques) | Logs de connexion, action PII |
| ISO 27001 Annexe A.8 | 6-12 mois | Journaux événements + monitoring |
| LPM (OIV France) | 6 ans | Sous contrôle ANSSI |
| SEC Cybersecurity Rules US | 5 ans | Incidents material |
| HIPAA (santé US) | 6 ans | Accès PHI |
En pratique, la plupart des organisations matures 2026 appliquent :
- 12-18 mois en hot/warm pour la détection et l'investigation.
- 3-7 ans en cold storage (S3 Glacier, Azure Archive) pour la conformité.
- Archivage chiffré et intègre (WORM - Write Once Read Many, object lock) pour preuves légales.
Protection des logs : le sujet oublié
Les logs sont une cible d'attaque à part entière. Trois risques principaux.
Log injection (CRLF)
Un attaquant insère des caractères de contrôle (\n, \r) dans un champ pour créer de faux événements de log ou masquer ses traces.
Input malveillant envoyé dans un champ User-Agent :
"Mozilla/5.0\n2026-04-24 10:00:00 INFO Admin login success from 10.0.0.1"
Si le logger écrit directement le User-Agent dans un fichier texte,
l'attaquant injecte une fausse ligne qui sera indexée par le SIEM.Défense : structured logging JSON systématique (pas de concat texte brute), échappement CRLF, filtres côté logger.
Log flooding / DoS
Un attaquant génère massivement des événements pour saturer le pipeline, masquer les vrais événements, ou causer un crash SIEM. Défense : rate limiting par source, sampling intelligent, alertes sur volumes anormaux.
Compromission du SIEM lui-même
Un attaquant compromet le SIEM pour effacer ses traces ou manipuler les détections. C'est la kill chain du groupe Lapsus$ 2022 (Microsoft, Nvidia, Okta). Défense : SIEM dans un segment réseau isolé, accès MFA obligatoire, logs du SIEM lui-même envoyés vers un second stockage write-once.
Règles Sigma : la détection portable
Sigma est le langage standard 2026 pour écrire des règles de détection portables entre SIEM (Splunk SPL, Sentinel KQL, Elastic EQL, Chronicle YARA-L).
# Exemple règle Sigma - détection brute force SSH
title: SSH Brute Force Authentication Failures
id: 6fef12cd-a39f-43bb-9988-7c18d74c7cb2
description: Detects high volume of SSH authentication failures from a single IP within 5 minutes
status: stable
logsource:
product: linux
service: sshd
detection:
selection:
process.name: sshd
event.outcome: failure
timeframe: 5m
condition: selection | count(source.ip) > 20
level: medium
tags:
- attack.credential_access
- attack.t1110.001Le repo SigmaHQ/sigma maintient 3 000+ règles communautaires gratuites en 2026.
Intégration avec SIEM
Le SIEM (Security Information and Event Management) est la destination finale des logs critiques. Principaux acteurs 2026 :
Commerciaux :
Splunk Enterprise Security : leader historique, cher
Microsoft Sentinel : cloud-native Azure, intégration Entra ID
IBM QRadar : enterprise legacy, mature
Elastic Security : open source + licence, rapide
Google Chronicle : cloud-native GCP, pricing par employés
Sumo Logic : SaaS, analytics
Exabeam Fusion : SOAR + UEBA intégrés
Securonix : UEBA avancé, cloud
Open source / low cost :
Wazuh : SIEM + EDR léger, gratuit
OpenSearch + Security plugin : fork Elastic, AWS-friendly
Graylog Open : mature, gratuit
LogRhythm NextGen SIEM : commercial mid-market10 bonnes pratiques à appliquer en 2026
- Structured logging JSON partout, avec schéma cohérent (ECS ou OCSF).
- Horloge NTP synchronisée sur tous les systèmes - timestamps fiables indispensables.
- Corrélation ID propagé cross-services (OpenTelemetry trace_id).
- TLS 1.2+ en transit sur tous les pipelines.
- Tiering hot/warm/cold pour optimiser le coût SIEM.
- Rétention documentée conforme au cadre réglementaire applicable.
- PII redacted au niveau logger, pas au niveau SIEM post-hoc.
- Monitoring du pipeline lui-même : alerter si shipper silencieux.
- WORM archive externe sur stockage indépendant du SIEM pour incidents critiques.
- Règles Sigma plutôt que règles SIEM-propriétaires pour portabilité.
Points clés à retenir
- Journalisation sécurité = 5 piliers : quoi logger (7 familles), comment structurer (JSON + ECS/OCSF), comment transporter (Fluentd/Vector + TLS), où stocker (hot/warm/cold), comment protéger (anti-injection, WORM).
- 7 familles prioritaires : auth, authz, opérations sur données sensibles, actions admin, appels API, réseau critique, erreurs applicatives.
- Formats : JSON structuré standard 2026, ECS dans l'écosystème Elastic, OCSF cross-vendor émergent (AWS/Splunk 2022), CEF/LEEF legacy.
- Shippers : Vector (Rust, performance), Fluent Bit (Kubernetes), Filebeat (Elastic), Winlogbeat (Windows), NXLog (Windows enterprise).
- Rétention 2026 : 12-18 mois hot/warm + 3-7 ans cold. NIS2 = 12 mois, DORA = 5-7 ans, PCI DSS = 12 mois, HDS = 3 ans.
- Ne jamais logger : passwords, tokens, clés privées, cartes bancaires complètes, PHI en clair. Utiliser hash, redaction, logger filters.
- SIEM principal + WORM archive externe (S3 Object Lock) = architecture robuste contre la compromission du SIEM lui-même.
- Règles Sigma comme langage portable entre SIEM (3 000+ règles communautaires SigmaHQ/sigma).
Pour approfondir les sources de télémétrie endpoint côté EDR, voir qu'est-ce qu'un EDR : définition, fonctionnement, outils 2026. Pour comprendre qui exploite ces logs au quotidien, lire différence entre SOC et CERT. Pour un parcours structuré blue team incluant la maîtrise du logging, voir la roadmap DevSecOps 2026.
