Best practice per la ricerca UDM

Supportato in:

Questo documento descrive le best practice consigliate da Google per eseguire ricerche utilizzando Ricerca UDM. Le ricerche UDM possono richiedere risorse di calcolo considerevoli per essere completate se non vengono costruite con attenzione. Le prestazioni variano anche in base alle dimensioni e alla complessità dei dati nell'istanza Google Security Operations.

Ogni condizione deve avere il formato udm-field operator value.

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

Cerca sempre di restringere l'intervallo di tempo al minimo necessario. Google Security Operations può importare una quantità enorme di dati, quindi limitare l'ampiezza di questi dati durante una ricerca può migliorare notevolmente le prestazioni di ricerca.

Puoi utilizzare le espressioni regolari per eseguire ricerche UDM:

  • Utilizza AND, OR e NOT.
  • AND viene assunto in assenza degli altri operatori.
  • Utilizza le parentesi per modificare l'ordine di precedenza. Esiste 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 anche gli elenchi di riferimento.

Utilizzare nocase come modificatore di ricerca

nocase può essere utilizzato come modificatore per ignorare le maiuscole.

Ad esempio, la seguente ricerca non è valida:

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

Le espressioni regolari non funzionano 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.

Ad esempio, la seguente ricerca non è valida:

metadata.eventtype = /NETWORK*/

Tuttavia, la seguente ricerca è valida (e approssimativa a quanto provato sopra):

(metadata.event_type = "NETWORK_CONNECTION" or metadata.event_type = "NETWORK_DHCP")

Utilizzo di tutti gli operatori nel campo Eventi

Nella ricerca UDM, alcuni campi sono etichettati come ripetuti, il che significa che si tratta di elenchi di valori o di altri tipi di messaggi. A differenza di YARA-L, i campi ripetuti nella ricerca UDM vengono sempre trattati con l'operatore any per impostazione predefinita, senza alcuna opzione per specificare any nella ricerca.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", la ricerca genererà corrispondenze. In questo modo, la ricerca viene ampliata in modo da includere i risultati che corrispondono a uno qualsiasi degli operatori anziché a tutti.

Ogni elemento del 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, in particolare quando esegui ricerche utilizzando l'operatore !=.

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

I timestamp utilizzano l'ora dell'epoca di Unix

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

Quando cerchi un timestamp specifico, è valido quanto segue (in epoch time):

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:

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

Poiché questi campi tendono ad avere valori univoci, la loro visualizzazione genera più "rumore" che valore nell'interfaccia di ricerca UDM.