La logique sous-jacente de la recherche de sécurité : comment les bonnes pratiques de Google SecOps transforment les opérations de sécurité

Quand les opérations de sécurité rencontrent le déluge de données

Les centres d'opérations de sécurité (SOC) modernes sont confrontés à une pression de données sans précédent. Les journaux provenant des endpoints, des réseaux, du cloud et des systèmes d'identité croissent de manière exponentielle, tandis que les tâches des analystes de sécurité deviennent de plus en plus complexes : ils doivent rapidement identifier les véritables menaces parmi des masses de données. C'est dans ce contexte que Google Security Operations (SecOps) a publié un document « bonnes pratiques de recherche » d'apparence simple. Mais la valeur de ce document dépasse de loin un guide opérationnel : il révèle la logique fondamentale de la mise en place de recherches de sécurité efficaces sur des plateformes de données à grande échelle, ainsi que la transformation profonde que traverse ce secteur.

Performances de recherche : le champ de bataille invisible des opérations de sécurité

Le document commence par souligner : « Si les requêtes sont mal construites, la recherche peut nécessiter d'importantes ressources de calcul. » Cette phrase est légère en apparence, mais elle frappe juste. Dans les opérations de sécurité, la vitesse est primordiale. Lorsqu'un attaquant se déplace latéralement, une requête lente peut signifier avoir manqué la meilleure fenêtre de réponse. Les performances de recherche ne sont donc pas un simple bonus, mais le fondement de l'efficacité de la sécurité.

La solution de Google consiste à orienter les utilisateurs vers des champs UDM spécifiques. L'UDM (modèle de données unifié) est l'abstraction centrale de Google SecOps : il mappe les journaux hétérogènes provenant de différentes sources de données en champs structurés. Le document recommande d'utiliser des champs haute performance tels que principal.ip, target.file.sha256 pour le filtrage, car ces champs bénéficient d'une optimisation de pré-indexation permettant une récupération rapide. Derrière cela se cache une réflexion approfondie sur la modélisation des données : la normalisation n'est pas une contrainte, mais la clé pour libérer les performances.

Champs UDM : pourquoi « moins, c'est plus »

De nombreux analystes de sécurité ont l'habitude d'utiliser la recherche en texte intégral ou la correspondance floue, mais avec des volumes de données importants, cette approche est coûteuse. Les bonnes pratiques de Google SecOps énumèrent clairement une série de champs principaux (Principal), de champs source (Source), de champs cible (Target), etc., qui couvrent les entités les plus courantes dans la détection des menaces : utilisateurs, actifs, fichiers, processus. En utilisant ces champs, le moteur de requête peut contourner de grandes quantités de données non structurées et atteindre directement les index.

Cette façon de penser est comparable à l'ingénierie des caractéristiques dans le domaine de l'intelligence artificielle. Lors de la construction d'un modèle d'apprentissage automatique, choisir les bonnes caractéristiques est souvent plus important que l'algorithme lui-même. De même, dans la recherche en sécurité, choisir les bons champs détermine l'efficacité et la précision des requêtes. Cela explique aussi pourquoi les plateformes de sécurité modernes mettent de plus en plus l'accent sur la conception conjointe du modèle de données et des règles de détection — les deux devraient être une seule et même chose.

La sagesse de l'ingénierie dans la syntaxe des requêtesLe document consacre une grande partie à expliquer les techniques d'optimisation des requêtes, notamment la réduction de la plage temporelle, l'utilisation du modificateur nocase, l'évitement des expressions régulières dans les champs d'énumération, la compréhension de la sémantique de l'opérateur any, etc. Ces détails peuvent sembler anodins, mais ils reflètent la compréhension approfondie qu'ont les ingénieurs de plateformes de sécurité de l'environnement de production.

Par exemple, le document met en garde spécifiquement : lors de l'utilisation de l'opérateur != dans un champ répété (comme principal.ip), la sémantique par défaut étant any, des résultats inattendus peuvent survenir. Cela signifie que lorsqu'un événement contient plusieurs IP, principal.ip != "1.2.3.4" correspondra aux événements contenant 5.6.7.8, même s'ils contiennent également 1.2.3.4. Ce n'est pas seulement un détail technique, c'est aussi un piège cognitif : dans les structures de données multi-valuées complexes, le jugement intuitif humain peut facilement se tromper. Les analystes de sécurité doivent comprendre la différence entre « n'importe quelle valeur » et « toutes les valeurs » dans le modèle de données afin d'éviter les faux positifs ou les faux négatifs en environnement de production.

