Utilizzo del grafico del contesto dell'entità (ECG)

Supportato in:

Google SecOps SIEM

Questo documento fornisce una panoramica del grafico del contesto delle entità (ECG), che copre le sue origini dati, la pipeline di elaborazione e le applicazioni nelle regole e nella ricerca. L'ECG è un modello dei dati delle entità di base che fornisce il contesto essenziale per il rilevamento, l'analisi e la ricerca avanzati delle minacce nelle regole di rilevamento, nella ricerca e nelle dashboard. La pipeline di elaborazione ECG (unisce) le informazioni contestuali di ogni ambiente Google SecOps.

L'ECG calcola anche le metriche di riepilogo per le entità. Questi includono la prevalenza (la frequenza con cui una specifica entità si verifica nei dati UDM rispetto ad altre entità) e first-seen-time e last-seen-time di un'entità. Identifica inoltre le principali fonti di arricchimento e gli indicatori di compromissione (IOC) come Google Threat Intelligence (GTI), Navigazione sicura, WHOIS e i dati di VirusTotal.

L'ECG utilizza gli eventi UDM per:

• Crea una visualizzazione arricchita, correlata e completa delle entità interne (asset e utenti) ed esterne (indicatori di compromissione).
• Identifica le relazioni tra queste entità.

Origini dati per l'ECG

La pipeline ECG combina i dati delle seguenti fonti:

Origine del contesto	Origine	Descrizione
Contesto entità	Fornito dal cliente	Google SecOps acquisisce direttamente dati organizzativi strutturati, come dettagli autorevoli su utenti e asset, da sistemi esterni. Queste fonti includono provider di identità (IdP), sistemi Configuration Management Database (CMDB) (come ServiceNow CMDB, Duo User Context) e sistemi di gestione di vulnerabilità.
Contesto derivato	Generato da Google SecOps	Google SecOps genera dati statistici basati sull'analisi dell'attività acquisita. Arricchisce eventi ed entità provenienti da varie origini all'interno del tuo ambiente (ad esempio Windows AD, Azure AD, Okta, Google Cloud, IAM). Ad esempio: Calcola e arricchisce ogni entità con una statistica di prevalenza che indica la sua popolarità nell'ambiente. Calcola e arricchisce entity first-seen-time e last-seen-time.
Contesto globale	Google-sourced	Le fonti globali forniscono dati di reputazione e threat intelligence interni ed esterni. Ad esempio: Importa e archivia i dati di Google Threat Intelligence. Arricchisce le entità con informazioni provenienti dagli elenchi di minacce di Navigazione sicura. Arricchisce le entità con i dati WHOIS.

Pipeline di elaborazione dei dati ECG

La pipeline di elaborazione dei dati ECG crea un profilo ricco e autorevole per ogni entità. A questo scopo, unisce il contesto di più origini (ad esempio provider di identità, database di gestione della configurazione (CMDB), feed di threat intelligence e contesto derivato) in un unico profilo di entità consolidato. L'unione degli ECG consente di:

• Aggiunta di nuove connessioni, proprietà e relazioni al grafico della conoscenza.
• Creazione e aggiornamento del contesto derivato.

Il processo complessivo prevede prima la normalizzazione degli eventi di sicurezza non elaborati in strutture UDM utilizzando l'aliasing e l'arricchimento UDM, quindi l'unione di questi dati degli eventi con varie origini contestuali per creare profili di entità avanzati.

Alias UDM e unione ECG

Innanzitutto, la pipeline di alias e arricchimento UDM acquisisce gli eventi di sicurezza non elaborati e li normalizza nelle strutture UDM.

Nota : "Unione ECG" non è la stessa cosa di "Alias UDM". Mentre l'assegnazione di alias UDM arricchisce gli eventi aggiungendo identificatori (ad esempio, mappando un indirizzo IP a un nome host all'interno di un evento), ECG unisce il contesto di più origini (come IdP, CMDB e threat intelligence) per creare un unico profilo per un'entità.

Entità temporizzate e senza tempo

L'ECG crea entità sia temporali (basate sul tempo) sia non temporali. Le entità a tempo vengono valutate negli intervalli di tempo specificati per la regola e la ricerca. Le entità senza tempo vengono valutate senza considerare l'intervallo di tempo della ricerca o della regola.

