Creare query multifase in YARA-L

Supportato in:

Questo documento descrive come le query multifase in YARA-L consentono di inserire l'output di una fase della query direttamente nell'input di una fase successiva. Questo processo ti offre un maggiore controllo sulla trasformazione dei dati rispetto a una singola query monolitica.

Integrare le query multifase con le funzionalità esistenti

Le query multifase funzionano in combinazione con le seguenti funzionalità esistenti in Google Security Operations:

  • Regole di rilevamento composite: le query multifase integrano le regole di rilevamento composite colmando il divario tra il rilevamento automatico e l'indagine attiva. Mentre le regole composite eccellono nell'identificazione di correlazioni complesse tra più eventi in finestre temporali estese, le query multifase consentono agli analisti di passare da questi rilevamenti a ricerche iterative in tempo reale per convalidare e definire immediatamente l'ambito di una minaccia in evoluzione.

  • Intervalli di tempo e regole multi-evento:puoi utilizzare query in più fasi per rilevare anomalie confrontando diverse finestre temporali all'interno dei tuoi dati. Ad esempio, puoi utilizzare le query iniziali per stabilire una base di riferimento in un periodo di tempo prolungato e poi utilizzare query successive per valutare l'attività recente rispetto a questa base di riferimento. Puoi anche utilizzare le regole multi-evento per creare un tipo di confronto simile.

Le query multifase in YARA-L sono supportate sia in Dashboard sia in Ricerca.

Le unioni aiutano a correlare i dati provenienti da più fonti per fornire un contesto più ampio per un'indagine. Collegando eventi, entità e altri dati correlati, puoi analizzare scenari di attacco complessi. Per saperne di più, vedi Utilizzare i join nella ricerca.

Considerazioni principali

Quando configuri una query multifase, tieni presente quanto segue:

  • Fase limite: le query multifase devono contenere da una a quattro fasi denominate, oltre alla fase radice.
  • Sintassi dell'ordine: definisci sempre la sintassi della fase denominata prima di definire la sintassi della fase radice.

Ti consigliamo di esaminare i seguenti problemi noti e le soluzioni alternative consigliate quando implementi query multifase:

  • Tutte le query multifase si comportano come le query di ricerca delle statistiche (l'output è costituito da statistiche aggregate anziché da eventi o righe di tabelle di dati non aggregati).

  • Le prestazioni dei join con UDM e gli eventi entità su un lato possono registrare prestazioni scarse a causa delle dimensioni del set di dati. Ti consigliamo vivamente di filtrare gli eventi UDM e delle entità del lato di unione il più possibile (ad esempio, filtrare in base al tipo di evento).

Per indicazioni generali sulle pratiche consigliate, consulta le best practice per YARA-L 2.0 e per informazioni specifiche sui join, consulta le best practice.

Terminologia chiave

Nel contesto dei join, una fase in finestra si riferisce a una fase con una sezione match contenente una finestra. Al contrario, uno stage di tabella non restituisce finestre.

Creare una query YARA-L multifase

Per creare una query YARA-L in più fasi, completa i seguenti passaggi.

Struttura e sintassi delle fasi

Vai a Indagine > Ricerca. Segui questa struttura quando definisci le fasi della query:

Sintassi: utilizza la seguente sintassi per denominare ogni fase e separarla dalle altre:

stage <stage name> { }

  • Parentesi graffe: inserisci tutta la sintassi dello stage tra parentesi graffe {}.

  • Order: definisci la sintassi per tutte le fasi denominate prima di definire la fase radice.

  • Riferimento: ogni fase può fare riferimento alle fasi definite in precedenza nella query.

  • Fase principale: una query deve avere una fase principale, che viene elaborata dopo tutte le fasi denominate.

La seguente fase di esempio, daily_stats, raccoglie le statistiche di rete giornaliere:

stage daily_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $source = principal.hostname
  $target = target.ip
  $source != ""
  $target != ""
  match:
    $source, $target by day
  outcome:
    $exchanged_bytes = sum(network.sent_bytes + network.received_bytes)
}

Output della fase di accesso

