Best practice per la ricerca UDM

Supportato in:

Questo documento descrive le best practice consigliate da Google per condurre ricerche con la ricerca UDM. Le ricerche UDM possono richiedere le risorse di calcolo da completare se non sono costruite con cura. 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 limitare l'intervallo di tempo al minimo necessario. Google Security Operations può importare un'enorme quantità di dati, limitando così l'ampiezza di questi dati durante una ricerca può migliorare notevolmente la ricerca le prestazioni dei dispositivi.

Quando esegui ricerche UDM, puoi utilizzare espressioni regolari:

  • 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 elenchi di riferimento.

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 si avvicina al tentativo effettuato 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 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.

Quando viene utilizzato l'operatore any, il predicato viene valutato come vero se c'è 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" e principal.ip = "5.6.7.8", la ricerca generano corrispondenze. In questo modo la ricerca si espande in modo da includere i risultati che corrispondono a uno qualsiasi di gli operatori anziché trovare la corrispondenza con tutti.

Ogni elemento del campo ripetuto viene trattato singolarmente. Se il campo ripetuto viene trovato negli eventi della ricerca, questi 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 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 dal giorno 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 seguenti:

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

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