chiavi di unione ECG

L'ECG unisce i record di contesto abbinando gli identificatori di chiavi comuni tra diverse origini dati. Esempi di questi identificatori includono hostname, MAC address, user ID o email address. L'ECG unisce i record che corrispondono a uno qualsiasi di questi valori per creare una visione completa e arricchita di un'entità.

L'aliasing ECG utilizza i seguenti campi UDM come chiavi di unione:

• Asset
  • entity.asset.product_object_id
  • entity.asset.hostname
  • entity.asset.asset_id
  • entity.asset.mac
• User
  • entity.user.product_object_id
  • entity.user.userid
  • entity.user.windows_sid
  • entity.user.email_addresses
  • entity.user.employee_id
• Resource
  • entity.resource.product_object_id
  • entity.resource.name
• Group
  • entity.group.product_object_id
  • entity.group.email_addresses
  • entity.group.windows_sid

Unione di tipi di entità specifici (file, URL, dominio)

Oltre alle chiavi di unione, ECG unisce il contesto per tipi di entità specifici (File, URL e Dominio) utilizzando i seguenti identificatori univoci:

• File

  • entity.file.md5
  • entity.file.sha1
  • entity.file.sha256
  • (e entity.file.product_object_id, se fornito)

• URL

  • entity.url.url
  • (e entity.url.product_object_id se fornito)

• Domain

  • entity.domain.domain
  • (e entity.domain.product_object_id, se fornito)

ECG unisce un record di contesto di entità per un File, un URL o un Domain con un altro record solo se tutti gli identificatori univoci presenti in entrambi i record corrispondono.

Ad esempio, se l'ECG considera due contesti di entità File per un'unione:

• Se entrambi hanno un hash md5, l'ECG richiede che corrispondano.
• Se una ha un md5 e l'altra un sha256, l'ECG non le unirà in base all'hash.
• Se viene fornito un product_object_id, l'ECG deve corrispondere anche a questo se è presente in entrambi i record confrontati, oltre agli identificatori basati sui contenuti (come md5, url o domain).

Ciò significa che per questi tipi, i campi come entity.file.md5, entity.url.url e entity.domain.domain devono essere presenti e corrispondere per il processo di unione, oltre a qualsiasi product_object_id fornito.

Risoluzione dei conflitti

Durante il processo di unione, se i campi hanno valori in conflitto, ECG aggiorna l'entità selezionando il valore con l'ora di inizio più recente. Quando l'ECG aggiorna un attributo dell'entità con un nuovo valore, conserva il valore precedente nei risultati di ricerca per l'intervallo di tempo durante il quale era valido. Di conseguenza, una query di ricerca che copre un periodo di tempo durante il quale un attributo è cambiato può restituire più contesti di entità per quell'entità.

Deduplicazione e intervalli di tempo

Per creare un'entità combinata comune, l'ECG elimina i dati ridondanti tramite la deduplicazione. I duplicati vengono identificati in base alla corrispondenza di tutti gli identificatori univoci pertinenti per un'entità in diverse origini di contesto. Genera intervalli di tempo anziché corrispondere a timestamp esatti.

Ad esempio, considera due entità e1 e e2 con timestamp t1 e t2, rispettivamente. Se e1 e e2 sono altrimenti identici, l'ECG li deduplica ignorando le differenze di timestamp nei seguenti campi:

• collected_timestamp
• creation_timestamp
• interval

Nota: se si verificano conflitti nei campi non ripetuti, vengono utilizzati i dati dell'ultima entità.

Finestra temporale

L'ECG crea dati di contesto dell'entità con una finestra temporale di cinque giorni. Questo processo consente di gestire i dati in arrivo in ritardo e stabilisce un tempo di permanenza implicito per i dati di contesto delle entità.

L'ECG distingue tra dati contestuali (assets, users, resources, groups) e indicatori di compromissione (IOC).

Esempio: unione dei dati utente con l'unione ECG