L'output di una fase denominata è accessibile alle fasi successive utilizzando i campi della fase. I campi della fase corrispondono alle variabili match e outcome della fase e possono essere utilizzati in modo simile ai campi Unified Data Model (UDM).

Utilizza la seguente sintassi per accedere a un campo della fase:

$<stage name>.<variable name>

(Facoltativo) Timestamp della finestra di accesso

Se una fase denominata utilizza una finestra di salto, scorrevole o a cascata, accedi all'inizio e alla fine della finestra per ogni riga di output utilizzando questi campi riservati:

  • $<stage name>.window_start

  • $<stage name>.window_end

window_start e window_end sono campi interi espressi in secondi dall'epoca Unix. Le finestre nelle diverse fasi possono variare di dimensioni.

Esempi di query multistadio

Gli esempi in questa sezione illustrano come creare una query YARA-L completa multifase.

Esempio: cerca connessioni di rete insolitamente attive (ore)

Questo esempio YARA-L in più fasi identifica coppie di indirizzi IP con un'attività di rete superiore alla norma, prendendo di mira le coppie che mantengono un'attività elevata per più di tre ore. La query include due componenti obbligatori: lo stage denominato hourly_stats e lo stage root.

La fase hourly_stats cerca coppie principal.ip e target.ip con livelli elevati di attività di rete.

Questa fase restituisce un singolo valore orario per i seguenti campi:

  • Statistiche per l'IP di origine (stringa): $hourly_stats.src_ip

  • Statistiche per l'IP di destinazione (stringa): $hourly_stats.dst_ip

  • Statistiche per il conteggio degli eventi (numero intero): $hourly_stats.count

  • Deviazione standard dei byte ricevuti (float): $hourly_stats.std_recd_bytes

  • Byte medi ricevuti (float): $hourly_stats.avg_recd_bytes

  • Ora di inizio del bucket in secondi a partire dal tempo Unix (numero intero): $hourly_stats.window_start

  • Ora di fine del bucket in secondi a partire dall'epoca Unix (numero intero): $hourly_stats.window_end

La fase principale elabora l'output della fase hourly_stats. Calcola le statistiche per le coppie principal.ip e target.ip con attività che superano la soglia specificata da $hourly_stats. A questo punto, filtra le coppie con più di tre ore di attività elevata.


stage hourly_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $src_ip = principal.ip
  $dst_ip = target.ip
  $src_ip != ""
  $dst_ip != ""

  match:
    $src_ip, $dst_ip by hour

  outcome:
    $count = count(metadata.id)
    $avg_recd_bytes = avg(network.received_bytes)
    $std_recd_bytes = stddev(network.received_bytes)

  condition:
    $avg_recd_bytes > 100 and $std_recd_bytes > 50
}

$src_ip = $hourly_stats.src_ip
$dst_ip = $hourly_stats.dst_ip
$time_bucket_count = strings.concat(timestamp.get_timestamp($hourly_stats.window_start), "|", $hourly_stats.count)

match:
 $src_ip, $dst_ip

outcome:
 $list = array_distinct($time_bucket_count)
 $count = count_distinct($hourly_stats.window_start)

condition:
 $count > 3

Se modifichi la condizione di corrispondenza nella fase principale come segue, puoi introdurre un'aggregazione windowed in base al giorno per la query multifase.

match:
 $src_ip, $dst_ip by day

Esempio: cerca connessioni di rete insolitamente attive (utilizzando il punteggio Z)

Questa query multifase confronta l'attività di rete media giornaliera con l'attività odierna utilizzando un calcolo del punteggio Z (che misura il numero di deviazioni standard dalla media). Questa query cerca in modo efficace attività di rete insolitamente elevata tra asset interni e sistemi esterni.

Prerequisito: la finestra temporale della query deve essere maggiore o uguale a 2 giorni e includere il giorno corrente affinché lo Z-score calcolato sia efficace.

