Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Panoramica del linguaggio YARA-L 2.0

YARA-L 2.0 è un linguaggio di computer utilizzato per creare regole per la ricerca nei dati di log aziendali mentre vengono importati nel tuo account Chronicle. La sintassi YARA-L deriva dalla lingua YARA sviluppata da VirusTotal. Il linguaggio funziona in sinergia con il motore di rilevamento Chronicle e ti consente di individuare eventuali minacce e altri eventi su grandi volumi di dati. Consulta anche la sintassi della lingua Yara-L 2.0.

Regole di esempio YARA-L 2.0

I seguenti esempi mostrano regole scritte in YARA-L 2.0. Ciascun elemento dimostra come collegare gli eventi nel linguaggio della regola.

Accessi da città diverse

La seguente regola cerca gli utenti che hanno eseguito l'accesso alla tua azienda da due o più città in meno di 5 minuti:

rule DifferentCityLogin {
  meta:

  events:
    $udm.metadata.event_type = "USER_LOGIN"
    $udm.principal.user.userid = $user
    $udm.principal.location.city = $city

  match:
    $user over 5m

  condition:
    $udm and #city > 1
}

Variabile di corrispondenza: $user

Variabile evento:$udm

Variabile segnaposto: $city e $user

Di seguito viene descritto il funzionamento della regola:

  • Raggruppa gli eventi con nome utente ($user) e lo restituisce ($user) quando viene trovata una corrispondenza.
  • La durata è di 5 minuti, il che significa che solo gli eventi di durata inferiore a 5 minuti sono correlati.
  • Ricerca di un gruppo di eventi ($udm) il cui tipo di evento è USER_LOGIN.
  • Per quel gruppo di eventi, la regola chiama l'ID utente come $user e la città di accesso come $city.
  • Restituisce una corrispondenza se il numero distinto di valori $city è maggiore di 1 nel gruppo di eventi ($udm) nell'intervallo di tempo di 5 minuti.

Creazione ed eliminazione rapida degli utenti

La seguente regola cerca gli utenti che sono stati creati e poi eliminati entro 4 ore:

rule UserCreationThenDeletion {
  meta:

  events:
    $create.target.user.userid = $user
    $create.metadata.event_type = "USER_CREATION"

    $delete.target.user.userid = $user
    $delete.metadata.event_type = "USER_DELETION"

    $create.metadata.event_timestamp.seconds <=
       $delete.metadata.event_timestamp.seconds

  match:
    $user over 4h

  condition:
    $create and $delete
}

Variabili evento:$create e $delete

Variabile di corrispondenza: $user

Variabile segnaposto: N/A