Ad esempio, Google SecOps acquisisce i dati utente per jdoe da tre origini: Okta, Azure AD e uno scanner di vulnerabilità. L'ECG unisce questi tre record in base agli identificatori corrispondenti (ad esempio [e-mail]). In questo modo viene creata un'unica entità utente jdoe nell'ECG, contenente gli attributi di tutte e tre le origini.

Origini dati ECG critiche per entità e contesto degli eventi

Google SecOps richiede diverse origini dati specifiche per creare e aggiornare le entità.

Origini dati ECG del contesto dell'entità critica

Le origini dati autorevoli per gli utenti e gli asset del tuo ambiente forniscono i dati di log più critici per la creazione di un modello di dati delle entità. Ad esempio:

Category	Origini dati critiche	Entità compilate
Gestione di identità e accessi	Active Directory, Azure AD, Okta, Google Cloud Identity	user, group
Inventario asset	CMDB, JAMF, Microsoft Intune	asset
Threat intelligence	Feed personalizzati o di terze parti, Google Threat Intelligence (GTI)	ip_address, domain_name, file

Ricerca di esempio

Per elencare i parser che supportano ogni categoria:

1. Vai a Tipi di log supportati con un parser predefinito.

2. Digita una categoria nella barra di ricerca, ad esempio:

   • Per i parser pertinenti all'inventario di asset, digita inventory o asset.
   • Per i parser pertinenti alla gestione di identità e accessi, digita identity.
   • Per i parser pertinenti alla threat intelligence, digita IOC.

Origini dati e campi UDM critici per la profilazione delle entità

Google SecOps migliora i profili delle entità in base a origini dati autorevoli del contesto delle entità e a campi UDM critici:

Tipo di entità	Origini dati	Campi UDM critici (per l'assegnazione di alias e l'indicizzazione)
Procedura	I log degli endpoint forniscono l'ID processo specifico del prodotto (PSPI, `principal.process.product_specific_process_id`), un identificatore stabile fondamentale per l'aliasing robusto dei processi. Alcuni esempi includono CrowdStrike EDR (CS_EDR) e Windows Sysmon (WINDOWS_SYSMON).	source.process.product_specific_process_id
Utente	Queste origini forniscono attributi utente e informazioni sull'identità. Ad esempio, i dati di contesto dell'entità Duo (DUO_CONTEXT) e Okta (OKTA).	source.user.userid, source.user.email_address, source.user.windows_sid, source.user.product_object_id
Asset o endpoint	Queste fonti forniscono informazioni autorevoli sugli asset. Ad esempio, ServiceNow CMDB (SERVICENOW_CMDB) e Tanium Asset (TANIUM_ASSET).	source.ip, source.hostname, source.asset_id, principal.asset.hostname
Hash file	Fornisce un'impronta digitale univoca dei contenuti dei dati per verificarne l'integrità dei dati.	source.file.sha256, source.file.sha1, source.file.md5

Campi UDM dei dati di contesto degli eventi critici

Google SecOps richiede diversi campi UDM di dati di contesto degli eventi critici.

• I campi UDM più importanti fungono da identificatori e indicatori di relazione stabili (campi principal.*, target.*, src_* e dst_*).

• Consulta l'elenco dei campi UDM chiave appartenenti all'area delle funzionalità Entity graph.

• Per creare un ECG completo, dai la priorità alle origini dati che forniscono identificatori e dati sulle relazioni di alto valore. Ad esempio:

  Tipo di entità	Origini dati critiche	Campi UDM critici per la creazione di entità
  Asset (host)	EDR e XDR, DNS e DHCP, firewall, Google Cloud audit log della console	metadata.event_type, principal.asset.asset_id, principal.asset.hostname, principal.ip
  Utente	Log del provider di identità (IdP), feed HR (contesto), log di Cloud Identity, gateway di posta	principal.user.userid, principal.user.email_addresses, target.user.userid, principal.ip
  Rete	Log di firewall, VPN, DNS e flusso VPC	principal.ip, target.ip, src_ip, dst_ip, network.direction
  File e processo	EDR e XDR, log delle applicazioni	target.file.full_path, target.process.file.full_path, target.process.command_line

Esempio

L'ECG si basa su questi campi UDM per unire i dati di contesto delle entità e i dati degli eventi UDM in regole, ricerche e dashboard.

