Informazioni sulla disponibilità dei dati per la ricerca

Supportato in:

Questo documento descrive in dettaglio il ciclo di vita dell'importazione dati, inclusi il flusso dei dati end-to-end e la latenza, nonché l'impatto di questi fattori sulla disponibilità dei dati importati di recente per l'esecuzione di query e l'analisi.

Importare ed elaborare i dati in Google SecOps

Questa sezione descrive in che modo Google SecOps importa, elabora e analizza i dati di sicurezza.

Importazione dati

La pipeline di importazione dei dati inizia con la raccolta dei dati di sicurezza non elaborati da origini come:

  • Log di sicurezza dei sistemi interni
  • Dati archiviati in Cloud Storage
  • Il Security Operations Center (SOC) e altri sistemi interni

Google SecOps porta questi dati sulla piattaforma utilizzando uno dei suoi metodi di importazione sicuri.

I metodi di importazione principali sono:

  • Importazione Google Cloud diretta

    Google SecOps utilizza l'importazione diretta Google Cloud per recuperare automaticamente i log e i dati di telemetria della tua organizzazione Google Cloud, inclusi Cloud Logging, i metadati di Cloud Asset Inventory e i risultati di Security Command Center Premium.

  • API di importazione

    Invia i dati direttamente a Google SecOps utilizzando le API di importazione REST pubbliche . Utilizza questo metodo per le integrazioni personalizzate o per inviare i dati come log non strutturati o come eventi UDM (Unified Data Model) preformattati.

  • Agente Bindplane

    Puoi eseguire il deployment dell'agente Bindplane versatile nel tuo ambiente (on-premise o altri cloud) per raccogliere i log da un'ampia varietà di origini e inoltrarli a Google SecOps.

  • Feed di dati

    In Google SecOps, configura i feed di dati per recuperare i log da origini di terze parti, come bucket di spazio di archiviazione sul cloud di terze parti specifici (ad esempio Amazon S3) o API di terze parti (ad esempio Okta o Microsoft 365).

Normalizzazione e arricchimento dei dati

Una volta che i dati arrivano in Google SecOps, la piattaforma li elabora nelle seguenti fasi:

  1. Analisi e normalizzazione

    Un parser elabora innanzitutto i dati di log non elaborati per convalidarli, estrarli e trasformare i dati dal formato originale nel formato UDM standardizzato. L'analisi e la normalizzazione ti consentono di analizzare origini dati disparate (ad esempio log del firewall, dati degli endpoint, log cloud) utilizzando un unico schema coerente. Il log non elaborato originale rimane archiviato insieme all'evento UDM.

  2. Indicizzazione

    Dopo la normalizzazione, Google SecOps indicizza i dati UDM per offrire velocità di query elevate su set di dati di grandi dimensioni, rendendo ricercabili gli eventi UDM.

  3. Alias e arricchimento UDM

    • Google SecOps esegue l'alias e l'arricchimento UDM per arricchire gli eventi UDM con un contesto prezioso, identificando e aggiungendo dati di contesto e indicatori per le entità di log. Ad esempio, collega un utente login name ai suoi vari IP addresses, hostnames e MAC addresses.
    • Geolocalizzazione: Google SecOps arricchisce gli indirizzi IP con dati di geolocalizzazione.

  4. Arricchimento ECG

Disponibilità dei dati per l'analisi

Dopo l'elaborazione e l'arricchimento, i dati UDM sono immediatamente disponibili per l'analisi:

  • Rilevamento in tempo reale

    Il motore di rilevamento esegue automaticamente regole personalizzate e create da Google abilitate per le regole live sui dati in entrata in tempo reale per identificare le minacce e generare avvisi.

  • Ricerca e indagine

    Un analista può utilizzare i metodi di ricerca per cercare in tutti questi dati normalizzati e arricchiti. Ad esempio, utilizzando la ricerca UDM per passare da entità correlate (come un user, al suo asset, a un domain dannoso) e indagare sugli avvisi.

Metodi di ricerca

Google SecOps fornisce diversi metodi distinti per la ricerca nei dati, ognuno con uno scopo diverso.

La ricerca UDM è il metodo di ricerca principale e più veloce, utilizzato per la maggior parte delle indagini.

  • Cosa cerca: esegue query sugli eventi UDM normalizzati e indicizzati. Poiché tutti i dati vengono analizzati in questo formato standard, puoi scrivere una query per trovare la stessa attività (ad esempio un accesso) in tutti i tuoi diversi prodotti (ad esempio Windows, Okta, Linux).
  • Come funziona: utilizzi una sintassi specifica per eseguire query su campi, operatori e valori.

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

    I risultati sono in genere disponibili entro 2-15 minuti dall'importazione.