Questa query multifase include la fase daily_stats e la fase root, che lavorano insieme per calcolare lo Z-score per l'attività di rete:

  • La fase daily_stats esegue l'aggregazione giornaliera iniziale. Calcola il totale dei byte scambiati ogni giorno per ogni coppia di IP (source e target) e restituisce i seguenti campi di fase (corrispondenti alle colonne nelle righe di output):

    • $daily_stats.source: singolare, stringa
    • $daily_stats.target: singolare, stringa
    • $daily_stats.exchanged_bytes: singolare, numero intero
    • $daily_stats.window_start: singolare, numero intero
    • $daily_stats.window_end: singolare, numero intero

  • La fase principale aggrega l'output della fase daily_stats per ogni coppia di IP. Calcola la media e la deviazione standard dei byte scambiati giornalmente nell'intero intervallo di ricerca, nonché i byte scambiati oggi. Utilizza questi tre valori calcolati per determinare lo Z-score.

  • L'output elenca gli Z-score per tutte le coppie di IP di oggi, ordinati in ordine decrescente.

// Calculate the total bytes exchanged per day by source and target

stage daily_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $source = principal.hostname
  $target = target.ip
  $source != ""
  $target != ""

  match:
    $source, $target by day

  outcome:
    $exchanged_bytes = sum(network.sent_bytes + network.received_bytes)
}

// Calculate the average per day over the time window and compare with the bytes exchanged today

$source = $daily_stats.source
$target = $daily_stats.target
$date = timestamp.get_date($daily_stats.window_start)

match:
  $source, $target

outcome:
  $today_bytes = sum(if($date = timestamp.get_date(timestamp.current_seconds()), cast.as_int($daily_stats.exchanged_bytes), 0))
  $average_bytes = window.avg($daily_stats.exchanged_bytes)
  $stddev_bytes = window.stddev($daily_stats.exchanged_bytes)
  $zscore = ($today_bytes - $average_bytes) / $stddev_bytes

order:
  $zscore desc

Esportare variabili non aggregate dalle fasi

In una tipica query multifase, i dati vengono spesso trasmessi tra le fasi tramite un processo di aggregazione, che può "comprimere" più eventi in un unico riepilogo. Tuttavia, in alcuni scenari devi conservare i dettagli specifici di ogni evento, ad esempio un ID processo univoco o una riga di comando specifica, senza perdere la granularità. Per supportare questa operazione, puoi esportare le variabili direttamente senza una funzione di raggruppamento.

Le fasi denominate possono includere una sezione outcome non aggregata. Ciò significa che le variabili definite all'interno di questa sezione outcome vengono generate direttamente dalla fase, consentendo alle fasi successive di accedervi come campi della fase senza richiedere un'aggregazione raggruppata.

Questo dettaglio è utile perché:

  • Mantiene la fedeltà dei dati: puoi passare gli attributi esatti di un evento (ad esempio, un percorso file specifico) alla fase successiva senza dover utilizzare un'aggregazione "segnaposto" artificiale come max() o array_distinct().
  • Riduce la complessità delle query: semplifica la logica YARA-L rimuovendo la necessità di una sezione match o di raggruppare le istruzioni solo per trasferire un valore dalla fase 1 alla fase 2.
  • Ottimizza il rendimento: ignorando il motore di aggregazione, il sistema può trasmettere i dati tra le fasi in modo più efficiente, il che si traduce in tempi di esecuzione più rapidi per le ricerche complesse e ad alto volume.

Esempio: esportare una variabile non aggregata

Questo esempio mostra come esportare le variabili non aggregate. Tieni presente la seguente logica:

  • La fase top_5_bytes_sent cerca i cinque eventi con la maggiore attività di rete.

  • La fase top_5_bytes_sent restituisce i seguenti campi della fase corrispondenti alle colonne nelle righe di output:

    • $top_5_bytes_sent.bytes_sent: singolare, numero intero
    • $top_5_bytes_sent.timestamp_seconds: singolare, numero intero

  • La fase root calcola i timestamp più recenti e meno recenti per i cinque eventi con l'attività di rete più elevata.

stage top_5_bytes_sent {
  metadata.event_type = "NETWORK_CONNECTION"
  network.sent_bytes > 0

  outcome:
    $bytes_sent = network.sent_bytes
    $timestamp_seconds = metadata.event_timestamp.seconds

  order:
    $bytes_sent desc

  limit:
    5
}