Ad esempio, puoi unire i dati del contesto utente in una regola di monitoraggio "brute force" per generare un avviso solo se l'utente coinvolto fa parte anche del gruppo "Amministratori di dominio" e l'asset coinvolto è un controller di dominio:

events:
  $fail.metadata.event_type = "USER_LOGIN"
  $fail.metadata.vendor_name = "Microsoft"
  $fail.principal.hostname = $hostname
  $fail.target.user.userid = $target_user
  $fail.security_result.action = "BLOCK"
  $fail.metadata.product_event_type = "4625"
 
  $fail.metadata.event_timestamp.seconds < $success.metadata.event_timestamp.seconds
 
  $success.metadata.event_type = "USER_LOGIN"
  $success.metadata.vendor_name = "Microsoft"
  $success.target.user.userid = $target_user
  $success.principal.hostname = $hostname
  $success.security_result.action = "ALLOW"
  $success.metadata.product_event_type = "4624"
  $user.graph.entity.user.userid = $target_user
  $user.graph.metadata.entity_type = "USER"
  $user.graph.metadata.source_type = "ENTITY_CONTEXT"
  any $user.graph.relations.entity.group.group_display_name = "Domain Admins"

  $asset.graph.entity.asset.hostname = $hostname
  $asset.graph.metadata.entity_type = "ASSET"
  $asset.graph.metadata.source_type = "ENTITY_CONTEXT"
  any $asset.graph.relations.entity.group.group_display_name = "Domain Controllers"
 
match:
  $target_user, $hostname over 15m
condition:
  #fail > 4 and $success and $user and $asset

Arricchimenti del contesto derivati

Google SecOps genera dati di inferenza dinamici basati sugli eventi per ogni entità in tutti gli spazi dei nomi dai dati sugli eventi della tua organizzazione. Utilizza informazioni sugli alias, dati provenienti da processi di arricchimento interni e dati sugli eventi di sicurezza per stabilire relazioni (ad esempio, un asset associato a un IP address).

Questo processo aggiunge un contesto prezioso per migliorare i profili delle entità. Alcuni esempi includono l'aggiunta di:

• Da entity.file.sha256 a file (hash) entità
• Da (principal or target).ip_geo_artifact.location.country_or_region a network (geolocation) entità

Google SecOps analizza più indicatori nell'attività inserita per arricchire gli eventi con informazioni di contesto. Esegue funzioni di arricchimento critiche per generare, ad esempio, metriche di rarità delle entità come statistiche di prevalenza e metriche temporali come first-seen-time e last-seen-time.

Statistiche sulla prevalenza

La pipeline ECG analizza i dati esistenti e in arrivo per calcolare e archiviare le metriche di prevalenza come campo contesto derivato. Queste metriche rappresentano un valore numerico di "popolarità" per entità come domain, file hash o IP address nel tuo ambiente. In questo modo puoi individuare attività rare o insolite, poiché le entità più popolari in genere comportano meno rischi.

Google SecOps aggiorna regolarmente queste statistiche e le memorizza in un contesto di entità separato. Il motore di rilevamento può utilizzare questi valori e puoi cercarli utilizzando la sintassi delle query UDM. Tuttavia, la console non mostra questi valori con altri dettagli dell'entità.

Puoi utilizzare i seguenti campi durante la creazione delle regole del motore di rilevamento.

Tipo di entità	Campi UDM
Dominio	entity.domain.prevalence.day_count entity.domain.prevalence.day_max entity.domain.prevalence.day_max_sub_domains entity.domain.prevalence.rolling_max entity.domain.prevalence.rolling_max_sub_domains
File (hash)	entity.file.prevalence.day_count entity.file.prevalence.day_max entity.file.prevalence.rolling_max
Indirizzo IP	entity.artifact.prevalence.day_count entity.artifact.prevalence.day_max entity.artifact.prevalence.rolling_max

Google SecOps calcola i valori di day_max e rolling_max in modo diverso, come segue:

• day_max rappresenta il punteggio di prevalenza massimo per l'artefatto durante il giorno (un giorno è definito dalle 00:00:00 alle 23:59:59 UTC).
• rolling_max rappresenta il punteggio di prevalenza giornaliero massimo (ovvero day_max) per l'artefatto nella finestra di 10 giorni precedente.
• day_count viene utilizzato per calcolare rolling_max e il suo valore è sempre 10.

Quando questi valori vengono calcolati per un domain, la differenza tra day_max e day_max_sub_domains (e rolling_max e rolling_max_sub_domains) è la seguente:

• rolling_max e day_max rappresentano il numero di indirizzi IP interni univoci giornalieri che accedono a un determinato dominio (esclusi i sottodomini).
• rolling_max_sub_domains e day_max_sub_domains rappresentano il numero di indirizzi IP interni univoci che accedono a un determinato dominio (sottodomini inclusi).

Google SecOps calcola le statistiche di prevalenza utilizzando i dati delle entità appena inseriti. Google SecOps non esegue calcoli retroattivi sui dati inseriti in precedenza. Sono necessarie circa 36 ore prima che Google SecOps calcoli e memorizzi le statistiche.

Attenzione: l'inclusione dell'argomento prevalence può aumentare significativamente i dati sottoposti a query, il che potrebbe causare un errore della regola. Se si verifica un errore di regola, perfeziona i parametri della regola. Ad esempio, aggiungi altri filtri o riduci l'intervallo di tempo specificato nella sezione match.

Esempio

La pipeline ECG richiede questi campi UDM per unire i dati di contesto pertinenti in una regola o una ricerca. Devi unire in modo esplicito tutti i dati correlati all'ECG ai dati sugli eventi UDM.

Ad esempio, puoi utilizzare i dati prevalence nell'ECG per determinare le connessioni a domini "rari" nei log di sicurezza:

    $dns.metadata.event_type = "NETWORK_DNS"
    $dns.network.dns.questions.name != ""
    $dns.network.dns.questions.name = $domain
    $prevalence.graph.metadata.entity_type = "DOMAIN_NAME"
    $prevalence.graph.metadata.source_type = "DERIVED_CONTEXT"
    $prevalence.graph.entity.hostname = $domain
    $prevalence.graph.entity.domain.prevalence.day_count = 10
    $prevalence.graph.entity.domain.prevalence.rolling_max > 0
    $prevalence.graph.entity.domain.prevalence.rolling_max <= 3

  match:
    $domain over 5m
  condition:
    $dns and $prevalence

Nota: Ricerca e Dashboard supportano un massimo di un'unione, mentre le Regole supportano un massimo di due unioni.

Nota: l'inclusione dell'argomento prevalence può comportare l'esecuzione di query su un numero di dati notevolmente superiore.

Ora della prima e dell'ultima visualizzazione delle entità

Google SecOps analizza i dati in entrata per arricchire i record di contesto delle entità con i seguenti campi critici:

• first-seen-time: la data e l'ora in cui l'entità è stata visualizzata per la prima volta nel tuo ambiente.
• last-seen-time: la data e l'ora dell'osservazione più recente.

Questi campi derivati ti consentono di correlare l'attività tra entità domain, file hash, asset, user o IP address.

Questi valori vengono memorizzati nei seguenti campi UDM:

Tipo di entità	Campi UDM
Dominio	entity.domain.first_seen_time entity.domain.last_seen_time
File (hash)	entity.file.first_seen_time entity.file.last_seen_time
Indirizzo IP	entity.artifact.first_seen_time entity.artifact.last_seen_time
Asset	entity.asset.first_seen_time
Utente	entity.user.first_seen_time

Eccezioni per i calcoli di first-seen-time e last-seen-time:

• Per le entità asset e user, Google SecOps compila solo il campo first_seen_time, ma non il campo last_seen_time.
• Google SecOps non calcola le statistiche per ogni entità all'interno dei singoli spazi dei nomi.
• Google SecOps non esporta queste statistiche nello schema events di Google SecOps in BigQuery.
• Google SecOps non calcola questi valori per altri tipi di entità, ad esempio un group o un resource.

Arricchimenti contestuali globali

Queste fonti includono dati esterni di threat intelligence e reputazione provenienti da fonti globali interne e di terze parti.

Importa i dati di Google Threat Intelligence

Google SecOps acquisisce i dati dalle origini dati di Google Threat Intelligence (GTI), fornendo informazioni contestuali per l'analisi dell'attività nel tuo ambiente.

Esegui query sulle seguenti origini dati:

• Nodi di uscita Tor GTI: indirizzi IP noti come nodi di uscita Tor.
• GTI Benign Binaries:file che fanno parte della distribuzione del sistema operativo originale o che sono stati aggiornati da una patch ufficiale del sistema operativo. Alcuni binari del sistema operativo ufficiali che sono stati sfruttati da un avversario tramite attività comuni negli attacchi living-off-the-land sono esclusi da questa origine dati, ad esempio quelli incentrati sui vettori di ingresso iniziali.
• Strumenti di accesso remoto GTI: file utilizzati di frequente da autori di attacchi informatici. Questi strumenti sono in genere applicazioni legittime che a volte vengono utilizzate in modo improprio per connettersi da remoto a sistemi compromessi.

I dati contestuali vengono archiviati a livello globale come entità. Puoi eseguire query sui dati utilizzando le regole del motore di rilevamento. Includi i seguenti campi e valori UDM nella regola per eseguire query su queste entità globali:

• graph.metadata.vendor_name = Google Threat Intelligence
• graph.metadata.product_name = GTI Feed

Nota: nelle sezioni seguenti, sostituisci il segnaposto <variable_name> con il nome univoco della variabile che utilizzi in una regola per identificare un record UDM.

Origini dati di Google Threat Intelligence temporizzate e non temporizzate

Le origini dati di Google Threat Intelligence includono tipi temporizzati o senza tempo.

Ogni voce nelle origini dati temporizzate ha un intervallo di tempo associato. Ad esempio, se Google SecOps genera un rilevamento il giorno 1, è previsto che generi lo stesso rilevamento per il giorno 1 durante una retrocaccia in qualsiasi giorno futuro.

Le origini dati senza tempo non hanno un intervallo di tempo associato, poiché deve essere considerato solo il set di dati più recente. Queste origini dati vengono in genere utilizzate per i dati che non dovrebbero cambiare, ad esempio gli hash dei file. Se Google SecOps non genera un rilevamento il giorno 1, un rilevamento potrebbe comunque essere generato per il giorno 1 durante una ricerca retroattiva il giorno 2 se è stata aggiunta una nuova voce all'origine dati senza data.

Dati sugli indirizzi IP dei nodi di uscita Tor

Google SecOps importa e archivia gli indirizzi IP noti dei nodi di uscita Tor. I nodi di uscita Tor sono i punti in cui il traffico esce dalla rete Tor. Questi dati sono temporizzati.

Google SecOps memorizza le informazioni inserite da questa origine dati nei seguenti campi UDM:

Campo UDM	Descrizione
<variable_name>.graph.metadata.vendor_name	Memorizza il valore Google Threat Intelligence.
<variable_name>.graph.metadata.product_name	Memorizza il valore GTI Feed.
<variable_name>.graph.metadata.threat.threat_feed_name	Memorizza il valore Tor Exit Nodes.
<variable_name>.graph.entity.artifact.ip	Memorizza l'indirizzo IP importato dall'origine dati GTI.

Ricerca di esempio

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Tor Exit Nodes"

Dati sui file di sistema operativo benigni

Google SecOps acquisisce e archivia gli hash dei file dall'origine dati GTI Benign Binaries. Google SecOps archivia le informazioni importate da questa origine dati nei seguenti campi UDM. I dati sui binari benigni sono senza tempo.

Campo UDM	Descrizione
<variable_name>.graph.metadata.vendor_name	Memorizza il valore Google Threat Intelligence.
<variable_name>.graph.metadata.product_name	Memorizza il valore GTI Feed.
<variable_name>.graph.metadata.threat.threat_feed_name	Memorizza il valore Benign Binaries.
<variable_name>.graph.entity.file.sha256	Memorizza il valore hash SHA256 del file.
<variable_name>.graph.entity.file.sha1	Memorizza il valore hash SHA-1 del file.
<variable_name>.graph.entity.file.md5	Memorizza il valore hash MD5 del file.