De la recherche d'événements à la recherche de graphes d'entités

Un signal encore plus intéressant est que le document précise clairement que pour les données d'entités et de contexte (comme AZURE_AD_CONTEXT, WORKSPACE_USERS), les recherches UDM traditionnelles ne renvoient aucun résultat ; il faut utiliser la syntaxe graph. Cela marque le passage des opérations de sécurité du paradigme de « liste d'événements » à celui de « relations entre entités ».

Les SIEM traditionnels (Security Information and Event Management) sont centrés sur les événements de journalisation ; les analystes identifient les activités suspectes grâce à des critères de filtrage. Mais les attaques modernes impliquent souvent plusieurs entités — utilisateurs, appareils, fichiers, connexions réseau — et chaque événement pris isolément n'est pas assez suspect. La recherche de graphes d'entités permet aux analystes d'explorer les chaînes de relations, par exemple en remontant d'un e-mail de phishing à l'utilisateur affecté, puis à tous les hôtes qu'il a visités. Cette capacité est en phase avec des technologies d'intelligence artificielle telles que les graphes de connaissances et les réseaux de neurones graphiques, annonçant l'avènement d'une ère d'analyse de sécurité plus intelligente.

Le paradoxe des horodatages et des données historiques

Dans les recherches, la plage temporelle est le critère de filtrage le plus courant. Mais Google SecOps a une conception subtile : la plage temporelle repose sur l'horodatage de l'analyse de l'événement, et non sur l'heure d'ingestion du journal brut. Par conséquent, lorsque vous recherchez des événements de la « dernière heure », les données historiques qui viennent d'être ingérées mais dont l'horodatage est plus ancien ne sont pas incluses par défaut. Pour résoudre ce problème, vous devez utiliser l'option « All time » et interroger explicitement metadata.ingested_timestamp.Derrière cette conception se trouve un arbitrage : une négociation entre performance et exhaustivité. Si chaque recherche devait analyser tout l'historique, le système ne pourrait pas supporter l'analyse interactive. Mais cela nous rappelle également que la sémantique temporelle dans les pipelines de données affecte directement la visibilité en matière de sécurité. Comprendre et maîtriser ces règles est un prérequis pour utiliser efficacement la plateforme.

Opérations de sécurité à l'ère de l'IA

Ce document de bonnes pratiques de Google SecOps, bien qu'il s'apparente à un guide opérationnel, est en réalité une interprétation de la philosophie d'ingénierie des plateformes de sécurité. Il nous enseigne qu'à une époque marquée par l'explosion des données et la pénétration de l'IA, la compétitivité des opérations de sécurité ne dépend plus uniquement de l'expérience des analystes, mais aussi et surtout de la conception du modèle de données sous-jacent, de l'optimisation du moteur de requêtes et de l'interface de collaboration homme-machine.

On peut s'attendre à ce que les opérations de sécurité recourent de plus en plus à l'IA générative pour l'analyse assistée. Mais quelle que soit la puissance de l'IA, elle a besoin d'une base de données normalisée et clairement indexée. En proposant l'UDM et les bonnes pratiques de recherche, Google prépare en réalité le terrain pour les assistants de sécurité intelligents de l'ère de l'IA. Ce n'est que lorsque les analystes peuvent obtenir les données les plus pertinentes à un coût minimal que l'apprentissage automatique et les modèles profonds peuvent réellement démontrer toute leur puissance.

Pour les équipes de sécurité des entreprises, ce document est un miroir. Il nous rappelle que l'efficacité des outils techniques dépend souvent de notre capacité à comprendre et à suivre leur logique interne. Tout en recherchant les technologies de pointe, n'oublions pas ces « bonnes pratiques » apparemment élémentaires : ce sont elles qui constituent les pierres angulaires déterminant la hauteur de l'échelle des opérations de sécurité.