Best practice per la rete di ricerca UDM

Questo documento descrive le best practice consigliate da Google per eseguire ricerche utilizzando la ricerca UDM. Le ricerche UDM possono richiedere notevoli risorse di calcolo per essere completate se non sono state create con cura. Le prestazioni variano anche a seconda delle dimensioni e della complessità dei dati nell'istanza di Google Security Operations.

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

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

Cerca sempre di limitare l'intervallo di tempo al minimo necessario. Le operazioni di sicurezza di Google possono importare un'enorme quantità di dati, quindi limitare l'ampiezza di questi dati durante l'esecuzione di una ricerca può migliorare notevolmente le prestazioni della ricerca.

Quando esegui ricerche UDM, puoi utilizzare espressioni regolari:

  • Usa AND, OR e NOT.
  • Si presume AND 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: = != >= > < <=

Usare "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 si basa sul tentativo precedente):

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

Utilizzare uno o 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 possibilità di specificare all nella ricerca.

Quando si utilizza l'operatore any, il predicato viene valutato come vero se qualsiasi valore 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 viene trovato 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 dell'epoca Unix

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

Quando cerchi un timestamp specifico, quanto segue (in base all'epoca) è valido:

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 crea più "rumore" rispetto al valore nell'interfaccia di 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 formato normale congiuntivo, ma puoi utilizzare (A OR B) AND (A OR C).

Il seguente esempio genererebbe 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 in cui viene utilizzato il formato normale congiuntivo 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 formato normale congiuntivo, ma puoi utilizzare NOT A AND NOT B.

Il seguente codice non è valido:

principal.hostname = "win-server" nocase AND NOT(metadata.event_type = "PROCESS_TERMINATION" OR metadata.event_type = "USER_RESOURCE_ACCESS")

Quanto segue è valido:

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 formato normale congiuntivo, ma puoi utilizzare A AND (B OR C) AND (B OR D).

Il seguente codice 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")

Quanto segue è valido:

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")