Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Utilizzare le unioni nella ricerca e nelle dashboard

Supportato in:

Google secops SIEM

Le unioni consentono di correlare i dati provenienti da più origini per fornire un contesto più ampio per un'indagine. Collegando eventi, entità e altri dati correlati, puoi esaminare scenari di attacco complessi e visualizzare le tendenze.

Questo documento spiega come utilizzare l'operazione di unione nella ricerca e nelle dashboard di Google Security Operations. Vengono inoltre trattati i tipi di unione supportati, i casi d'uso e le best practice.

Creare un'unione

Sono supportate solo le unioni basate su statistiche. Devi definirle nella sezione match di una query.

La finestra temporale di correlazione (finestra di corrispondenza) dipende dal fatto che tu stia utilizzando la ricerca o le dashboard:

Ricerca: fino a 48 ore.
Dashboard: fino a 365 giorni (per la maggior parte delle origini dati).

Puoi creare un'unione collegando direttamente i campi (ad esempio $e1.hostname = $e2.hostname) o utilizzando variabili segnaposto. Quando definisci un'unione nella sezione match, devi utilizzare le variabili segnaposto.

La query nell'esempio seguente unisce due campi con un segno di uguale (=) e una variabile segnaposto condivisa:

Esempio 1:


events:

  // Assign a value from the first event to the placeholder variable $user

  $user = $e1.principal.user.userid

  // The second assignment creates an implicit join, linking $e2 to $e1

  // where the user ID is the same.

  $user = $e2.principal.user.userid

match:

  $user over 1h

condition:

  $e1 and $e2

Esempio 2:


$e1.principal.ip = $ip

$e1.metadata.event_type = "USER_LOGIN"

$e1.principal.hostname = $host

$e2.target.ip = $ip

$e2.principal.hostname = "altostrat"

$e2.target.hostname = $host

match:
  $ip, $host over 5m

Tipi di unione supportati

Questa sezione descrive i diversi tipi di unione che puoi utilizzare. Gli esempi in questa sezione mostrano la sintassi utilizzata nella ricerca. Per informazioni sulle unioni nelle dashboard, vedi Unioni nelle dashboard.

Unione evento-evento

Un'unione evento-evento collega due eventi UDM (Universal Data Model) diversi. La query nell'esempio seguente collega un evento USER_LOGIN a un altro evento per trovare il nome host (altostrat) con cui l'utente ha interagito, in base a un indirizzo IP comune:
```
$e1.principal.ip = $ip

$e1.metadata.event_type = "USER_LOGIN"

$e2.target.ip = $ip

$e2.principal.hostname = "altostrat"

match:

  $ip over 5m
```

Unione evento-ECG

Un'unione evento-ECG collega un evento UDM a un'entità del grafico del contesto delle entità (ECG). La query nell'esempio seguente trova un evento NETWORK_CONNECTION e un ASSET dal grafico delle entità che condividono lo stesso nome host in un intervallo di 1 ora:
```
events:

  $e1.metadata.event_type = "NETWORK_CONNECTION"

  $g1.graph.metadata.entity_type = "ASSET"

  $e1.principal.asset.hostname = $g1.graph.entity.asset.hostname

  $x = $g1.graph.entity.asset.hostname

match:

  $x over 1h

condition:

  $e1 and $g1
```

Unione tabella dati-evento

Un'unione tabella dati-evento collega gli eventi UDM alle voci di una tabella dati personalizzata. Questa operazione è utile per confrontare i dati degli eventi live con un elenco definito dall'utente, ad esempio indirizzi IP dannosi noti o utenti malintenzionati. La query nell'esempio seguente unisce gli eventi NETWORK_CONNECTION a una tabella dati per trovare le connessioni che coinvolgono indirizzi IP specifici di questo elenco:
```
$ip = %DATATABLE_NAME.COLUMN_NAME

$ip = $e1.principal.ip

$e1.metadata.event_type = "NETWORK_CONNECTION"

match:

  $ip over 1h
```

Best practice

