Applicare i join nella ricerca e nelle dashboard

Supportato in:

Google SecOps SIEM

Nota: questa funzionalità è coperta dai Termini delle offerte pre-GA dei Termini di servizio specifici di Google Security Operations. Le funzionalità pre-GA potrebbero avere supporto limitato e le modifiche alle funzionalità pre-GA potrebbero non essere compatibili con altre versioni pre-GA. Per saperne di più, consulta le linee guida per i servizi di assistenza tecnica di Google SecOps e i Termini di servizio specifici di Google SecOps.

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 analizzare 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 join supportati, i casi d'uso e le best practice.

Creare un join

Sono supportati solo i join basati sulle statistiche. Devi definirli nella sezione match di una query.

La finestra temporale di correlazione (finestra di corrispondenza) dipende dall'utilizzo della ricerca o delle 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 join nella sezione match, devi utilizzare le variabili segnaposto.

Nota :la finestra di corrispondenza è diversa dall'intervallo di tempo di ricerca selezionato nell'interfaccia utente. L'intervallo di tempo di ricerca seleziona il blocco di dati storici da analizzare, mentre la finestra di corrispondenza definisce il periodo di tempo specifico in cui gli eventi devono essere correlati.

Le seguenti query di esempio uniscono due campi con un segno 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 join supportati

Questa sezione descrive i diversi tipi di join che puoi utilizzare. Gli esempi in questa sezione mostrano la sintassi utilizzata nella ricerca. Per informazioni sui join nelle dashboard, vedi Join nelle dashboard.

Unione evento-evento

• Un join 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 delle 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 datatable-evento collega gli eventi UDM alle voci di una datatable 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 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 generici e ampi 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 per YARA-L.

Join 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 delle seguenti origini utilizzando i rispettivi prefissi YARA-L:

Prefisso	Origine dati
case	Casi e avvisi
case_history	Tendenze dell'attività durante il ciclo di vita della richiesta
detection	Cronologia dei rilevamenti delle regole e feedback degli analisti
ingestion	Metriche di integrità relative al volume e all'importazione dei log
ioc	Corrispondenze IoC (indicatore di compromissione)
playbook	Metriche di esecuzione di playbook e risposta automatizzata
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 non distingue tra maiuscole e minuscole per impostazione predefinita, le 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.

Esempio: unione di richieste 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))
  

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 di dati per query.

• Non puoi unire eventi di tabelle di dati, UDM ed ECG in un'unica query.

• L'intervallo di tempo massimo per le query è 90 giorni.

• La finestra temporale massima di match è di 48 ore per la ricerca e 365 giorni per le dashboard.

• I join sono supportati 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 i join.

Rilevare il furto e l'utilizzo delle 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 lo diventano quando si verificano insieme. Cerca prima un evento USER_LOGIN e poi un evento FILE_DELETION. Questi sono uniti dal comune user.userid con un breve intervallo 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 dagli asset critici

Obiettivo: arricchisci 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: 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 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
  
  

Caccia agli indicatori di compromissione degli autori delle 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 intelligence sulle minacce.

• 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.