Architettura e flussi di dati di Google SecOps

Supportato in:

Google SecOps

Gli ambienti di sicurezza moderni generano enormi quantità di telemetria su infrastrutture cloud-native, microservizi ed endpoint distribuiti. Le architetture legacy di security information and event management (SIEM) spesso faticano a scalare con questi volumi di dati, con conseguenti query lente e visibilità frammentata.

La piattaforma Google Security Operations fornisce un livello di analisi della sicurezza unificato e ad alte prestazioni. Basata sulla stessa infrastruttura alla base dei servizi globali principali di Google, importa ed esegue query su petabyte di telemetria di sicurezza con una latenza inferiore al secondo, eliminando al contempo la distinzione legacy tra i livelli di dati ad accesso frequente e ad accesso infrequente.

Questo documento descrive l'architettura e i flussi di dati di Google SecOps, tra cui l'importazione, la normalizzazione UDM, il rilevamento delle minacce YARA-L e la risposta automatizzata.

Convergenza di intelligence, analisi e risposta

Google SecOps unifica le funzionalità di operazioni di sicurezza storicamente separate. Combina l'analisi SIEM e SOAR (Security Orchestration, Automation and Response) in una piattaforma strettamente accoppiata. Inoltre, incorpora la threat intelligence di Google Threat Intelligence e VirusTotal, nonché le funzionalità di AI generativa basate su Gemini direttamente nei workflow di indagine e rilevamento.

Panoramica dell'architettura della piattaforma

Google SecOps funziona come un piano di sicurezza cloud-native specializzato basato sull'infrastruttura principale Google Cloud . Eredita le proprietà di scalabilità, durabilità e prestazioni dei servizi Google sottostanti, tra cui Spanner e Colossus.

Contesto di sistema

Google SecOps funge da piano operativo centrale per l'ambiente di sicurezza, gestendo i dati in tre fasi principali:

• Input: importa la telemetria da ambienti ibridi, inclusi i collettori on-premise (come l'agente BindPlane), le API dei provider di servizi cloud e i connettori diretti di software as a service (SaaS) di terze parti.
• Core di elaborazione: normalizza la telemetria non elaborata nello schema UDM strutturato, valuta gli eventi utilizzando il motore di rilevamento YARA-L e orchestra i workflow utilizzando il motore di gestione delle richieste SOAR.
• Output: fornisce informazioni di sicurezza utilizzabili e informazioni di triage AI agli analisti, inviando al contempo comandi di contenimento automatizzati agli ambienti di destinazione tramite API e agenti remoti.

Il seguente diagramma illustra il contesto di sistema e i flussi di dati.

Vantaggio dell'infrastruttura

Un vantaggio architettonico fondamentale di Google SecOps è il suo modello di hot storage unificato. Le architetture legacy spostano la telemetria meno recente nell'archiviazione ad accesso infrequente, rallentando le query o richiedendo la reidratazione manuale. Al contrario, Google SecOps conserva tutta la telemetria importata in uno stato ad accesso frequente attivo e ricercabile tramite indice per un massimo di 12 mesi. Questo design ti consente di eseguire query su un anno intero di dati storici con le stesse prestazioni delle query sull'ultima ora.

Pipeline di raccolta e normalizzazione dei dati

Google SecOps utilizza una pipeline di importazione ad alta velocità effettiva che trasforma i log non strutturati non elaborati nel modello di dati unificato (UDM) strutturato. Durante la normalizzazione, la pipeline arricchisce ogni evento con i metadati contestuali del grafico del contesto delle entità.

Architettura di raccolta

L'acquisizione dei dati avviene tramite tre vettori principali:

• Collettori: collettori basati su agenti (come l'agente BindPlane o gli agenti OpenTelemetry) di cui è stato eseguito il deployment all'interno delle reti locali per aggregare i dati syslog e dei pacchetti. I collettori memorizzano nel buffer, comprimono e criptano la telemetria a livello di trasporto (TLS) prima di inoltrarla a Google SecOps.
• API di importazione: endpoint API REST diretti che importano la telemetria strutturata e non strutturata da servizi cloud, applicazioni personalizzate e pipeline serverless.
• Integrazioni di terze parti: connettori pull-based integrati che recuperano i log, gli avvisi e i dati della directory direttamente da piattaforme SaaS esterne e API cloud (come Microsoft 365 o Microsoft Entra ID).

Flusso della pipeline di raccolta e preparazione dei dati

Il seguente diagramma illustra in dettaglio i passaggi di trasformazione specifici dai dati non elaborati al formato UDM.

Panoramica dello schema del modello di dati unificato

Il modello di dati unificato (UDM) normalizza i log di fornitori diversi in un unico schema strutturato. Questa rappresentazione standard semplifica l'analisi e la ricerca garantendo che le entità equivalenti (come indirizzi IP, nomi utente o hash di file) condividano percorsi di campo coerenti in tutte le origini log.

Architettura dello schema UDM

L'UDM utilizza uno schema gerarchico con tipi di dati definiti in modo rigoroso per rappresentare gli eventi e le entità di sicurezza. Organizza i dati nelle seguenti strutture logiche principali:

• Metadati: contesto dell'evento di log stesso, inclusi il timestamp dell'evento, l'ora di importazione, il nome del prodotto del fornitore e il tipo di evento.
• Entità principale: l'entità che ha avviato l'attività (ad esempio l'utente, l'host, l'indirizzo IP o il processo di origine).
• Destinazione: l'entità direttamente interessata dall'attività (ad esempio il file di destinazione, l'host di destinazione o l'account utente).
• Origine, intermediario e osservatore: partecipanti alla rete secondaria (ad esempio proxy di inoltro, firewall o hop di routing) coinvolti nella transazione.
• Rete: attributi del protocollo di rete e artefatti di transazione (inclusi protocolli applicativi, query DNS e dettagli delle richieste HTTP).
• Risultato di sicurezza: l'azione o la gravità segnalata dal dispositivo di sicurezza (ad esempio ALLOWED, BLOCKED, o QUARANTINED).
• Estensioni: campi personalizzati e coppie chiave-valore specifici del fornitore che non rientrano nello schema principale standard. Per informazioni dettagliate sul mapping delle definizioni e sullo sviluppo del parser, vedi Configurare i parser personalizzati e Campi UDM importanti.

Diagramma delle classi UDM

Il seguente diagramma fornisce un progetto strutturale dell'UDM.

Architettura di ricerca

Google SecOps fornisce potenti meccanismi di ricerca personalizzati per diversi workflow di indagine. Puoi eseguire query sulla telemetria normalizzata nell'archiviazione ad accesso frequente, eseguire la corrispondenza di pattern con i log non elaborati non analizzati o cercare dati di richieste strutturati. Per indicazioni sull'ottimizzazione, vedi Best practice per la ricerca UDM.

La seguente tabella riassume le funzionalità di ricerca principali disponibili sulla piattaforma:

Tipo di ricerca	Funzione architettonica
Ricerca UDM	Il motore di ricerca strutturato principale che esegue query sugli eventi UDM normalizzati e indicizzati nella finestra ad accesso frequente di 12 mesi. Consente il filtraggio, le aggregazioni e le correlazioni di più campi tra origini log diverse.
Scansione dei log non elaborati	Scansiona le stringhe di testo originali e non analizzate dei log importati. Questa funzionalità supporta le ricerche di espressioni regolari (`regex`) e sottostringhe per artefatti e parametri personalizzati non mappati su una sintassi UDM specifica.
Ricerca in linguaggio naturale	Utilizza Gemini AI per tradurre le domande in linguaggio naturale direttamente nella sintassi di ricerca UDM formale, velocizzando la creazione di query e i workflow di indagine.
Ricerca delle richieste	Un motore di ricerca specializzato all'interno del livello di risposta che esegue query su richieste di indagine, avvisi, playbook e metadati delle entità annotati all'interno del database SOAR.

Ciclo di rilevamento e risposta alle minacce

L'architettura di Google SecOps crea un ciclo di feedback continuo tra l'analisi di rilevamento e la risposta automatizzata. Le regole di rilevamento generano avvisi ad alta fedeltà che attivano i workflow di risposta, mentre i risultati dell'indagine forniscono feedback utilizzati per perfezionare e ottimizzare la logica di rilevamento futura.

Architettura del funnel di rilevamento

Il motore di rilevamento utilizza un approccio a funnel multi-fase per distillare enormi volumi di telemetria di sicurezza non elaborata in avvisi ad alta fedeltà:

1. Importazione e normalizzazione: i log non elaborati vengono importati e formattati continuamente in strutture di eventi UDM standard.
2. Arricchimento: gli eventi vengono arricchiti dinamicamente con mapping degli alias, dati delle risorse contestuali e threat intelligence globale da origini come Google Threat Intelligence.
3. Valutazione del rilevamento: il motore YARA-L 2.0 con stato valuta gli eventi arricchiti in base alle regole comportamentali e di minaccia in finestre temporali estese. Per le linee guida sull'ottimizzazione delle regole, vedi Best practice per YARA-L.
4. Prioritizzazione e raggruppamento: i rilevamenti corrispondenti vengono aggregati in avvisi, vengono assegnati punteggi di rischio dinamici e vengono raggruppati in richieste unificate.

Combinando i dati delle risorse contestuali con la threat intelligence, questa strategia di funnel filtra le anomalie innocue (riducendo i falsi positivi) ed evidenzia le minacce reali (riducendo i falsi negativi), aiutando il team di sicurezza a concentrarsi sugli incidenti utilizzabili.

Ciclo di feedback e correzione automatizzata

La pipeline di rilevamento e risposta combina la valutazione delle regole con stato con il triage e il contenimento automatizzati:

1. Valutazione continua: i flussi di telemetria UDM arricchiti vengono trasmessi tramite il motore di rilevamento YARA-L 2.0 con stato.
2. Creazione di richieste e triage AI: quando viene soddisfatta una condizione di regola, Google SecOps genera un avviso e apre una richiesta. Un agente di triage e indagine basato sull'AI esegue ricerche dinamiche e ricerche di threat intelligence per valutare i risultati.
3. Esecuzione automatizzata dei playbook: se il triage AI conferma un vero positivo, la piattaforma attiva i playbook di risposta automatizzati (ad esempio isolando un endpoint o sospendendo un account utente tramite agenti remoti). Se classificata come falso positivo, la richiesta viene chiusa automaticamente.
4. Ottimizzazione continua: i risultati della correzione e i verdetti di triage degli analisti vengono riutilizzati per perfezionare le soglie di rilevamento e ridurre i falsi positivi futuri.

Livello di rilevamento delle minacce

Il motore YARA-L 2.0 valuta la telemetria UDM in entrata utilizzando una pipeline di streaming multi-fase per rilevare anomalie comportamentali e pattern di attacco multi-evento in finestre temporali estese. Puoi anche generare e perfezionare le regole YARA-L utilizzando Gemini.

Il ciclo di vita dell'elaborazione per ogni regola YARA-L segue cinque fasi di valutazione distinte:

1. Importazione (Ingest): gli eventi UDM arricchiti entrano nella pipeline di valutazione del rilevamento in tempo reale.
2. Filtraggio (Filter): gli eventi in entrata vengono valutati in base ai criteri degli eventi della regola (sezione events). Gli eventi che non corrispondono vengono eliminati, mentre gli eventi corrispondenti vengono passati alla valutazione con stato.
3. Finestra di corrispondenza (Window): gli eventi corrispondenti vengono raggruppati in base alle chiavi di correlazione specificate in una finestra temporale definita (da secondi a 12 mesi). Il motore tiene traccia di più timer con stato simultanei (TimerStart a TimerEnd) man mano che gli eventi si accumulano.
4. Valutazione della condizione (Condition): quando la finestra di corrispondenza si chiude o si attiva, il motore valuta i requisiti di soglia e le espressioni matematiche definiti nella sezione condition della regola (ad esempio conteggi degli eventi, soglie distinte o join tra dati).
5. Attivazione (Trigger): se la condizione restituisce True, il motore genera un rilevamento, attivando un avviso e aprendo o aggiornando una richiesta nel livello di risposta. Se False, lo stato viene cancellato senza attivare un avviso.

Macchina a stati di esecuzione delle regole

Il seguente diagramma illustra il ciclo di vita dell'esecuzione di una regola.

Architettura di risposta ed esecuzione remota

Google SecOps SOAR rappresenta il pilastro di risposta della piattaforma. Funziona come motore di orchestrazione sopra il livello di analisi per importare avvisi, eseguire il triage delle richieste ed eseguire workflow di risposta automatizzati.

Orchestrazione, automazione e indagine

Il livello di risposta include strumenti specializzati progettati per semplificare i workflow del Security Operations Center (SOC) per indagine, gestione delle richieste e automazione dei playbook:

• Gestione delle richieste: raggruppa gli avvisi correlati in richieste unificate, ordina e filtra le code degli incidenti, assegna attività e collabora alle indagini con il monitoraggio completo degli audit.
• Progettazione di playbook: crea playbook di risposta automatizzati utilizzando un canvas visivo senza codice con azioni di integrazione predefinite.
• Ambiente di sviluppo integrato (IDE): utilizza l'IDE integrato basato su codice per scrivere script Python personalizzati, modificare le integrazioni delle azioni esistenti ed eseguire il debug di workflow di automazione complessi.
• Visualizzazioni di indagine e strumento di indagine dei grafici: visualizza i percorsi di attacco e le relazioni tra le entità utilizzando le visualizzazioni di indagine basate su grafici. I riepiloghi delle entità dedicati (ad esempio le visualizzazioni Risorsa, Indirizzo IP, Hash, Dominio e Utente) mostrano immediatamente gli eventi della sequenza temporale pertinenti.
• Dashboard e report: monitora le metriche operative del SOC, il carico di lavoro degli analisti e il tempo medio di risposta (MTTR) utilizzando dashboard predefinite o widget di reporting personalizzati.

Architettura dei componenti SOAR

Il seguente diagramma illustra il flusso degli avvisi in entrata nel motore di gestione delle richieste e l'attivazione dei workflow di correzione automatizzati nei playbook visivi e nelle integrazioni IDE personalizzate.

Architettura dell'agente remoto

Per eseguire azioni di correzione all'interno di reti private (come data center on-premise o cloud privati virtuali), Google SecOps si basa su un'architettura di agenti remoti sicura e solo in uscita remote agent architecture.

In questo modello, la piattaforma Google SecOps non avvia mai connessioni in entrata al tuo ambiente privato:

1. Avvio dell'attività: quando un'azione del playbook richiede l'esecuzione locale, Google SecOps pubblica l'istruzione in una coda di pubblicazione sicura ospitata in Google Cloud.
2. Polling asincrono: l'agente remoto di cui è stato eseguito il deployment all'interno del tuo ambiente privato esegue continuamente il polling della coda di pubblicazione tramite una connessione in uscita criptata con TLS.
3. Esecuzione locale: quando viene recuperata un'istruzione di attività, l'agente remoto esegue l'azione richiesta localmente su strumenti di sicurezza interni o endpoint di rete (ad esempio disabilitando un account o bloccando una porta del firewall).
4. Report sullo stato: al termine, l'agente remoto restituisce lo stato dell'azione e i log di esecuzione alla coda di pubblicazione tramite TLS, dove vengono recuperati e visualizzati nella visualizzazione della richiesta SOAR.

Sicurezza, conformità e responsabilità condivisa

In quanto piattaforma cloud-native, Google SecOps opera in base a un modello di responsabilità condivisa: Google è responsabile della sicurezza della piattaforma, mentre tu sei responsabile della sicurezza nella piattaforma.

Modello di responsabilità condivisa

Google SecOps eredita la progettazione della sicurezza di base, le funzionalità di calcolo e l'architettura di archiviazione di Google Cloud infrastruttura. In questo modello:

• Google gestisce: la sicurezza fisica dei data center, l'infrastruttura cloud sottostante, la disponibilità della piattaforma e la crittografia predefinita dei dati inattivi e in transito.
• Tu gestisci: la governance dei dati, i controlli degli accessi e l'RBAC dei dati configurati tramite Identity and Access Management (IAM), le regole di rilevamento personalizzate e le impostazioni di conformità del tenant.

Tutti i requisiti di conformità, le regole di residenza dei dati e le policy di accesso vengono ereditati e applicati dalla gerarchia dell'organizzazione tramite cartelle e progetti al tenant controllato dalla conformità.

Conformità e preparazione di livello enterprise

Per soddisfare i rigorosi requisiti di governance normativa e organizzativa, Google SecOps offre tenant controllati dalla conformità. Questi tenant applicano standard di sicurezza rigorosi tramite Assured Workloads, supportando sia i framework di conformità legale sia i pacchetti di protezione dei dati tecnici.

Framework di conformità legale supportati:

• FedRAMP: livelli di impatto Moderate e High (FEDRAMP_MODERATE, FEDRAMP_HIGH)
• Livelli di impatto del Dipartimento della Difesa: IL4 e IL5 (IL4_AND_IL5)
• Sanità e finanza: HIPAA e PCI DSS (HIPAA, PCI_DSS)

Per eseguire il deployment di un tenant controllato dalla conformità, collega l'istanza Google SecOps a un Google Cloud progetto che si trova in una cartella Assured Workloads configurata per il pacchetto di controllo richiesto.

Residenza dei dati e trasparenza degli accessi

Google SecOps applica un rigoroso isolamento logico dei tenant e supporta Access Transparency per offrirti un controllo verificabile e visibilità degli audit sull'accesso ai dati amministrativi.

Pacchetti di sicurezza e residenza dei dati supportati:

• Chiavi di crittografia gestite dal cliente (CMEK): controlla e gestisci le chiavi utilizzate per criptare i dati inattivi (CMEK_V1).
• Residenza dei dati avanzata: applica i limiti di residenza dei dati regionali e i controlli degli accessi amministrativi (DRZ_ADVANCED).
• Controlli di servizio VPC: stabilisci perimetri sicuri e personalizzati intorno alle risorse di sicurezza cloud utilizzando i Controlli di servizio VPC (VPC-SC).

L'architettura di sicurezza della piattaforma si basa su un modello di ereditarietà a quattro livelli, in cui i controlli di sicurezza amministrativi si basano sulle fondamenta rafforzate dell'infrastruttura Google principale:

Lo stack di sicurezza a quattro livelli:

1. Livello di controllo della sicurezza del cliente: i controlli amministrativi di livello superiore, inclusi i controlli degli accessi basati su ruoli (RBAC) gestiti tramite Identity and Access Management (IAM), le chiavi di crittografia gestite dal cliente (CMEK) e le policy di residenza dei dati regionali.
2. Livello di sicurezza della piattaforma: isolamento logico dei tenant, crittografia predefinita per i dati a riposo e in transito (TLS) e logging di audit di Access Transparency.
3. Livello dell'infrastruttura Google: infrastruttura di calcolo e archiviazione principale, inclusa la gestione dei cluster Borg, l'archiviazione distribuita Colossus e i database globali Spanner.
4. Livello di sicurezza fisica: sicurezza di base supportata dai data center aziendali di Google, controlli biometrici multi-fattore e chip di sicurezza Titan personalizzati (roots of trust).

Ad esempio, quando Access Transparency è abilitato, se un esperto dell'Assistenza Google o dell'engineering accede ai dati del tenant per risolvere un ticket di assistenza, deve inviare una giustificazione dell'accesso crittografica valida. Questa richiesta di accesso viene registrata in modo sicuro e resa visibile nei log di audit quasi in tempo reale.

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