Best practice per la ricerca UDM
Questo documento descrive le best practice consigliate da Google per effettuare ricerche con la Ricerca UDM. Le ricerche UDM possono richiedere notevoli risorse di calcolo per il completamento se non sono create con attenzione. Le prestazioni variano anche a seconda delle dimensioni e della complessità dei dati nell'istanza Chronicle.
Costruzione di base di una ricerca UDM
Ogni condizione deve essere nel formato udm-field operator value
.
Ad esempio:
principal.hostname = "win-server"
Ottimizzare l'intervallo di tempo per la ricerca UDM
Cerca sempre di restringere l'intervallo di tempo al minimo necessario. Chronicle può importare un'enorme quantità di dati, quindi limitare la portata di questi dati durante l'esecuzione di una ricerca può migliorare notevolmente le prestazioni della ricerca.
Utilizzo di espressioni regolari con la ricerca UDM
Quando esegui ricerche UDM puoi utilizzare espressioni regolari:
- Utilizza
AND
,OR
eNOT
. AND
viene usato in assenza degli altri operatori.- Utilizza le parentesi per modificare l'ordine di precedenza.
- A seconda del tipo di campo, gli operatori di campo possono includere:
= != >= > < <=
Utilizzare nocase come modificatore di ricerca
nocase
può essere utilizzato come modificatore per ignorare le lettere 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 rispecchia quanto suggerito sopra):
(metadata.event_type = "NETWORK_CONNECTION" or metadata.event_type = "NETWORK_DHCP")
Utilizzare 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 la possibilità di specificare all
nella ricerca.
Quando viene utilizzato l'operatore any
, il predicato viene valutato come vero 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"
, la ricerca genererà corrispondenze. In questo modo la ricerca viene espansa in modo da includere i risultati che corrispondono a uno qualsiasi degli operatori, anziché corrispondere a tutti gli operatori.
Ogni elemento nel campo ripetuto viene trattato singolarmente. Se il campo ripetuto si trova negli eventi della ricerca, gli eventi vengono valutati per ogni elemento del campo. Ciò può causare comportamenti imprevisti, soprattutto durante la ricerca con l'operatore !=
.
Quando utilizzi l'operatore any
, il predicato viene valutato come vero se qualsiasi valore nel campo ripetuto soddisfa la condizione.
I timestamp utilizzano il tempo epoch di Unix
I campi timestamp vengono abbinati utilizzando il tempo epoch Unix (numero di secondi trascorsi da giovedì 1 gennaio 1970 alle 00:00:00).
Quando cerchi un timestamp specifico, quanto segue (nel periodo dell'epoca) è valido:
metadata.ingested_timestamp.seconds = 1660784400
Il seguente timestamp non è valido:
metadata.ingested_timestamp = "2022-08-18T01:00:00Z"
Alcuni campi vengono esclusi dai filtri, tra cui:
metadata.id
metadata.product_log_id
*.timestamp
Poiché questi campi tendono ad avere valori univoci, la loro visualizzazione crea più "rumore" che valore nell'interfaccia della Ricerca UDM.
Forma normale congiuntiva
La ricerca UDM utilizza la forma normale congiuntiva, un approccio alla logica booleana che esprime le formule come congiunzioni di clausole con AND oppure OR. Ogni clausola collegata da una congiunzione (AND), deve essere un valore letterale o contenere una disgiunzione (OR).
Ad esempio:
(A OR B) AND (C OR D)
(A OR B) AND (NOT C OR B)
Le clausole possono anche essere valori letterali:
A OR B
A AND B
Non puoi utilizzare A OR (B AND C)
in forma congiuntiva normale, ma puoi usare (A OR B) AND (A OR C)
.
L'esempio seguente genererà un errore nella Ricerca UDM:
principal.hostname = "win-server" nocase OR (principal.hostname = "win-adfs" nocase AND metadata.event_type = "NETWORK_CONNECTION")
Di seguito è riportato un esempio valido che utilizza la forma normale congiuntiva in una ricerca UDM:
(principal.hostname = "win-server" nocase OR principal.hostname = "win-adfs" nocase) AND (principal.hostname = "win-server" nocase OR metadata.event_type = "NETWORK_CONNECTION")
Non puoi utilizzare NOT (A OR B)
in forma congiuntiva normale, ma puoi usare NOT A AND NOT B
.
Quanto segue non è valido:
principal.hostname = "win-server" nocase AND NOT(metadata.event_type = "PROCESS_TERMINATION" OR metadata.event_type = "USER_RESOURCE_ACCESS")
È valido quanto segue:
principal.hostname = "win-server" nocase AND NOT metadata.event_type = "PROCESS_TERMINATION" AND NOT metadata.event_type = "USER_RESOURCE_ACCESS"
Non puoi utilizzare A AND (B OR (C AND D))
in forma congiuntiva normale, ma puoi usare A AND (B OR C) AND (B OR D)
.
Quanto segue non è valido:
principal.hostname = "win-server" nocase AND (metadata.event_type = "PROCESS_LAUNCH" OR (metadata.event_type = "NETWORK_CONNECTION" AND target.ip = "10.128.0.21")
È valido quanto segue:
principal.hostname = "win-server" nocase AND (metadata.event_type = "PROCESS_LAUNCH" OR metadata.event_type = "NETWORK_CONNECTION") AND (metadata.event_type = "PROCESS_LAUNCH" OR target.ip = "10.128.0.21")