Ricerca di esempio

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Benign Binaries"

Dati sugli strumenti di accesso remoto

Gli strumenti di accesso remoto includono hash di file per strumenti di accesso remoto noti, come i client VNC che sono stati utilizzati di frequente da malintenzionati. Questi strumenti sono in genere applicazioni legittime che a volte vengono utilizzate in modo improprio per connettersi da remoto a sistemi compromessi. Google SecOps archivia le informazioni importate da questa origine dati nei seguenti campi UDM. I dati degli strumenti di accesso remoto sono senza limiti di tempo.

Campo UDM	Descrizione
<variable_name>.graph.metadata.vendor_name	Memorizza il valore Google Threat Intelligence.
<variable_name>.graph.metadata.product_name	Memorizza il valore GTI Feed.
<variable_name>.graph.metadata.threat.threat_feed_name	Memorizza il valore Remote Access Tools.
<variable_name>.graph.entity.file.sha256	Memorizza il valore hash SHA256 del file.
<variable_name>.graph.entity.file.sha1	Memorizza il valore hash SHA-1 del file.
<variable_name>.graph.entity.file.md5	Memorizza il valore hash MD5 del file.

Ricerca di esempio

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Remote Access Tools"

Arricchire le entità con le informazioni degli elenchi di minacce di Navigazione sicura

Google SecOps acquisisce i dati di Navigazione sicura correlati agli hash dei file. Google SecOps archivia i dati di ogni file come entità e fornisce un contesto aggiuntivo sul file. Puoi creare regole del motore di rilevamento che eseguono query su questi dati del contesto dell'entità per creare analisi sensibili al contesto.

Nota :puoi utilizzare Navigazione sicura solo nelle regole e i dati sono considerati senza limiti di tempo.

Google SecOps archivia le seguenti informazioni con il record di contesto dell'entità.

Campo UDM	Descrizione
entity.metadata.product_entity_id	Un identificatore univoco per l'entità.
entity.metadata.entity_type	Questo valore è FILE, il che indica che l'entità descrive un file.
entity.metadata.collected_timestamp	La data e l'ora in cui è stata osservata l'entità o si è verificato l'evento.
entity.metadata.interval	Memorizza l'ora di inizio e l'ora di fine per cui questi dati sono validi. Poiché i contenuti degli elenchi di minacce cambiano nel tempo, start_time e end_time riflettono l'intervallo di tempo durante il quale i dati sull'entità sono validi. Ad esempio, è stato osservato che l'hash di un file è dannoso o sospetto tra il giorno start_time e il giorno end_time.
entity.metadata.threat.category	Google SecOps SecurityCategory è impostato su uno o più dei seguenti valori: SOFTWARE_MALICIOUS: indica che la minaccia è correlata a malware. SOFTWARE_PUA: indica che la minaccia è correlata a software indesiderato.
entity.metadata.threat.severity	Questo è il Google SecOps ProductSeverity. Se il valore è CRITICAL, significa che l'artefatto appare dannoso. Se il valore non è specificato, non c'è sufficiente certezza per indicare che l'artefatto è dannoso.
entity.metadata.product_name	Memorizza il valore Google Safe Browsing.
entity.file.sha256	Il valore hash SHA256 del file.

Regola di esempio

events:
    // find a process launch event, match on hostname
    $execution.metadata.event_type = "PROCESS_LAUNCH"
    $execution.target.process.file.sha256 != ""
    $execution.principal.hostname = $hostname

    // join execution event with Safe Browsing graph
    $sb.graph.entity.file.sha256 = $execution.target.process.file.sha256

    // look for files deemed malicious
    $sb.graph.metadata.entity_type = "FILE"
    $sb.graph.metadata.threat.severity = "CRITICAL"
    $sb.graph.metadata.product_name = "Google Safe Browsing"

  match:
    $hostname over 5m

  condition:
    $execution and $sb

Arricchisci le entità con i dati WHOIS

Google SecOps esegue l'arricchimento giornaliero dei dati WHOIS, una funzione fondamentale, utilizzando dati temporizzati e senza scadenza.

