検出ルールの作成
プレビュー
Lakewatchは プライベート プレビュー段階です。アクセスをリクエストするには、Databricksアカウントチームにお問い合わせください。
検出ルールのロジックは、何を探すかを定義するSQLです。このページでは、ルールのラン方法、一般的な検出パターンのアプローチの選択方法、およびルールを適切なデータウィンドウにスコープする方法について説明します。ルールを作成するためのUIステップについては、検出ルールの作成と管理を参照してください。
検出ルールの実行方法
Lakewatch内の各検出ルールはスケジュールで実行されます。ルールがランすると、検出SQLを一定の時間枠で実行し、一致するごとにシグナルを生成します。FROM句を含む完全なクエリーを記述することで、テーブルを結合したり、テーブル全体をスキャンしたり、集計をコンピュートしたりできます。ルールは、提供されたSQL Warehouse、またはServerlessコンピュートでランされます。 検出warehouseの設定を参照してください。
ルールを作成するときに、スケジュールとコンピュートを設定します。「検出ルールの作成と管理」を参照してください。
アプローチの選択
このテーブルは、一般的な検出パターンと、それぞれの作成方法を対応付けたものです。
検出パターン | 例 | 作成方法 |
|---|---|---|
シグネチャまたはIOCの一致 | 問題があると判明したリストのプロセスハッシュ、フラグが立てられた IP への接続 | イベントを既知の不正な値のリストと照合する |
アトミックシグナル | 新しい管理者アカウント、監査ログのクリア、メールボックス転送ルールの追加 | それ自体が注目に値する単一のイベントに一致 |
短期間のthreshold | 1分以内にユーザーが5回以上ログインに失敗した、または1つのIPアドレスが10分以内に20のアカウントに対してログインに失敗した | 短いスケジュールで集計とthreshold処理を実行します |
行動のベースラインまたは異常 | 30日間の基準よりもはるかに多くのサーバーにアクセスしているユーザー | ベースラインテーブルと比較 |
まれ、または初めて検出された | これまでに確認されたことのないプロセスハッシュ。特権グループへの初回追加 | seen-listテーブルと比較 |
ソース間の相関 | ログイン、ファイル共有アクセス、データ流出、ソース間の結合 | 1時間以内のスケジュールでソース全体を結合する |
ルールを時間範囲にスコープする
可能な限り、テーブル全体をスキャンするのではなく、ルールのスコープを関連する時間範囲に設定してください。そのウィンドウを表すにはIN_TIMERANGE()関数を使用し、境界はランで指定します：
SELECT *
FROM process_activity
WHERE IN_TIMERANGE(time)
AND activity_id = 1
AND endswith(lower(process.name), '\\hashcat.exe')
IN_TIMERANGE(time) イベントのタイムスタンプが現在のランの有効な時間範囲内にある場合にtrueを返します。範囲は半開：イベントのTimestampがウィンドウの起動と等しい場合は含まれますが、終了と等しい場合は除外されます。そのため、隣接するランが境界を二重にカウントすることはありません。起動時刻と終了時刻をSQLに自分で記述することはありません。その代わりに、Lakewatchはクエリーの実行方法に基づいて範囲を提供します：
- 検出ルールでは、期間はルールのスケジュールから導出され、ランのTrigger時に終了します。15分ごとにランされるルールは、15分間のスライスをカバーします。
extend_lookbackでそのスライスを広げて、遅れて到着したLogsを含めることができます。 - クエリーページ（ルールを開発するために使用できる）で、日付/時刻ピッカーを使用してウィンドウを選択します。クエリーページに記述されたSQL自体には時間範囲が含まれていないため、そのまま検出ルールとしてデプロイできます。
ウィンドウを以下で拡張 extend_lookback
IN_TIMERANGE() イベント時間に基づいてフィルタリングを行いますが、Logsはイベント発生から数分後にテーブルに到達することがよくあります。イベント時間をカバーするウィンドウを持つランがすでに終了した 後に 行が到着する可能性があり、その後のランは新しいイベント時間をスキャンするため、カバレッジにギャップが生じます。extend_lookback はオプションのルールごとの設定で、ウィンドウの開始を早めて、各ランが古いイベント時間のスライスを再スキャンし、前回のラン以降に到着した行をキャッチできるようにします。これは最も早い境界のみをシフトし、最も遅い境界はランのTrigger時刻のままです。30s、 10m、または 2hのような期間に設定します。スケジュールされたルールがスキャンするウィンドウは、そのスケジュールの周期に extend_lookback を加えたものです：
| スケジュール | スキャンされた時間範囲（Trigger時間で終了） |
|---|---|---|
未設定 (default 15 分) | 5分ごと | 前の20分 |
| 5分ごと | 前の5分 |
| 30分ごと | 過去 42 分間 |
| 10分ごと | 過去5時間10分 |
extend_lookbackを設定しない場合、Lakewatchはdefaultの15分を適用します。ほとんどのエンタープライズソースは数分以内に配信されますが、上限を保証するものはほとんどないため、defaultでは調整なしで一般的な遅延着信を吸収します。
extend_lookback 専用のフォームフィールドはありません。ルールをYAMLとして編集し（検出ルールの作成と管理を参照）、トップレベルのtimerangeブロックを追加して設定します：
timerange:
extend_lookback: 30m
適切な時間列を選択する
extend_lookbackとペアリングされたイベント時刻（time）が、ほぼすべてのルールで適切なアプローチとなります。ソースの取り込みラグを見積もり、それをカバーするようにextend_lookbackを設定します。また、迅速に配信されるソースについては、defaultの15分を使用してください。
ソースの取り込み遅延の変動が激しく、単一のextend_lookbackでは確実にカバーできない場合は、代わりにルールを取り込み時刻で範囲指定できます。Lakewatchデータソースによって作成されたテーブルでは、lw_meta.ingestion_time列にLakewatchが取り込み後に各行を書き込んだ時刻が記録されるため、これに対するウィンドウは配信遅延の影響を受けません：
WHERE IN_TIMERANGE(lw_meta.ingestion_time)
イベント時間にextend_lookbackを足してもジョブを処理できない場合にのみ、これに到達します。各ランは、 イベント 時間ではなく、 取り込み 時間の固定スライスをカバーするため、イベント独自のTimestampがランの公称期間外になる可能性があり、これによりタイムバケット集計が歪む可能性があります。まずはイベント時間で解決するようにしてください。
NOW()へのアンカーや CURRENT_TIMESTAMP()
一般的なパターンとして、現在の経過実時間に対してウィンドウを手動で記述します。
-- Avoid this
WHERE time BETWEEN CURRENT_TIMESTAMP() - INTERVAL 24 HOUR AND CURRENT_TIMESTAMP()
これはルーチン ランには機能しますが、問題を引き起こす可能性があります:
- データが欠落したり、重複してカウントされたりする可能性があります。 「過去1時間」のようなウィンドウは、ランがトリガーされた時点に固定され、対象とするスライスには固定されません。3:00のランが3:12に遅延した場合、2:12～3:12をスキャンし、2:00～2:12のギャップを残し、次のランと重複する可能性があります。
IN_TIMERANGE()はスケジュールされたスライスから期間を導出するため、ギャップや重複のリスクを排除できます。 - スケジュール変更には対応しません。 ルールを15分ごとから30分ごとのように変更した場合、手動で編集するまで、ハードコードされた
INTERVAL 15 MINUTESは間違った値のままになります。IN_TIMERANGE()を使用すると、ウィンドウはスケジュールに従います。 - ウィンドウの再設定はできません。 欠落している期間のバックフィル、データ修正後の再生、古いデータに対する新しいルールのプレビューでは、すべて異なるウィンドウで同じルールが実行されます。
NOW()にロックされたクエリーは、手動で編集しない限りそれを行うことはできません。 - 再現が困難です。 同じ境界が与えられると、
IN_TIMERANGE()はすべてのランで同じ行をスキャンするため、結果は再現可能です。NOW()に結び付けられたクエリーは、実行されるたびに変わります。
イベントが現在からどれくらい前かを計算するなど、実際の実測時刻を参照する必要がある場合にのみ、NOW()とCURRENT_TIMESTAMP()を予約します。
ランのウィンドウを参照する TIMERANGE_NOW()
壁時計ではなくランの期間を尊重する「現在」の値が必要な場合は、TIMERANGE_NOW()を使用してください。ランのTrigger時を返し、期間が設定されていない場合（クエリーページなど）は実際の現在時刻にフォールバックします。これを使用して、IN_TIMERANGE()で表現できないウィンドウを手動で構築します（ウィンドウのオフセットや、1回のランで隣接していない2つの期間をスキャンする場合など）。
スケジュール | 述語 | 結果 |
|---|---|---|
10分ごと |
| 10分間のウィンドウを7分間過去にずらします |
毎日 |
| 今日と先週の同じ曜日のイベントが一致 |
この表は、各関数を使用する場合をまとめたものです：
目標 | 使用 |
|---|---|
ルールのスコープをその時間ウィンドウに限定する |
|
ランのウィンドウを尊重した「現在」を参照 |
|