Comprendre la disponibilité des données pour la recherche

Compatible avec :

SecOps Google

Ce document décrit en détail le cycle de vie de l'ingestion de données, y compris le flux de données et la latence de bout en bout, et explique comment ces facteurs ont un impact sur la disponibilité des données récemment ingérées pour les requêtes et l'analyse.

Ingérer et traiter des données dans Google SecOps

Cette section décrit comment Google SecOps ingère, traite et analyse les données de sécurité.

Ingestion de données

Le pipeline d'ingestion de données commence par collecter vos données de sécurité brutes à partir de sources telles que :

• Journaux de sécurité de vos systèmes internes
• Données stockées dans Cloud Storage
• Votre centre des opérations de sécurité (SOC) et d'autres systèmes internes

Google SecOps importe ces données sur la plate-forme à l'aide de l'une de ses méthodes d'ingestion sécurisées.

Voici les principales méthodes d'ingestion :

• Ingestion Google Cloud directe

  Google SecOps utilise l'ingestion directe Google Cloud pour extraire automatiquement les journaux et les données de télémétrie des Google Cloudde votre organisation, y compris Cloud Logging, les métadonnées inventaire des éléments cloud et les résultats Security Command Center Premium.

• API d'ingestion

  Envoyez les données directement à Google SecOps à l'aide de ses API d'ingestion REST publiques. Vous utilisez cette méthode pour les intégrations personnalisées ou pour envoyer des données sous forme de journaux non structurés ou d'événements UDM (Unified Data Model) préformatés.

• Agent Bindplane

  Vous pouvez déployer l'agent Bindplane polyvalent dans votre environnement (sur site ou dans d'autres clouds) pour collecter les journaux provenant de diverses sources et les transférer vers Google SecOps.

• Flux de données

  Dans Google SecOps, vous configurez des flux de données pour extraire les journaux de sources tierces, telles que des buckets de stockage cloud tiers spécifiques (comme Amazon S3) ou des API tierces (comme Okta ou Microsoft 365).

Normalisation et enrichissement des données

Une fois les données reçues dans Google SecOps, la plate-forme les traite en plusieurs étapes :

1. Analyse et normalisation

   Un analyseur traite d'abord les données de journaux brutes pour les valider, les extraire et les transformer de leur format d'origine au format UDM standardisé. Le parsing et la normalisation vous permettent d'analyser des sources de données disparates (par exemple, les journaux de pare-feu, les données de points de terminaison, les journaux cloud) à l'aide d'un schéma unique et cohérent. Le journal brut d'origine reste stocké à côté de l'événement UDM.

2. Indexation

   Après la normalisation, Google SecOps indexe les données UDM pour fournir des requêtes rapides sur des ensembles de données volumineux, ce qui permet de rechercher les événements UDM.

3. Alias et enrichissement UDM

   • Google SecOps effectue l'alias et l'enrichissement UDM pour enrichir les événements UDM avec un contexte précieux, en identifiant et en ajoutant des données et des indicateurs contextuels pour les entités de journaux. Par exemple, il associe le login name d'un utilisateur à ses différents IP addresses, hostnames et MAC addresses.
   • Géolocalisation : Google SecOps enrichit les adresses IP avec des données de géolocalisation.

4. Enrichissement des données ECG

   • Google SecOps effectue un alias ECG qui fusionne le contexte de plusieurs sources (telles que les IdP, les CMDB et les renseignements sur les menaces) pour créer un profil d'entité consolidé dans le graphique de contexte d'entité.

   • Informations sur les menaces : Google SecOps compare automatiquement les données d'événements aux vastes informations de Google sur les menaces, y compris des sources telles que Google Threat Intelligence et Navigation sécurisée, pour identifier les menaces malveillantes connues, comme domains, IP addresses et file hashes.

   • WHOIS : Google SecOps enrichit les noms de domaine avec leurs informations d'enregistrement public WHOIS.

Disponibilité des données pour l'analyse

