Best practice per la ricerca

Supportata in:

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

Utilizza filtri specifici nelle query per ottenere la massima velocità e prestazioni ottimali

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

Le sezioni seguenti elencano i campi UDM ad alte prestazioni da utilizzare come filtri nelle query.

Campi dei metadati

  • metadata.event_timestamp.seconds
  • metadata.event_type
  • metadata.log_type
  • metadata.product_event_type
  • metadata.product_name
  • metadata.vendor_name

Campi Principal

  • principal.application
  • principal.asset_id
  • 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.pid
  • principal.user.email_addresses
  • principal.user.userid

Campi di origine

  • src.asset_id
  • src.hostname
  • src.ip
  • src.mac
  • src.user.userid

Campi di destinazione

  • target.application
  • target.asset_id
  • target.file.md5
  • target.file.sha1
  • target.file.sha256
  • target.hostname
  • target.ip
  • target.mac
  • target.process.file.md5
  • target.process.file.sha1
  • target.process.file.sha256
  • target.user.email_addresses
  • target.user.employee_id
  • target.user.userid
  • target.user.windows_sid

Campi di rete

  • network.dhcp.chaddr
  • network.dhcp.ciaddr
  • network.dhcp.client_hostname
  • network.dhcp.yiaddr
  • network.dns.answers.class
  • network.dns.answers.name
  • network.dns.answers.type
  • network.dns.questions.class
  • network.dns.questions.name
  • network.dns.questions.type
  • network.email.from
  • network.email.to
  • network.http.method

Campi dei risultati di sicurezza

  • security_result.action
  • security_result.category
  • security_result.rule_name

Come eseguire query sui dati di entità e contesto

Se cerchi tipi di log di entità o contesto (come 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 dei log non elaborati. Questo perché la ricerca UDM esegue query solo sui record degli eventi UDM.

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

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

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

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

    graph.entity.user.email_addresses = "foo_email"

Per saperne di più, consulta Esegui una ricerca dei dati di contesto delle entità.

Crea query di ricerca efficaci per le prestazioni

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

udm-field operator value

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

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

Utilizza le espressioni regolari nella query di ricerca

Puoi utilizzare operatori logici e di confronto standard durante la creazione delle 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 ignorare l'ordine di precedenza predefinito. Esiste un limite massimo di 169 operatori logici (OR, AND, NOT) che puoi utilizzare tra 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 eseguire ricerche efficienti in un ampio insieme di valori, puoi utilizzare gli elenchi di riferimento.

Utilizza nocase come modificatore di ricerca

Puoi aggiungere il modificatore nocase a una condizione di confronto delle stringhe per fare in modo che la ricerca non faccia distinzione tra maiuscole e minuscole, ignorando le lettere maiuscole.

Ad esempio, la seguente ricerca ignora le maiuscole e minuscole e trova tutte le combinazioni che contengono tim.smith indipendentemente dalle maiuscole e minuscole:

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

Evita di utilizzare espressioni regolari nei campi enumerati

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

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

Invece, il seguente esempio è una ricerca valida: (metadata.event_type = "NETWORK_CONNECTION" o metadata.event_type = "NETWORK_DHCP")

Utilizza 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. I campi ripetuti vengono sempre trattati con l'operatore any per impostazione predefinita (non è possibile specificare all).

Quando viene utilizzato l'operatore any, il predicato viene valutato come true se un valore qualsiasi 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 ampliata 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 della ricerca, gli eventi vengono valutati per ogni elemento del campo. Ciò può causare un comportamento imprevisto, soprattutto quando esegui ricerche utilizzando l'operatore !=.

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

Utilizza l'epoca di Unix per i timestamp o le funzioni YARA-L per la conversione delle date

I campi del timestamp vengono abbinati utilizzando l'epoca di Unix (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, è valido quanto segue (in tempo epoch):

metadata.ingested_timestamp.seconds = 1660784400

Il seguente timestamp non è valido:

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

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

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

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

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 importati con timestamp meno recenti

Non puoi cercare eventi appena importati con un timestamp precedente, a meno che 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 importazione dell'evento di log non elaborato.

Per cercare eventi UDM per i log importati con timestamp degli eventi meno recenti, puoi utilizzare l'opzione Sempre 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 sulle prestazioni di ricerca.

Risoluzione dei problemi

Se ricevi un messaggio di errore generico, ad esempio "Errore: la ricerca ha riscontrato un errore 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 un'altra rete. Ad esempio, utilizza una VM cloud per identificare eventuali problemi di rete.
  • Assicurati che le chiamate API di 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 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 della Ricerca 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.