Best practice per la ricerca

Supportato in:

Questo documento descrive le best practice consigliate da Google per l'utilizzo della funzionalità Ricerca in Google Security Operations. Le ricerche possono richiedere risorse di calcolo sostanziali se non vengono create con attenzione. Il rendimento varia anche in base alle dimensioni e alla complessità dei dati nell'istanza di Google SecOps.

Utilizzare filtri specifici nelle query per la massima velocità e il massimo rendimento

Il modo più efficace per migliorare il rendimento della ricerca è creare query utilizzando campi Unified Data Model (UDM) specifici e ottimizzati. Questi campi sono ottimizzati per il recupero rapido, il che garantisce che le ricerche vengano eseguite rapidamente e utilizzino meno risorse di calcolo.

Le sezioni seguenti elencano i campi UDM ad alto rendimento da utilizzare come filtri nelle query.

Campi principali

  • principal.asset.hostname
  • principal.asset.ip
  • principal.asset.mac
  • principal.file.md5
  • principal.file.sha1
  • principal.file.sha256
  • principal.hostname
  • principal.ip
  • principal.mac
  • principal.process.file.md5
  • principal.process.file.sha1
  • principal.process.file.sha256
  • principal.process.parent_process.file.md5
  • principal.process.parent_process.file.sha1
  • principal.process.parent_process.file.sha256
  • principal.user.email_addresses
  • principal.user.product_object_id
  • principal.user.userid
  • principal.user.windows_sid

Campi di origine

  • source.user.userid
  • src.asset.hostname
  • src.hostname
  • src.ip

Campi di destinazione

  • target.asset.hostname
  • target.file.md5
  • target.file.sha1
  • target.file.sha256
  • target.hostname
  • target.ip
  • target.process.file.md5
  • target.process.file.sha1
  • target.process.file.sha256
  • target.user.email_addresses
  • target.user.product_object_id
  • target.user.userid
  • target.user.windows_sid

Campi aggiuntivi

  • about.file.md5
  • about.file.sha1
  • about.file.sha256
  • intermediary.hostname
  • intermediary.ip
  • network.dns.questions.name
  • network.email.from
  • network.email.to
  • observer.hostname
  • observer.ip

Come eseguire query sui dati di entità e di contesto

Se cerchi tipi di log di entità o di contesto (ad esempio AZURE_AD_CONTEXT o WORKSPACE_USERS) utilizzando metadata.log_type = "<LOG_TYPE>", la ricerca non restituisce risultati anche se i log non elaborati sono visibili nella ricerca nei log non elaborati. Questo perché la ricerca UDM esegue query solo sui record di eventi UDM.

Per cercare dati di entità e di contesto, utilizza la sintassi graph:

  • Per cercare il tipo di log di entità o di contesto, esegui query sui campi dei metadati graph. Ad esempio:

    graph.metadata.event_metadata.log_type = "<LOG_TYPE>"

  • Per cercare i campi di entità, utilizza il prefisso graph.entity.noun.field. Ad esempio:

    graph.entity.user.email_addresses = "foo_email"

Per ulteriori informazioni, vedi Eseguire una ricerca di dati di contesto di entità.

Creare query di ricerca efficaci per il rendimento

Scrivere query ottimizzate è fondamentale per massimizzare la velocità e ridurre al minimo il consumo di risorse nei dati di sicurezza. Tutte le condizioni delle query devono rispettare rigorosamente questa struttura fondamentale:

udm-field operator value

Ad esempio: principal.hostname = "win-server"

Poiché Google SecOps può acquisire una grande quantità di dati durante una ricerca, ridurre al minimo l'intervallo di tempo e restringere l'ambito della query può migliorare il rendimento della ricerca.

Utilizzare espressioni regolari nella query di ricerca

Puoi utilizzare gli operatori logici e di confronto standard quando crei le query di ricerca UDM per creare espressioni complesse:

  • Operatori logici: utilizza AND, OR e NOT per combinare le condizioni. Se ometti un operatore tra due condizioni, viene utilizzato AND.
  • Precedenza degli operatori: utilizza le parentesi () per sostituire l'ordine di precedenza predefinito. Esiste un limite massimo di 169 operatori logici (OR, AND, NOT) che puoi utilizzare all'interno delle parentesi.
  • Operatori di confronto: a seconda del tipo di campo UDM (stringa, numero intero, timestamp), gli operatori di campo possono includere: =, !=, >=, >, <, <=

Google SecOps utilizza il motore di espressioni regolari RE2.

In alternativa, per una ricerca efficiente di un insieme di valori di grandi dimensioni, puoi utilizzare gli elenchi di riferimento.

Utilizzare nocase come modificatore di ricerca

Puoi aggiungere il modificatore nocase a una condizione di confronto di stringhe per rendere la ricerca senza distinzione tra maiuscole e minuscole, che ignora le maiuscole.

Ad esempio, la seguente ricerca ignora la distinzione tra maiuscole e minuscole e corrisponde a tutte le combinazioni che contengono tim.smith indipendentemente dalla distinzione tra maiuscole e minuscole:

target.user.userid = "TIM.SMITH" nocase

Evitare di utilizzare espressioni regolari nei campi enumerati

Non puoi utilizzare espressioni regolari quando cerchi campi enumerati (campi con un intervallo di valori predefiniti) come metadata.event_type o network.ip_protocol

Il seguente esempio è una ricerca non valida: metadata.event_type = /NETWORK_*/

Mentre il seguente esempio è una ricerca valida: (metadata.event_type = "NETWORK_CONNECTION" or metadata.event_type = "NETWORK_DHCP")

Utilizzare tutti gli operatori nel campo Eventi

In Ricerca, alcuni campi UDM (come principal.ip o target.file.md5) sono etichettati come ripetuti, perché possono contenere un elenco di valori o tipi di messaggi all'interno di un singolo evento. Per impostazione predefinita, i campi ripetuti vengono sempre trattati con l'operatore any (non è possibile specificare all).

Quando viene utilizzato l'operatore any, il predicato viene valutato come true se un qualsiasi valore nel campo ripetuto soddisfa la condizione. Ad esempio, se cerchi principal.ip != "1.2.3.4" e gli eventi nella ricerca includono sia principal.ip = "1.2.3.4" sia principal.ip = "5.6.7.8", viene generata una corrispondenza. In questo modo, la ricerca viene espansa per includere i risultati che corrispondono a uno qualsiasi degli operatori anziché a tutti.

Ogni elemento nel campo ripetuto viene trattato singolarmente. Se il campo ripetuto viene trovato negli eventi nella ricerca, gli eventi vengono valutati per ogni elemento nel campo. Ciò può causare un comportamento imprevisto, soprattutto quando si esegue la ricerca utilizzando l'operatore !=.

Quando viene utilizzato l'operatore any, il predicato viene valutato come true se un qualsiasi valore nel campo ripetuto soddisfa la condizione.

Utilizzare il tempo Unix epoch per i timestamp o le funzioni YARA-L per la conversione della data

I campi timestamp vengono abbinati utilizzando il tempo Unix epoch (il numero totale di secondi trascorsi da giovedì 1° gennaio 1970 00:00:00 UTC) oppure puoi utilizzare le funzioni YARA-L per la conversione della data.

Quando cerchi un timestamp specifico, il seguente (in tempo epoch) è valido:

metadata.ingested_timestamp.seconds = 1660784400

Il seguente timestamp non è valido:

metadata.ingested_timestamp = "2022-08-18T01:00:00Z"

Quando cerchi un timestamp specifico, il seguente (utilizzando una funzione YARA-L per la conversione della data) è valido:

metadata.event_type = "NETWORK_CONNECTION"
timestamp.get_date(metadata.ingested_timestamp.seconds) = "2026-03-15"

Il seguente esempio YARA-L utilizza le funzioni timestamp per verificare gli intervalli di tempo di acquisizione:

metadata.event_type = "NETWORK_CONNECTION"
$date = timestamp.get_date(metadata.ingested_timestamp.seconds)
$date > "2026-03-15" AND $date < "2026-03-17"

Come eseguire query sui dati appena acquisiti con timestamp precedenti

Non puoi cercare gli eventi appena acquisiti che hanno un timestamp precedente, a meno che tu non specifichi l'intervallo di tempo degli eventi su cui eseguire la query. Questo perché l'intervallo di tempo si basa sul timestamp dell'evento analizzato, anziché sul timestamp di acquisizione dell'evento del log non elaborato.

Per cercare gli eventi UDM per i log acquisiti con timestamp di eventi precedenti, puoi utilizzare l'opzione Tutto il tempo per cercare ed eseguire query su metadata.ingested_timestamp.

Campi esclusi dai filtri

I seguenti campi sono intenzionalmente esclusi dai filtri di ricerca:

  • metadata.id
  • metadata.product_log_id
  • *.timestamp

Sebbene questi campi contengano metadati importanti, i loro valori univoci introducono un'elevata cardinalità e varianza nelle statistiche, il che influisce negativamente sul rendimento della ricerca.

Risoluzione dei problemi

Se ricevi un messaggio di errore generico, ad esempio "Errore: si è verificato un errore durante la ricerca e non è stato possibile caricare i dati", segui questi passaggi per risolvere il problema. Se l'errore persiste, contatta il supporto clienti.

  • Connettiti a Google SecOps da una rete diversa. Ad esempio, utilizza una VM cloud per identificare eventuali problemi di rete.
  • Assicurati che le chiamate all'API Chronicle siano consentite dalla configurazione o dalla policy del firewall o del proxy della tua organizzazione.
  • Verifica che non sia configurato alcun limite di dati per le chiamate all'API di ricerca, poiché le ricerche possono restituire set di dati di grandi dimensioni.
  • Le query di ricerca possono essere eseguite in modo asincrono e potrebbero richiedere più tempo per restituire i dati. Puoi visualizzare le ricerche eseguite in precedenza nella cronologia delle ricerche e selezionarle per visualizzare i risultati in un secondo momento.

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