outcome:
  $latest_timestamp = timestamp.get_timestamp(max($top_5_bytes_sent.timestamp_seconds))
  $earliest_timestamp = timestamp.get_timestamp(min($top_5_bytes_sent.timestamp_seconds))

Implementa il windowing nelle query multifase

Nei rilevamenti multifase, il raggruppamento in finestre consente di definire limiti di tempo specifici per la correlazione degli eventi all'interno di una fase. Se partizioni i dati in bucket temporali discreti, ad esempio una finestra scorrevole di 5 minuti o una finestra a cascata di 1 ora, puoi identificare pattern come attacchi di forza bruta o comportamenti di beaconing che diventano visibili solo se analizzati come sequenza con limiti di tempo.

Le query multifase supportano tutti i tipi di finestre (hop, scorrevole e sequenziale) nelle fasi denominate. In questo modo, puoi trasferire dati contestualizzati nel tempo tra le fasi, ad esempio utilizzando la fase 1 per identificare una finestra di eventi ad alta frequenza e la fase 2 per correlare questa finestra specifica con le azioni amministrative successive.

Se una fase denominata include una finestra, l'inizio e la fine della finestra per ogni riga di output sono accessibili utilizzando i seguenti campi riservati:

  • $stage_window_start: il timestamp Unix che indica l'inizio della finestra.
  • $stage_window_end: il timestamp Unix che indica la fine della finestra.

Per maggiori dettagli sul raggruppamento in finestre, consulta Logica di raggruppamento in finestre di YARA-L 2.0.

Casi d'uso comuni

  • Rilevamento sequenziale: superamento del periodo di tempo specifico di un picco rilevato di accessi non riusciti a una seconda fase che cerca un accesso riuscito poco dopo.
  • Analisi della durata: calcolo del "time-to-compromise" confrontando il $stage_window_start di una fase di exploit iniziale con i timestamp degli eventi in una fase successiva.
  • Definizione della base storica: utilizzo di finestre per confrontare i conteggi degli eventi attuali con le variabili di output di una finestra precedente.

Esempio: finestra di hop

L'esempio seguente illustra come utilizzare le finestre di hop in una query multifase:

  • hourly_stats esegue ricerche di coppie IP con un'attività di rete elevata nella stessa ora.

  • hourly_stats restituisce i seguenti campi di fase corrispondenti alle colonne nelle righe di output:

    • $hourly_stats.src_ip: singolare, stringa
    • $hourly_stats.dst_ip: singolare, stringa
    • $hourly_stats.count: singolare, numero intero
    • $hourly_stats.std_recd_bytes: singolare, float
    • $hourly_stats.avg_recd_bytes: singolare, float
    • $hourly_stats.window_start: singolare, numero intero
    • $hourly_stats.window_end: singolare, numero intero

  • Il filtro della fase radice esclude le coppie di IP con più di 3 ore di attività elevata. Le ore potrebbero sovrapporsi a causa dell'utilizzo di una finestra di hop nella fase hourly_stats.

stage hourly_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $src_ip = principal.ip
  $dst_ip = target.ip
  $src_ip != ""
  $dst_ip != ""

  match:
    $src_ip, $dst_ip over 1h

  outcome:
    $count = count(metadata.id)
    $avg_recd_bytes = avg(network.received_bytes)
    $std_recd_bytes = stddev(network.received_bytes)

  condition:
    $avg_recd_bytes > 100 and $std_recd_bytes > 50
}

$src_ip = $hourly_stats.src_ip
$dst_ip = $hourly_stats.dst_ip
$time_bucket_count = strings.concat(timestamp.get_timestamp($hourly_stats.window_start), "|", $hourly_stats.count)

match:
 $src_ip, $dst_ip

outcome:
 $list = array_distinct($time_bucket_count)
 $count = count_distinct($hourly_stats.window_start)

condition:
 $count > 3

Inner join nelle query multifase