Le query di unione possono richiedere molte risorse perché combinano molti risultati. I filtri ampi e generici possono causare il mancato funzionamento delle query, a volte dopo un lungo ritardo, ad esempio:
- target.ip != ""
- metadata.event_type = "NETWORK_CONNECTION" (se questo tipo di evento è molto comune nel tuo ambiente)
Ti consigliamo di combinare i filtri generici con quelli più specifici per ridurre il numero totale di eventi che la query deve elaborare. Un filtro ampio come target.ip != "" deve essere abbinato a filtri più specifici per migliorare il rendimento della query, ad esempio:
```
$e1.metadata.log_type = $log
$e1.metadata.event_type = "USER_LOGIN"
$e1.target.ip != ""

$e2.metadata.log_type = $log
$e2.principal.ip = "10.0.0.76"
$e2.target.hostname != "altostrat"

match:
$log over 5m
```

Se la query è ancora lenta, puoi anche ridurre l'intervallo di tempo complessivo della query (ad esempio, da 30 giorni a una settimana).

Per saperne di più, consulta le best practice per YARA-L.

Unioni nelle dashboard

Le dashboard supportano una gamma più ampia di origini dati e finestre di correlazione più lunghe rispetto alla ricerca.

Origini dati supportate

Nelle dashboard, puoi unire i dati provenienti dalle seguenti origini utilizzando i rispettivi prefissi YARA-L:

Prefisso	Origine dati
`case`	Casi e avvisi
`case_history`	Tendenze delle attività durante il ciclo di vita del caso
`detection`	Cronologia dei rilevamenti delle regole e feedback degli analisti
`ingestion`	Metriche relative al volume dei log e all'integrità dell'importazione
`ioc`	Corrispondenze IoC (indicatore di compromissione)
`playbook`	Metriche relative alla risposta automatizzata e all'esecuzione dei playbook
`ruleset` / `rules`	Metadati sui set di regole attivi
`graph`	Dati del grafico delle entità (ECG)
`events`	Eventi UDM

Distinzione tra maiuscole e minuscole

A differenza della ricerca, che per impostazione predefinita non distingue tra maiuscole e minuscole, le dashboard distinguono tra maiuscole e minuscole. Per eseguire un'unione o una ricerca senza distinzione tra maiuscole e minuscole in una dashboard, utilizza il modificatore nocase.

Esempio: unire case e case_history

Puoi correlare i metadati dei casi con la relativa attività storica unendoli in base all'ID caso univoco.

La query nell'esempio seguente unisce le origini dati case e case_history per contare il numero totale di azioni storiche per ogni caso con priorità elevata.

  // 1. Establish the Join using a shared placeholder variable ($case_id)
  $h.case_history.case_response_platform_info.case_id = $case_id
  $c.case.response_platform_info.response_platform_id = $case_id

  // 2. Apply Filters
  $c.case.priority = "PRIORITY_HIGH"

  // 3. Group the correlated data by the Case ID
  match:
    $case_id

  // 4. Calculate the selected metrics to display on the dashboard
  outcome:
    $case_name = array_distinct($c.case.display_name)
    $total_historical_actions = count($h.case_history.case_activity)

Caso d'uso avanzato: calcolo dell'MTTR

Per metriche più complesse come il tempo medio di risoluzione (MTTR) o il tempo medio di chiusura (MTTC), puoi utilizzare una query in più fasi. In questo modo, puoi calcolare la durata di ogni singolo caso nella prima fase e poi calcolare la media di queste durate a livello globale nel blocco dei risultati finali.

La query seguente calcola il tempo medio di chiusura dei casi (in minuti) in tutti i casi nell'"Ambiente predefinito".

stage stage1 {
  // 1. Establish the Join
  $h.case_history.case_response_platform_info.case_id = $case_id
  $c.case.response_platform_info.response_platform_id = $case_id

  // 2. Filter by specific environment
  $c.case.environment = "Default Environment"

  // 3. Group by Case ID to process per case
  match:
    $case_id

  // 4. Calculate the Time to Close (TTC) for each case individually
  outcome:
    $case_close_time = max(if($h.case_history.case_activity = "CLOSE_CASE", $h.case_history.event_time.seconds, 0))
    $status = array_distinct($h.case_history.case_activity)

    // Subtract the very first event time (creation) from the close time
    $TTC = $case_close_time - min($h.case_history.event_time.seconds)

  // 5. Filter to ensure the case has a complete lifecycle
  condition:
    arrays.contains($status, "CREATE_CASE") and
    arrays.contains($status, "CLOSE_CASE")
}