Une fois traitées et enrichies, les données UDM sont immédiatement disponibles pour l'analyse :

• Détection en temps réel

  Le moteur de détection exécute automatiquement des règles personnalisées et intégrées à Google avec l'option "Règle en direct" sur les données entrantes en direct pour identifier les menaces et générer des alertes.

• Recherche et investigation

  Un analyste peut utiliser les méthodes de recherche pour effectuer des recherches dans toutes ces données normalisées et enrichies. Par exemple, utilisez la recherche UDM pour passer d'une entité associée à une autre (par exemple, d'un user à son asset, puis à un domain malveillant) et examiner les alertes.

Méthodes de recherche

Google SecOps propose plusieurs méthodes distinctes pour rechercher vos données, chacune ayant un objectif différent.

Recherche UDM

La recherche UDM est la méthode de recherche principale et la plus rapide, utilisée pour la plupart des investigations.

• Éléments recherchés : la requête interroge les événements UDM normalisés et indexés. Comme toutes les données sont analysées dans ce format standard, vous pouvez écrire une requête pour trouver la même activité (comme une connexion) dans tous vos produits (par exemple, Windows, Okta, Linux).
• Fonctionnement : vous utilisez une syntaxe spécifique pour interroger des champs, des opérateurs et des valeurs.

• Exemple : principal.hostname = "win-server" AND target.ip = "10.1.2.3"

  Les résultats sont généralement disponibles entre 2 et 15 minutes après l'ingestion.

Recherche dans les journaux bruts

Utilisez la recherche dans le journal brut pour trouver un élément dans le message de journal d'origine non analysé qui n'a peut-être pas été mappé à un champ UDM. Cette méthode de recherche est optimisée pour les recherches à grande vitesse. Elle renvoie généralement des résultats en moins de deux secondes pour des indicateurs spécifiques tels que les hachages de fichiers ou les adresses IP.

• Ce que la recherche analyse : elle analyse le texte brut d'origine des journaux avant qu'ils ne soient analysés et normalisés. Cela permet de trouver des chaînes spécifiques, des arguments de ligne de commande ou d'autres artefacts qui ne sont pas des champs UDM indexés.
• Fonctionnement : vous utilisez le préfixe raw =. Elle peut être plus lente que la recherche UDM, car elle ne recherche pas les champs indexés.
• Exemple (chaîne) : raw = "PsExec.exe"
• Exemple (expression régulière) : raw = /admin\$/

Recherche de statistiques

Utilisez la recherche statistique pour identifier les tendances à long terme qui agrègent des millions de lignes de données. Étant donné que la plate-forme doit effectuer des analyses statistiques et des regroupements, les temps de chargement de ces requêtes seront plus longs.

Recherche en langage naturel (Gemini)

La recherche en langage naturel (Gemini) vous permet de poser des questions en langage courant, que Gemini traduit ensuite en requête UDM formelle.

• Ce qu'il recherche : il fournit une interface conversationnelle pour interroger les données UDM.
• Comment ça marche : vous saisissez une question, et Gemini génère la requête de recherche UDM sous-jacente pour vous. Vous pouvez ensuite l'exécuter ou l'affiner.
• Exemple : "Montre-moi toutes les tentatives de connexion ayant échoué pour l'utilisateur 'bob' au cours des dernières 24 heures"

Recherche SOAR

La recherche SOAR est spécifique aux composants SOAR. Vous l'utilisez pour gérer les incidents de sécurité, et non pour rechercher des informations dans les journaux.

• Éléments recherchés : la recherche porte sur les demandes et les entités (comme les utilisateurs, les composants et les adresses IP) dans la plate-forme SOAR.
• Fonctionnement : vous pouvez utiliser des filtres en texte libre ou basés sur des champs pour trouver des cas par ID, nom d'alerte, état, utilisateur attribué, etc.
• Exemple : Recherchez CaseIds:180 ou AlertName:Brute Force

Pipeline d'ingestion de données pour la recherche de disponibilité

