La guerre de la couche sémantique des données de sécurité : l’économie de la puissance de calcul derrière les spécifications de recherche de Google SecOps

Un document qui vous apprend à économiser de l’argent révèle un changement structurel dans tout le secteur

Google Security Operations (anciennement Chronicle) a publié un document sur les bonnes pratiques de recherche UDM. Il se lit comme un document technique classique d’un éditeur : on y parle de champs, d’opérateurs, d’optimisation des performances, de dépannage.

Mais replacé dans son contexte, ce document dit en réalité quelque chose de plus grand : sur les plateformes modernes de sécurité opérationnelle, la recherche n’est plus une action gratuite.

Le document avertit dès son introduction : si une requête est mal construite, la recherche consomme d’importantes ressources de calcul, et les performances varient aussi selon le volume et la complexité des données de l’instance. Puis, presque sur le ton d’un consultant en coûts, il énumère point par point les « champs à hautes performances », les « champs exclus » et « comment réduire la plage temporelle ».

Ce n’est pas un cours de syntaxe. C’est de l’économie de la puissance de calcul. Quand la documentation officielle d’un produit de sécurité consacre de longues pages à expliquer aux utilisateurs comment dépenser moins, calculer moins et scanner moins de données, cela signifie que la tension centrale des opérations de sécurité est passée de « peut-on voir une attaque ? » à « peut-on se permettre de la voir ? ».

Liste blanche des champs : le schéma, c’est le pouvoir de l’infrastructure

La partie la plus informative du document est la liste explicite des « champs UDM à hautes performances » qu’il donne pour chaque type de scénario de requête. Métadonnées, entité principale (principal), source, cible, réseau, résultats de sécurité — six grandes catégories de champs sont énumérées une à une, avec la mention explicite qu’elles sont « optimisées pour une recherche rapide ».

Cela reflète un fait établi mais souvent négligé : un modèle de données unifié n’est pas seulement une spécification de données ; il définit les frontières de la capacité d’interrogation.

Dans le monde des journaux bruts, tout champ est en théorie interrogeable, au prix d’un balayage complet de la table. Dans le monde UDM, une partie des champs est intégrée à l’index et au chemin de recherche, tandis que l’autre vit dans le texte original et n’est analysée qu’en cas de besoin. Cette stratification n’est pas un détail technique, mais un pari des concepteurs du produit sur la manière dont se mèneront les enquêtes de sécurité à l’avenir : ils estiment que ce que les enquêteurs utilisent réellement et fréquemment, ce sont les noms d’hôtes, les adresses IP, les hachages de fichiers, les identifiants de processus, les identifiants utilisateur, les adresses e-mail, les méthodes HTTP et les noms de règles de sécurité.

Cette liste constitue en elle-même un portrait de « comportement d’enquête de sécurité » : l’unité atomique de la chasse moderne aux menaces est l’identifiant d’entité corrélable, et non le texte libre.

Pour les concurrents, cette liste est un mur. Celui qui définit les champs définit la manière d’écrire les règles de détection, le modèle mental des analystes et le coût d’une migration hors de cette plateforme. Le schéma (schema) n’est jamais neutre : il est la forme concrète du pouvoir de l’infrastructure.

Les champs délibérément exclus : l’angle révélé par l’économie de la puissance de calculIl y a dans la documentation un passage d’une rare franchise : certains champs sont délibérément exclus des filtres de recherche, notamment metadata.id, metadata.product_log_id et tous les champs *.timestamp. La raison est donnée sans détour : les valeurs uniques de ces champs entraînent une cardinalité élevée (high cardinality), introduisent une variance statistique et nuisent aux performances de recherche.

Cette phrase mérite d’être relue plusieurs fois.

Dans le domaine de l’observabilité et des données de sécurité, la cardinalité élevée a toujours été l’adversaire le plus coriace de la structure de coûts. Un champ contenant des millions, voire des milliards, de valeurs uniques est presque impossible à indexer efficacement. Face à cela, les fournisseurs n’ont que deux choix : soit l’assumer de front et répercuter le coût sur les utilisateurs ; soit le tenir à l’écart de la couche de recherche rapide, en faisant payer aux utilisateurs un coût plus élevé lorsqu’ils en ont besoin.

Google a choisi la seconde option, et l’a inscrite dans sa documentation publique. Cela signifie qu’il admet une chose : dans une plateforme de données de sécurité, toutes les données ne naissent pas égales.

Plus subtil encore, les horodatages sont rangés dans cette catégorie. Le temps devrait être la première dimension d’une enquête de sécurité, mais précisément parce que ses valeurs sont quasi infinies, il ne peut pas servir de condition de correspondance exacte à bon rapport coût-efficacité. La solution de remplacement proposée par la documentation consiste à comparer des secondes Unix epoch, ou à appeler les fonctions temporelles de YARA-L pour effectuer des conversions de dates — autrement dit, traduire le « temps lisible par l’humain » en « entiers indexables par la machine », l’utilisateur assumant ce coût de traduction.

