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. Se non sono costruite con attenzione, le ricerche possono richiedere risorse di calcolo sostanziali. Il rendimento varia anche a seconda delle dimensioni e della complessità dei dati nell'istanza Google SecOps.

Creare query di ricerca efficaci

Ogni condizione deve essere nel formato udm-field operator value.

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

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

Utilizzare espressioni regolari nella query di ricerca

Puoi utilizzare le espressioni regolari durante la ricerca dei dati:

  • Utilizza AND, OR e NOT.
  • AND viene presupposto in assenza degli altri operatori.
  • Utilizza le parentesi per modificare l'ordine di precedenza. È previsto un limite massimo di 169 operatori logici (OR, AND e NOT) che possono essere utilizzati tra parentesi.
  • A seconda del tipo di campo, gli operatori di campo possono includere: = != >= > < <=

In alternativa, puoi utilizzare gli elenchi di riferimenti.

Utilizzare nocase come modificatore di ricerca

nocase può essere utilizzato come modificatore per ignorare la distinzione tra maiuscole e minuscole.

Ad esempio, la seguente ricerca non è valida:

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

Non utilizzare espressioni regolari per i campi enumerati

Non puoi utilizzare espressioni regolari per i 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.eventtype = /NETWORK*/

Il seguente esempio, invece, è una ricerca valida: (metadata.event_type = "NETWORK_CONNECTION" or metadata.event_type = "NETWORK_DHCP")

Utilizzo di tutti gli operatori nel campo Eventi

In Ricerca, alcuni campi sono etichettati come ripetuti, il che significa che contengono un elenco di valori o tipi di messaggio. 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 vero se un valore nel campo ripetuto soddisfa la condizione. Ad esempio, se cerchi principal.ip != "1.2.3.4" e gli eventi nella tua 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 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 si utilizza l'operatore any, il predicato viene valutato come true se un valore nel campo ripetuto soddisfa la condizione.

I timestamp utilizzano l'ora Unix epoch

I campi timestamp vengono abbinati utilizzando il tempo Unix (numero di secondi trascorsi da giovedì 1° gennaio 1970 alle ore 00:00:00).

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"

Alcuni campi sono esclusi dai filtri, tra cui i seguenti:

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

Poiché questi campi spesso contengono valori unici, possono aggiungere dettagli non necessari, il che potrebbe ridurre l'efficacia della ricerca.

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