La disponibilité des données de bout en bout correspond au temps total entre le moment où un événement se produit et le moment où il est disponible pour la recherche ou l'exécution de règles dans Google SecOps. Cette latence correspond à la somme des deux composants suivants :

1. Délai de disponibilité côté source : délai entre le moment où un événement se produit et celui où le système source met les données de journaux à disposition pour l'ingestion. Ce délai dépend de l'architecture, du traitement, du regroupement et des plannings de publication des API du système source. Google SecOps ne peut pas influencer ce délai. Par exemple, des retards peuvent se produire lorsqu'un système écrit des journaux dans un bucket de stockage ou les publie sur un point de terminaison d'API.

2. Délai de traitement Google SecOps : temps nécessaire à Google SecOps pour traiter les données après les avoir reçues. Cette durée inclut les étapes du pipeline interne telles que l'ingestion, l'analyse, la normalisation, l'indexation et l'enrichissement.

Vous devez tenir compte des deux composants lorsque vous résolvez les problèmes liés aux délais de visibilité des données.

Retards provenant de la source de données

Les facteurs suivants peuvent avoir une incidence sur le délai de disponibilité côté source :

• Traitement par lot : certains systèmes génèrent des journaux par lots à des intervalles définis (par exemple, toutes les heures).
• Latence de l'API : l'API source peut présenter des délais inhérents pour rendre les nouveaux événements interrogeables.
• Heure de création et de publication d'un événement : l'horodatage d'un événement dans un journal peut être beaucoup plus ancien que celui auquel le journal est finalisé et devient disponible pour la collecte.
• Limitation du débit : les limites de débit des API côté source peuvent ralentir la récupération des données.
• Remplissage initial : le traitement et l'ingestion de grands volumes de données historiques prennent du temps.

Ces délais varient en fonction de la source de données et du type de journaux. Pour en savoir plus sur les méthodes d'ingestion, consultez Présentation de l'ingestion de données. La documentation de référence sur l'API Feed Management décrit des considérations spécifiques pour les types de journaux tels que Microsoft Graph, SentinelOne, Okta et CrowdStrike.

Temps de traitement de Google SecOps

Le système traite les données nouvellement ingérées en plusieurs étapes. La durée de ces étapes détermine le moment où les données nouvellement ingérées deviennent disponibles pour les requêtes et l'analyse.

Le tableau suivant détaille les étapes de traitement des données nouvellement ingérées par méthode de recherche. Une fois ces étapes terminées, les nouvelles données ingérées deviennent consultables.

Méthode de recherche	Données recherchées	Étapes de traitement contribuant au délai de disponibilité
Recherche UDM Recherche en langage naturel (Gemini)	Événements UDM normalisés et enrichis	Ingestion : le journal arrive au point d'ingestion Google SecOps. Analyse : le journal brut est identifié et traité par son analyseur spécifique. Normalisation : les données sont extraites et mappées au schéma UDM. Indexation (UDM) : l'enregistrement UDM normalisé est indexé pour une recherche structurée et rapide. Enrichissement : le contexte (renseignements sur les menaces, géolocalisation, données utilisateur ou sur les ressources) est ajouté.
Recherche dans les journaux bruts	Texte du journal d'origine non analysé	Ingestion : le journal arrive au point d'ingestion Google SecOps.
Moteur de détection (règles)	Événements normalisés	Disponibilité des événements UDM : suivez les mêmes étapes que pour la recherche UDM. Évaluation de la détection : le moteur de règles évalue les journaux par "micro-lots". Les détections sont généralement déclenchées dans les 5 à 10 minutes suivant l'arrivée de l'événement.
Recherche SOAR	Cas et entités	Il s'agit d'un cycle de vie différent, car il recherche des alertes et des requêtes, et non des journaux. L'heure est basée sur : Disponibilité des événements UDM : utilise les mêmes étapes de traitement que celles listées pour la "recherche UDM". Détection : une règle du moteur de détection doit correspondre aux événements UDM. Génération d'alertes : le système crée une alerte formelle à partir de la détection. Création de la demande : la plate-forme SOAR ingère l'alerte et crée une demande.