C’est un compromis d’ingénierie typique, et aussi un choix de modèle économique typique.

Deux horloges : la scission entre temps d’événement et temps d’ingestion

Un autre détail de la documentation, facile à négliger mais lourd de sens, concerne les « données nouvellement ingérées mais à l’horodatage plus ancien » : la plage temporelle de recherche est basée sur l’horodatage de l’événement après analyse, et non sur l’horodatage d’ingestion des journaux bruts.

Il donne même la contre-mesure : pour rechercher des journaux nouvellement ingérés avec d’anciens horodatages d’événements, il faut utiliser l’option All time et interroger plutôt metadata.ingested_timestamp.

Derrière cela se rejoue, dans le contexte de la sécurité, un vieux problème du domaine du traitement de flux : la séparation entre le temps d’événement (event time) et le temps de traitement (processing time). Dans les systèmes distribués, les journaux en retard, la dérive d’horloge, la mise en cache par des proxys, la retransmission différée par des appareils hors ligne, tout cela dissocie le moment d’arrivée des données du moment où l’événement s’est produit.

Et dans une enquête de sécurité, ce détail technique détermine directement si la conclusion est juste ou fausse. Lors de la reconstruction de la chronologie d’une intrusion, si l’analyste part du principe que la fenêtre de recherche est divisée selon le temps d’ingestion, il peut manquer complètement les journaux qu’un attaquant a laissés des semaines auparavant et qui n’ont été téléversés qu’aujourd’hui.Le problème plus profond est le suivant : le fait que les plateformes de sécurité décomposent le concept de « temps » en deux champs revient en réalité à restituer partiellement à l’utilisateur le pouvoir d’interpréter la sémantique temporelle. C’est à la fois une flexibilité et un transfert de responsabilité. Lorsque la plateforme ne décide plus à votre place « quel temps compte vraiment », l’analyste doit répondre lui-même à une question qui devrait relever de l’ingénierie des données.

La séparation entre entités et événements : les données contextuelles traitées séparément

La documentation indique explicitement : si l’on utilise metadata.log_type = "..." pour rechercher des types de journaux d’entités ou de contexte tels que AZURE_AD_CONTEXT, WORKSPACE_USERS, un résultat vide sera renvoyé — car la recherche UDM n’interroge que les enregistrements d’événements UDM. Pour accéder à ces données, il faut utiliser la syntaxe graph, via des chemins tels que graph.metadata.event_metadata.log_type ou graph.entity.user.email_addresses.

Ce détail révèle une bifurcation de l’architecture des données de sécurité : les événements (events) et les entités (entities) sont désormais stockés et interrogés séparément.

Les événements représentent « ce qui s’est passé », les entités « qui est qui ». Au cours des dix dernières années, les SIEM se sont principalement occupés des premiers. Mais les opérations de sécurité modernes dépendent de plus en plus de ces derniers — graphes d’identités, contexte des actifs, profils utilisateurs. Les attaquants se dévoilent rarement au moyen d’un seul événement ; leurs traces sont dispersées dans un grand nombre d’événements, et ce n’est qu’en reliant les événements entre eux par les entités que les anomalies émergent.

Interroger les données d’entités avec une syntaxe entièrement différente est un signal au niveau architectural : les données d’entités ne sont pas un accessoire des événements, mais une autre structure de données nécessitant une modélisation et une optimisation indépendantes. Cela explique aussi pourquoi les requêtes de graphe (graph) sont en train de devenir une capacité standard des plateformes de sécurité, et non plus seulement un outil réservé au renseignement sur les menaces.

Pour l’écosystème des startups, il existe ici une fenêtre d’opportunité claire : la résolution d’entités, la normalisation des identités et l’alignement d’entités entre sources sont en train de devenir une couche d’infrastructure indépendante du SIEM.

Les champs répétés et le piège silencieux de any

La documentation contient un passage sur les « champs répétés », d’un ton neutre, mais aux conséquences non négligeables. Des champs tels que principal.ip et target.file.md5 peuvent contenir plusieurs valeurs dans un même événement. Par défaut, ils sont évalués avec l’opérateur any : dès que n’importe quelle valeur du champ satisfait la condition, le prédicat entier devient vrai.L’exemple donné dans la documentation est très représentatif : recherchez principal.ip != "1.2.3.4" ; si un événement contient à la fois 1.2.3.4 et 5.6.7.8, cet événement sera tout de même mis en correspondance. Parce que 5.6.7.8 remplit la condition « différent de ».

Pour un analyste humain, c’est presque contre-intuitif. Pour un ingénieur qui construit des règles de détection automatiques, c’est un piège pouvant directement entraîner des faux positifs et des faux négatifs.

Cela révèle un problème plus général : la sémantique des langages de requête de sécurité est en train de devenir une discipline nécessitant un apprentissage spécialisé. Lorsque le comportement des opérateurs logiques dépend de la structure de stockage interne du modèle de données, l’ingénierie de détection ne consiste plus seulement à « écrire une logique correcte », mais à « comprendre comment les structures de données sous-jacentes sont évaluées ».

