Security Center:休眠アカウントによるログイン検知のベストプラクティス

最近のアクティビティの定義

(
  select
    user_id,
    src_ip,
    username,
    uuid,
    start_time
  from
    log
  where
    cast(start_time as bigint) >= cast(to_unixtime (current_timestamp) as bigint) - 20 * 60
    and cast(start_time as bigint) < cast(to_unixtime (current_timestamp) as bigint)
) a

• 構文解析：

  • from log：log テーブルからデータをクエリ。

  • to_unixtime(current_timestamp)：現在の Unix タイムスタンプを秒単位で返します。

  • cast(... as bigint)：タイムスタンプを数学的な演算と比較のために bigint (長整数) データ型に変換します。

  • where ...：現在時刻を終了とする 20 分間のスライディングタイムウィンドウを定義。

    • >= ... - 20 * 60：ログの開始時刻 (start_time) は、「現在時刻 - 20 分」以上である必要があります。

    • < ...：ログの開始時刻は、「現在時刻」未満である必要があります。

• 意味解析：

  • 目的：分析の対象を絞るために、「最近のアクティビティ」として a という名前のセットを定義。

  • 結果：user_id や src_ip など、過去 20 分間にアクティブだったユーザーの一時的な結果セットです。

  • キーポイント：「最近」の期間は、現在時刻から遡る 20 分間のタイムウィンドウとして正確に定義されます。

履歴ベースラインの定義

(
  select
    user_id,
    username,
    uuid
  from
    log
  where
    schema='HOST_LOGIN_ACTIVITY' and
    cast(start_time as bigint) >= cast(to_unixtime (current_timestamp) as bigint) - 24 * 3600
    and cast(start_time as bigint) < cast(to_unixtime (current_timestamp) as bigint) - 20 * 60
) b

• 構文解析：

  • schema='HOST_LOGIN_ACTIVITY'：ホストのログインアクティビティログのみをクエリすることで、履歴ベースラインの精度を向上させます。

  • where ...：24 時間前から 20 分前までの時間範囲を定義。

    • >= ... - 24 * 3600：ログの開始時刻は、「現在時刻 - 24 時間」以上である必要があります。

    • < ... - 20 * 60：ログの開始時刻は、「現在時刻 - 20 分」未満である必要があります。

• 意味解析：

  • 目的：アクティビティが異常であるかどうかを判断するための参照として、「履歴ベースライン」セット b を構築。

  • 結果：過去 1 日以内にログインしたユーザー (直近 20 分間を除く) を含む一時的な結果セットです。

  • キーポイント：このタイムウィンドウは、24 時間前から 20 分前までに設定されます。これにより、履歴ベースラインデータが最近のアクティビティデータと重複しないことが保証されるため、自己比較による論理エラーを防ぎます。

差分比較のための LEFT JOIN の使用

... a
left join
... b on a.username = b.username and a.uuid = b.uuid and a.user_id = b.user_id

• 構文解析：

  • LEFT JOIN：左テーブル (a、最近のユーザー) をベースとして使用し、その各レコードを右テーブル (b、履歴ユーザー) のレコードと照合。

  • on a.username = b.username and a.uuid = b.uuid and a.user_id = b.user_id：結合条件を指定。username、uuid、および user_id フィールドを組み合わせてユーザーエンティティを一意に識別し、正確な照合を保証します。

• 意味解析：

  • 目的：「最近のアクティビティ」(a) を「履歴ベースライン」(b) と関連付け、最近の各ユーザーアクティビティに対応する履歴ログインレコードを見つけ出します。

  • 結果：テーブル a のすべてのレコードと、ユーザー ID フィールドに基づいて正常に照合されたテーブル b のレコードを含む結合結果セットを生成。

  • キーポイント：このクエリは LEFT JOIN の非対称性を利用します。テーブル a のユーザーがテーブル b に存在しない場合、結果としてテーブル b のすべての列が NULL になります。これが、新しいアクティビティを特定するためのコアメカニズムです。

最終結果のフィルタリング

where
  (
    b.username is null
    or b.username = ''
  )

• 構文解析：

  • b.username is null：これは LEFT JOIN の特性を活用する上で重要です。最近ログインしたユーザー (テーブル a 内) が履歴ベースライン (テーブル b) に見つからない場合、b.username は NULL になります。

  • or b.username = '': これは、ログフィールドが NULL ではなく空文字列 '' となるケースに対応するための防御的条件です。

• 意味解析：

  • 目的：結合された結果をフィルタリングし、最近出現したが履歴レコードがないアクティビティを分離。

  • 結果：このフィルターが適用された後、結果セットには LEFT JOIN で一致しなかったレコード、つまり探している異常イベントのみが含まれます。

  • キーポイント：b.username is null は、検出ロジック全体の中核です。前のステップで生成された NULL 値を使用して、「最近存在し、履歴には存在しない」レコードを膨大なデータセットから分離します。

