Comprendre la disponibilité des données pour la recherche

Compatible avec :

Google secops

Ce document décrit le cycle de vie de l'ingestion de données, y compris le flux de données de bout en bout et la latence, ainsi que l'impact de ces facteurs 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 :

• les journaux de sécurité de vos systèmes internes ;
• les 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 dans la plate-forme à l'aide de l'une de ses méthodes d'ingestion sécurisées.

Les principales méthodes d'ingestion sont les suivantes :

• Ingestion Google Cloud directe

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

• API d'ingestion

  Envoyez des 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 le Bindplane agent polyvalent dans votre environnement (sur site ou dans d'autres clouds) pour collecter des journaux à partir d'une grande variété de sources et les transférer vers Google SecOps.

• Flux de données

  Dans Google SecOps, vous configurez les flux de données pour extraire les journaux de sources tierces, telles que des buckets Cloud Storage 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 arrivées 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 les données de leur format d'origine au format standardisé UDM. L'analyse et la normalisation vous permettent d'analyser des sources de données disparates (par exemple, des journaux de pare-feu, des données de point de terminaison, des 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 offrir des vitesses de requête 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 des alias et un enrichissement UDM pour enrichir les événements UDM avec un contexte précieux, en identifiant et en ajoutant des données contextuelles et des indicateurs pour les entités de journaux. Par exemple, il associe le login name d'un utilisateur à ses différentes IP addresses, hostnames et MAC addresses.
   • Géolocalisation : Google SecOps enrichit les adresses IP avec des données de géolocalisation.

4. Enrichissement 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é.

   • Renseignements sur les menaces : Google SecOps compare automatiquement les données d'événement aux vastes renseignements sur les menaces de Google, y compris des sources telles que Google Threat Intelligence et la navigation sécurisée, afin d'identifier les menaces malveillantes connues, telles que domains, IP addresses, et file hashes.

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

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 activées par des règles 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, en utilisant la recherche UDM pour passer d'entités associées (comme un user, à son asset et à 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.

• Ce qu'elle recherche : elle interroge les événements UDM normalisés et indexés. Étant donné que 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 différents 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 dans les 2 à 15 minutes suivant l'ingestion.

Recherche dans les journaux bruts

Utilisez la recherche dans les journaux bruts 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, et 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 qu'elle recherche : elle analyse le texte brut d'origine des journaux avant leur analyse et leur normalisation. Cela est utile pour 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 n'effectue pas de recherche dans les champs indexés.
• Exemple (chaîne) raw = "PsExec.exe"
• Exemple (expression régulière) : raw = /admin\$/

Recherche de statistiques

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

Recherche en langage naturel (Gemini)

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

• Ce qu'elle recherche : elle fournit une interface conversationnelle pour interroger les données UDM.
• Fonctionnement : vous saisissez une question, et Gemini génère la requête de recherche UDM sous-jacente, que vous pouvez ensuite exécuter ou affiner.
• Exemple : "Show me all failed logins from user 'bob' in the last 24 hours"

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 dans les journaux.

• Ce qu'elle recherche : elle recherche des cas et des entités (telles que des utilisateurs, des actifs, des adresses IP) dans la plate-forme SOAR.
• Fonctionnement : vous pouvez utiliser des filtres de texte libre ou basés sur des champs pour trouver des cas, par exemple, par leur ID, leur nom d'alerte, leur état et l'utilisateur attribué.
• Exemple : recherchez CaseIds:180 ou AlertName:Brute Force

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

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 est la somme des deux composants suivants :

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

2. Temps 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 internes du pipeline, telles que l'ingestion, l'analyse, la normalisation, l'indexation et l'enrichissement.

Vous devez tenir compte des deux composants lors du dépannage des délais de visibilité des données.

Délais provenant de la source de données

Les facteurs suivants peuvent influencer le délai de disponibilité côté source :

• Traitement par lot : certains systèmes génèrent des journaux par lot à intervalles définis (par exemple, toutes les heures).
• Latence de l'API : l'API source peut avoir des délais inhérents pour rendre les nouveaux événements interrogeables.
• Heure de création et de publication de l'événement : un horodatage d'événement dans un journal peut être beaucoup plus ancien que l'horodatage lorsque le journal est finalisé et devient disponible pour la collecte.
• Limitation : les limites de débit de l'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 journal. Pour en savoir plus sur les méthodes d'ingestion, consultez la présentation de l'ingestion de données. La documentation de référence de l'API de gestion des flux décrit des considérations spécifiques pour les types de journaux tels que Microsoft Graph, SentinelOne, Okta et CrowdStrike.

Temps de traitement 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 présente les étapes de traitement des données nouvellement ingérées par méthode de recherche. Les données nouvellement ingérées deviennent consultables une fois ces étapes terminées.

Méthode de recherche	Données recherchées	Étapes de traitement contribuant au temps 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 rapide et structurée. Enrichissement : le contexte (renseignements sur les menaces, géolocalisation, données utilisateur ou d'actif) est ajouté.
Recherche dans les journaux bruts	Texte de 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 : mêmes étapes que celles listées pour la recherche UDM. Évaluation de la détection : le moteur de règles évalue les journaux dans des "micro-lots", déclenchant généralement des détections 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 cas, et non des journaux. Le temps est basé 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 à un ou plusieurs événements UDM. Génération d'alertes : le système crée une alerte formelle à partir de la détection. Création de cas : la plate-forme SOAR ingère l'alerte et crée un cas.

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é, ce qui les rend 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é à partir de services cloud tels qu'Amazon S3 ou à partir du Google 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 produit, le développement et la maintenance.
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 avec des données contextuelles.
7. Offre un accès sécurisé aux utilisateurs 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 prévu avant la disponibilité de la recherche

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

Par exemple, le délai 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 à partir de 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 3 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	Rend les données indexées disponibles en tant que données client analysées pour l'analyse.	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 au sein de la plate-forme Google SecOps sont soumis aux limites architecturales suivantes une fois que Google SecOps reçoit les données :

• Visibilité de 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'interface utilisateur : pour maintenir les performances du navigateur, les données de journal à volume élevé sont soumises à une limite de visualisation de 10 000 lignes.

Remarque : Pour les plages de recherche supérieures à 30 jours, les événements récemment ingérés peuvent mettre plus de temps à s’afficher. Pour obtenir des résultats en temps quasi réel, sélectionnez une plage de 30 jours ou moins.

Remarque : Ces délais commencent après que Google SecOps a reçu les données. La disponibilité des données de bout en bout dépend également des délais 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 n'indique pas nécessairement un échec de synchronisation. Si l'événement s'est produit il y a moins de 15 minutes pour la recherche ou il y a moins de 10 minutes pour les règles, les données sont probablement toujours dans le pipeline de traitement standard. Le 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.