Normaliser les logs avec OCSF, ECS ou CIM

Un journal de pare-feu, une trace d’authentification et un événement applicatif peuvent tous signaler la même attaque, tout en nommant différemment l’adresse source, l’utilisateur et le résultat. La normalisation transforme ce chaos syntaxique en événements interrogeables, mais son coût, ses erreurs et son placement dans l’architecture déterminent la capacité de détection réelle.

→ Lire l’explication complète de la marmotte

OCSF, ECS et CIM : un vocabulaire commun, pas une langue universelle

Un schéma de normalisation fixe des champs, leurs types, leur sens et souvent leur hiérarchie. L’objectif est de mapper src_ip, client.address, remoteHost, ip_source ou sender vers une représentation commune. Une règle de détection peut alors chercher une adresse Internet Protocol (IP) source sans connaître les caprices lexicaux de chaque éditeur.

OCSF (Open Cybersecurity Schema Framework) propose un modèle orienté événements de sécurité. Ses classes couvrent notamment l’authentification, l’activité réseau, les processus et les découvertes. Il sépare les catégories d’événements des extensions spécifiques aux produits. C’est un bon choix pour une plateforme multi-outils construite autour de la sécurité, surtout lorsque les producteurs et consommateurs ne dépendent pas d’un seul moteur d’analyse.

ECS (Elastic Common Schema) structure les données autour de documents JSON (JavaScript Object Notation) indexés dans Elastic. Ses conventions de nommage sont précises, par exemple source.ip, destination.ip, user.name, event.action et process.executable. ECS est très efficace lorsque la chaîne Elastic est déjà le plan de données principal. Sortir de cet écosystème reste possible, mais le schéma porte l’empreinte de son indexeur.

CIM (Common Information Model) de Splunk organise les champs et les jeux de données autour des usages de recherche et des accélérations de modèle de données. Il résout bien la corrélation dans Splunk, avec une maturité opérationnelle réelle. Son coût principal est le couplage avec les conventions de recherche, les add-ons et les modèles Splunk.

Aucun de ces schémas n’est devenu universel parce qu’un schéma n’est pas seulement une liste de champs. C’est un contrat sur la sémantique. user.name peut désigner un compte soumis, un compte effectif après délégation, un identifiant affiché ou un principal technique. Les produits sources ne s’accordent déjà pas entre eux, et les organisations ajoutent des objets métier, des identités hybrides et des champs réglementaires. La promesse d’un vocabulaire global finit généralement dans une slide avec beaucoup de flèches et un champ custom.magic_value.

La recommandation est nette : adopter un schéma canonique unique pour les événements qui alimentent la détection, l’investigation et les indicateurs. Conserver le log brut à côté. Choisir OCSF pour une architecture de sécurité indépendante des outils, ECS dans un socle Elastic assumé, CIM dans un socle Splunk assumé. Tenter d’agréger les trois comme schémas maîtres produit une fédération de dictionnaires, pas une normalisation.

Les champs canoniques doivent au minimum distinguer :

l’horodatage émis par la source et celui de réception ;
l’action observée, son résultat et sa gravité ;
les sujets, acteurs et comptes effectifs ;
les adresses, hôtes, ports et protocoles réseau ;
le processus, le fichier ou la ressource concernée ;
la source de collecte, sa version et le parseur appliqué ;
un identifiant d’événement stable et le document brut immuable.

La sécurité des identités dépend directement de cette distinction entre compte déclaré et identité effectivement utilisée. Fusionner les deux dans un champ user rend invisibles les délégations, les exécutions de service et une partie des élévations de privilèges.

Pipeline de transformation : du brut à l’événement exploitable

Le pipeline commence par une enveloppe de transport fiable : collecteur identifié, canal chiffré, accusé de réception si la source le permet, horodatage de réception et partitionnement. Le message brut doit être stocké avant toute transformation destructive. Un parseur qui casse ne doit jamais faire disparaître l’élément qu’il ne comprend pas. Sinon, l’attaquant n’a qu’à envoyer la ponctuation qui donne de l’urticaire au parseur.

Le parsing extrait les champs selon le format réel : JSON, Syslog, paires clé-valeur, CSV (Comma-Separated Values), XML (Extensible Markup Language) ou texte libre. Il faut versionner chaque parseur et associer sa version à l’événement. Une mise à jour d’agent qui renomme username en userName est une rupture de contrat, pas une variation cosmétique.

Le mapping convertit ensuite les valeurs extraites vers le schéma canonique. Il doit préserver la valeur source lorsqu’une conversion est ambiguë. Convertir aveuglément deny en failure est raisonnable pour un pare-feu, moins pour une politique applicative où le refus représente le comportement attendu. Chaque règle de mapping doit donc déclarer la source, la cible, le type, les valeurs autorisées et le comportement en cas d’absence.

