検出ルールの作成と管理
プレビュー
Lakewatchは プライベート プレビュー段階です。アクセスをリクエストするには、Databricksアカウントチームにお問い合わせください。
検出ルールは、テーブルに対して実行して異常や潜在的なセキュリティ上の脅威を識別するためのフィルターです。ルールは通常、データソースによって書き込まれた解析済みテーブルからデータを消費しますが、クエリー可能な任意のテーブルに対してランできます。ルールは、指定された条件に基づいてシグナルを識別します。
このページでは、UIで検出ルールを作成、表示、更新、管理する方法について説明します。
UIで検出ルールの作成と管理を行う
このページでは、UIでの検出ルールの構成とデプロイについて説明します。ルール実行のパラメーター、スケジュール、コンピュートリソース、およびシグナルの生成設定を構成します。
始める前に
前提条件 ：検出ロジックをすでに設計している必要があります。このページでは、本番運用環境でそのロジックがどのように実行されるかを構成します。
ワークフロー : このフォームの入力を完了すると、Lakewatchは設定に従って検出ルールをランします。一致したものはシグナルを生成します。Lakewatchはシグナルをアラートにグループ化します。アラートはアラートサイドパネルに表示され、アナリストがレビューします。Unity Catalogのsignalsシステムテーブルでシグナルを直接クエリーすることもできます。
検出ルールを作成するには？
検出ルール に移動し、 検出ルールの作成 をクリックします。フォームにはSQLとクエリーの構成が含まれており、設定は次のtabに整理されています。
- 実行： スケジュール、アクティブな状態、アラート抑制、および実行プリンシパル。
- シグナル : 出力サマリー、コンテキストフィールド、および重複排除。
- MITRE ATT&CK (オプション): 検出を MITRE ATT&CK フレームワークにマップします。
- 詳細 ：分類メタデータ（重大度、カテゴリ、忠実度、目的）。
以下のヘッダー設定は全体に適用されます：
- Genieで作成 : Genie（AIアシスタント）が検出ロジックを作成および調整するドッキングされたサイドパネルを開きます。Genieのタグライン： 「AIパートナーと連携し、検出ルールを構築、レビュー、調整します。」
- YAMLとして編集 : フォームと YAML としてのルールの編集を切り替えます。この2つは同期されたままになります。「ルールを YAML として編集」を参照してください。
- アクティブ (トグル)：ルールが有効で、そのスケジュールでランされるかどうか。
- アラート無効化の編集 (ボタン)：無効化がオンの場合、アクティブなルールは引き続き実行され、 シグナルを生成しますが、それらのシグナルによってアラートが開くことはありません。無効化を終了する まで の日時を設定します（必須）。時刻にはローカルタイムゾーンを使用し、UTCとして保存されます。
ルール構成
ルールの名前を付け、その検出ロジックを定義し、そのコンピュート warehouseを選択します：
- ルール名 (必須): ルール名を入力します。作成後に変更することはできません。
- 検出SQL （必須）：検出ロジックをインラインSQLとして記述します。検出SQLの仕組みについては、検出ルールの作成を参照してください。
- SQLウェアハウス （必須）：検出ルールは、選択したSQLウェアハウス上で、独立したジョブとして検出SQLを実行します。ルールは、クラスターのグループ化やカスタムコンピュート設定を使用しません。検出ワークロードに適したサイズのwarehouseがない場合は、「検出warehouse ガイド」を参照してください。
- 説明 （任意）：ルールの機能についての簡単な説明。例：「認証情報の詰め込みを検出」または「大容量のEメール添付ファイルを特定」。
- 実行プリンシパル (オプション): ルールが実行されるユーザーまたはService Principal。ルール作成者がdefaultになります。
実行tab
ルールの実行時間、有効かどうか、アラートを抑制する方法を構成します。
-
有効 (トグル): ルールが有効で、スケジュールに従ってランが実行されるかどうか。default: オン。
-
スケジュール (「スケジュールの編集」ボタン)：2つのスケジュールのいずれかを使用して、ルールのラン頻度を設定します。
- 少なくとも : ルールは少なくともこの頻度（最小5分）で実行されますが、場合によってはより頻繁に実行されることもあります。期間と単位（分、時間、または日）を設定します。
- 正確に : ルールはcronスケジュールで実行されます。 Every N コントロールと単位（分、時間、日、週、または月）に at コントロールを組み合わせて作成するか、 Show cron syntax を選択してQuartz cron式を直接入力します。
- どちらの方法でも、ルールは ルールと入力 ステップで選択したSQL Warehouse上で、独立したジョブとして実行されるバッチジョブです。クラスターのグループ化とコンピュート設定は適用されません。
-
アラートの無効化 （「アラートの無効化を編集」ボタン）：オンにすると、ルールは引き続き実行されてシグナルが生成されますが、それらのシグナルによってアラートが開かれることはありません。無効化が終了する 期限 の日時を設定します（必須）。時刻にはローカルタイムゾーンが使用され、 UTC として保存されます。
シグナルtab
ルールによって生成されたシグナルの形式を整え、重複排除を制御します：
サマリー
シグナルのサマリーは検出結果リストに表示され、何が検出されたかを簡潔に説明した見出しをアナリストに提供します。このフィールドを使用すると、中括弧{sql-expression}で囲まれたSQL式を使用して元のイベントからのデータを組み込むことにより、動的なアラートメッセージを作成できます。サマリー、ルールID、およびバージョンが共通するシグナルは、1つのアラートにグループ化されます。重複排除の期間内に出力行全体も一致する場合、重複分は除外されます。過剰な数のアラートが作成されるのを防ぐために、サマリーを一般的なものにし、TimestampやイベントIDのように、一致するたびにユニークな値を生成するフィールド展開を避けるようにします。
例 :
Brute force attempt detected for `{user.name}`
コンテキスト
コンテキストフィールドは、シグナルイベントに構造化メタデータをキーと値のペアとして添付します。各キーはラベルであり、各値にはイベントの詳細を挿入するための中括弧 {sql-expression} で囲まれたSQL式を含めることができます。たとえば、キーが source_ip で値が {src_endpoint.ip}のタグ。
代わりに、 すべてのデータを含める を切り替えて、シグナルをトリガーした入力行のすべての列を自動的に記録します。
重複排除
このルールによって生成された重複したシグナルをLakewatchでスキップするかどうかを制御します。重複の識別方法と時間枠の仕組みについては、シグナルの重複排除を参照してください。
- 重複排除 : オンに切り替えると、時間枠内で出力行全体が同一であるシグナルがドロップされます。オフに切り替えると、すべてのシグナルが記録されます。
- 重複排除の時間枠 ： 自動（推奨） では、ルールのスケジュールに基づいて時間枠が導出されます。カスタムウィンドウは7日を超えることはできません。
MITRE ATT&CK tab
標準化された脅威分類のために、検出結果をMITRE ATT&CKフレームワークにマッピングします：
MITRE ATT&CK®は、実世界の観測に基づく敵の戦術とテクニックの世界的にアクセス可能なナレッジベースです。ATT&CKナレッジベースは、民間セクター、政府、およびサイバーセキュリティ製品およびサービスコミュニティにおける特定の脅威モデルおよび手法の開発の基礎として使用されます。
検出がMITRE ATT&CKフレームワークにマッピングされている場合は、次のフィールドに記入して、アナリストが脅威のコンテキストを理解し、より優れた脅威ハンティングを有効にできるようにします。
追加 をクリックしてマッピングを作成し、これらのドロップダウンに入力します。適用されるマッピングを必要なだけ追加します：
- 分類 : Enterpriseなど、MITRE ATT&CKマトリックス。
- 戦術 : 攻撃者の戦術的な目標。
- テクニック ：戦術を達成するために使用される方法。
- サブテクニック ：テクニックの特定のバリエーション。
詳細tab
ルールの分類メタデータを設定します：
必須フィールド：
-
重大度 : 脅威の重大度の評価。シグナルにリスクスコアを割り当てるために使用されます。値:
Informational、Low、Medium、High、Critical。 -
カテゴリー ：検出方法を説明する分類。すべてのLakewatchワークスペースには、以下のdefaultカテゴリーが含まれます。
- 静的シグネチャ - 正確なパターン（既知のマルウェアハッシュなど）と一致するルールの場合
- ファジーシグネチャ - バリエーション許容範囲を持つパターンマッチング（例：類似したフィッシング件名）の場合
- 行動的 — アクションベースの検出用（例：権限昇格シーケンス）
- 統計的 — thresholdベースの検出用（例：異常なログイン数）
- 機械学習 (AI/ML) - MLベースの検出（例：異常検出モデル）用
ワークスペース構成でカスタムカテゴリーを追加できます。カテゴリーを使用すると、ルールを整理したり、方法論で検出をフィルタリングしたり、検出カバレッジを理解したりできます。
条件付きで必須：
- 忠実性 ：ルールの成熟度レベル。新しく作成された未テストのルールは、
DevelopmentまたはInvestigativeとしてマークする必要があります。古く十分にテストされたルールは、Highとしてマークする必要があります。これは、アナリストが信号が偽陽性である可能性を判断するのに役立ちます。値:Development、Investigative、Medium、High。（ルールの作成にのみ必要。ドラフトの場合は空欄でも可。）
オプションフィールド：
- 目的 ：詳細なルールドキュメント用の長い説明です。ルールを作成した理由、テスト方法、実装に関するメモなどを含めることができます。
- アノテーション（キーと値のペア） : カスタム構成に柔軟なタグ付けシステムを使用した追加の分類方法。
ルールを作成またはキャンセルします
必要なすべてのフィールドを記入したら、 「ルールを作成する」 をクリックして、ルールを保存してデプロイします。 [キャンセル] をクリックして、変更を破棄します。
ルールを YAML として編集
ルールフォームには、YAMLエディターを開く YAMLとして編集 ボタンが含まれています。フォームとYAMLエディターは同期されています。YAMLで行った変更はフォームに反映され、YAMLには常に現在のフォーム値が反映されます。YAMLエディターを使用してルール全体を一目で確認したり、ルールをコピーしていくつかのフィールドを調整したりできます。
ルールのYAMLはフラットなsnake_caseフィールド名を使用し、各フィールドはウィザードのコントロールにマップされます。次の例では、解析された認証イベントを読み取り、一致するログインごとにシグナルを生成するスケジュールルールを定義します。
catalog_name: security
schema_name: detections
rule_name: suspicious_login_activity
description: Detects login attempts from unusual locations.
severity: High
category: Behavioral
fidelity: FIDELITY_INVESTIGATIVE
schedule:
enabled: true
at_least_every: 1h
batch:
sql:
query: |
SELECT
time,
actor.user.name AS user_name,
src_endpoint.ip AS source_ip
FROM security.parsed.authentication_events
WHERE IN_TIMERANGE(time)
AND activity_name = 'Logon'
output:
event_time_column: time
summary: 'Suspicious login from {source_ip} by {user_name}'
context:
user_name: '{user_name}'
source_ip: '{source_ip}'
default_context: false
ルールフィールド
各フィールドは、上記で説明したウィザードコントロールにマッピングされます。フィールドの機能については、ウィザードのステップを参照してください。
YAMLフィールド | ウィザードコントロール | 必須 | 注 |
|---|---|---|---|
| カタログ | はい | ルール作成後の変更はできません。 |
| スキーマ | はい | ルール作成後の変更はできません。 |
| 名前 | はい | ルール作成後の変更はできません。 |
| 説明 | No | |
| ラン実行者ID | No | ユーザーのEメールまたはService PrincipalのアプリケーションID。デフォルトはルールの作成者です。 |
| 検出SQL | はい | 検出クエリー。 |
| コンピュート | No | ルールが実行されるSQLウェアハウスのIDです。 |
| 重要度 | はい |
|
| カテゴリー | No |
|
| 忠実性 | はい |
|
| 目的 | No | |
| MITRE ATT&CK | No | マッピングのリスト。それぞれ |
| サマリー | No |
|
| コンテキスト | No | キー/値マップ。値は |
| すべてのデータを含める | No |
|
| — | No | イベントのTimestampを保持する出力列。 |
| 重複排除 | No |
|
| 重複排除の時間枠 | No |
|
| アクティブ | No | ルールをスケジュールどおりにランするかどうか。defaultは |
| 最小頻度 | 次のうちの1つ |
|
| 次に一致： | 次のうちの1つ | 時刻指定 スケジュールのQuartz cron式。 |
| 無効化の期限 | No | ルールのシグナルがアラートを開かないTimestamp。 |
| 注釈 | No | キー/値マップ。 |