Crea analisi sensibili al contesto
Chronicle consente di visualizzare i dati di telemetria, contesto dell'entità, relazioni e vulnerabilità come un unico rilevamento all'interno del tuo account Chronicle. Fornisce la contestualizzazione delle entità per consentirti di comprendere sia i pattern comportamentali della telemetria sia il contesto di tali entità interessate da tali pattern.
Esempi:
- Mostrare le autorizzazioni per un account per cui si sta tentando di accedere a una forza bruta.
- L'importanza dei dati ospitati da un asset che sono anche la fonte delle attività di rete in uscita.
I clienti possono utilizzare questa contestualizzazione per i filtri di rilevamento, la priorità euristica degli avvisi, la classificazione e gli accertamenti.
Gli analisti della sicurezza e i tecnici responsabili del rilevamento lavorano in genere per creare un rilevamento basato su un pattern di base della telemetria degli eventi (una connessione di rete in uscita), che crea numerosi rilevamenti per consentire agli analisti di assegnare una priorità. Gli analisti tentano di tracciare una comprensione di quello che è accaduto per attivare l'allerta e quanto sia significativa la minaccia.
L'analisi sensibile al contesto integra funzionalità di arricchimento avanzate fin dalle prime fasi del flusso di lavoro di creazione ed esecuzione del rilevamento, consentendoti di offrire le seguenti funzionalità aggiuntive:
- Rendere disponibile un contesto pertinente per il punteggio dei rischi contestuali basati sull'euristica al momento dell'esecuzione del rilevamento, anziché nella fase di triage umano
- Riduzione del tempo impiegato per la classificazione e per l'unione manuale delle informazioni da diversi sistemi di sicurezza IT (console EDR, log firewall/proxy, contesto CMDB e IAM, risultati di analisi delle vulnerabilità)
- Consentire ad analisti e tecnici di rilevamento di escludere interi cluster di minacce che potrebbero verificarsi o che comportano un pericolo minimo o nullo per l'azienda (test di malware in un ambiente sandbox, vulnerabilità e attività anomale in una rete di sviluppo senza accesso o dati sensibili e altro).
Scrittura di regole per l'analisi sensibile al contesto
Puoi utilizzare le regole di Detection Engine per cercare dati di contesto delle entità nel tuo account Chronicle.
Per cercare i dati contesto di entità, completa la procedura seguente:
Specifica un'origine utilizzando udm o entità.
$eventname.[<source>].field1.field2Per un contesto di entità, <source> è "graph". Per un evento UDM, <source> è "udm". Se omesso, il valore predefinito di <source> è udm.Specifica i dati dell'entità:
$e1.graph.entity.hostname = "my-hostname"$e1.graph.entity.relations.relationship = "OWNS"Specifica i dati dell'evento UDM. Le seguenti affermazioni sono equivalenti.
$e1.udm.principal.asset_id = "my_asset_id"$e1.principal.asset_id = "my_asset_id"
Puoi creare molti degli stessi tipi di regole per i contesti delle entità come faresti per gli eventi UDM, tra cui quelli seguenti:
Più regole evento
Confronto dei contesti delle entità con altri contesti delle entità
Confronto dei contesti delle entità con gli eventi UDM
Campi ripetuti nei contesti delle entità
Finestre scorrevoli
Calcolo di un punteggio di rischio per i rilevamenti
A differenza di un evento UDM, un contesto entità non ha un timestamp specifico. Ogni record di contesto entità ha un intervallo di tempo entità.metadata.interval su cui è valido il contesto dell'entità. Questo intervallo di tempo non può essere un limite giornaliero e può essere di qualsiasi durata.
Un evento UDM sarà correlato a un record di contesto entità solo quando il timestamp dell'evento UDM rientra nell'intervallo di tempo del record di contesto entità. Se questa condizione non è soddisfatta, l'UDM e l'entità non vengono valutate per i rilevamenti. Il motore di rilevamento applica implicitamente questa impostazione e non è necessario specificarla come condizione in una regola.
- Quando si confrontano gli eventi UDM con un contesto entità con windowing, un contesto entità rappresenta un valore costante in una finestra specificata.
- Se sono presenti bucket giornalieri adiacenti in cui il contesto dell'entità modifica il proprio valore, Chronicle tenta di trovare una corrispondenza su tutti i valori di contesto dell'entità e restituisce tutte le corrispondenze trovate.
Regole di esempio
Ricerca di entità con contesto amministratore
La seguente regola cerca le entità collegate anche ai privilegi di amministratore. Sta cercando i casi in cui qualcuno con privilegio di amministratore ha tentato di accedere al sistema o di disconnettersi.
rule LoginLogout {
meta:
events:
$log_in.metadata.event_type = "USER_LOGIN"
$log_in.principal.user.user_display_name = $user
$log_out.metadata.event_type = "USER_LOGOUT"
$log_out.principal.user.user_display_name = $user
$log_in.metadata.event_timestamp.seconds <=
$log_out.metadata.event_timestamp.seconds
$context.graph.entity.user.user_display_name = $user
$context.graph.entity.resource.attribute.roles.type = "ADMINISTRATOR"
match:
$user over 2m
condition:
$log_in and $log_out and $context
}
Esempio di finestra scorrevole
Il seguente esempio di finestra scorrevole è valido.
rule Detection {
meta:
events:
$e1.graph.entity.hostname = $host
$e2.udm.principal.hostname = $host
match:
// Using e2 (a UDM event) as a pivot.
$host over 3h after $e2
condition:
$e1 and $e2
}
Esempio di finestra scorrevole non valida
Il seguente esempio di finestra scorrevole non è valido. Il contesto dell'entità non può essere utilizzato come pivot per una finestra scorrevole.
rule Detection {
meta:
events:
$e1.graph.entity.hostname = $host
$e2.udm.principal.hostname = $host
match:
// Attempting to use $e1 (an entity context) as a pivot. Invalid.
$host over 3h after $e1
condition:
$e1 and $e2
}
Esempio di accesso che utilizza la sezione dei risultati
L'esempio seguente utilizza la sezione outcome per calcolare un punteggio di rischio per il rilevamento.
rule Detection {
meta:
events:
$auth.metadata.event_type = "USER_LOGIN"
$auth.metadata.vendor_name = "Acme"
$auth.metadata.product_name = "Acme SSO"
$auth.target.user.userid = $user
$auth.target.user.termination_date.seconds > 0
$auth.metadata.event_timestamp.seconds >
$context.graph.entity.user.termination_date.seconds
$context.graph.metadata.vendor_name = "Microsoft"
$context.graph.metadata.product_name = "Azure Active Directory"
$context.graph.metadata.entity_type = "USER"
$context.graph.entity.user.userid = $user
$context.graph.entity.user.termination_date.seconds > 0
match:
$user over 15m
outcome:
$risk_score = max(
if ( $auth.metadata.event_type = "USER_LOGIN", 50) +
if (
$context.graph.entity.user.title = "Remote" nocase or
$context.graph.entity.user.title = "Temp" nocase or
$context.graph.entity.user.title = "Vendor" nocase, 40) +
if ( $context.graph.entity.user.title = "Legal" nocase, 10)
)
condition:
$auth and $context
}
Esempio di lancio di un processo sospetto
L'esempio seguente valuta i dati del processo degli eventi UDM rispetto ai dati di contesto IOC archiviati come contesto dell'entità.
rule ProcessLaunch {
meta:
events:
$ioc.graph.metadata.vendor_name = "ACME"
$ioc.graph.metadata.product_name = "IOCs"
$ioc.graph.metadata.entity_type = "FILE"
$ioc.graph.entity.file.sha256 = $hash
$process.metadata.event_type = "PROCESS_LAUNCH"
$process.principal.hostname = $hostname
(
not $process.target.process.file.sha256 = "" and
$process.target.process.file.sha256 = $hash
)
match:
$hash over 15m
condition:
$ioc and $process
}
Qualificatori aggiuntivi per il contesto dell'entità
Per creare una variabile evento che utilizza un contesto entità, devi fornire un <source> dopo il nome dell'evento. <source> deve essere graph.
Il seguente pattern si riferisce a un contesto entità:
$e.graph.entity.hostname
Tieni presente che esistono due metodi equivalenti per fare riferimento a un evento UDM:
$u.udm.principal.asset_id$u.principal.asset_id
Puoi combinare e abbinare tutti questi qualificatori nel testo della regola. Puoi anche utilizzare qualificatori diversi per lo stesso evento.
Sezione dei risultati
Il motore di rilevamento supporta una sezione outcome che ti consente di ricavare più informazioni da una regola. La logica definita nella sezione outcome viene valutata in base a ogni rilevamento. Se una regola genera rilevamenti N, ognuno dei rilevamenti N può determinare un insieme di risultati diverso.
Puoi trovare una regola di esempio che utilizza la sezione outcome qui.
L'utilizzo dettagliato e la sintassi di una sezione outcome sono disponibili in questa sezione.
Sezione dei risultati e deduplicazione o raggruppamento di rilevamento
Per le regole con una sezione di corrispondenza, ricorda che i rilevamenti sono "raggruppati per" le variabili di corrispondenza. In questo modo i rilevamenti vengono deduplicati, in modo che venga restituita una riga per ogni insieme univoco di variabili di corrispondenza e finestra temporale.
Le variabili di risultato vengono ignorate durante questa deduplicazione. Pertanto, se sono presenti due rilevamenti diversi con gli stessi valori per le variabili di corrispondenza e l'intervallo di tempo, ma con valori diversi per le variabili di risultato, questi verranno deduplicati e verrà visualizzato un solo rilevamento. Questo può succedere quando, ad esempio, è stato creato un rilevamento a causa di dati in ritardo. Ecco un esempio che illustra questo caso.
rule ExampleOutcomeRule {
...
match:
$hostname over <some window>
outcome:
$risk_score = <some logic here>
...
}
Questa regola restituisce le seguenti corrispondenze:
Rilevamento 1: nome host: nome-host test finestra temporale: [t1, t2] Risk_score: 10
Rilevamento 2: nome host: test-nome-host finestra temporale: [t1, t2] Risk_score: 73
Poiché le variabili di corrispondenza e la finestra temporale sono le stesse per il rilevamento 1 e il rilevamento 2, queste vengono deduplicate e vedrai un solo rilevamento, anche se la variabile di risultato, Risk_score, è diversa.
Passaggi successivi
Per informazioni su come Chronicle importa i dati contestuali e arricchisce le entità, consulta Come Chronicle arricchisce i dati di eventi ed entità