Best practice per la ricerca
Questo documento descrive le best practice consigliate da Google per l'utilizzo della funzionalità Ricerca in Google Security Operations. Se non sono strutturate con attenzione, le ricerche possono richiedere risorse di calcolo sostanziali. Il rendimento varia anche a seconda delle dimensioni e della complessità dei dati nell'istanza Google SecOps.
Utilizza i campi UDM indicizzati per la massima velocità
Il modo più efficace per migliorare le prestazioni di ricerca è creare query utilizzando campi indicizzati. Questi campi sono ottimizzati per il recupero rapido. I campi Unified Data Model (UDM) noti che vengono indicizzati sono i seguenti:
Campi principale
principal.asset.hostname
principal.asset.ip
principal.asset.mac
principal.file.md5
principal.file.sha1
principal.file.sha256
principal.hostname
principal.ip
principal.mac
principal.process.file.md5
principal.process.file.sha1
principal.process.file.sha256
principal.process.parent_process.file.md5
principal.process.parent_process.file.sha1
principal.process.parent_process.file.sha256
principal.user.email_addresses
principal.user.product_object_id
principal.user.userid
principal.user.windows_sids
Campi di origine
source.user.userid
src.asset.hostname
src.hostname
src.ip
Campi di destinazione
target.asset.hostname
target.file.md5
target.file.sha1
target.file.sha256
target.hostname
target.ip
target.process.file.md5
target.process.file.sha1
target.process.file.sha256
target.user.email_addresses
target.user.product_object_id
target.user.userid
target.user.windows_sid
Campi aggiuntivi
about.file.md5
about.file.sha1
about.file.sha256
intermediary.hostname
intermediary.ip
network.dns.questions.name
network.email.from
network.email.to
observer.hostname
observer.ip
Creare query di ricerca efficaci per il rendimento
Scrivere query ottimizzate è fondamentale per massimizzare la velocità e ridurre al minimo il consumo di risorse nei dati di sicurezza. Tutte le condizioni della query devono rispettare rigorosamente questa struttura fondamentale:
udm-field operator value
Ad esempio:
principal.hostname = "win-server"
Restringere l'intervallo di tempo per la ricerca
Poiché Google SecOps può importare una grande quantità di dati durante una ricerca, devi ridurre al minimo l'intervallo di tempo della query per restringere l'ambito e migliorare le prestazioni di ricerca.
Utilizzare espressioni regolari nella query di ricerca
Puoi utilizzare gli operatori logici e di confronto standard quando crei le query di ricerca UDM per creare espressioni complesse:
- Operatori logici:utilizza
AND
,OR
eNOT
per combinare le condizioni.AND
viene presupposto se ometti un operatore tra due condizioni. - Precedenza degli operatori: utilizza le parentesi () per ignorare l'ordine di precedenza predefinito. Esiste un limite massimo
di 169 operatori logici (
OR
,AND
,NOT
) che puoi utilizzare tra parentesi. - Operatori di confronto: a seconda del tipo di campo UDM (stringa, numero intero, timestamp), gli operatori di campo possono includere:
=
,!=
,>=
,>
,<
,<=
In alternativa, per una ricerca efficiente di un ampio insieme di valori, puoi utilizzare gli elenchi di riferimento.
Utilizzare nocase
come modificatore di ricerca
Puoi aggiungere il modificatore nocase
a una condizione di confronto di stringhe per rendere la ricerca senza distinzione tra maiuscole e minuscole, che ignora le lettere maiuscole.
Ad esempio, la seguente ricerca non è valida:
target.user.userid = "TIM.SMITH" nocase
Evita di utilizzare espressioni regolari nei campi enumerati
Non puoi utilizzare espressioni regolari quando cerchi campi enumerati (campi con un intervallo di valori predefiniti) come metadata.event_type
o network.ip_protocol
.
Il seguente esempio è una ricerca non valida:
metadata.event_type = /NETWORK_*/
Il seguente esempio, invece, è una ricerca valida:
(metadata.event_type = "NETWORK_CONNECTION"
o metadata.event_type = "NETWORK_DHCP")
Utilizza tutti gli operatori nel campo Eventi
In Ricerca, alcuni campi UDM (come principal.ip
o target.file.md5
) sono etichettati come ripetuti, perché possono contenere un elenco di valori o tipi di messaggio all'interno di un singolo evento. I campi ripetuti vengono sempre
trattati con l'operatore any
per impostazione predefinita (non è possibile specificare all
).
Quando viene utilizzato l'operatore any
, il predicato viene valutato come true
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"
, viene generata una corrispondenza. In questo modo, la ricerca viene ampliata per includere i risultati che corrispondono a uno qualsiasi degli operatori anziché a tutti.
Ogni elemento nel campo ripetuto viene trattato singolarmente. Se il campo ripetuto
viene trovato negli eventi nella ricerca, gli eventi vengono valutati per ogni
elemento nel campo. Ciò può causare un comportamento imprevisto, soprattutto quando
si esegue la ricerca utilizzando l'operatore !=
.
Quando si utilizza l'operatore any
, il predicato viene valutato come true
se un valore
nel campo ripetuto soddisfa la condizione.
Utilizza l'ora Unix epoch per i timestamp
I campi timestamp vengono abbinati utilizzando l'ora Unix (il numero totale di secondi trascorsi da giovedì 1° gennaio 1970 alle ore 00:00:00 UTC).
Quando cerchi un timestamp specifico, è valido quanto segue (in tempo epoch):
metadata.ingested_timestamp.seconds = 1660784400
Il seguente timestamp non è valido:
metadata.ingested_timestamp = "2022-08-18T01:00:00Z"
Escludere i campi dai filtri
I seguenti campi sono intenzionalmente esclusi dai filtri di ricerca. Sebbene contengano metadati cruciali, i loro valori altamente unici possono introdurre dettagli di ricerca non necessari e ridurre l'efficienza e l'efficacia complessive del motore di query:
metadata.id
metadata.product_log_id
*.timestamp
Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.