Cela explique aussi pourquoi la documentation mentionne spécifiquement qu’il existe une limite au nombre d’opérateurs logiques entre parenthèses (169), pourquoi les champs énumérés ne peuvent pas utiliser d’expressions régulières, pourquoi le comportement du moteur RE2 doit être expliqué séparément. La complexité des langages de requête de sécurité approche celle d’un petit langage de programmation — et chaque nouveau langage engendre une nouvelle spécialisation professionnelle.

Les prérequis d’un agent d’investigation IA sont écrits dans cette documentation

Si l’on lit cette documentation comme une préparation à l’avenir, son aspect le plus intéressant est qu’elle définit involontairement les conditions qu’un agent de sécurité IA doit d’abord remplir pour pouvoir fonctionner.

Première condition : le coût des requêtes doit être prévisible. Un agent d’investigation autonome, si chaque requête exploratoire peut déclencher une consommation de calcul incontrôlable, personne n’oserait le laisser agir librement. Les listes blanches de champs, les contraintes de fenêtre temporelle, les champs à forte cardinalité exclus, sont essentiellement des moyens de rendre le modèle de coût budgétisable.

Deuxième condition : la sémantique doit être déterministe. Le comportement par défaut de l’opérateur any, l’évaluation élément par élément des champs répétés, la distinction entre temps d’événement et temps d’ingestion : ce sont des règles que l’agent doit maîtriser précisément, sans ambiguïté. Une machine ne peut pas contourner les pièges sémantiques par intuition.

Troisième condition : l’interface doit être structurée. La documentation recommande d’utiliser des listes de référence (reference lists) au lieu de la correspondance sur de grandes quantités de valeurs, d’utiliser des Unix epoch au lieu de chaînes temporelles humaines, d’utiliser des chemins de champs explicites au lieu de la recherche en texte libre — tout cela transforme « l’investigation » d’une activité humaine floue en un ensemble d’étapes déterministes pouvant être appelées par un programme.

Autrement dit, un concept comme agentic SOC ne consiste pas d’abord à avoir un agent, puis à l’adapter à une plateforme. L’ordre réel est exactement l’inverse : la plateforme commence par organiser le modèle de données, la sémantique des requêtes et les limites de coût sous une forme exploitable par une machine, et c’est alors que l’agent peut trouver sa place. Cette documentation fait partie de ce travail préparatoire, même si elle ne le dit pas elle-même.

Standardisation des schémas : une concurrence silencieuse mais crucialeEn prenant du recul, le champ de bataille dans lequel s’inscrit ce document est la concurrence autour de la standardisation des schémas de données de sécurité (schema).

D’un côté, il y a les schémas propriétaires des fournisseurs, comme l’UDM de Google. Leur avantage est une optimisation poussée et une intégration étroite avec leurs propres moteurs de recherche et de détection ; le prix à payer : les coûts de migration et l’enfermement de l’écosystème. De l’autre, une direction de schémas ouverts portée conjointement par le secteur, avec pour objectif de donner aux journaux de différentes sources une sémantique de champs cohérente et d’abaisser les barrières à la collaboration entre plateformes.

Cette concurrence ne se montrera pas au public sous la forme de conférences de lancement ou de guerres marketing. Elle se joue dans des endroits plus arides : la dénomination des champs, la liste des champs interrogeables, la manière de représenter les horodatages, la séparation ou non des entités et des événements, le choix du moteur d’expressions régulières.

Mais ces détails déterminent la réalité de la prochaine génération : les règles de détection pourront-elles être réutilisées d’une plateforme à l’autre, les renseignements sur les menaces pourront-ils être échangés entre organisations, les agents d’IA pourront-ils comprendre des données issues de différents fournisseurs, et combien de marge de négociation restera-t-il à une équipe de sécurité avant qu’elle ne soit verrouillée.

Conclusion : les opérations de sécurité passent d’une activité de stockage à une activité de couche sémantique

Au cours des vingt dernières années, le récit central du SIEM était « centraliser les journaux ». Le stockage était un coût, la recherche une fonctionnalité.

Aujourd’hui, cette relation s’est inversée. Le stockage est relativement bon marché, et rendre les données interrogeables, corrélables et compréhensibles par les machines est la partie réellement coûteuse et réellement précieuse.

La valeur de ce document Google SecOps ne tient pas à la syntaxe qu’il enseigne, mais au fait qu’il expose honnêtement les nouvelles règles du jeu : les champs sont hiérarchisés, le temps est ambigu, les requêtes ont un prix, la sémantique a des limites.

Celui qui peut définir ces limites ne se contente pas de vendre une plateforme de sécurité : il définit la grammaire de l’investigation de sécurité elle-même. Cela mérite plus d’attention que n’importe quel lancement de produit.

---

Source : Search best practices | Google Security Operations