SELECT DISTINCT：アラートの出力

select distinct
     a.user_id,
     a.src_ip,
     a.username,
     a.uuid

• 構文解析：

  • SELECT DISTINCT：指定されたフィールドを選択して出力し、結果から重複を削除します。これにより、単一の異常イベントに対して 1 つのアラートのみが生成されることを保証します。

• 意味解析：

  • 目的：アラートに直接使用できる異常イベントの最終リストをフォーマットして出力。

  • 結果：重複が排除されたクリーンなアラートのリスト。各レコードには、ユーザー ID やソース IP など、異常イベントを追跡するために必要なコア情報が含まれています。

  • キーポイント：DISTINCT の使用は重要です。結果を重複排除することで、検出ウィンドウ (20 分) 内で同じユーザーによる同じ異常な動作が1つのアラートのみをトリガーすることを保証します。

最終的な SQL クエリ

*|set session mode=scan;
select distinct
     a.user_id,
     a.src_ip,
     a.username,
     a.uuid
   from
     (
       select
         user_id,
         src_ip,
         username,
         uuid,
         start_time
       from
         log
       where
         cast(start_time as bigint) >= cast(to_unixtime (current_timestamp) as bigint) -20 * 60
         and cast(start_time as bigint) < cast(to_unixtime (current_timestamp) as bigint)
     ) a
     left join (
       select
         user_id,
         username,
         uuid
       from
         log
       where
         schema='HOST_LOGIN_ACTIVITY' and
         cast(start_time as bigint) >= cast(to_unixtime (current_timestamp) as bigint) - 24 * 3600
         and cast(start_time as bigint) < cast(to_unixtime (current_timestamp) as bigint) -20 * 60
     ) b on a.username = b.username
     and a.uuid = b.uuid
     and a.user_id = b.user_id
   where
     (
       b.username is null
       or b.username = ''
     )

Agentic SOC でのルールの設定

1. Agentic SOC の購入と有効化

   購入オプションについては、「購入と有効化」をご参照ください。すべてのカスタム脅威検出サービスにアクセスするには、[ログアクセストラフィック] と [Log Storage Capacity ] の両方を購入することを推奨します。

2. コンソールにログインし、 Create Custom Rule ページに移動します

   1. にログインします。

   2. 左側のナビゲーションウィンドウで、脅威の分析と応答 > ルール管理 を選択します。コンソールの左上隅で、資産のあるリージョン ([Chinese Mainland]または[Outside Chinese Mainland]) を選択します。

   3. カスタム タブで、Create Custom Rule をクリックします。

3. アラート生成ルールの設定

   1. Create Custom Rule パネルの Basic Information タブで、ルール名と説明を入力し、次へ をクリックして Alert Settings ページに移動します。

   2. SQL 検出ルールを設定します。以下のパラメータ設定をご参照ください。

      パラメータ	値
      Rule Body	SQL
      Log Scope	ログオンログ - ホストログオン成功ログ
      SQL Query	「最終的な SQL クエリ」セクションからコードをコピーします。
      Scheduling Interval	固定間隔 - 20分
      SQL Time Window	24時間
      Start Time	ルールが有効になったとき
      Generation Structure	その他のアラートログ
      Alarm Metric	異常なログオン
      Alert Severity	中
      ATT&CK Tactic	永続化 - T1136 アカウント作成
      Entity Mapping	Network Address is_malware: 1 ip: $src_ip net_connect_dir: in Host is_asset: 1 uuid: $uuid

4. インシデント生成ルールの設定

   1. Alert Settings ページで設定を完了した後、次へをクリックして イベント生成の設定 ページに移動します。

   2. 時間ルールを設定します。以下のパラメータ設定をご参照ください。

      • Generate Event：はい。

      • Incident Generation Method：タイプ別に集約

      • Aggregation Window：20分

5. ルールの検証

   新しいルールは、デフォルトで Disabled になっています。テストして有効性を評価できます。テスト中、システムはアラートフィールドを自動的に較正します。生成された較正の提案を使用して、ルールの SQL またはプレイブックを最適化し、ルールが有効化された後のアラートの正確性と標準化を確保します。

   1. 対象ルールの Enabling Status を Testing に変更します。

   2. 対象ルールの [操作] 列で、View Alert Test Result をクリックします。

   3. テスト結果の詳細ページで、アラートのトレンドチャートと生成されたアラートのリストを表示します。

   4. アラートの [操作] 列で、[Details] をクリックして較正結果を表示します。

6. カスタムルールの有効化

   ルールがテストに合格したら、その Enabling Status を Enabled に設定します。

   重要

   ルールを有効にする前にテストすることを推奨します。