Utilizza la ricerca log non elaborati per trovare qualcosa nel messaggio di log originale e non analizzato che potrebbe non essere stato mappato a un campo UDM. Questo metodo di ricerca è ottimizzato per le ricerche ad alta velocità e in genere restituisce i risultati in meno di 2 secondi per indicatori specifici come gli hash di file o gli indirizzi IP.

  • Cosa cerca: esegue la scansione del testo originale e non elaborato dei log prima che vengano analizzati e normalizzati. Questa opzione è utile per trovare stringhe specifiche, argomenti della riga di comando o altri artefatti che non sono campi UDM indicizzati.
  • Come funziona: utilizzi il prefisso raw =. Può essere più lento della ricerca UDM perché non cerca i campi indicizzati.
  • Esempio (stringa): raw = "PsExec.exe"
  • Esempio (regex): raw = /admin\$/

Utilizza la ricerca statistiche per le tendenze a lungo termine che aggregano milioni di righe di dati. Poiché la piattaforma deve eseguire analisi statistiche e raggruppamenti, prevedi tempi di caricamento più lunghi per queste query.

Ricerca in linguaggio naturale (Gemini)

La ricerca in linguaggio naturale (Gemini) ti consente di utilizzare l'inglese semplice per porre domande, che Gemini traduce in una query UDM formale.

  • Cosa cerca: fornisce un'interfaccia conversazionale per eseguire query sui dati UDM.
  • Come funziona: digiti una domanda e Gemini genera la query di ricerca UDM sottostante, che puoi quindi eseguire o perfezionare.
  • Esempio: "Show me all failed logins from user 'bob' in the last 24 hours"

La ricerca SOAR è specifica per i componenti SOAR. La utilizzi per gestire gli incidenti di sicurezza, non per cercare nei log.

  • Cosa cerca: cerca richieste ed entità (come utenti, asset, indirizzi IP) all'interno della piattaforma SOAR.
  • Come funziona: puoi utilizzare filtri di testo libero o basati su campi per trovare le richieste, ad esempio in base a ID, nome dell'avviso, stato e utente assegnato.
  • Esempio: Search for CaseIds:180 or AlertName:Brute Force

Pipeline di importazione dei dati per la disponibilità della ricerca

La disponibilità dei dati end-to-end è il tempo totale che intercorre tra il momento in cui si verifica un evento e il momento in cui è disponibile per la ricerca o l'esecuzione di regole in Google SecOps. Questa latenza è la somma dei due componenti seguenti:

  1. Ritardo di disponibilità lato origine: il tempo che intercorre tra il momento in cui si verifica un evento e il momento in cui il sistema di origine rende disponibili i dati di log per l'importazione. Questo ritardo dipende dall'architettura, dall'elaborazione, dal batch e dalle pianificazioni di pubblicazione delle API del sistema di origine. Google SecOps non può influenzare questo ritardo. Esempi includono ritardi quando un sistema scrive i log in un bucket di archiviazione o li pubblica in un endpoint API.

  2. Tempo di elaborazione di Google SecOps: il tempo necessario a Google SecOps per elaborare i dati dopo averli ricevuti. Questa durata include le fasi della pipeline interna, come importazione, analisi, normalizzazione, indicizzazione e arricchimento.

Devi considerare entrambi i componenti quando risolvi i problemi relativi alle sequenze temporali di visibilità dei dati.

Ritardi provenienti dall'origine dati

I seguenti fattori possono influenzare il ritardo di disponibilità lato origine:

  • Elaborazione batch: alcuni sistemi generano log in batch a intervalli prestabiliti (ad esempio, ogni ora).
  • Latenza API: l'API di origine può avere ritardi intrinseci nel rendere eseguibili le query sui nuovi eventi.
  • Ora di creazione e pubblicazione dell'evento: il timestamp di un evento in un log potrebbe essere molto precedente al timestamp in cui il log viene finalizzato e diventa disponibile per la raccolta.
  • Limitazione: i limiti di frequenza delle API lato origine possono rallentare il recupero dei dati.
  • Backfill iniziale: la pubblicazione e l'importazione di grandi volumi di dati storici richiedono tempo.

Questi ritardi variano in base all'origine dati e al tipo di log. Per ulteriori dettagli sui metodi di importazione, consulta la panoramica sull'importazione dei dati. Il riferimento API di gestione dei feed descrive considerazioni specifiche per i tipi di log come Microsoft Graph, SentinelOne, Okta e CrowdStrike.

Tempo di elaborazione di Google SecOps

Il sistema elabora i dati appena importati in diversi passaggi. La durata di questi passaggi determina il momento in cui i dati appena importati diventano disponibili per l'esecuzione di query e l'analisi.

La tabella seguente suddivide i passaggi di elaborazione dei dati appena importati in base al metodo di ricerca. I dati appena importati diventano ricercabili al termine di questi passaggi.