L’enrichissement ajoute du contexte externe. Une résolution DNS (Domain Name System) inverse peut associer une adresse à un nom, une base de géolocalisation peut fournir pays et réseau autonome, un annuaire LDAP (Lightweight Directory Access Protocol) peut ajouter le service, le statut ou les groupes d’un compte. Ces données sont des observations dérivées, jamais des faits équivalents au log source.

La résolution inverse est particulièrement trompeuse : l’enregistrement PTR (Pointer Record) est contrôlé par le détenteur de la zone inverse et peut être périmé ou manipulé. Il ne faut pas utiliser un nom obtenu ainsi comme preuve d’identité. Pour un contrôle d’accès, la seule réponse correcte est aucune. Pour une piste d’investigation, stocker le nom, la date de résolution, la source et une durée de validité limitée.

La déduplication supprime ou regroupe les répétitions selon une clé déterministe : source, identifiant natif, horodatage, action et objet. Une fenêtre temporelle seule est dangereuse. Deux refus d’authentification identiques à quelques secondes d’écart peuvent signaler un bourrage d’identifiants, pas un doublon. Dédupliquer les retransmissions de collecteurs, oui. Dédupliquer les signaux de sécurité parce qu’ils se ressemblent, non.

Exemple reproductible de mapping JSON vers ECS

Cet exemple transforme un événement d’authentification brut avec jq, processeur JSON disponible sur les distributions courantes. Il conserve la charge brute dans event.original et marque explicitement le résultat du mapping.

# Installer jq sur Debian ou Ubuntu, puis enregistrer l'entrée dans auth.json.
sudo apt-get install -y jq

# Transformer le log brut vers des champs ECS sélectionnés.
jq '
{
  "@timestamp": .timestamp,
  "event": {
    "kind": "event",
    "category": ["authentication"],
    "type": ["start"],
    "action": .action,
    "outcome": (if .result == "success" then "success" else "failure" end),
    "original": (tojson)
  },
  "user": {
    "name": .username
  },
  "source": {
    "ip": .source_ip
  },
  "host": {
    "name": .host
  }
}' auth.json

Le fichier auth.json peut contenir :

{"timestamp":"2026-09-22T10:15:00Z","action":"login","result":"success","username":"alice","source_ip":"198.51.100.42","host":"vpn-01"}

Le résultat est exploitable, mais pas complet. Le script ne valide ni le format de l’horodatage ni l’adresse IP, ne distingue pas une authentification locale d’une fédération, et ne protège pas contre une taille excessive de event.original. En production, imposer une limite de taille, un schéma de validation et une file d’échec séparée. Le rejet silencieux est un mécanisme de dissimulation offert gratuitement aux entrées malformées.

Normaliser à l’ingestion ou à la requête

Le compromis central est brutal : normaliser à l’ingestion paie du processeur, de la mémoire et parfois du stockage maintenant ; normaliser à la requête paie ce coût à chaque recherche, précisément quand la charge et l’urgence montent.

La normalisation à l’ingestion produit des index cohérents. Les requêtes de détection sont rapides, les règles sont réutilisables et les tableaux de bord ne recalculent pas mille fois la même extraction. Elle exige des parseurs maintenus, une capacité de calcul dimensionnée pour les pics, des mécanismes de reprise idempotents et une gouvernance des changements. C’est le bon choix pour les sources qui alimentent les alertes, les investigations fréquentes et les exigences de rétention active.

La normalisation à la requête conserve des données proches de leur forme native et reporte la transformation. Elle réduit le coût initial et accélère l’onboarding de nouvelles sources. Elle est acceptable pour l’archivage, les données rarement consultées et l’exploration initiale. Elle devient toxique lorsqu’une équipe doit joindre, filtrer et agréger plusieurs téraoctets pendant un incident. La recherche lente n’est pas une limitation ergonomique, c’est une perte de capacité de réponse.

La position à retenir : normaliser à l’ingestion les événements de sécurité prioritaires, conserver le brut et réserver la normalisation à la requête aux données froides ou expérimentales. Un pipeline hybride est sain si la frontière est explicite : niveau de criticité, délai de recherche attendu, durée de rétention et coût par source. Un hybride flou est juste un retard de facturation, avec des règles de détection qui découvrent l’existence du concept de latence le soir où elles deviennent nécessaires.

Cette décision doit rejoindre l’architecture de données et les mécanismes de menaces réseau. Indexer toutes les métadonnées imaginables n’améliore pas une détection ; indexer les pivots réellement utilisés, si.

Surface d’attaque, exploitation et reprise

