UEBA のリスク分析

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

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

ルールセットの説明

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

認証

  • ユーザーによるデバイスへの新しいログイン: ユーザーが新しいデバイスにログインしました。
  • ユーザーによる異常な認証イベント: 単一のユーザー エンティティで、過去の使用状況と比較して、最近異常な 認証イベントが発生しました。
  • デバイスによる認証の失敗: 単一のデバイス エンティティで、過去の使用状況と比較して、最近 ログイン試行が何度も失敗しました。
  • ユーザーによる認証の失敗: 単一のユーザー エンティティで、過去の使用状況と比較して、最近 ログイン試行が何度も失敗しました。

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

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

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

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

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

疑わしいアクション

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

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

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

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

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

認証

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

WINEVTLOG の場合は、データの収集構成を構成して、次の Windows Event IDs を Security イベントログ Channel に含める必要があります。これらのイベントは、検出エンジンで使用される Event types（USER_LOGIN や PROCESS_LAUNCH など）に直接マッピングされます。

Windows イベント ID の要件

イベントの種類 Windows イベント ID
USER_LOGIN 529, 4624, 4625, 4626, 4648, 4672, 4768, 4769, 4770, 4771, 4777, 4820, 4821, 4964
USER_CREATION 4720
NETWORK_CONNECTION 4096, 4097, 4321, 5156, 5632, 5633, 5157
GROUP_MODIFICATION 4728, 4729, 4732, 4733, 4735, 4737, 4745, 4746, 4747, 4750, 4751, 4752, 4755, 4756, 4757, 4760, 4761, 4762, 4764, 4784, 4785, 4786, 4787, 4788, 4791
PROCESS_LAUNCH 4688
PROCESS_OPEN 4663, 4670, 4691, 8002

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

これらのルールセットを使用するには、ネットワーク アクティビティをキャプチャするログデータを収集します。 例: 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 のプロフェッショナルから回答を得ることができます。