// 6. Global Aggregation: Calculate the Mean (Average) across all processed cases
outcome:
  $case_count = count($stage1.case_id)
  $MTTC = (math.round(avg($stage1.TTC) / 60))

Limitazioni

Quando utilizzi le unioni, si applicano le seguenti limitazioni:

Puoi utilizzare un massimo di due eventi UDM per query nella ricerca.
Puoi utilizzare un massimo di un evento ECG per query nella ricerca.
Puoi utilizzare un massimo di due tabelle dati per query.
Non puoi unire eventi di tabelle dati, UDM ed ECG in una singola query.
L'intervallo di tempo massimo della query è di 90 giorni.
La finestra di tempo match massima è di 48 ore per la ricerca e di 365 giorni per le dashboard.
Le unioni sono supportate nell'interfaccia utente e nell'API EventService.UDMSearch, ma non nell'API SearchService.UDMSearch.

Casi d'uso comuni

Questa sezione elenca alcuni modi comuni per utilizzare le unioni.

Rilevare il furto e l'utilizzo delle credenziali

Obiettivo: trovare le istanze in cui un utente esegue l'accesso correttamente e poi elimina rapidamente un file di sistema critico. Questo potrebbe suggerire un takeover dell'account o un'attività dannosa di un insider.

Tipo di unione: unione evento-evento

Descrizione: questa query collega due eventi distinti che non sono sospetti di per sé, ma diventano molto sospetti quando si verificano insieme. Innanzitutto, cerca un evento USER_LOGIN, poi un evento FILE_DELETION. Questi vengono uniti dal user.userid comune con una breve finestra di tempo.

Query di esempio:


// Event 1: A user successfully logs in

$e1.metadata.event_type = "USER_LOGIN"

$e1.security_result.action = "ALLOW"

$e1.principal.user.userid = $user

// Event 2: The same user deletes a critical file

$e2.metadata.event_type = "FILE_DELETION"

$e2.target.file.full_path = /etc\/passwd|C:\\Windows\\System32\\/

$e2.principal.user.userid = $user

match:
  $user over 10m

condition:
  $e1 and $e2

Identificare le connessioni rischiose da asset critici

Obiettivo: arricchire i dati di rete live con le informazioni sugli asset per trovare le connessioni in uscita dai server che non devono comunicare con domini esterni a bassa prevalenza (ad esempio, un server di database di produzione).

Tipo di unione: unione evento-ECG

Descrizione: una singola connessione di rete a un dominio raro potrebbe non essere una priorità elevata. Tuttavia, questa query aumenta l'importanza di questo evento unendolo al grafico del contesto delle entità (ECG). Cerca in modo specifico gli eventi NETWORK_CONNECTION provenienti da asset etichettati come "Server di database critico" nel grafico delle entità.

Query di esempio:


events:
  $e.metadata.event_type = "NETWORK_CONNECTION"

  $e.target.domain.prevalence.day_count <= 5

  $asset.graph.metadata.entity_type = "ASSET"

  $asset.graph.entity.asset.labels.value = "Critical Database Server"

  $e.principal.asset.hostname = $asset.graph.entity.asset.hostname

  $host = $e.principal.asset.hostname

match:
  $host over 1h

condition:
  $e and $asset

Cercare gli IoC degli utenti malintenzionati

Obiettivo: cercare attivamente gli indicatori di compromissione (IoC) controllando tutte le query DNS live rispetto a un elenco di domini noti per essere utilizzati da un utente malintenzionato specifico.

Tipo di unione: unione tabella dati-evento

Descrizione: il tuo team di threat intelligence gestisce una tabella dati denominata ThreatActor_Domains che elenca i domini dannosi. Questa query unisce tutti gli eventi NETWORK_DNS_QUERY in tempo reale a questa tabella dati. Mostra immediatamente qualsiasi istanza in cui un host nella tua rete tenta di risolvere un dominio dall'elenco di threat intelligence.

Query di esempio:


// Datatable: Get the list of malicious domains

$domain = %DATATABLE_NAME.COLUMN_NAME

// Event: A DNS query is made

$e.metadata.event_type = "NETWORK_DNS"

$e.network.dns.questions.name = $domain

match:
  $domain over 5m

condition:
  $e

Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.