UEBA カテゴリのリスク分析の概要

以下でサポートされています。

このドキュメントでは、UEBA カテゴリのリスク分析のルールセットの概要、必要なデータ、各ルールセットによって生成されるアラートの調整に使用できる構成について説明します。これらのルールセットは、 Google Cloud データを使用して Google Cloud環境の脅威を特定するのに役立ちます。

ルールセットの説明

Risk Analytics for UEBA カテゴリでは、次のルールセットを使用できます。これらは、検出されたパターンのタイプごとにグループ化されています。

認証

  • New Login by User to Device: ユーザーが新しいデバイスにログインした。
  • ユーザー別の異常な認証イベント: 過去の使用状況と比較して、最近、単一のユーザー エンティティで異常な認証イベントが発生しました。
  • デバイス別の認証失敗: 単一デバイス エンティティで、過去の使用状況と比較して、最近ログインの失敗が多発している。
  • ユーザーによる認証の失敗: 単一のユーザー エンティティで、過去の使用状況と比較して、最近ログインの失敗が多発している。

ネットワーク トラフィックの分析

  • デバイス別の異常な受信バイト数: 過去の使用量と比較して、最近単一のデバイス エンティティにアップロードされたデータ量が大幅に増加しています。
  • デバイス別の異常なアウトバウンド バイト数: 過去の使用状況と比較して、最近 1 つのデバイス エンティティからダウンロードされたデータ量が大幅に増加しています。
  • デバイス別の異常な合計バイト数: デバイス エンティティが、過去の使用量と比較して、最近大量のデータをアップロードおよびダウンロードしました。
  • ユーザー別の異常な受信バイト数: 単一ユーザー エンティティが、過去の使用状況と比較して、最近大量のデータをダウンロードしました。
  • ユーザー別の異常な合計バイト数: ユーザー エンティティが、過去の使用状況と比較して、最近大量のデータをアップロードおよびダウンロードしました。
  • ブルート フォース攻撃の後にユーザーがログインに成功: 1 つの IP アドレスからの単一ユーザー エンティティが、特定のアプリケーションに対して認証の失敗を複数回試みた後、ログインに成功しました。

ピアグループに基づく検出

  • 新規作成されたユーザーの異常または過剰なログイン: 最近作成されたユーザーの異常または過剰な認証アクティビティ。これは、AD コンテキストデータの作成時間を使用します。

  • 新規作成されたユーザーの異常または過剰な不審なアクティビティ: 最近作成されたユーザーの異常または過剰なアクティビティ（HTTP テレメトリー、プロセス実行、グループの変更など）。これは、AD コンテキストデータの作成時間を使用します。

疑わしいアクション

  • デバイスによるアカウントの過剰な作成: デバイス エンティティが複数の新しいユーザー アカウントを作成しました。
  • ユーザー別の過剰なアラート: ウイルス対策デバイスまたはエンドポイント デバイスからの多数のセキュリティ アラート（接続がブロックされた、マルウェアが検出されたなど）が報告されました。これは、過去のパターンよりもはるかに大きなデータです。これは、security_result.action UDM フィールドが BLOCK に設定されているイベントです。

データ損失防止に基づく検出

  • データの引き出し機能を持つ異常なプロセスまたは過剰なプロセス: キーロガー、スクリーンショット、リモート アクセスなどのデータの引き出し機能に関連するプロセスの異常なアクティビティまたは過剰なアクティビティ。これは、VirusTotal のファイル メタデータ拡充を使用します。

UEBA カテゴリのリスク分析に必要なデータ

このセクションでは、最適なパフォーマンスを実現するために各ルールセット カテゴリで必要なデータについて詳しく説明します。UEBA 検出は、サポートされているすべてのデフォルト パーサーで動作するように設計されていますが、次の特定のデータ型を使用すると、そのメリットを最大限に活用できます。サポートされているデフォルト パーサーの一覧については、サポートされているログタイプとデフォルト パーサーをご覧ください。

認証

これらのルールセットのいずれかを使用するには、Azure AD ディレクトリ監査（AZURE_AD_AUDIT）または Windows イベント（WINEVTLOG）からログデータを収集します。

ネットワーク トラフィックの分析