Metodo di ricerca Dati su cui viene eseguita la ricerca Passaggi di elaborazione che contribuiscono al tempo di disponibilità
Eventi UDM normalizzati e arricchiti
  1. Importazione: il log arriva al punto di importazione di Google SecOps.
  2. Analisi: il log non elaborato viene identificato ed elaborato dal parser specifico.
  3. Normalizzazione: i dati vengono estratti e mappati allo schema UDM.
  4. Indicizzazione (UDM): il record UDM normalizzato viene indicizzato per una ricerca strutturata e rapida.
  5. Arricchimento: vengono aggiunti dati di contesto (threat intelligence, geolocalizzazione, dati utente o asset).
Ricerca log non elaborati Testo del log originale e non analizzato
  1. Importazione: il log arriva al punto di importazione di Google SecOps.
Motore di rilevamento (regole) Eventi normalizzati
  1. Disponibilità degli eventi UDM: stessi passaggi elencati per la ricerca UDM.
  2. Valutazione del rilevamento: il motore delle regole valuta i log in "micro-batch", in genere attivando i rilevamenti entro 5-10 minuti dall'arrivo dell'evento.
Ricerca SOAR Richieste ed entità Si tratta di un ciclo di vita diverso, in quanto cerca avvisi e richieste, non log. Il tempo si basa su:
  1. Disponibilità degli eventi UDM: utilizza gli stessi passaggi di elaborazione elencati per la "ricerca UDM".
  2. Rilevamento: una regola del motore di rilevamento deve corrispondere agli eventi UDM.
  3. Generazione di avvisi: il sistema crea un avviso formale dal rilevamento.
  4. Creazione di richieste: la piattaforma SOAR importa l'avviso e crea una richiesta.

Esempio di flusso di dati

L'esempio seguente mostra in che modo Google SecOps importa, elabora, migliora e analizza i dati di sicurezza, rendendoli disponibili per le ricerche e ulteriori analisi.

Esempio di passaggi di elaborazione dei dati

  1. Recupera i dati di sicurezza da servizi cloud come Amazon S3 o da Google Cloud. Google SecOps cripta questi dati in transito.
  2. Separa e archivia i dati di sicurezza criptati nel tuo account. L'accesso è limitato a te e a un numero limitato di dipendenti Google per l'assistenza, lo sviluppo e la manutenzione dei prodotti.
  3. Analizza e convalida i dati di sicurezza non elaborati, semplificandone l'elaborazione e la visualizzazione.
  4. Normalizza e indicizza i dati per ricerche rapide.
  5. Archivia i dati analizzati e indicizzati nel tuo account.
  6. Arricchisce con i dati di contesto.
  7. Offre agli utenti un accesso sicuro per cercare e rivedere i propri dati di sicurezza.
  8. Confronta i dati di sicurezza con il database di malware di Google Threat Intelligence per identificare le corrispondenze. In una visualizzazione degli eventi di Google SecOps, ad esempio la visualizzazione Asset, fai clic su Contesto VT per visualizzare le informazioni di Google Threat Intelligence. Google SecOps non condivide i tuoi dati di sicurezza con Google Threat Intelligence.

Flusso ed elaborazione dei dati in Google SecOps

Esempi del tempo previsto fino alla disponibilità della ricerca

Il tempo previsto fino a quando i dati appena importati diventano disponibili per la ricerca è la somma delle durate del flusso lungo il flusso di dati.

Ad esempio, un tempo medio tipico per la disponibilità dei dati nella ricerca UDM è di circa 5 minuti e 30 secondi dal momento in cui i dati vengono inviati al servizio di importazione di Google SecOps.

Passaggio del flusso di dati Descrizione Durata del flusso
Cloud Storage a Log non elaborati Importa i log non elaborati da Cloud Storage. Meno di 30 secondi
Log di sicurezza a Servizio di inoltro dei dati Trasmette i log di sicurezza dai sistemi interni alla piattaforma. N/D
Servizio di inoltro dei dati a Log non elaborati Invia i dati di sicurezza non elaborati ricevuti da varie origini alla pipeline di importazione. Meno di 30 secondi
Log non elaborati a Analizza e convalida Analizza e convalida i log non elaborati nel formato UDM. Meno di 3 minuti
Analizza e convalida a Indice Indicizza i dati UDM analizzati per una ricerca rapida. N/D
Indice a Dati dei clienti analizzati Rende disponibili i dati indicizzati come dati dei clienti analizzati per l'analisi. Meno di 2 minuti

Risoluzione dei problemi

Questa sezione fornisce indicazioni per la risoluzione dei problemi.

Latenza e limiti

I ritardi di elaborazione e visualizzazione all'interno della piattaforma Google SecOps sono soggetti ai seguenti limiti architetturali dopo che Google SecOps riceve i dati:

  • Visibilità della ricerca: da 2 a 15 minuti dopo l'importazione.
  • Esecuzione delle regole: da 5 a 10 minuti dopo l'arrivo dell'evento.
  • Visualizzazione dell'interfaccia utente: per mantenere le prestazioni del browser, i dati di log di grandi dimensioni sono soggetti a un limite di visualizzazione di 10.000 righe.

Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.