Le pipeline est une cible. L’injection de logs peut fabriquer des séparateurs, de faux horodatages ou des champs conçus pour casser une corrélation. Protéger les formats structurés, limiter les tailles, encoder les valeurs lors de l’affichage et isoler les événements de parsing en erreur. Ne jamais exécuter une commande ou une expression issue d’un champ de journal.

L’empoisonnement d’enrichissement vise les données externes : enregistrement DNS falsifié, base de géolocalisation obsolète, annuaire compromis, attribut de groupe excessivement large. Les enrichissements doivent être étiquetés avec leur provenance et leur instant de calcul. Une règle d’alerte ne doit pas dépendre exclusivement d’un enrichissement non authentifié.

Les secrets de collecte, certificats clients et comptes de lecture LDAP nécessitent une rotation documentée. Un compte d’annuaire dédié doit avoir lecture des seuls attributs nécessaires, sans droit d’écriture et sans appartenance administrative. La désactivation des liaisons LDAP non protégées reste un prérequis, détaillé dans la désactivation du simple bind LDAP.

Superviser le taux de parsing réussi, la dérive des champs, le retard de bout en bout, la profondeur des files, les échecs d’enrichissement et le taux de déduplication. Une baisse brutale du volume peut révéler une panne de collecte, pas une semaine miraculeusement calme. Sauvegarder les configurations de parseurs, les dictionnaires de mapping, les règles de déduplication et les références d’enrichissement. Tester la reprise avec relecture de données brutes : restaurer uniquement les index normalisés revient à restaurer une traduction sans garder le texte original.

La normalisation ne garantit ni exhaustivité, ni intégrité de la source, ni détection d’une attaque inconnue. Ces propriétés dépendent de la couverture des capteurs, de l’authentification des collecteurs, de l’horodatage fiable, des contrôles d’accès et des règles de détection. Un schéma commun rend les données comparables. Il ne rend pas un capteur aveugle soudainement voyant. Même les tableurs savent faire semblant mieux que cela.

🐝 Ce qui arrive si on s’en passe

Sans schéma canonique, chaque règle de détection doit être réécrite pour chaque produit, et une source ajoutée reste muette tant que son dialecte n’est pas appris. La corrélation inter sources devient manuelle : rapprocher un refus de pare-feu, un échec d’authentification et une exécution de processus suppose de deviner quel champ porte l’adresse ou le compte, ce qui allonge la reconstruction de chronologie et laisse passer les pivots. Les indicateurs de couverture perdent leur sens, puisque compter des événements hétérogènes revient à additionner des unités différentes. En audit, prouver qu’un accès a été tracé devient une recherche au cas par cas dans des formats bruts. Enfin, un renommage de champ après mise à jour d’agent casse silencieusement des recherches qui continuent de renvoyer zéro résultat, sans signal distinguant l’absence d’attaque de l’absence de données.

🦫 Explication de la marmotte 🍫

Les logiciels produisent des journaux pour raconter ce qu’ils ont fait : connexion réussie, connexion refusée, fichier ouvert ou échange réseau. Le problème est que chaque logiciel écrit ces informations avec ses propres noms et son propre format. Pour analyser plusieurs sources ensemble, un système de traitement reçoit d’abord le message original et le conserve. Cette conservation permet de vérifier plus tard ce qui a réellement été envoyé.

Ensuite, le système lit le message, extrait les informations et les place dans des rubriques communes. Une adresse de départ, un compte utilisé, une action et son résultat reçoivent toujours le même nom, quelle que soit la source. Le système peut ajouter des informations, par exemple le pays associé à une adresse ou le service auquel appartient un compte. Ces ajouts doivent rester séparés du message original, car ils peuvent être faux, anciens ou manipulés.

Le système repère aussi les retransmissions identiques pour éviter de compter plusieurs fois le même message. Il ne doit pas supprimer des événements réellement répétés, car ils peuvent signaler une attaque.

Faire ce travail dès l’arrivée demande des ressources de calcul, mais les recherches sont ensuite rapides pendant un incident. Le faire seulement au moment de rechercher économise des ressources au départ, mais ralentit chaque enquête. Si une étape échoue, le message original doit partir dans une file d’erreur, être surveillé et pouvoir être retraité après correction.

Pages voisines

La citent

Normaliser les logs avec OCSF, ECS ou CIM

Elle cite

Normaliser les logs avec OCSF, ECS ou CIM

Normaliser les logs avec OCSF, ECS ou CIM

OCSF, ECS et CIM : un vocabulaire commun, pas une langue universelle

Pipeline de transformation : du brut à l’événement exploitable

Exemple reproductible de mapping JSON vers ECS

Normaliser à l’ingestion ou à la requête

Surface d’attaque, exploitation et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines