Applicare i join nella ricerca e nelle dashboard

Supportato in:

I join aiutano a 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 nel campo Ricerca e nei riquadri della dashboard di Google SecOps. Vengono illustrati i tipi di join supportati, i casi d'uso e le best practice.

Concetti principali dei join

Puoi creare un'unione collegando le origini dati utilizzando variabili segnaposto condivise o istruzioni di uguaglianza esplicite (ad esempio $e1.hostname = $e2.hostname). Quando definisci un'unione nella sezione match di una query basata sulle statistiche, devi utilizzare variabili segnaposto.

Gli esempi seguenti mostrano come collegare le origini dati utilizzando due campi con un segno di uguale (=) e una variabile segnaposto condivisa.

  • Esempio 1: join implicito utilizzando variabili segnaposto

    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: join esplicito che utilizza l'uguaglianza e i segnaposto

    $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

Gli esempi in questa sezione mostrano la sintassi utilizzata in Search.

Per impostazione predefinita, le query nella ricerca non distinguono tra maiuscole e minuscole.

Unione evento-evento

  • Un'unione evento-evento collega due eventi Universal Data Model (UDM) diversi. La seguente query di esempio 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

Event-ECG join

  • Un'unione Event-ECG collega un evento UDM a un'entità del grafico del contesto dell'entità (ECG). La seguente query di esempio 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

Datatable-event join

  • Un'unione evento-tabella di dati collega gli eventi UDM alle voci di una tabella di dati personalizzata. Ciò è utile per confrontare i dati degli eventi live con un elenco definito dall'utente, ad esempio indirizzi IP dannosi noti o autori di minacce. La seguente query di esempio unisce gli eventi NETWORK_CONNECTION a una tabella di 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

Utilizzare la clausola IN con le tabelle di dati

Puoi anche utilizzare la clausola in per verificare se un valore di campo esiste in una colonna della tabella di dati. Questa sintassi è supportata in tutte le origini dati (ad esempio ioc.type in %abc.type) e offre un modo pratico per filtrare gli eventi in base agli elenchi di riferimento senza definire variabili segnaposto esplicite per il join.

Casi d'uso comuni

Questa sezione elenca alcuni modi comuni per utilizzare i join.

Rilevare il furto e l'utilizzo di credenziali

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

Tipo di unione: evento-evento

Descrizione: questa query collega due eventi distinti che non sono sospetti di per sé, ma diventano altamente sospetti quando si verificano insieme. Viene prima cercato un evento USER_LOGIN, poi un evento FILE_DELETION. Questi sono uniti dal comune user.userid con una breve finestra temporale.

  • Query di rilevamento del furto di credenziali

    // 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 dagli asset critici

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

Tipo di 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 dell'evento unendolo al grafico del contesto delle entità (ECG). Cerca in particolare gli eventi NETWORK_CONNECTION provenienti da asset etichettati come "Critical Database Server" nel grafico delle entità.

  • Query sulle connessioni rischiose

    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

Caccia agli IOC degli autori di minacce

Obiettivo: cercare attivamente indicatori di compromissione (IoC) controllando tutte le query DNS attive rispetto a un elenco di domini noti per essere utilizzati da un attore delle minacce specifico.

Tipo di unione: unione tabella dati-evento

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

  • Query di ricerca degli IOC degli autori delle minacce

    // 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

Join nelle dashboard

Le dashboard supportano una gamma più ampia di origini dati e finestre di correlazione più lunghe rispetto alla ricerca. A differenza delle query SQL standard, YARA-L 2.0 non utilizza istruzioni JOIN esplicite. Al contrario, connette le origini dati mettendo in correlazione le variabili segnaposto condivise o utilizzando query in più fasi.

Distinzione tra maiuscole e minuscole

Le query del dashboard sono sensibili alle maiuscole. Per eseguire un'unione o una ricerca senza distinzione tra maiuscole e minuscole in una dashboard, utilizza il modificatore nocase.

Origini dati supportate

Nelle dashboard, puoi unire i dati delle combinazioni di unione supportate delle origini dati. Non tutte le combinazioni di origini dati possono essere unite in una singola query.

Ogni riferimento ai dati in una query del dashboard multiorigine deve includere il qualificatore del prefisso YARA-L (ad esempio $u1), non solo i campi uniti. In questo modo, il sistema può identificare correttamente la proprietà dei campi nelle origini dati sovrapposte.

Combinazioni di unione supportate