これらのルールセットを使用するには、ネットワーク アクティビティをキャプチャするログデータを収集します。例: FortiGate（FORTINET_FIREWALL）、Check Point（CHECKPOINT_FIREWALL）、Zscaler（ZSCALER_WEBPROXY）、CrowdStrike Falcon（CS_EDR）、Carbon Black（CB_EDR）などのデバイスから。

ピアグループに基づく検出

これらのルールセットのいずれかを使用するには、Azure AD ディレクトリ監査（AZURE_AD_AUDIT）または Windows イベント（WINEVTLOG）からログデータを収集します。

疑わしいアクション

このグループのルールセットは、それぞれ異なる種類のデータを使用します。

デバイス　ルールセットによる過剰なアカウント作成

このルールセットを使用するには、Azure AD ディレクトリ監査（AZURE_AD_AUDIT）または Windows イベント（WINEVTLOG）からログデータを収集します。

ユーザー　ルールセットによる過剰なアラート

このルールセットを使用するには、CrowdStrike Falcon（CS_EDR）、Carbon Black（CB_EDR）、Azure AD ディレクトリ監査（AZURE_AD_AUDIT）によって記録されたエンドポイントアクティビティや監査データなど、エンドポイントのアクティビティをキャプチャするログデータを収集します。

データ損失防止に基づく検出

これらのルールセットを使用するには、CrowdStrike Falcon（CS_EDR）、Carbon Black（CB_EDR）、SentinelOne EDR（SENTINEL_EDR）などで記録されたプロセスとファイル アクティビティをキャプチャするログデータを収集します。

このカテゴリのルールセットは、metadata.event_type 値が PROCESS_LAUNCH、PROCESS_OPEN、PROCESS_MODULE_LOAD のイベントに依存します。

このカテゴリのルールセットによって返されるアラートを調整する

ルール除外を使用して、ルールまたはルールセットが生成する検出数を減らすことができます。

ルールの除外では、ルールセットまたはルールセット内の特定のルールによる評価対象からイベントを除外するために使用される条件を定義します。1 つ以上のルールの除外を作成して、検出の量を減らします。これを行う方法については、ルール除外を構成するをご覧ください。

UEBA カテゴリのリスク分析のルールの例

次の例は、リスクスコアが 100 を超えるエンティティ ホスト名で検出を生成するルールを作成する方法を示しています。

rule EntityRiskScore {
  meta:
  events:
    $e1.principal.hostname != ""
    $e1.principal.hostname = $hostname

    $e2.graph.entity.hostname = $hostname
    $e2.graph.risk_score.risk_window_size.seconds = 86400 // 24 hours
    $e2.graph.risk_score.risk_score >= 100

    // Run deduplication across the risk score.
    $rscore = $e2.graph.risk_score.risk_score

  match:
    // Dedup on hostname and risk score across a 4 hour window.
    $hostname, $rscore over 4h

  outcome:
    // Force these risk score based rules to have a risk score of zero to
    // prevent self feedback loops.
    $risk_score = 0

  condition:
    $e1 and $e2
}

この例のルールでは、一致セクションを使用して自己重複除去も実行します。ルール検出がトリガーされる可能性があるものの、ホスト名とリスクスコアが 4 時間以内に変化しない場合、新しい検出は作成されません。

エンティティ リスクスコア ルールで設定できるリスク期間は、24 時間または 7 日間（それぞれ 86,400 秒または 604,800 秒）のみです。ルールにリスク ウィンドウ サイズを含めないと、ルールは不正確な結果を返します。

エンティティ リスクスコア データは、エンティティ コンテキスト データとは別に保存されます。両方を 1 つのルールで使用するには、ルールに 2 つの個別のエンティティ イベント、1 つはエンティティ コンテキスト用、もう 1 つはエンティティ リスクスコア用が必要です。次に例を示します。

rule EntityContextAndRiskScore {
  meta:
  events:
    $log_in.metadata.event_type = "USER_LOGIN"
    $log_in.principal.hostname = $host

    $context.graph.entity.hostname = $host
    $context.graph.metadata.entity_type = "ASSET"

    $risk_score.graph.entity.hostname = $host
    $risk_score.graph.risk_score.risk_window_size.seconds = 604800

  match:
    $host over 2m

  outcome:
    $entity_risk_score = max($risk_score.graph.risk_score.normalized_risk_score)

  condition:
    $log_in and $context and $risk_score and $entity_risk_score > 100
}

次のステップ

さらにサポートが必要な場合 コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。