Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica del linguaggio YARA-L 2.0

Supportato in:

Google secops SIEM

YARA-L 2.0 è un linguaggio informatico utilizzato per creare regole per cercare nei dati dei log aziendali man mano che vengono importati nell'istanza Google Security Operations. La sintassi YARA-L deriva dal linguaggio YARA sviluppato da VirusTotal. Il linguaggio funziona in combinazione con il motore di rilevamento di Google SecOps e ti consente di cercare minacce e altri eventi in grandi volumi di dati.

Per ulteriori informazioni, consulta le seguenti risorse:

Regole di esempio YARA-L 2.0

Gli esempi riportati di seguito mostrano regole scritte in YARA-L 2.0. Ciascuno mostra come correlare gli eventi all'interno del linguaggio delle regole.

Regole e ottimizzazione

La seguente regola verifica la presenza di pattern specifici nei dati degli eventi e crea un rilevamento se li trova. Questa regola include una variabile $e1 per il monitoraggio del tipo di evento e il campo metadata.event_type UDM. La regola verifica la presenza di occorrenze specifiche di corrispondenze di espressioni regolari con e1. Quando si verifica l'evento $e1, viene creata una rilevazione. Nella regola è inclusa una condizione not per escludere determinati percorsi non dannosi. Puoi aggiungere not condizioni per evitare falsi positivi.

rule suspicious_unusual_location_svchost_execution
{

 meta:
   author = "Google Cloud Security"
   description = "Windows 'svchost' executed from an unusual location"
   yara_version = "YL2.0"
   rule_version = "1.0"

 events:

   $e1.metadata.event_type = "PROCESS_LAUNCH"
   re.regex($e1.principal.process.command_line, `\bsvchost(\.exe)?\b`) nocase
   not re.regex($e1.principal.process.command_line, `\\Windows\\System32\\`) nocase

condition:

   $e1
}

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 di questa regola:

Raggruppa gli eventi con il nome utente ($user) e lo restituisce ($user) quando viene trovata una corrispondenza.
L'intervallo di tempo è di 5 minuti, il che significa che vengono correlati solo gli eventi che distano meno di 5 minuti l'uno dall'altro.
Ricerca di un gruppo di eventi ($udm) il cui tipo di evento è USER_LOGIN.
Per questo 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 (indicati da #city) è maggiore di 1 nel gruppo di eventi ($udm) nell'intervallo di tempo di 5 minuti.

Creazione ed eliminazione rapide degli utenti

La seguente regola cerca gli utenti che sono stati creati ed 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 di questa regola:

Raggruppa gli eventi con il nome utente ($user) e lo restituisce ($user) quando viene trovata una corrispondenza.
La finestra temporale è di 4 ore, il che significa che vengono correlati solo gli eventi separati da meno di 4 ore.
Cerca due gruppi di eventi ($create e $delete, dove $create equivale a #create >= 1).
$create corrisponde agli eventi USER_CREATION e chiama l'ID utente come $user.
$user viene utilizzato per unire i due gruppi di eventi.
$delete corrisponde agli eventi USER_DELETION 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 di $delete si verifica dopo l'evento di $create, restituendo una corrispondenza quando viene rilevata.

Regola per singolo evento

Le regole per un singolo evento sono regole che mettono in correlazione un singolo evento. Una singola regola evento può essere:

Qualsiasi regola senza una sezione di corrispondenza.
Regola con una sezione match e una sezione condition che controllano solo l'esistenza di un evento (ad esempio, "$e", "#e > 0", "#e >= 1", "1 <= #e", "0 < #e").

Ad esempio, la seguente regola cerca un evento di accesso utente e restituirebbe il primo che incontra nei dati aziendali archiviati nel tuo account Google SecOps:

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

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

  condition:
    $e
}

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

rule SingleEventRule {
  meta:
    author = "alice@example.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
}

rule MultiEventRule{
  meta:
    author = "alice@example.com"
    description = "Rule with outcome condition and simple existence condition on one event variable"

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

  match:
    $user over 10m

  outcome:
    $num_events_in_match_window = count($e.metadata.id)

  condition:
    #e > 0 and $num_events_in_match_window >= 10 // Could be rewritten as #e >= 10
}

Regola per più eventi

Utilizza più regole per gli eventi per raggruppare molti eventi in un intervallo di tempo specificato e provare a trovare correlazioni tra gli eventi. Una tipica regola per più eventi avrà quanto segue:

Una sezione match che specifica l'intervallo di tempo in cui devono essere raggruppati gli eventi.
Una sezione condition che specifica la condizione che 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 di evento che cerca corrispondenze tra due nomi host 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 regola qualsiasi

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

rule SuspiciousIPLogins {
  meta:
    author = "alice@example.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 al confronto tra variabili $host e alla funzione regex, entrambi questi confronti non fanno distinzione tra maiuscole e minuscole.regex

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
}

Esempi di regole composite

I rilevamenti compositi migliorano il rilevamento delle minacce utilizzando regole composite. Queste regole composite utilizzano come input i rilevamenti di altre regole. Ciò consente il rilevamento di minacce complesse che le singole regole potrebbero non rilevare. Per maggiori informazioni, consulta la panoramica dei rilevamenti compositi.

Rilevamenti tripwire

I rilevamenti compositi tripwire sono la forma più semplice di rilevamento composito che opera sui campi all'interno dei risultati del rilevamento, come le variabili di risultato o i metadati delle regole. Aiutano a filtrare i rilevamenti per condizioni che potrebbero indicare un rischio maggiore, ad esempio un utente amministratore o un ambiente di produzione.

rule composite_admin_detection {
  meta:
    rule_name = "Detection with Admin User"
    author = "Google Cloud Security"
    description = "Composite rule that looks for any detections where the actor is an admin user"
    severity = "Medium"

  events:
    $rule_name = $d.detection.detection.rule_name
    $principal_user = $d.detection.detection.outcomes["principal_users"]
    $principal_user = /admin|root/ nocase

  match:
    $principal_user over 1h

  outcome:
    $risk_score = 75
    $upstream_rules = array_distinct($rule_name)

  condition:
    $d
}

Rilevamenti di soglia e aggregazione

Le regole di rilevamento composite di aggregazione consentono di raggruppare i risultati del rilevamento in base ad attributi condivisi, come un nome host o un nome utente, e analizzare i dati aggregati. Di seguito sono riportati alcuni casi d'uso comuni.

Identificare gli utenti che generano un volume elevato di avvisi di sicurezza o un rischio aggregato.
Rilevamento di host con pattern di attività insoliti mediante l'aggregazione di rilevamenti correlati.

Esempio di aggregazione dei rischi:

rule composite_risk_aggregation {
  meta:
    rule_name = "Risk Aggregation Composite"
    author = "Google Cloud Security"
    description = "Composite detection that aggregates risk of a user over 48 hours"
    severity = "High"

  events:
    $rule_name = $d.detection.detection.rule_name
    $principal_user = $d.detection.detection.outcomes["principal_users"]
    $risk = $d.detection.detection.risk_score

  match:
    $principal_user over 48h

  outcome:
    $risk_score = 90
    $cumulative_risk = sum($risk)
    $principal_users = array_distinct($principal_users)
    $upstream_rules = array_distinct($rule_name)

  condition:
    $d and $cumulative_risk > 500
}

Esempio di aggregazione delle tattiche:

rule composite_tactic_aggregation {
  meta:
    rule_name = "MITRE Tactic Aggregation Composite"
    author = "Google Cloud Security"
    description = "Composite detection that detects if a user has triggered detections over multiple mitre tactics."
    severity = "Medium"

  events:
    $principal_user = $d.detection.detection.outcomes["principal_users"]
    $tactic = $d.detection.detection.rule_labels["tactic"]
    $rule_name = $d.detection.detection.rule_name

  match:
    $principal_user over 48h

  outcome:
    $mitre_tactics_count = count_distinct($tactic)
    $mitre_tactics = array_distinct($d.detection.rule_labels["tactic"])
    $risk_score = min(100, (50+15*$mitre_tactics_count))
    $upstream_rules = array_distinct($rule_name)

  condition:
    $d and $mitre_tactics_count > 1
}

Rilevamenti compositi sequenziali

I rilevamenti compositi sequenziali identificano pattern di eventi correlati in cui la sequenza di rilevamenti è importante, ad esempio un rilevamento di un tentativo di accesso con attacco di tipo brute force, seguito da un accesso riuscito. Questi pattern possono coinvolgere più rilevamenti di base o una combinazione di rilevamenti di base ed eventi.

rule composite_bruteforce_login {
  meta:
    rule_name = "Bruteforce Login Composite"
    author = "Google Cloud Security"
    description = "Detects when an IP address associated with a Workspace brute force attempt successfully logs in"
    severity = "High"

  events:
    $bruteforce_detection.detection.detection.rule_name = /Workspace Anomalous Failed Logins/
    $bruteforce_ip = $d.detection.detection.outcomes["principal_ips"]

    $login_event.metadata.product_name = "login"
    $login_event.metadata.product_event_type = "login_success"
    $login_event.metadata.vendor_name = "Google Workspace"
    $login_ip = $login_event.principal.ip

    // Ensure the brute force detection and successful login occurred from the same IP
    $login_ip = $bruteforce_ip

    $target_account = $login_event.target.user.email_addresses

    // Ensure the brute force detection occurred before the successful login
    $bruteforce_detection.detection.detection_time.seconds < $login_event.metadata.event_timestamp.seconds

  match:
    $bruteforce_ip over 24h

  outcome:
    $risk_score = 90
    $principal_users = array_distinct($target_account)

  condition:
    $bruteforce_detection and $login_event
}

Rilevamento sensibile al contesto

I rilevamenti compositi sensibili al contesto arricchiscono i rilevamenti con un contesto aggiuntivo, come gli indirizzi IP trovati nei feed sulle minacce.

rule composite_tor_enrichment {
  meta:
    rule_name = "Detection with IP from TOR Feed"
    author = "Google Cloud Security"
    description = "Adds additional context from the TOR intel feed to detections"
    severity = "High"

  events:
    $detection_ip = $d.detection.detection.outcomes["principal_ips"]
    $gcti.graph.metadata.entity_type = "IP_ADDRESS"
    $gcti.graph.metadata.vendor_name = "Google Cloud Threat Intelligence"
    $gcti_feed.graph.metadata.source_type = "GLOBAL_CONTEXT"
    $gcti.graph.metadata.product_name = "GCTI Feed"
    $gcti.graph.metadata.threat.threat_feed_name = "Tor Exit Nodes"

    $detection_ip = $gcti.graph.entity.ip

    $rule_name = $d.detection.detection.rule_name
    $risk = $d.detection.detection.outcomes["risk_score"]

  match:
    $detection_ip, $rule_name over 1h

  outcome:
    $risk_score = 80
    $upstream_rule = array_distinct($rule_name)

  condition:
    $d and $gcti
}

Rilevamenti di co-occorrenze

I rilevamenti compositi di co-occorrenza sono una forma di aggregazione che può rilevare una combinazione di eventi correlati, ad esempio una combinazione di rilevamenti di escalation dei privilegi esfiltrazione di datiti attivati da un utente.

rule composite_privesc_exfil_sequential {
  meta:
    rule_name = "Privilege Escalation and Exfiltration Composite"
    author = "Google Cloud Security"
    description = "Looks for a detection sequence of privilege escalation followed by exfiltration."
    severity = "High"

  events:
    $privilege_escalation.detection.detection.rule_labels["tactic"] = "TA0004"
    $exfiltration.detection.detection.rule_labels["tactic"] = "TA0010"

    $pe_user = $privilege_escalation.detection.detection.outcomes["principal_users"]
    $ex_user = $exfiltration.detection.detection.outcomes["principal_users"]

    $pe_user = $ex_user

  match:
    $pe_user over 48h

  outcome:
    $risk_score = 75
    $privesc_rules = array_distinct($privilege_escalation.detection.detection.rule_name)
    $exfil_rules = array_distinct($exfiltration.detection.detection.rule_name)

  condition:
    $privilege_escalation and $exfiltration
}

Esempio di regola della finestra scorrevole

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

rule SlidingWindowRuleExample {
  meta:
    author = "alice@example.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 valori pari a zero

Rules Engine filtra implicitamente i valori pari a zero per tutti i segnaposto utilizzati nella sezione match. Per ulteriori informazioni, consulta la gestione dei valori zero nella sezione match. Questa opzione può essere disattivata utilizzando l'opzione allow_zero_values come descritto in allow_zero_values.

Tuttavia, per gli altri campi evento a cui viene fatto riferimento, i valori pari a zero non vengono esclusi, a meno che tu non specifichi esplicitamente queste condizioni.

rule ExcludeZeroValues {
  meta:
    author = "alice@example.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. The rule behaves as if the
    // predicate, `$hostname != ""` was added to the events section, because
    // `$hostname` is used in the match section.
    $hostname over 1h

  condition:
    $e1 and $e2
}

Esempio di regola con sezione `outcome`

Puoi aggiungere la sezione facoltativa outcome in una regola YARA-L 2.0 per estrarre informazioni aggiuntive di ogni rilevamento. Nella sezione delle condizioni, puoi anche specificare condizioni sulle variabili di risultato. Puoi utilizzare la sezione outcome di una regola di rilevamento per impostare le variabili per l'utilizzo downstream. Ad esempio, puoi impostare un punteggio di gravità in base ai dati degli eventi analizzati.

Per ulteriori informazioni, consulta le seguenti risorse:

Regola multi-evento con sezione dei risultati:

La seguente regola esamina due eventi per ottenere il valore di $hostname. Se il valore di $hostname corrisponde per un periodo di 5 minuti, viene applicato un punteggio di gravità. Quando includi un periodo di tempo nella sezione match, la regola esegue il controllo entro il periodo di tempo specificato.

rule OutcomeRuleMultiEvent {
    meta:
      author = "Google Cloud Security"
    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")
}

rule OutcomeRuleMultiEvent {
    meta:
      author = "alice@example.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:
      $total_network_bytes = sum($u.network.sent_bytes) + sum($u.network.received_bytes)

      $risk_score = if(total_network_bytes > 1024, 100, 50) + 
        max(
          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 dei risultati:

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

    outcome:
        $suspicious_host = $hostname
        $admin_severity = if($u.principal.userid in %admin_users, "SEVERE", "MODERATE")
        $severity_tag = if($file_size > 1024, $admin_severity, "LOW")

    condition:
        $u
}

Refactoring di una regola di esito a più eventi in una regola di esito a evento singolo.

Puoi utilizzare la sezione outcome sia per le regole a evento singolo (regole senza una sezione match) sia per le regole a più eventi (regole con una sezione match). Se in precedenza hai progettato una regola in modo che fosse multi-evento solo per poter utilizzare la sezione Risultato, puoi facoltativamente eseguire il refactoring di queste regole eliminando la sezione match per migliorare il rendimento. Tieni presente che, poiché la regola non ha più una sezione match che applica il raggruppamento, potresti ricevere più rilevamenti. Questo refactoring è possibile solo per le regole che utilizzano una variabile evento, come mostrato nell'esempio seguente.

Regola di esito multievento che utilizza una sola variabile evento (un buon candidato per il refactoring):

rule OutcomeMultiEventPreRefactor {
    meta:
      author = "alice@example.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
}

Puoi eseguire il refactoring della regola eliminando la sezione match. Tieni presente che devi rimuovere anche l'aggregazione nella sezione outcome, poiché ora la regola sarà a evento singolo. Per ulteriori informazioni sulle aggregazioni, consulta la sezione Aggregazioni dei risultati.

rule OutcomeSingleEventPostRefactor {
    meta:
      author = "alice@example.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 al segnaposto

Puoi assegnare una variabile segnaposto al risultato di una chiamata di funzione e utilizzarla in altre sezioni della regola, ad esempio nelle sezioni match, outcome o condition. Vedi il seguente esempio:

rule FunctionToPlaceholderRule {
    meta:
      author = "alice@example.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 per le condizioni del risultato

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

rule OutcomeConditionalRule {
    meta:
        author = "alice@example.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
}

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