コンテキストアウェア分析の概要
Google Security Operations を使用すると、テレメトリー、エンティティ コンテキスト、関係、脆弱性を Google Security Operations アカウント内の単一の検出として表示できます。エンティティのコンテキストを利用することで、テレメトリーの動作パターンと、これらのパターンから影響を受けるエンティティのコンテキストを理解できます。
例:
- ブルート フォース ログインを試行しているアカウントの権限の表示。
- 送信ネットワーク アクティビティの送信元でもある、アセットによってホストされるデータの重要度。
このコンテキストを使用すると、検出フィルタリング、ヒューリスティックなアラートの優先順位付け、トリアージ、調査を行うことができます。
セキュリティ アナリストと検出エンジニアは通常、イベント テレメトリーの基本的なパターン(送信ネットワーク接続)に基づいて検出を作成する作業を行い、アナリストがトリアージするための多数の検出を作成します。アナリストは、アラートをトリガーするために何が起きたのか、脅威がどの程度深刻であるかを理解しようとします。
コンテキストアウェア分析では、検出のオーサリングと実行のワークフローの早い段階で高度な拡張機能が組み込まれており、次の追加機能を使用できます。
- 関連するコンテキストを、人間のトリアージ ステージではなく、検出実行時のヒューリスティックなコンテキスト リスク スコアリングで使用できるようにする
- さまざまな IT セキュリティ システム(EDR コンソール、ファイアウォール / プロキシログ、CMDB と IAM のコンテキスト、脆弱性スキャンの結果)から取得した情報のトリアージと手動で結びつける作業に費やす時間を短縮する
- アナリストや検出エンジニアが、企業にとってリスクがほとんど、あるいはまったくない脅威(サンドボックス環境でのマルウェア テスト、開発ネットワークの機密データやアクセスのない脆弱性や異常なアクティビティなど)を除外できる
Writing rules for context-aware analytics
検出エンジンのルールを使用すると、Google Security Operations アカウントのエンティティ コンテキスト データを検索できます。
エンティティ コンテキスト データを検索するには、次のことを行います。
udm または entity を使用してソースを指定します。
$eventname.[<source>].field1.field2
エンティティ コンテキストの場合、<source> は「graph」です。UDM イベントの場合、<source> は「udm」です。省略した場合、<source> はデフォルトで udm になります。エンティティ データを指定します。
$e1.graph.entity.hostname = "my-hostname"
$e1.graph.entity.relations.relationship = "OWNS"
UDM イベントデータを指定します。次のステートメントは同等です。
$e1.udm.principal.asset_id = "my_asset_id"
$e1.principal.asset_id = "my_asset_id"
エンティティ コンテキストには、UDM イベントの場合と同じ種類のルールの多くを作成できます。たとえば次のようなルールを作成できます。
マルチイベントのルール
エンティティ コンテキストと他のエンティティ コンテキストの比較
エンティティ コンテキストと UDM イベントの比較
エンティティ コンテキストの繰り返しフィールド
スライディング ウィンドウ
検出のリスクスコアの計算
UDM イベントとは異なり、エンティティ コンテキストには特定のタイムスタンプがありません。各エンティティ コンテキスト レコードには、エンティティ コンテキストが有効な時間間隔 entity.metadata.interval があります。この時間間隔は日境界ではなく、任意の期間に設定できます。
UDM イベントは、UDM イベントのタイムスタンプがエンティティ コンテキスト レコードの期間内にある場合にのみ、エンティティ コンテキスト レコードに関連付けられます。この条件が満たされない場合、UDM とエンティティは検出に関して評価されません。これは検出エンジンによって暗黙的に強制されるため、ルールの条件として指定する必要はありません。
- ウィンドウ処理を使用して UDM イベントをエンティティ コンテキストと比較する場合、エンティティ コンテキストは指定された時間枠に対する定数値を表します。
- エンティティ コンテキストによって値が変更される隣接する日単位のバケットが存在する場合、Google Security Operations は、エンティティのコンテキスト値をすべて照合して、見つかった場合はすべての一致を返すことを試行します。
ルールの例
管理者コンテキストを持つエンティティの検索
次のルールは、管理者権限にも関連付けられているエンティティを検索します。管理者権限を持つユーザーがシステムにログインまたはログアウトを試行した時刻を検索します。
rule LoginLogout {
meta:
events:
($log_inout.metadata.event_type = "USER_LOGIN" or $log_inout.metadata.event_type = "USER_LOGOUT")
$log_inout.principal.user.user_display_name = $user
$context.graph.entity.user.user_display_name = $user
$context.graph.entity.resource.attribute.roles.type = "ADMINISTRATOR"
match:
$user over 2m
condition:
$log_inout and $context
}
スライディング ウィンドウの例
次のスライディング ウィンドウの例は有効です。
rule Detection {
meta:
events:
$e1.graph.entity.hostname = $host
$e2.udm.principal.hostname = $host
match:
// Using e2 (a UDM event) as a pivot.
$host over 3h after $e2
condition:
$e1 and $e2
}
無効なスライディング ウィンドウの例
次のスライディング ウィンドウの例は無効です。スライディング ウィンドウのピボットとして、エンティティ コンテキストを使用することはできません。
rule Detection {
meta:
events:
$e1.graph.entity.hostname = $host
$e2.udm.principal.hostname = $host
match:
// Attempting to use $e1 (an entity context) as a pivot. Invalid.
$host over 3h after $e1
condition:
$e1 and $e2
}
結果セクションを使用したログインの例
次の例では、outcome
セクションを使用して検出のリスクスコアを計算しています。
rule Detection {
meta:
events:
$auth.metadata.event_type = "USER_LOGIN"
$auth.metadata.vendor_name = "Acme"
$auth.metadata.product_name = "Acme SSO"
$auth.target.user.userid = $user
$auth.target.user.termination_date.seconds > 0
$auth.metadata.event_timestamp.seconds >
$context.graph.entity.user.termination_date.seconds
$context.graph.metadata.vendor_name = "Microsoft"
$context.graph.metadata.product_name = "Azure Active Directory"
$context.graph.metadata.entity_type = "USER"
$context.graph.entity.user.userid = $user
$context.graph.entity.user.termination_date.seconds > 0
match:
$user over 15m
outcome:
$risk_score = max(
if ( $auth.metadata.event_type = "USER_LOGIN", 50) +
if (
$context.graph.entity.user.title = "Remote" nocase or
$context.graph.entity.user.title = "Temp" nocase or
$context.graph.entity.user.title = "Vendor" nocase, 40) +
if ( $context.graph.entity.user.title = "Legal" nocase, 10)
)
condition:
$auth and $context
}
不審なプロセスの起動の例
次の例では、エンティティ コンテキストとして格納された IOC コンテキスト データに対して UDM イベント プロセス データを評価しています。
rule ProcessLaunch {
meta:
events:
$ioc.graph.metadata.vendor_name = "ACME"
$ioc.graph.metadata.product_name = "IOCs"
$ioc.graph.metadata.entity_type = "FILE"
$ioc.graph.entity.file.sha256 = $hash
$process.metadata.event_type = "PROCESS_LAUNCH"
$process.principal.hostname = $hostname
(
not $process.target.process.file.sha256 = "" and
$process.target.process.file.sha256 = $hash
)
match:
$hash over 15m
condition:
$ioc and $process
}
エンティティ コンテキストの追加修飾子
エンティティ コンテキストを使用するイベント変数を作成するには、イベント名の後に <source>
を指定する必要があります。<source>
は graph
とする必要があります。
次のパターンは、エンティティ コンテキストを参照します。
$e.graph.entity.hostname
UDM イベントを参照する同等の方法として、以下の 2 つがあります。
$u.udm.principal.asset_id
$u.principal.asset_id
ルールテキストでは、これらの修飾子をすべて組み合わせて一致させることができます。同じイベントに対して異なる修飾子を使用することもできます。
結果セクション
検出エンジンは、ルールから詳細情報を取得できる outcome
セクションをサポートしています。outcome
セクションで定義されたロジックは、検出ごとに評価されます。ルールで N 個の検出結果を生成すると、N 個の検出のそれぞれが異なる結果に場合があります。
outcome
セクションを使用するルールの例については、こちらをご覧ください。
outcome
セクションの詳細な使用法と構文については、こちらのセクションをご覧ください。
結果セクションと検出結果の重複除去 / 検出結果のグループ化
一致セクションがあるルールの場合は、別の箇所で説明したように検出結果は一致変数によって「グループ化」されます。これによって、一連の個別の一致変数と時間枠ごとに 1 つの行が返されるように、検出結果の重複が除去されます。
この重複除去では結果の変数は無視されます。したがって、一致変数と時間枠の値が同じ 2 つの異なる検出結果があり、結果変数の値が異なる場合、重複は除外され、検出は 1 つだけ表示されます。これは、たとえば、到着が遅れたデータが原因で検出が作成された場合に発生することがあります。以下に、このケースを説明する例を示します。
rule ExampleOutcomeRule {
...
match:
$hostname over <some window>
outcome:
$risk_score = <some logic here>
...
}
このルールでの一致結果は次のとおりです。
検出 1: ホスト名: test-hostname 時間枠: [t1, t2] risk_score: 10
検出 2: ホスト名: test-hostname 時間枠: [t1, t2] risk_score: 73
一致変数と時間枠は検出 1 と検出 2 で同じであるため、重複が除去され、結果変数(risk_score)は異なっていても、1 つの検出結果のみが表示されます。
次のステップ
Google Security Operations でコンテキスト データを取り込み、エンティティを強化する方法については、Google Security Operations がイベントとエンティティ データを強化する方法をご覧ください。