Pseudonymiser les données de journal dans Cribl Detect avec le pack LogTotal Sanitizer

Résumé

Cribl Detect, sorti le 29 septembre 2026, est un SIEM qui fonctionne sur la plateforme de données de Cribl. Les données qu’il stocke et recherche sont ingérées via les Cribl Stream Routes and Pipelines, donc une étape de nettoyage dans ces Pipelines détermine ce à quoi les analystes, la hiérarchisation assistée par IA, les notifications d’alerte et les ensembles de données retenus peuvent accéder.

The Cribl LogTotal Sanitizer est un Cribl Pack open-source (ce projet n’est affilié ni avec Cribl ni avec SOC Prime) basé sur le moteur de nettoyage de LogTotal de SOC Prime. Il pseudonymise les données journaux en texte libre en temps réel. Il détecte onze catégories de valeurs sensibles et remplace chacune par un jeton HMAC indexé qui porte un label de type, par exemple <USER:…> ou <IP:…>. Les jetons sont déterministes, donc les événements référant le même utilisateur, hôte ou adresse peuvent toujours être corrélés après que la valeur originale ait été supprimée.

• Les identifiants, les données de paiement, les données de santé et les identificateurs personnels sont supprimés avant l’enregistrement des données. Cela réduit l’impact d’une violation et le périmètre de conformité du SIEM.
• Les détections basées sur la corrélation continuent de fonctionner sur les valeurs tokenisées.
• Le Pack est sous licence MIT et fonctionne sur la capacité Worker existante, sans frais de licence au Go.

Contactez le service commercial

Où se situe le nettoyage dans le chemin de données Detect

Detect utilise le modèle standard Cribl de Sources, Routes, Pipelines et Destinations. Les détections en temps réel, la recherche fédérée, l’enquête assistée par IA et le routage d’alerte s’exécutent sur les données que Stream écrit dans Cribl Lake ou les ensembles de données Cribl Search (Présentation de SOC Prime). Les données que Detect interroge sur place via la recherche fédérée, comme un bucket existant S3, ne passent pas par un Pipeline et doivent être nettoyées au moment de l’écriture.

Un SIEM expose le contenu des événements à plus de consommateurs qu’un pipeline de journal typique : analystes de niveau 1, partenaires MSSP, agents IA, notifications Slack et PagerDuty, et rétention à long terme. Supprimer les valeurs sensibles une fois, en amont de tous, est plus simple à opérer et à auditer que d’appliquer des contrôles d’accès pour chaque consommateur.

Origine : LogTotal de SOC Prime

Le moteur de nettoyage dans le Pack a été développé par SOC Prime. SOC Prime a publié LogTotal en tant qu’aperçu public gratuit le 26 août 2026 (annonce). LogTotal nettoie les fichiers journaux localement dans le navigateur avant que quoi que ce soit soit téléchargé. Les événements nettoyés sont ensuite corrélés avec le contenu de détection de SOC Prime : environ un million de règles de détection, un ensemble de données de 13 000 labels, des règles Sigma d’ordre supérieur et la corrélation IA agentique. LogTotal ne conserve pas les journaux téléchargés.

SOC Prime a publié le composant de nettoyage séparément en tant que bibliothèque open-source @socprime/logtotal-sanitizer sous Apache-2.0. Le Cribl Pack est un projet communautaire de M3NIX qui encapsule cette bibliothèque.

Les décisions de conception décrites ci-dessous suivent la logique de SOC Prime pour LogTotal, qui identifie trois modes d’échec courants de la rédaction des journaux :

• Le masquage statique remplace chaque adresse IP ou nom d’utilisateur par le même espace réservé. Dix échecs de connexion semblent alors identiques, et un seul compte compromis ne peut plus être distingué d’une attaque de diffusion de mot de passe contre dix comptes.
• La recherche et remplacement simple manque des valeurs dans les JSON imbriqués ou les encodages inhabituels, et surphrase les valeurs qui ne semblent qu’avoir l’air sensibles, telles que les numéros de version en forme d’adresses IP ou les UUID utilisés comme identifiants de message.
• Les hachages non indexés peuvent être inversés par des attaques par dictionnaire, et des hachages non salés identiques provenant d’organisations différentes peuvent lier à tort des incidents non liés.

Les jetons indexés et typés traitent ces trois problèmes.

Comment fonctionne le Pack

Le Pack (cc-stream-logtotal-sanitizer) implémente une fonction personnalisée Cribl. Par défaut, la fonction applique tous les détecteurs intégrés à _raw, remplace chaque correspondance par un jeton et définit __logtotal_sanitized: true sur les événements qu’elle modifie. _time et tous les autres champs restent inchangés.

Les détecteurs sont évalués dans cet ordre de priorité :

1. Secrets : jetons de porteur, JWT, clés API, blocs PEM et jetons de fournisseurs de cloud
2. Cookies de session
3. Données de paiement, validées avec les sommes de contrôle Luhn et mod-97
4. Identificateurs gouvernementaux
5. Identificateurs de santé et codes similaires à ICD
6. Numéros de téléphone
7. Adresses IPv4, IPv6 et MAC
8. Noms d’hôtes et FQDN
9. Noms d’utilisateur et adresses email
10. Géolocalisation
11. Chemins de répertoires personnels

Pour les entrées JSON, les valeurs sous des noms de clé sensible connus sont remplacées en fonction du nom de clé. Le reste de l’événement est toujours traité par les détecteurs regex.

Un jeton est le HMAC-SHA-256 de l’ID de règle et de la valeur originale, tronqué à 16 caractères hexadécimaux. La même clé, règle et valeur produiront toujours le même jeton. En mode pseudo, le jeton inclut un label de type. En mode masque, utilisé pour les secrets et les données de paiement, le jeton a la forme neutre <R:…>. Exemple, avec les valeurs des jetons raccourcies :

