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.

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

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

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.

Quando esegui ricerche UDM puoi utilizzare espressioni regolari:

  • Utilizza AND, OR e NOT.
  • 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")