条件セクションの構文
このドキュメントでは、YARA-L クエリの condition セクションの使用方法について説明します。condition セクションは検索とダッシュボードで使用され、ルールに必要です。結果をさらにフィルタするロジックが含まれています。検索クエリまたはダッシュボード クエリで使用すると、条件を満たす出力のみが表示されます。検出ルールで使用する場合、アラートをトリガーするには条件を満たす必要があります。
condition セクションでは、ブール演算子、比較演算子、outcome 変数の結果を使用して、クエリをトリガーするかどうかを判断できます。
condition セクションを定義する
condition セクションで、イベントとプレースホルダ変数の条件式を定義します。また、events セクションで定義されているイベントとプレースホルダの一致条件を指定することもできます。必要に応じて、and キーワードを使用して、outcome セクションで定義されている結果変数を使用して一致条件を指定します(結果セクションの構文を参照)。
式は、and または or キーワードを使用して結合できます。
条件の間には
andを使用します。orは、クエリに単一のイベント変数のみが含まれている場合にのみ使用します。
condition セクションでイベント名またはプレースホルダ変数名の前に # 文字を使用すると、events セクションのすべての条件を満たす固有のイベントまたは値の数を表すことができます。次に例を示します。
#c > 1 は、変数 c が 1 回以上出現する必要があることを意味します。
condition セクションで、結果変数の名前の前に $ 文字を使用して、その結果の値を表します。イベント名またはプレースホルダ変数名の前で使用する場合は(例: $event)、#event > 0 を表します。
このルール例では、10 分間のウィンドウ(match セクションで定義)内で、各ユーザーのログイン失敗回数が 5 回(condition セクションで定義)を超えた場合に検出を返します。
rule failed_logins
{
meta:
author = "Security Team"
description = "Detects multiple failed user logins within 10-minute windows."
severity = "HIGH"
events:
$e.metadata.event_type = "USER_LOGIN"
$e.security_result.action = "FAIL"
$user = $e.target.user.userid
match:
$user over 10m
outcome:
$failed_login_count = count($e.metadata.id)
$first_fail_time = min($e.metadata.event_timestamp.seconds)
condition:
#e >= 5
}
制限付き条件と制限なし条件
クエリでは、制限ありまたは制限なしの条件を使用できます。
境界条件により、関連付けられたイベント変数が強制的に存在します。つまり、検出によりイベントが少なくとも 1 回出現する必要があります。制限付き条件は次のとおりです。
$var // equivalent to #var > 0#var > n // where n >= 0#var >= m // where m > 0制限なし条件を使用すると、一定期間イベントが発生していないことを検出できます。たとえば、10 分以内に軽減イベントが発生していない脅威イベントなどです。制限なし条件では、関連付けられたイベント変数が存在しない(非存在クエリ)ようにできます。つまり、検出でイベントのオカレンスがない可能性があり、イベント変数でフィールドを参照するとゼロ値が返されます。
制限なし条件は次のとおりです。
!$var // equivalent to #var = 0#var >= 0#var < n // where n > 0#var <= m // where m >= 0
不在クエリの要件
不在クエリをコンパイルするには、次の要件を満たす必要があります。
- 少なくとも 1 つの UDM イベントに制限付き条件が必要です(つまり、少なくとも 1 つの UDM イベントが存在する必要があります)。
- プレースホルダに制限なし条件が設定されている場合は、少なくとも 1 つの制限付き UDM イベントに関連付ける必要があります。
- エンティティに制限なし条件がある場合は、少なくとも 1 つの制限付き UDM イベントに関連付ける必要があります。
例: 非存在クエリ
条件セクションを省略した次のクエリを考慮します。
rule NonexistenceExample {
meta:
author = "Google Security"
description = "Example: non-existence query."
events:
$u1.metadata.event_type = "NETWORK_CONNECTION" // $u1 is a UDM event.
$u2.metadata.event_type = "NETWORK_CONNECTION" // $u2 is a UDM event.
$e1.graph.metadata.entity_type = "FILE" // $e1 is an entity.
$e2.graph.metadata.entity_type = "FILE" // $e2 is an entity.
$user = $u1.principal.user.userid // Match variable is required for multi-event query.
// Placeholder Associations:
// u1 u2
// | \ /
// port ip
// | \
// e1 e2
$u1.target.port = $port
$e1.graph.entity.port = $port
$u1.principal.ip = $ip
$u2.target.ip = $ip
$e2.graph.entity.ip = $ip
// UDM-Entity Associations:
// u1 - u2
// | \ |
// e1 e2
$u1.metadata.event_type = $u2.metadata.event_type
$e1.graph.entity.hostname = $u1.principal.hostname
$e2.graph.entity.hostname = $u1.target.hostname
$e2.graph.entity.hostname = $u2.principal.hostname
match:
$user over 5m
condition:
//Add valid condition
}有効な条件セクション
条件セクションの有効な例を次に示します。
$u1 and !$u2 and $e1 and $e2- すべての UDM イベントとエンティティが条件セクションに含まれる。
- 少なくとも 1 つの UDM イベントが制限されている。
$u1 and !$u2 and $e1 and !$e2$e2は制限付きの$u1に関連付けられているため、制限なしで許可されます。$e2が$u1に関連付けられていない場合、これは無効になります。#port > 50 and #ip = 0- 条件セクションに UDM イベントとエンティティが存在しません。ただし、既存のプレースホルダは、すべての UDM イベントとエンティティに対応しています。
$ipは$u1と$u2の両方に割り当てられ、#ip = 0は制限なし条件です。ただし、制限付き条件は制限なし条件よりも強力です。$portは$u1に割り当てられており、#port > 50は制限付き条件であるため、$u1は引き続き制限付きです。
無効な条件セクション
条件セクションの無効な例を次に示します。
$u1 and $e1eventsセクションに表示されるすべての UDM イベントとエンティティは、conditionセクションに表示される必要があります(または、conditionセクションに表示されるプレースホルダが割り当てられている必要があります)。$u1, $u2, $e1, $u2, #port > 50- カンマは条件の区切り文字として使用できません。
!$u1 and !$u2 and $e1 and $e2- 少なくとも 1 つの UDM イベントが制限されるという最初の要件に違反します。
($u1 or #port < 50) and $u2 and $e1 and $e2orキーワードは、制限なし条件ではサポートされていません。($u1 or $u2) and $e1 and $e2orキーワードは、異なるイベント変数間ではサポートされていません。not $u1 and $u2 and $e1 and $e2notキーワードは、イベントとプレースホルダの条件では使用できません。#port < 50 and #ip = 0- プレースホルダはすべての UDM イベントとエンティティを参照しますが、関連付けられているすべての条件は上限がありません。つまり、UDM イベントがバインドされていないため、ルールをコンパイルできません。
結果条件
出力変数の条件は、condition セクションに含めることができます。キーワード and または or と結合するか、キーワード not が前に付加されます。
結果の条件は、結果変数のタイプに応じて異なる方法で指定します。
整数: 演算子
=, >, >=, <, <=, !=を使用して整数リテラルと比較します。次に例を示します。$risk_score > 10浮動小数点数: 演算子
=, >, >=, <, <=, !=を使用して浮動小数点リテラルと比較します。 例:$risk_score <= 5.5文字列:
=または!=の文字列リテラルと比較します。次に例を示します。$severity = "HIGH"整数のリストまたは配列:
arrays.contains関数を使用して条件を指定します。 例:arrays.contains($event_ids, "id_1234")
match セクションのあるクエリで結果条件を指定すると、そのクエリはクエリ割り当てのマルチイベント クエリとして分類されます。単一イベントとマルチイベントの分類について詳しくは、一致構文をご覧ください。
制限事項
conditionセクションでmatch変数を使用しないでください。イベントはmatch変数値によってグループ化されるため、セマンティック エラーになります。match変数が割り当てられているすべてのevent変数に非境界条件のみを指定しないでください。これはセマンティック エラーです。match変数値が返されるには、その値を含むイベントが少なくとも 1 つ存在している必要があります。スライディング ウィンドウを使用する場合、少なくとも 1 つの境界条件にピボット イベント変数が含まれていなければなりません。
次のステップ
その他の情報
さらにサポートが必要な場合 コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。