Creare analisi sensibili al contesto

Chronicle consente di visualizzare la telemetria, il contesto dell'entità, le relazioni e le vulnerabilità come un unico rilevamento all'interno dell'account Chronicle. Fornisce il contesto delle entità per consentirti di comprendere sia i pattern comportamentali della telemetria sia il contesto delle entità interessate da tali schemi.

Esempi:

  • Mostrare le autorizzazioni per un account per il quale si sta tentando di eseguire un accesso illecito.
  • Importanza dei dati ospitati da un asset che rappresenta anche la fonte dell'attività di rete in uscita.

I clienti possono utilizzare questo contesto per il rilevamento dei filtri, l'assegnazione di priorità agli avvisi euristici, la classificazione e l'indagine.

Gli analisti per la sicurezza e i tecnici che si occupano di rilevamento lavorano in genere per creare un rilevamento basato su un modello di base della telemetria degli eventi (una connessione di rete in uscita), creando numerosi rilevamenti da far analizzare agli analisti. Gli analisti tentano di tracciare un punto di osservazione su cosa è successo per attivare l'avviso e sul grado di gravità della minaccia.

L'analisi sensibile al contesto incorpora funzionalità di arricchimento avanzate nelle prime fasi del flusso di lavoro di creazione ed esecuzione del rilevamento, consentendoti di fornire 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 valutazione umana
  • Ridurre il tempo impiegato per la valutazione e per eseguire manualmente il stitching di informazioni da diversi sistemi di sicurezza IT (console EDR, log firewall/proxy, contesto CMDB e IAM, risultati dell'analisi delle vulnerabilità)
  • Consentire agli analisti e ai tecnici di rilevamento di filtrare interi cluster di minacce che potrebbero essere previsti o che rappresentano un pericolo minimo o nullo per l'azienda (test di malware in un ambiente sandbox, vulnerabilità e attività anomala in una rete di sviluppo senza accesso a dati sensibili e altro ancora).

Scrivere regole per l'analisi sensibile al contesto

Puoi utilizzare le regole di Motore di rilevamento per cercare i dati di contesto delle entità nel tuo account Chronicle.

Per cercare i dati di contesto delle entità, completa la procedura seguente:

  1. Specifica un'origine utilizzando udm o l'entità.

    $eventname.[<source>].field1.field2 Per il contesto di un'entità, <source> è 'grafo'. Per un evento UDM, <source> è 'udm'. Se omesso, l'impostazione predefinita in <source> è udm.

  2. Specifica i dati dell'entità:

    $e1.graph.entity.hostname = "my-hostname"

    $e1.graph.entity.relations.relationship = "OWNS"

  3. Specifica i dati dell'evento UDM. Le affermazioni che seguono sono equivalenti.

    $e1.udm.principal.asset_id = "my_asset_id"

    $e1.principal.asset_id = "my_asset_id"

Per i contesti delle entità puoi creare molti degli stessi tipi di regole previsti per gli eventi UDM, tra cui:

  • Più regole evento

  • Confronto tra contesti di entità con altri contesti di entità

  • Confronto dei contesti 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 contesto di entità ha un intervallo di tempo durante il quale l'associazione è valida. L'intervallo di tempo non deve iniziare in un giorno limite e può essere di una durata arbitraria.

  • Quando confronti gli eventi UDM con un contesto di entità con il periodo, un contesto di entità rappresenta un valore costante in un periodo specifico.
  • Se sono presenti bucket di giorni adiacenti in cui il contesto dell'entità cambia il proprio valore, Chronicle tenta di trovare una corrispondenza su tutti i valori del contesto dell'entità e restituisce tutte le corrispondenze trovate.

Regole di esempio

Ricerca di entità con contesto amministrativo

La seguente regola cerca le entità associate anche ai privilegi di amministratore. Sta cercando 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_in.principal.user.userid = "alice"

    $log_out.metadata.event_type = "USER_LOGOUT"
    $log_out.principal.user.user_display_name = $user
    $log_out.principal.user.userid = "alice"

    $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 a scorrimento 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 con 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 di evento 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 di 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 tutti questi qualificatori nel testo della regola. Per lo stesso evento puoi utilizzare anche qualificatori diversi.

Sezione dei risultati

Il motore di rilevamento supporta una sezione outcome che 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 N rilevamenti, ogni rilevamento di N potrebbe restituire un risultato diverso.

Per una regola di esempio che utilizza la sezione outcome, fai clic qui.

Puoi trovare informazioni dettagliate sull'utilizzo e sulla sintassi di una sezione outcome in questa sezione.

Sezione dei risultati e deduplicazione / rilevamento del rilevamento

Per le regole con una sezione di corrispondenza, ricorda che i rilevamenti sono "raggruppati" dalle variabili di corrispondenza. Questo fa sì che i rilevamenti vengano deduplicati, in modo che venga restituita una riga per ogni insieme univoco di variabili di corrispondenza e finestra di tempo.

Le variabili di risultato vengono ignorate durante la deduplicazione. Pertanto, se esistono due rilevamenti diversi con gli stessi valori per le variabili di corrispondenza e la finestra temporale, ma con valori diversi per le variabili di risultato, questi verranno deduplicati e verrà visualizzato un solo rilevamento. Questo può accadere quando un rilevamento è stato creato, ad esempio, 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 determina le seguenti corrispondenze:

Rilevamento 1: nome host: test-nome host finestra di tempo: [t1, t2] Risk_score: 10

Rilevamento 2: nome host: test-nome host finestra di tempo: [t1, t2] Risk_score: 73

Poiché le variabili di corrispondenza e la finestra temporale sono le stesse per Rilevamento 1 e Rilevamento 2, questi vengono deduplicati e vedrai solo un rilevamento, anche se la variabile del risultato, Risk_score, è diversa.