Problemi noti e limitazioni di YARA-L 2.0
Questo documento descrive i problemi noti e le limitazioni di YARA-L 2.0.Aggregazioni dei risultati con l'estrazione dei campi ripetuti
Quando una regola fa riferimento a un campo ripetuto in una variabile evento con più elementi, ogni elemento viene suddiviso in una riga evento separata.
Ad esempio, i due indirizzi IP nel campo ripetuto target.ip dell'evento $e vengono suddivisi in due istanze di $e, ognuna con un valore target.ip diverso.
rule outbound_ip_per_app {
meta:
events:
$e.principal.application = $app
match:
$app over 10m
outcome:
$outbound_ip_count = count($e.target.ip) // yields 2.
condition:
$e
}
Record evento prima dell'estrazione del campo ripetuto
La tabella seguente mostra il record evento prima dell'annidamento del campo ripetuto:
| metadata.id | principal.application | target.ip |
|---|---|---|
aaaaaaaaa |
Google SecOps |
[192.0.2.20, 192.0.2.28] |
Record evento dopo l'estrazione del campo ripetuto
La tabella seguente mostra il record evento dopo l'estrazione del campo ripetuto:
| metadata.id | principal.application | target.ip |
|---|---|---|
aaaaaaaaa |
Google SecOps |
192.0.2.20 |
aaaaaaaaa |
Google SecOps |
192.0.2.28 |
Quando una regola fa riferimento a un campo ripetuto nidificato all'interno di un altro, ad esempio security_results.action, l'annidamento si verifica sia a livello principale che secondario. Le istanze risultanti dall'annidamento di un singolo evento formano un prodotto cartesiano degli elementi nei campi principale e secondario.
Nella seguente regola di esempio, l'evento $e con due valori ripetuti in security_results e due valori ripetuti in security_results.actions viene separato in quattro istanze.
rule security_action_per_app {
meta:
events:
$e.principal.application = $app
match:
$app over 10m
outcome:
$security_action_count = count($e.security_results.actions) // yields 4.
condition:
$e
}
Record evento prima dell'estrazione del campo ripetuto
La tabella seguente mostra il record evento prima dell'annidamento del campo ripetuto:
| metadata.id | principal.application | security_results |
|---|---|---|
aaaaaaaaa |
Google SecOps |
[ { actions: [ ALLOW, FAIL ] }, { actions: [ CHALLENGE, BLOCK ] } ] |
Record di eventi dopo l'estrazione del campo ripetuto
La tabella seguente mostra il record evento dopo l'estrazione del campo ripetuto:
| metadata.id | principal.application | security_results.actions |
|---|---|---|
aaaaaaaaa |
Google SecOps |
CONSENTI |
aaaaaaaaa |
Google SecOps |
ESITO NEGATIVO |
aaaaaaaaa |
Google SecOps |
SFIDA |
aaaaaaaaa |
Google SecOps |
BLOCCA |
Questo comportamento di annullamento del nesting nella valutazione delle regole può produrre aggregazioni di risultati impreviste quando la regola fa riferimento a uno o più campi ripetuti con un campo principale che è anche un campo ripetuto. Gli aggregati non distinti
come sum(), array() e count() non possono tenere conto dei valori duplicati
di altri campi dello stesso evento prodotti dal comportamento di unnesting. Nella seguente regola di esempio, l'evento $e ha un singolo nome host google.com, ma il risultato hostnames aggrega quattro istanze non nidificate dello stesso evento $e, ognuna con un valore principal.hostname duplicato. Questo risultato produce quattro nomi host anziché uno
a causa dell'annullamento dell'annidamento dei valori ripetuti in security_results.actions.
rule security_action_per_app {
meta:
events:
$e.principal.application = $app
match:
$app over 10m
outcome:
$hostnames = array($e.principal.hostname) // yields 4.
$security_action_count = count($e.security_results.action) // yields 4.
condition:
$e
}
Record evento prima dell'estrazione del campo ripetuto
La tabella seguente mostra il record evento prima dell'annidamento del campo ripetuto:
| metadata.id | principal.application | principal.hostname | security_results |
|---|---|---|---|
aaaaaaaaa |
Google SecOps |
google.com |
[ { action: [ ALLOW, FAIL ] }, { action: [ CHALLENGE, BLOCK ] } ] |
Record evento dopo l'estrazione ripetuta del campo
La tabella seguente mostra il record evento dopo l'estrazione del campo ripetuto:
| metadata.id | principal.application | principal.hostname | security_results.action |
|---|---|---|---|
aaaaaaaaa |
Google SecOps |
google.com |
CONSENTI |
aaaaaaaaa |
Google SecOps |
google.com |
ESITO NEGATIVO |
aaaaaaaaa |
Google SecOps |
google.com |
SFIDA |
aaaaaaaaa |
Google SecOps |
google.com |
BLOCCA |
Soluzione temporanea
Le aggregazioni che ignorano o eliminano i valori duplicati non sono interessate da questo comportamento di annidamento. Utilizza la versione distinta di un'aggregazione se riscontri valori di risultati imprevisti a causa dell'annullamento dell'annidamento.
Le seguenti aggregazioni non sono interessate dal comportamento di annidamento descritto in precedenza.
max()min()array_distinct()count_distinct()
Aggregazioni dei risultati con più variabili evento
Se una regola contiene più variabili evento, nell'aggregazione è presente un elemento separato per ogni combinazione di eventi inclusa nel rilevamento. Ad esempio, se la seguente regola di esempio viene eseguita in base agli eventi elencati:
events:
$e1.field = $e2.field
$e2.somefield = $ph
match:
$ph over 1h
outcome:
$some_outcome = sum(if($e1.otherfield = "value", 1, 0))
condition:
$e1 and $e2
event1:
// UDM event 1
field="a"
somefield="d"
event2:
// UDM event 2
field="b"
somefield="d"
event3:
// UDM event 3
field="c"
somefield="d"
La somma viene calcolata su ogni combinazione di eventi, consentendoti di utilizzare entrambe le variabili evento nei calcoli del valore del risultato. Nel calcolo vengono utilizzati i seguenti elementi:
1: $e1 = event1, $e2 = event2
2: $e1 = event1, $e2 = event3
3: $e1 = event2, $e2 = event1
4: $e1 = event2, $e2 = event3
5: $e1 = event3, $e2 = event1
5: $e1 = event3, $e2 = event2
Il risultato è una somma massima potenziale di 6, anche se $e2 può corrispondere solo a 3 eventi distinti.
Ciò influisce su somma, conteggio e matrice. Per conteggio e matrice, l'utilizzo di count_distinct
o array_distinct può risolvere il problema, ma non esiste una soluzione alternativa
per la somma.
Parentesi all'inizio di un'espressione
L'utilizzo di parentesi all'inizio di un'espressione genera il seguente errore:
parsing: error with token: ")"
invalid operator in events predicate
Il seguente esempio genererebbe questo tipo di errore:
($event.metadata.ingested_timestamp.seconds -
$event.metadata.event_timestamp.seconds) / 3600 > 1
Le seguenti varianti di sintassi restituiscono lo stesso risultato, ma con una sintassi valida:
$event.metadata.ingested_timestamp.seconds / 3600 -
$event.metadata.event_timestamp.seconds / 3600 > 1
1 / 3600 * ($event.metadata.ingested_timestamp.seconds -
$event.metadata.event_timestamp.seconds) > 1
1 < ($event.metadata.ingested_timestamp.seconds -
$event.metadata.event_timestamp.seconds) / 3600
L'array di indici nel risultato richiede l'aggregazione per i singoli valori nel campo ripetuto
L'indicizzazione degli array nella sezione dei risultati richiede ancora l'aggregazione. Ad esempio, quanto segue non funziona:
outcome:
$principal_user_dept = $suspicious.principal.user.department[0]
Tuttavia, puoi salvare l'output dell'indice dell'array in una variabile segnaposto e utilizzarla nella sezione dei risultati come mostrato qui:
events:
$principal_user_dept = $suspicious.principal.user.department[0]
outcome:
$principal_user_department = $principal_user_dept
Condizione OR con non esistenza
Se viene applicata una condizione OR tra due variabili evento distinte e se la
regola corrisponde all'inesistenza, la regola viene compilata correttamente, ma può produrre
rilevamenti di falsi positivi. Ad esempio, la seguente sintassi della regola può corrispondere
a eventi con $event_a.field = "something" anche se non dovrebbe.
events:
not ($event_a.field = "something" **or** $event_b.field = "something")
condition:
$event_a and #event_b >= 0
La soluzione alternativa consiste nel separare le condizioni in due blocchi in cui ogni blocco applica il filtro a una sola variabile, come mostrato di seguito:
events:
not ($event_a.field = "something")
not ($event_b.field = "something")
condition:
$event_a and #event_b >= 0
Aritmetica con campi evento non firmati
Se provi a utilizzare una costante intera in un'operazione aritmetica con un campo UDM il cui tipo è un numero intero senza segno, riceverai un errore. Ad esempio:
events:
$total_bytes = $e.network.received_bytes * 2
Il campo udm.network.received_bytes è un numero intero senza segno. Ciò accade perché
le costanti intere vengono impostate per impostazione predefinita su numeri interi con segno, che non funzionano con
numeri interi senza segno nelle operazioni aritmetiche.
La soluzione alternativa consiste nel forzare la costante intera a un valore mobile, che funzionerà con l'intero senza segno. Ad esempio:
events:
$total_bytes = $e.network.received_bytes * (2/1)
Coerenza finale e falsi positivi nell'arricchimento GeoIP
Il sistema dà la priorità alla velocità rispetto all'accuratezza immediata nelle fasi di arricchimento iniziali (streaming e sensibilità alla latenza), il che può portare a dati mancanti e potenziali falsi positivi. Il sistema continuerà ad arricchire i dati in background, ma questi potrebbero non essere disponibili quando viene eseguita la regola. Fa parte del normale processo di coerenza finale. Per evitare questi tipi di falsi positivi, non fare affidamento sull'esistenza di campi arricchiti negli eventi per attivare i rilevamenti.
Ad esempio, considera questo evento regola:
$e.principal.ip_geo_artifact.network.asn = "16509" AND
$e.principal.ip_geo_artifact.location.country_or_region = "United Kingdom"
La regola si basa sul fatto che l'evento deve avere $e.principal.ip_geo_artifact.network.asn = "16509" E $e.principal.ip_geo_artifact.location.country_or_region = "United Kingdom", che sono entrambi campi arricchiti. Se l'arricchimento non viene completato in tempo, la regola genererà un falso positivo.
Per evitare questo problema, un controllo migliore per questa regola sarebbe:
$e.principal.ip_geo_artifact.network.asn != "" AND
$e.principal.ip_geo_artifact.network.asn = "16509" AND
$e.principal.ip_geo_artifact.location.country_or_region != "" AND
$e.principal.ip_geo_artifact.location.country_or_region = "United Kingdom"
Questa regola elimina la possibilità che l'evento venga attivato da IP con ASN 16509 ma che si trovano al di fuori del Regno Unito. In questo modo, la precisione complessiva della regola migliora.
Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.