Durante l'importazione dati del dispositivo, Google SecOps valuta i domini in base ai dati WHOIS. Quando i domini corrispondono, Google SecOps memorizza i dati WHOIS correlati nel record dell'entità del dominio. Per ogni entità con entity.metadata.entity_type = DOMAIN_NAME, Google SecOps arricchisce il record con le informazioni WHOIS.

Google SecOps compila il record dell'entità con i dati WHOIS arricchiti nei seguenti campi:

• entity.domain.admin.attribute.labels
• entity.domain.audit_update_time
• entity.domain.billing.attribute.labels
• entity.domain.billing.office_address.country_or_region
• entity.domain.contact_email
• entity.domain.creation_time
• entity.domain.expiration_time
• entity.domain.iana_registrar_id
• entity.domain.name_server
• entity.domain.private_registration
• entity.domain.registrant.company_name
• entity.domain.registrant.office_address.state
• entity.domain.registrant.office_address.country_or_region
• entity.domain.registrant.email_addresses
• entity.domain.registrant.user_display_name
• entity.domain.registrar
• entity.domain.registry_data_raw_text
• entity.domain.status
• entity.domain.tech.attribute.labels
• entity.domain.update_time
• entity.domain.whois_record_raw_text
• entity.domain.whois_server
• entity.domain.zone

Google SecOps arricchisce le entità domain (entity.metadata.entity_type = "DOMAIN_NAME") con i dati registrant, creation e expiration time dei record WHOIS global context.

Per le descrizioni di questi campi, consulta il documento Elenco dei campi Unified Data Model.

Ricerca di esempio

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "WHOISXMLAPI Simple Whois"
graph.entity.domain.registry_data_raw_text != b""

Best practice: identifica le origini dati arricchite con il contesto globale

Per migliorare il rendimento delle regole, includi un filtro nelle regole che utilizza i dati delle origini di arricchimento del contesto globale. Questo filtro deve identificare il tipo o l'origine di arricchimento specifico.

I seguenti parametri di filtro identificano il tipo o l'origine dell'arricchimento: entity_type, product_name e vendor_name.

Ad esempio, includi i seguenti campi filtro nella sezione events della regola che unisce i dati WHOIS:

$enrichment.graph.metadata.entity_type = "DOMAIN_NAME"
$enrichment.graph.metadata.product_name = "WHOISXMLAPI Simple Whois"
$enrichment.graph.metadata.vendor_name = "WHOIS"

Nota: conoscere l'origine dell'arricchimento può essere prezioso quanto i dati stessi e un singolo campo UDM può avere più origini di arricchimento. Puoi visualizzare queste informazioni nel Visualizzatore eventi o utilizzando una ricerca di eventi UDM (ad esempio, principal.hostname="john.doe.desktop" metadata.event_type="NETWORK_CONNECTION").

Best practice per l'ECG

Quando utilizzi dati arricchiti in base al contesto, tieni presente le seguenti best practice per ECG:

• Non aggiungere intervalli ai dati dell'entità; lascia che sia la pipeline ECG a crearli. Google SecOps genera intervalli durante la deduplicazione, se non diversamente specificato.
• Se specifichi gli intervalli, Google SecOps deduplica solo gli eventi identici e conserva l'entità più recente.
• Per garantire il corretto funzionamento delle regole live e delle ricerche retrospettive, devi importare le entità almeno una volta al giorno.
• Se non importi entità giornalmente, ma solo una volta ogni due o più giorni, le regole live potrebbero comunque funzionare come previsto. Tuttavia, le ricerche retrospettive potrebbero perdere alcuni contesti degli eventi.
• Se importi entità identiche più di una volta al giorno, Google SecOps le deduplica in un'unica entità.
• Se mancano i dati degli eventi per un giorno, Google SecOps utilizza temporaneamente i dati del giorno precedente per garantire il corretto funzionamento delle regole attive.

Per informazioni dettagliate sui limiti generali del servizio Google SecOps, consulta Limiti del servizio.

Contenuti esterni correlati

• Utilizzare il grafico entità come elenco multidimensionale
• Alias in Chronicle SIEM
• Indicatori di compromissione in scadenza nel grafico delle entità
• Google Navigazione sicura in Chronicle SIEM

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