Exemple de flux de données

L'exemple suivant montre comment Google SecOps ingère, traite, améliore et analyse vos données de sécurité, en les rendant disponibles pour les recherches et les analyses plus approfondies.

Exemple d'étapes de traitement des données

1. Récupère les données de sécurité des services cloud tels qu'Amazon S3 ou à partir deGoogle Cloud. Google SecOps chiffre ces données en transit.
2. Sépare et stocke vos données de sécurité chiffrées dans votre compte. L'accès est limité à vous et à un petit nombre d'employés Google pour l'assistance, le développement et la maintenance des produits.
3. Analyse et valide les données de sécurité brutes, ce qui facilite leur traitement et leur affichage.
4. Normalise et indexe les données pour des recherches rapides.
5. Stocke les données analysées et indexées dans votre compte.
6. Enrichit les données avec des données contextuelles.
7. Offre aux utilisateurs un accès sécurisé pour rechercher et examiner leurs données de sécurité.
8. Compare vos données de sécurité à la base de données de logiciels malveillants Google Threat Intelligence pour identifier les correspondances. Dans une vue d'événement Google SecOps, telle que la vue "Actif", cliquez sur Contexte VT pour afficher les informations Google Threat Intelligence. Google SecOps ne partage pas vos données de sécurité avec Google Threat Intelligence.

Exemples de délai avant la disponibilité de la recherche

Le temps prévu avant que les données nouvellement ingérées ne soient disponibles pour la recherche correspond à la somme des durées des flux le long du flux de données.

Par exemple, le temps moyen typique de disponibilité des données dans la recherche UDM est d'environ 5 minutes et 30 secondes à partir du moment où les données sont envoyées au service d'ingestion Google SecOps.

Étape du flux de données	Description	Durée du flux
Cloud Storage vers Journaux bruts	Ingère les journaux bruts depuis Cloud Storage.	Moins de 30 secondes
Journaux de sécurité vers Service de transfert de données	Transmet les journaux de sécurité des systèmes internes à la plate-forme.	N/A
Service de transfert de données vers Journaux bruts	Envoie les données de sécurité brutes reçues de différentes sources au pipeline d'ingestion.	Moins de 30 secondes
Journaux bruts vers Analyser et valider	Analyse et valide les journaux bruts au format UDM.	Moins de trois minutes
Analyser et valider vers Index	Indexe les données UDM analysées pour une recherche rapide.	N/A
Index vers Données client analysées	Met à disposition les données indexées sous forme de données client analysées.	Moins de 2 minutes

Dépannage

Cette section fournit des conseils de dépannage.

Latence et limites

Les délais de traitement et de visualisation dans la plate-forme Google SecOps sont soumis aux limites architecturales suivantes une fois que Google SecOps a reçu les données :

• Visibilité dans la recherche : 2 à 15 minutes après l'ingestion.
• Exécution des règles : 5 à 10 minutes après l'arrivée de l'événement.
• Visualisation de l'UI : pour maintenir les performances du navigateur, les données de journaux à volume élevé sont soumises à une limite de visualisation de 10 000 lignes.

Remarque : Ces délais commencent une fois que Google SecOps a reçu les données. La disponibilité des données de bout en bout dépend également des retards provenant de la source de données qui se produisent avant que les données n'entrent dans le pipeline Google SecOps.

Attention : Si une modification n'apparaît pas immédiatement dans l'interface utilisateur, cela ne signifie pas nécessairement qu'une synchronisation a échoué. Si l'événement s'est produit il y a moins de 15 minutes pour la recherche ou de 10 minutes pour les règles, les données sont probablement encore en cours de traitement. Ce délai n'indique pas une défaillance du système.

Vous avez encore besoin d'aide ? Obtenez des réponses auprès des membres de la communauté et des professionnels Google SecOps.