Le unioni ti consentono di correlare eventi UDM, contesto delle entità e tabelle di dati nelle dashboard integrate. Per mantenere le prestazioni del sistema, rivedi le combinazioni supportate e i limiti tecnici in questa sezione prima di creare le query.

  • Evento UDM a evento UDM (più eventi)
  • Evento UDM nel contesto dell'entità
  • Evento UDM in tabella di dati

  • Caso alla cronologia casi: questa combinazione è strettamente limitata a una sola origine case e a una sola origine case_history. Non puoi includere altre origini dati in questa unione.

Per informazioni su limiti e misure di protezione, consulta Limiti e vincoli tecnici.

Esempio: unione di case e case_history

Puoi correlare i metadati della richiesta con la sua attività storica unendoli in base all'ID richiesta univoco.

  • L'esempio seguente unisce le origini dati case e case_history per conteggiare il numero totale di azioni storiche per ogni richiesta ad alta priorità.

      // 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 del 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 del risultato finale.

  • La seguente query calcola il tempo medio di chiusura delle richieste (in minuti) per tutte le richieste 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))

Best practice

Per ottimizzare il rendimento delle query di unione e assicurarti che vengano elaborate in modo efficiente, segui queste best practice per filtrare gli eventi e gestire l'ambito di ricerca.

Utilizza filtri specifici per ridurre il numero di eventi

Le query di unione possono richiedere molte risorse perché combinano molti risultati.

  • I filtri ampi e generali possono causare errori nelle 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 generali con quelli più specifici per ridurre il numero totale di eventi che la query deve elaborare. Un filtro generico come target.ip != "" deve essere abbinato a filtri più specifici per migliorare le prestazioni 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 (ad esempio, da 30 giorni a una settimana).

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

Limiti e vincoli tecnici

Quando utilizzi i join in Search e nelle dashboard, si applicano le seguenti limitazioni e limiti.

Limiti di corrispondenza e query

La finestra di corrispondenza definisce il periodo di tempo specifico in cui gli eventi devono essere correlati. È diverso dall'intervallo di tempo di ricerca selezionato nell'interfaccia utente.

La ricerca è ottimizzata per le indagini in tempo reale o rapide in periodi di tempo più brevi.

Limite di query Utilizzo
Fino a 48 ore (alcune query potrebbero supportare finestre più lunghe). Correlare gli eventi in indagini rapide.

Limiti nelle dashboard

Le dashboard supportano l'analisi storica a lungo termine.

Tipo di unione Limite di query Utilizzo
UDM-to-UDM e UDM-to-Entity 31 giorni Query di telemetria ad alto volume.
Case-to-CaseHistory 90 giorni Query di monitoraggio del ciclo di vita.
Altre configurazioni supportate Fino a 365 giorni Fallback per origini non UDM o basate su metriche (ad esempio, metriche di importazione).

Limiti di origini dati e tabelle

Il numero massimo di origini dati e tabelle che puoi unire in una singola query dipende dall'utilizzo di Ricerca o dei dashboard.

Vincoli di ricerca

  • Puoi utilizzare un massimo di due eventi UDM per query.
  • Puoi utilizzare un massimo di un evento ECG per query.
  • Puoi utilizzare un massimo di due tabelle di dati per query.
  • Non puoi unire una tabella di dati direttamente a una tabella di contesto dell'entità; devi utilizzare un evento UDM come ponte intermedio (ad esempio, correlare $event.target.hostname sia a $datatable.hostname che a $asset.graph.entity.asset.hostname).

Vincoli della dashboard

Tipo di unione Numero massimo di tabelle degli eventi (UDM o tabella di dati) Numero massimo di tabelle delle entità
Multi-evento (UDM a UDM) 2 N/D
UDM to entity 2 1
UDM a tabella di dati 2 N/D
Query in più fasi 2 1

Rendimento e sistemi di protezione

Il sistema monitora le query di join complesse per il consumo eccessivo di risorse. Per proteggere le prestazioni complessive dell'ambiente, il sistema potrebbe mettere automaticamente in pausa o in quarantena le query che superano le soglie di sicurezza delle risorse.

Se una query non va a buon fine o restituisce errori che indicano che ha superato i limiti delle risorse, prova le seguenti ottimizzazioni:

  • Restringi la finestra temporale della query.
  • Aggiungi filtri più specifici per ridurre le dimensioni del set di dati prima dell'unione.
  • Semplifica le aggregazioni.

Vincoli relativi al tipo di API e di query

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