avant : user alice@corp.example échec de connexion depuis 10.20.1.7 vers db-prod-01.corp.example

après :  user <USER:3f9a…> échec de connexion depuis <IP:b81c…> vers <HOST:0d4e…>

Les règles personnalisées sont définies comme un tableau JSON dans la configuration de la fonction. Chaque règle spécifie un ID, une expression régulière, un mode et un préfixe de jeton. Les numéros de ticket interne ou de personnels, par exemple, peuvent être mappés sur des jetons <TICKET:…>.

Déploiement

Le Pack est installé avec le workflow standard Pack de Cribl dans le groupe Worker qui envoie des données à Detect. Les fichiers de version, les exigences et les instructions d’installation se trouvent dans le dépôt GitHub du projet. En résumé, le Pack est importé avec les fonctions personnalisées activées, une clé HMAC aléatoire est stockée en tant que Secret de groupe Worker, et la sortie est vérifiée contre l’échantillon d’aperçu fourni. Le Pack est ensuite défini comme le Pipeline d’une Route qui livre aux ensembles de données de Detect, avec un filtre qui sélectionne les sources contenant des données sensibles.

Trois détails de mise en œuvre nécessitent une attention particulière :

• Le Pack réécrit un seul champ de chaîne de texte de niveau supérieur, _raw par défaut. Les champs extraits plus tôt dans le Pipeline conservent leurs valeurs originales, donc le Pack doit être exécuté avant l’analyse, ou les champs doivent être ré-extraits à partir de _raw nettoyé.
• Tous les Workers qui doivent produire des jetons correspondants doivent utiliser la même clé, version du Pack et configuration des règles. La rotation de la clé change chaque jeton, donc la rotation doit être programmée en tenant compte des périodes de rétention des ensembles de données.
• Detect est disponible uniquement sur Cribl.Cloud. Exécuter le Pack sur un groupe Worker géré par le client (hybride) pseudonymise les données avant qu’elles ne quittent le réseau client. Historiquement, Cribl.Cloud a limité les fonctions et scripts personnalisés aux Workers hybrides (Blog Cribl), il faut donc confirmer le support avant de s’appuyer sur des Workers gérés par Cribl.

Dans cette configuration, les valeurs non modifiées n’existent qu’à l’intérieur du réseau client. Les détections et enrichissements nécessitant les valeurs originales sont exécutés avant le Pack, et tout ce qui est écrit à la destination contient des jetons.

Caractéristiques distinctives

La principale différence technique par rapport aux options natives de Cribl est la pseudonymisation indexée. Les valeurs originales sont supprimées, mais les références à la même entité restent liées à travers les événements.

Les jetons indexés ne sont pas vulnérables aux attaques par dictionnaire qui fonctionnent contre les hachages simples. Un SHA-256 non indexé d’une adresse IPv4 ou d’un nom d’utilisateur peut être inversé en énumérant le petit espace d’entrée. Un jeton HMAC ne peut pas être calculé sans la clé secrète. Le label de type dans chaque jeton (<HOST:…>, <USER:…>) informe toujours les analystes et les outils de hiérarchisation basés sur LLM du type d’entité auquel un événement se réfère, donc les chronologies restent lisibles.

Onze familles de détecteurs fonctionnent sans configuration supplémentaire. La validation des sommes de contrôle réduit les faux positifs, tels que les chaînes de chiffres aléatoires étant identifiées comme des numéros de carte.

La ré-identification ne nécessite pas de droits de déchiffrement en masse. Toute personne détenant la clé peut calculer le jeton pour un indicateur connu, comme un nom de compte suspect, et le rechercher.

Comme le moteur est la bibliothèque LogTotal de SOC Prime, elle est également disponible sous forme d’application web LogTotal, d’une interface en ligne de commande et d’un package Node.js, y compris pour les environnements isolés. Avec la même clé et configuration des règles, un extrait de journal préparé pour un ticket fournisseur ou un contrat de réponse aux incidents peut être traité de manière cohérente avec les données du SIEM. Le code est open-source, il n’y a pas de frais par Go, et le Pack regroupe ses dépendances.

Limitations et considérations opérationnelles

L’impact opérationnel le plus important est sur le contenu de détection qui dépend des valeurs originales.

• Les adresses IP, domaines et noms d’utilisateur tokenisés ne correspondent pas aux flux IOC, aux bases de données GeoIP, aux règles basées sur les CIDR ou aux recherches d’actifs. Atténuations : Exécuter les détections et enrichissements en temps réel avant le Pack, désactiver les règles ips et hosts sur la Route affectée, ou envoyer une copie à pleine fidélité à un magasin restreint.
• La bibliothèque sous-jacente supporte une liste blanche ne jamais rédiger, mais les paramètres documentés du Pack ne l’exposent pas.
• Chaque événement est évalué par rapport à un grand ensemble d’expressions régulières. Le mode agressif augmente à la fois le coût CPU et les faux positifs, et le dimensionnement des Workers doit en tenir compte.
• Les jetons ne peuvent pas être décryptés. La ré-identification est uniquement possible en recalculant le jeton pour une valeur connue.

Conclusion

Pour les déploiements qui envoient des données de sécurité à Cribl Detect, le LogTotal Sanitizer Pack fournit une pseudonymisation en pipeline à moindre coût. Les valeurs sensibles sont supprimées avant qu’elles n’atteignent les analystes, les agents IA et le stockage à long terme, tandis que les relations d’entités utilisées par les règles de corrélation sont préservées. Un déploiement pratique commence avec une seule source à haut risque. Valider la sortie avec l’échantillon d’aperçu, confirmer que les détections pertinentes se déclenchent toujours, puis étendre le Pack à d’autres Routes.