Di seguito viene descritto il funzionamento della regola:

  • Raggruppa gli eventi con nome utente ($user) e lo restituisce ($user) quando viene trovata una corrispondenza.
  • La finestra temporale è di 4 ore, il che significa che solo gli eventi separati da meno di 4 ore sono correlati.
  • Ricerche per due gruppi di eventi ($create e $delete, dove $create equivale a #create >= 1).
  • $create corrisponde a USER_CREATION eventi e chiama l'ID utente come $user.
  • $user viene utilizzato per unire i due gruppi di eventi.
  • $delete corrisponde a USER_DELETION eventi e chiama l'ID utente come $user. Questa regola cerca una corrispondenza in cui l'identificatore utente nei due gruppi di eventi è lo stesso.
  • Questa regola cerca i casi in cui l'evento da $delete si verifica dopo l'evento da $create, restituisce una corrispondenza quando viene rilevata.

Singola regola evento

Le regole per un singolo evento sono regole correlate a un singolo evento. Una regola di evento singola può essere:

  • Qualsiasi regola senza una sezione di corrispondenza.
  • Regola con una sezione della corrispondenza e una sezione della condizione che verificano solo l'esistenza di 1 evento (ad esempio, "$e", "#e > 0", "#e >= 1", "1 <= #e", "0 < #e&t;

Ad esempio, la seguente regola cerca semplicemente un evento utente di accesso e restituisce il primo che rileva all'interno dei dati aziendali memorizzati nel tuo account Chronicle:

rule SingleEventRule {
  meta:
    author = "noone@altostrat.com"

  events:
    $e.metadata.event_type = "USER_LOGIN"

  condition:
    $e
}

Ecco un altro esempio di regola di evento singola con una sezione di corrispondenza. Questa regola cerca un utente che ha eseguito l'accesso almeno una volta in meno di 5 minuti. Controlla la semplice esistenza di un evento di accesso dell'utente.

rule SingleEventRule {
  meta:
    author = "noone@google.com"
    description = "windowed single event example rule"

  events:
    $e.metadata.event_type = "USER_LOGIN"
    $e.principal.user.userid = $user

  match:
    $user over 5m

  condition:
    #e > 0
}

Regola per più eventi

Utilizza più regole per gli eventi per raggruppare molti eventi in un periodo di tempo specificato e cercare di trovare correlazioni tra gli eventi. Una tipica regola per più eventi prevede quanto segue:

  • Corrispondenza della sezione che specifica l'intervallo di tempo in cui gli eventi devono essere raggruppati.
  • Sezione Condizione che specifica quale condizione deve attivare il rilevamento e il controllo dell'esistenza di più eventi.

Ad esempio, la seguente regola cerca un utente che ha eseguito l'accesso almeno 10 volte in meno di 10 minuti:

rule MultiEventRule {
  meta:
    author = "noone@altostrat.com"

  events:
    $e.metadata.event_type = "USER_LOGIN"
    $e.principal.user.userid = $user

  match:
    $user over 10m

  condition:
    #e >= 10
}

Singolo evento nell'intervallo di indirizzi IP

L'esempio seguente mostra una singola regola evento che cerca una corrispondenza tra due utenti specifici e un intervallo specifico di indirizzi IP:

rule OrsAndNetworkRange {
  meta:
    author = "noone@altostrat.com"

  events:
    // Checks CIDR ranges.
    net.ip_in_range_cidr($e.principal.ip, "203.0.113.0/24")

    // Detection when the hostname field matches either value using or.
    $e.principal.hostname = /pbateman/ or $e.principal.hostname = /sspade/

  condition:
    $e
}

esempio di tutte le regole

La seguente regola cerca gli eventi di accesso in cui tutti gli indirizzi IP di origine non corrispondono a un indirizzo IP noto per essere sicuro entro un periodo di tempo di 5 minuti.

rule SuspiciousIPLogins {
  meta:
    author = "noone@google.com"

  events:
    $e.metadata.event_type = "USER_LOGIN"

    // Detects if all source IP addresses in an event do not match "100.97.16.0"
    // For example, if an event has source IP addresses
    // ["100.97.16.1", "100.97.16.2", "100.97.16.3"],
    // it will be detected since "100.97.16.1", "100.97.16.2",
    // and "100.97.16.3" all do not match "100.97.16.0".

    all $e.principal.ip != "100.97.16.0"

    // Assigns placeholder variable $ip to the $e.principal.ip repeated field.
    // There will be one detection per source IP address.
    // For example, if an event has source IP addresses
    // ["100.97.16.1", "100.97.16.2", "100.97.16.3"],
    // there will be one detection per address.

    $e.principal.ip = $ip

  match:
    $ip over 5m

  condition:
    $e
}

Espressioni regolari in una regola

Il seguente esempio di espressione regolare YARA-L 2.0 cerca eventi con email ricevute dal dominio altostrat.com. Poiché nocase è stato aggiunto alla variabile $host regex e alla funzione regex, entrambi i confronti non fanno distinzione tra maiuscole e minuscole.

rule RegexRuleExample {
  meta:
    author = "noone@altostrat.com"

  events:
    $e.principal.hostname = $host
    $host = /.*HoSt.*/ nocase
    re.regex($e.network.email.from, `.*altostrat\.com`) nocase

  match:
    $host over 10m

  condition:
    #e > 10
}

Esempio di regola a scorrimento per finestra

Il seguente esempio di finestra scorrevole YARA-L 2.0 cerca l'assenza di eventi firewall_2 dopo firewall_1 eventi. La parola chiave after viene utilizzata con la variabile evento pivot $e1 per specificare che solo 10 minuti dopo ciascun evento firewall_1 devono essere controllati durante la correlazione degli eventi.

rule SlidingWindowRuleExample {
  meta:
    author = "noone@google.com"

  events:
    $e1.metadata.product_name = "firewall_1"
    $e1.principal.hostname = $host

    $e2.metadata.product_name = "firewall_2"
    $e2.principal.hostname = $host

  match:
    $host over 10m after $e1

  condition:
    $e1 and !$e2
}

Esempio di esclusione di zero

Se la regola non specifica le opzioni allow_zero_values, nessun valore viene restituito dai valori della variabile di corrispondenza. Tuttavia, per gli altri campi evento di riferimento, i valori zero non vengono esclusi a meno che non specifichi esplicitamente tali condizioni. Per ulteriori dettagli, fai clic qui.

rule ExcludeZeroValues {
  meta:
    author = "noone@google.com"

  events:
    $e1.metadata.event_type = "NETWORK_DNS"
    $e1.principal.hostname = $hostname

    // $e1.principal.user.userid may be empty string.
    $e1.principal.user.userid != "Guest"

    $e2.metadata.event_type = "NETWORK_HTTP"
    $e2.principal.hostname = $hostname

    // $e2.target.asset_id cannot be empty string as explicitly specified.
    $e2.target.asset_id != ""

  match:
    // $hostname cannot be empty string.
    $hostname over 1h

  condition:
    $e1 and $e2
}

Esempio di regola con sezione dei risultati

Puoi aggiungere la sezione facoltativa outcome nella regola YARA-L 2.0 per estrarre ulteriori informazioni su ciascun rilevamento. Nella sezione delle condizioni, puoi anche specificare le condizioni relative alle variabili di risultato.

Per ulteriori informazioni, consulta quanto segue:

Regola per più eventi con sezione dei risultati:

rule OutcomeRuleMultiEvent {
    meta:
      author = "noone@google.com"
    events:
      $u.udm.principal.hostname = $hostname
      $asset_context.graph.entity.hostname = $hostname

      $severity = $asset_context.graph.entity.asset.vulnerabilities.severity

    match:
      $hostname over 5m

    outcome:
      $risk_score =
        max(
            100
          + if($hostname = "my-hostname", 100, 50)
          + if($severity = "HIGH", 10)
          + if($severity = "MEDIUM", 5)
          + if($severity = "LOW", 1)
        )

      $asset_id_list =
        array(
          if($u.principal.asset_id = "",
             "Empty asset id",
             $u.principal.asset_id
          )
        )

      $asset_id_distinct_list = array_distinct($u.principal.asset_id)

      $asset_id_count = count($u.principal.asset_id)

      $asset_id_distinct_count = count_distinct($u.principal.asset_id)

    condition:
      $u and $asset_context and $risk_score > 50 and not arrays.contains($asset_id_list, "id_1234")
}

Regola per un singolo evento con sezione di risultati:

rule OutcomeRuleSingleEvent {
    meta:
        author = "noone@google.com"
    events:
        $u.metadata.event_type = "FILE_COPY"
        $u.principal.file.size = $file_size
        $u.principal.hostname = $hostname

    outcome:
        $suspicious_host = $hostname
        $severity_tag = if($file_size > 1024, "SEVERE", "MODERATE")

    condition:
        $u
}

Refactoring di una regola di risultato a più eventi in una regola di risultato per un singolo evento.

Puoi utilizzare la sezione dei risultati sia per le regole per eventi singoli (regole senza un'impostazione di corrispondenza) sia per le regole per più eventi (regole con una sezione di corrispondenza). Se in precedenza hai progettato una regola per l'utilizzo in più eventi solo per poter utilizzare la sezione dei risultati, puoi reintegrare tali regole eliminando la sezione delle corrispondenze per migliorare il rendimento. Tieni presente che, poiché la regola non contiene più una sezione di corrispondenza che applica il raggruppamento, potresti ricevere più rilevamenti. Questo refactoring è possibile solo per le regole che utilizzano una variabile di evento, come mostrato nell'esempio seguente.

Regola di risultato per più eventi che utilizza una sola variabile evento (una buona candidata per un refactoring):

rule OutcomeMultiEventPreRefactor {
    meta:
      author = "noone@google.com"
      description = "Outcome refactor rule, before the refactor"

    events:
      $u.udm.principal.hostname = $hostname

    match:
      $hostname over 5m

    outcome:
      $risk_score = max(if($hostname = "my-hostname", 100, 50))

    condition:
      $u
}

Per eseguire il refactoring della regola, elimina la sezione delle corrispondenze. Tieni presente che devi rimuovere anche l'aggregazione nella sezione dei risultati poiché la regola sarà ora a evento singolo. Per ulteriori informazioni sulle aggregazioni, consulta la nostra documentazione sulle aggregazioni dei risultati.

rule OutcomeSingleEventPostRefactor {
    meta:
      author = "noone@google.com"
      description = "Outcome refactor rule, after the refactor"

    events:
      $u.udm.principal.hostname = $hostname

    // We deleted the match section.

    outcome:
      // We removed the max() aggregate.
      $risk_score = if($hostname = "my-hostname", 100, 50)

    condition:
      $u
}

Esempio di regola per la funzione segnaposto

Puoi assegnare una variabile segnaposto al risultato di una chiamata funzione e puoi utilizzare la variabile segnaposto in altre sezioni della regola, ad esempio nella sezione delle corrispondenze, dei risultati o della condizione. Vedi l'esempio di seguito:

rule FunctionToPlaceholderRule {
    meta:
      author = "noone@google.com"
      description = "Rule that uses function to placeholder assignments"

    events:
        $u.metadata.event_type = "EMAIL_TRANSACTION"

        // Use function-placeholder assignment to extract the
        // address from an email.
        // address@website.com -> address
        $email_to_address_only = re.capture($u.network.email.from , "(.*)@")

        // Use function-placeholder assignment to normalize an email:
        // uid@??? -> uid@company.com
        $email_from_normalized = strings.concat(
            re.capture($u.network.email.from , "(.*)@"),
            "@company.com"
        )

        // Use function-placeholder assignment to get the day of the week of the event.
        // 1 = Sunday, 7 = Saturday.
        $dayofweek = timestamp.get_day_of_week($u.metadata.event_timestamp.seconds)

    match:
        // Use placeholder (from function-placeholder assignment) in match section.
        // Group by the normalized from email, and expose it in the detection.
        $email_from_normalized over 5m

    outcome:
        // Use placeholder (from function-placeholder assignment) in outcome section.
        // Assign more risk if the event happened on weekend.
        $risk_score = max(
            if($dayofweek = 1, 10, 0) +
            if($dayofweek = 7, 10, 0)
        )

    condition:
        // Use placeholder (from function-placeholder assignment) in condition section.
        // Match if an email was sent to multiple addresses.
        #email_to_address_only > 1
}

Regola di esempio di condizioni condizionali

Nella sezione delle condizioni, puoi utilizzare le variabili di risultato definite nella sezione dei risultati. Il seguente esempio mostra come filtrare i punteggi di rischio per ridurre il rumore nei rilevamenti utilizzando le condizionali di risultato.

rule OutcomeConditionalRule {
    meta:
        author = "noone@google.com"
        description = "Rule that uses outcome conditionals"

    events:
        $u.metadata.event_type = "FILE_COPY"
        $u.principal.file.size = $file_size
        $u.principal.hostname = $hostname

        // 1 = Sunday, 7 = Saturday.
        $dayofweek = timestamp.get_day_of_week($u.metadata.collected_timestamp.seconds)

    outcome:
        $risk_score =
            if($file_size > 500*1024*1024, 2) + // Files 500MB are moderately risky
            if($file_size > 1024*1024*1024, 3) + // Files over 1G get assigned extra risk

            if($dayofweek=1 or $dayofweek=7, 4) + // Events from the weekend are suspicious

            if($hostname = /highly-privileged/, 5) // Check for files from highly privileged devices

    condition:
        $u and $risk_score >= 10
}