I join interni consentono di correlare i dati in diverse fasi o tipi di origine, il che crea flussi di lavoro analitici complessi, ad esempio il confronto tra eventi in tempo reale e baseline statistiche precalcolate. Unendo le fasi, puoi arricchire la telemetria non elaborata con dati stateful (come mediane o tabelle di ricerca) per identificare outlier o minacce multi-vettore che un filtro eventi a una sola fase non rileverebbe.

I join interni sono supportati all'interno e tra le fasi delle query multifase. La funzionalità di inner join supporta i seguenti tipi:

  • UDM e UDM: correlazione di due diversi insiemi di eventi di sicurezza (ad esempio, corrispondenza di un evento di accesso con un successivo accesso ai file).
  • UDM ed ECG: unione dei dati sugli eventi con le informazioni di Entity Context Graph per l'arricchimento di identità o asset.
  • UDM e tabella di dati: unione di eventi live con elenchi di riferimento statici o caricati (ad esempio, un elenco di asset di alto valore o intervalli IP specifici per reparto).

L'esempio seguente mostra come configurare un'unione senza corrispondenza (un'unione eseguita nella sezione outcome o events anziché nella sezione match) tra gli eventi UDM e una fase della tabella calcolata. Questo pattern consente di eseguire il rilevamento statistico delle anomalie, come mostrato nel seguente calcolo della deviazione assoluta media (MAD):

  • median fase: calcola i byte inviati mediani per ogni coppia di host di origine e IP di destinazione.
    • $median.host: singolare, stringa
    • $median.target: singolare, stringa
    • $median.median: singolare, float
  • absolute_deviations: unisce ogni evento UDM alla riga corrispondente della fase mediana. In questo modo puoi calcolare la deviazione assoluta dei byte inviati per ogni singolo evento rispetto al suo gruppo di peer.
    • $absolute_deviations.host: singolare, stringa
    • $absolute_deviations.target: singolare, stringa
    • $absolute_deviations.absolute_deviation: singolare, float
  • Fase principale: calcola la media di queste deviazioni assolute in tutti gli eventi UDM per stabilire una soglia di anomalia.

Esempio: configurare un'unione senza corrispondenze

stage median {
  metadata.event_type = "NETWORK_CONNECTION"
  $host = principal.hostname
  $target = target.ip

  match:
    $host, $target

  outcome:
    $median = window.median(network.sent_bytes, true)
}

stage absolute_deviations {
  metadata.event_type = "NETWORK_CONNECTION"
  $join_host = principal.hostname
  $join_host = $median.host
  $join_target = target.ip[0]
  $join_target = $median.target

  outcome:
    $host = $join_host
    $target = $join_target
    $absolute_deviation = math.abs(network.sent_bytes - $median.median)
}

$host = $absolute_deviations.host
$target = $absolute_deviations.target

match:
  $host, $target

outcome:
  $mean_absolute_deviation = avg($absolute_deviations.absolute_deviation)

Esempio: unione senza corrispondenze tra la fase della finestra e la fase della tabella

L'esempio seguente illustra come configurare un'unione senza corrispondenze tra una fase con finestre e una fase di tabella in una query multifase.

  • La fase hourly_stats calcola il totale dei byte inviati per ogni coppia di host di origine e di destinazione e per ogni bucket orario.
  • La fase hourly_stats restituisce i seguenti campi della fase corrispondenti alle colonne nelle righe di output:
    • $hourly_stats.source_host: singolare, stringa
    • $hourly_stats.dst_host: singolare, stringa
    • $hourly_stats.total_bytes_sent: singolare, float
    • $hourly_stats.window_start: singolare, numero intero
    • $hourly_stats.window_end: singolare, numero intero
  • agg_stats calcola la media e la deviazione standard dei byte all'ora per ogni coppia di host di origine e di destinazione.

  • agg_stats restituisce i seguenti campi di fase corrispondenti alle colonne nelle righe di output:

    • $agg_stats.source_host: singolare, stringa
    • $agg_stats.dst_host: singolare, stringa
    • $agg_stats.avg_bytes_sent: singolare, float
    • $agg_stats.stddev_bytes_sent: singolare, float

  • La fase principale unisce ogni riga di hourly_stats alla riga di agg_stats per la stessa coppia di host di origine e di destinazione. Per ogni coppia di host di origine e di destinazione, calcola lo z-score utilizzando i byte totali inviati per il bucket della coppia di host e le statistiche aggregate.

stage hourly_stats {
 $source_host = principal.hostname
 $dst_host = target.hostname
 principal.hostname != ""
 target.hostname != ""
 match:
   $source_host, $dst_host by hour
 outcome:
   $total_bytes_sent = sum(network.sent_bytes)
}

stage agg_stats {
  $source_host = $hourly_stats.source_host
  $dst_host = $hourly_stats.dst_host
  match:
    $source_host, $dst_host
  outcome:
   $avg_bytes_sent = avg($hourly_stats.total_bytes_sent)
   $stddev_bytes_sent = stddev($hourly_stats.total_bytes_sent)
}

$source_host = $agg_stats.source_host
$source_host = $hourly_stats.source_host

$dst_host = $agg_stats.dst_host
$dst_host = $hourly_stats.dst_host

outcome:
  $hour_bucket = timestamp.get_timestamp($hourly_stats.window_start)
  $z_score = ($hourly_stats.total_bytes_sent - $agg_stats.avg_bytes_sent)/$agg_stats.stddev_bytes_sent

Cross join nelle query multifase

Quando utilizzi la ricerca o i dashboard di Google SecOps, i cross join nelle query multifase ti consentono di confrontare i singoli dati degli eventi UDM con le statistiche aggregate calcolate in altre fasi YARA-L.

In YARA-L, la parola chiave cross join funziona con una fase che restituisce una sola riga.

Quando viene utilizzato un cross join tra una fase con un limite di 1 e un altro set di dati (ad esempio, eventi UDM), la singola riga di output della fase viene aggiunta a ogni riga dell'altro set di dati. In questo modo, i dati sugli eventi vengono arricchiti con le statistiche complessive.

Esempio: trovare attività di accesso insolite

Il seguente esempio identifica gli utenti che accedono più spesso del normale. Per calcolarlo, confronta il numero di accessi di ogni utente (utilizzando la fase user_login_counts) con il numero medio di accessi di tutti gli utenti (utilizzando la fase total_users). Gli utenti che accedono un numero insolito di volte possono essere ordinati nei risultati di ricerca.

Successivamente, utilizzi la parola chiave cross join per collegare i risultati della fase total_users a quelli della fase user_login_counts.

stage user_login_counts {
    $user = principal.user.userid
    metadata.event_type = "USER_LOGIN"
    security_result.action = "ALLOW"

    match:
        $user

    outcome:
        $login_count = count(metadata.id)
}

stage total_users {
    outcome:
        $count = count($user_login_counts.user)
    limit:
        1
}

cross join $total_users, $user_login_counts

$login_count = $user_login_counts.login_count
$user = $user_login_counts.user
$tot_users = $total_users.count

// all users who logged in the same number of times are grouped together.
match:
    $login_count
outcome:
    $num_users = count($user)
    $frequency_percent = (count($user) / max($tot_users) ) * 100

Limitazioni

Le query multifase presentano i seguenti vincoli funzionali e strutturali:

Requisiti strutturali

Quando crei le query, devi rispettare i seguenti requisiti strutturali:

  • Fase principale: è consentita una sola fase principale per query.
  • Fasi denominate: sono supportate al massimo quattro fasi denominate.
  • Riferimento allo stage: uno stage può fare riferimento solo agli stage definiti logicamente prima di esso nella stessa query.
  • Cross join: un cross join può fare riferimento solo a una fase che restituisce una singola riga. Per soddisfare questo requisito, devi includere un limite (1) nella fase a cui viene fatto riferimento. Ciò è utile perché ti consente di aggiungere una singola statistica globale (ad esempio un valore massimo o medio) a ogni riga di evento individuale per il confronto.
  • Join: sono consentiti un massimo di quattro join non di tabelle di dati in tutte le fasi.
  • Requisito di risultato: ogni fase denominata (esclusa la fase principale) deve includere una sezione match o una sezione outcome in cui la sezione outcome non richiede l'aggregazione.

Limiti di finestre e compatibilità

Le seguenti limitazioni si applicano alla modalità di utilizzo delle finestre e alla posizione in cui esegui le query:

  • Supporto delle funzionalità: le query multifase funzionano nella ricerca e nei dashboard, ma la funzionalità non è supportata nelle regole.
  • Tipi di finestre: evita di combinare diversi tipi di finestre in una singola query.
  • Dipendenza dalla finestra: uno stage che utilizza una finestra di salto o scorrevole non può dipendere da un altro stage che utilizza anch'esso una finestra di salto o scorrevole.
  • Dimensioni della finestra a cascata: sebbene le finestre a cascata nelle diverse fasi possano variare di dimensioni, la differenza di dimensioni deve essere inferiore a 720x.

Esempio: Differenza di aggregazione della fase (non valida)

La seguente configurazione non è valida perché un mese contiene 44.640 minuti (44.640 / 1 > 720):

Fase: monthly_stats { ... match: by month }

Root: match: by minute

Esempio: Differenza di aggregazione della fase (valida)

Per risolvere il problema, assicurati che il rapporto tra le fasi sia inferiore. Ad esempio, aggrega i dati orari in un report giornaliero:

Fase: daily_stats { ... match: by day }

Root: match: by hour

Poiché 24 (ore in un giorno) è inferiore a 720, il sistema può mappare in modo efficiente i dati dello stato allo stato principale.

Limitazioni di fase e query

Ogni singola fase all'interno di una query multifase ha vincoli specifici. La maggior parte delle limitazioni che si applicano a una query a una sola fase si applicano anche a ogni singola fase:

  • Requisito di output: ogni fase deve restituire almeno una variabile di corrispondenza o risultato (campo della fase).

  • Intervallo di tempo della query:

    • Query standard: il massimo è 30 giorni.
    • Query multifase con join senza corrispondenze: il massimo è limitato a 14 giorni.

  • Limiti delle dimensioni della finestra: le dimensioni massime della finestra (hop, scorrevole o tumbling) dipendono dal fatto che la query includa un'unione:

    • Con join: la dimensione massima della finestra per qualsiasi tipo (hop, scorrevole o cumulativa) è di 2 giorni. Per maggiori dettagli, vedi Limitazioni delle unioni di ricerca.

    • Senza join (singolo evento):

    • Finestre di hop e scorrevoli: il massimo è 2 giorni.

    • Finestre temporali: l'aumento massimo è di 30 giorni.

  • Variabili di risultato massime:

    • 20 per impostazione predefinita
    • 50 per i clienti che hanno attivato il limite più elevato
    • Limiti degli array: in una variabile di risultato con valori di array sono consentiti al massimo 10.000 elementi.

  • Vincoli degli eventi per query:

    • Massimo due eventi UDM
    • Massimo un evento ECG
    • Massimo due tabelle di dati

Limiti di servizio e prestazioni

Le query multifase sono soggette alle stesse limitazioni delle query statistiche:

  • Query statistiche: 120 QPH (API e UI).
  • Visualizzazioni della ricerca: 100 visualizzazioni al minuto.
  • Supporto API: il sistema Google SecOps e l'API EventService.UDMSearch supportano i join in più fasi, ma l'API SearchService.UDMSearch no. Il sistema consente inoltre di eseguire query multifase senza join.

Limitazioni a livello di evento e globali

Devi rispettare i seguenti limiti a livello di evento e di piattaforma:

Numero massimo di eventi

Le query multifase limitano rigorosamente il numero di eventi che possono elaborare contemporaneamente:

  • Eventi UDM: sono consentiti al massimo due eventi UDM.
  • Eventi Entity Context Graph (ECG): è consentito un massimo di un evento ECG.

Limitazioni delle query globali

Questi vincoli a livello di piattaforma controllano quanto indietro nel tempo e quanti dati restituisce una query multifase:

  • Intervallo di tempo della query: l'intervallo di tempo massimo per una query standard è 30 giorni.
  • Set di risultati totale: la dimensione massima del set di risultati totale è di 10.000 risultati.

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