YARA-L の既知の問題と制限事項
このドキュメントでは、YARA-L の既知の問題と制限事項について説明します。
繰り返しフィールドのネスト解除を使用した結果の集計
ルールでイベント変数の繰り返しフィールドを参照し、その繰り返しフィールドに複数の要素が含まれている場合、各要素は個別のイベント行にネスト解除されます。
たとえば、次のルールのイベント $e
の繰り返しフィールド target.ip
にある 2 つの IP アドレス文字列は、それぞれが異なる target.ip
要素を持つイベント $e
の 2 つのインスタンスにネスト解除されます。
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
}
繰り返しフィールドのネスト解除前のイベント レコード
次の表は、繰り返しフィールドのネスト解除前のイベント レコードを示しています。
metadata.id | principal.application | target.ip |
---|---|---|
aaaaaaaaa |
Google SecOps |
[192.0.2.20 、192.0.2.28] |
繰り返しフィールドのネスト解除後のイベント レコード
次の表は、繰り返しフィールドのネスト解除後のイベント レコードを示しています。
metadata.id | principal.application | target.ip |
---|---|---|
aaaaaaaaa |
Google SecOps |
192.0.2.20 |
aaaaaaaaa |
Google SecOps |
192.0.2.28 |
ルールで、security_results.action
のような別の繰り返しフィールドの子である繰り返しフィールドを参照する場合、ネスト解除は親フィールド レベルと子フィールド レベルの両方で行われます。単一イベントからネスト解除されたインスタンスのセットは、親フィールド内の要素と子フィールド内の要素のデカルト積です。
次の例のルールでは、security_results
に 2 つの繰り返し値があり、security_results.actions
に 2 つの繰り返し値を持つイベント $e
が、4 つのインスタンスにネスト解除されます。
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
}
繰り返しフィールドのネスト解除前のイベント レコード
次の表は、繰り返しフィールドのネスト解除前のイベント レコードを示しています。
metadata.id | principal.application | security_results |
---|---|---|
aaaaaaaaa |
Google SecOps |
[ { actions: [ ALLOW, FAIL ] } 、{ actions: [ CHALLENGE, BLOCK ] } ] |
繰り返しフィールドのネスト解除後のイベント レコード
次の表は、繰り返しフィールドのネスト解除後のイベント レコードを示しています。
metadata.id | principal.application | security_results.actions |
---|---|---|
aaaaaaaaa |
Google SecOps |
許可する |
aaaaaaaaa |
Google SecOps |
FAIL |
aaaaaaaaa |
Google SecOps |
CHALLENGE |
aaaaaaaaa |
Google SecOps |
ブロック |
ルール評価におけるこのネスト解除の動作により、ルールが繰り返しフィールドでもある親フィールドを持つ 1 つ以上の繰り返しフィールドを参照する場合、予期しない結果の集計が発生する可能性があります。sum()
、array()
、count()
などの個別でない集計では、ネスト解除の動作によって生成された同じイベントにおける他のフィールドの重複値は考慮できません。次の例のルールでは、イベント $e
に単一のホスト名 google.com
がありますが、結果 hostnames
は同じイベント $e
のネストされていない 4 つのインスタンスに集計され、それぞれ重複した principal.hostname
値を持ちます。security_results.actions
で繰り返し値がネスト解除されるため、この結果では、1 つではなく 4 つのホスト名が生成されます。
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
}
繰り返しフィールドのネスト解除前のイベント レコード
次の表は、繰り返しフィールドのネスト解除前のイベント レコードを示しています。
metadata.id | principal.application | principal.hostname | security_results |
---|---|---|---|
aaaaaaaaa |
Google SecOps |
google.com |
[ { action: [ ALLOW, FAIL ] } 、{ action: [ CHALLENGE, BLOCK ] } ] |
繰り返しフィールドのネスト解除後のイベント レコード
次の表は、繰り返しフィールドのネスト解除後のイベント レコードを示しています。
metadata.id | principal.application | principal.hostname | security_results.action |
---|---|---|---|
aaaaaaaaa |
Google SecOps |
google.com |
許可する |
aaaaaaaaa |
Google SecOps |
google.com |
FAIL |
aaaaaaaaa |
Google SecOps |
google.com |
CHALLENGE |
aaaaaaaaa |
Google SecOps |
google.com |
ブロック |
回避策
重複する値を無視する集計や、重複する値を削除する集計は、このネスト解除の動作の影響を受けません。ネスト解除によって予期しない結果値が発生している場合は、個別のバージョンの集計を使用します。
次の集計は、前述のネスト解除の動作の影響を受けません。
max()
min()
array_distinct()
count_distinct()
複数のイベント変数を使用した結果の集計
ルールに複数のイベント変数が含まれている場合は、検出に含まれるイベントの組み合わせごとに、集計に別々の項目があります。たとえば、次のサンプル ルールを、リストされたイベントに対して実行するとします。
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"
合計はイベントのすべての組み合わせで計算されるため、結果の値の計算では両方のイベント変数を使用できます。計算には次の要素が使用されます。
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
これにより、$e2 が 3 つの異なるイベントにのみ対応する場合でも、とりうる最大合計値は 6 になります。
これは、sum、count、array に影響します。count と array では、count_distinct
または array_distinct
を使用して問題を解決できますが、現在、sum に対する代替策はありません。
式の先頭の括弧
式の先頭で括弧を使用すると、次のエラーが発生します。
parsing: error with token: ")"
invalid operator in events predicate
次の例では、このようなエラーが生成されます。
($event.metadata.ingested_timestamp.seconds -
$event.metadata.event_timestamp.seconds) / 3600 > 1
次の構文バリエーションは同じ結果を返しますが、構文は有効です。
$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
結果のインデックス配列では繰り返しフィールドの単一値の集計が必要
結果セクションの配列のインデックス化には引き続き集計が必要です。 たとえば、以下は機能しません。
outcome:
$principal_user_dept = $suspicious.principal.user.department[0]
ただし、配列インデックスの出力をプレースホルダ変数に保存し、ここに示すように、結果変数でその変数を使用できます。
events:
$principal_user_dept = $suspicious.principal.user.department[0]
outcome:
$principal_user_department = $principal_user_dept
または、存在しない OR 条件
2 つの別々のイベント変数間で OR 条件が適用され、ルールの一致が存在しない場合に、ルールは正常にコンパイルされますが、誤って正の検出が発生する可能性があります。たとえば、次のルール構文は $event_a.field = "something"
を持つイベントと、一致すべきでなくても、一致する可能性があります。
events:
not ($event_a.field = "something" **or** $event_b.field = "something")
condition:
$event_a and #event_b >= 0
回避手段は、条件が 2 つのブロックに分け、ここで各ブロックはここで示すように単一の変数にのみフィルタを適用することです。
events:
not ($event_a.field = "something")
not ($event_b.field = "something")
condition:
$event_a and #event_b >= 0
符号なしイベント フィールドを使用した算術
UDM フィールドの型が符号なし整数の算術演算で整数定数を使用しようとすると、エラーが発生します。次に例を示します。
events:
$total_bytes = $e.network.received_bytes * 2
フィールド udm.network.received_bytes
は符号なし整数です。これは、整数定数がデフォルトで符号付き整数であるために発生します。符号付き整数は、算術演算では符号なし整数では機能しません。
この問題を回避するには、整数定数を強制的に浮動小数点数にします。こうすることで、符号なし整数でも使用できるようになります。次に例を示します。
events:
$total_bytes = $e.network.received_bytes * (2/1)