UDM (Unified Data Model)とは

セキュリティ分析プラットフォーム（SIEM）では、さまざまな機器やサービス（Palo Alto Firewall、Active Directory、CrowdStrike、AWSなど）から多様な形式のログが送られてきます。UDMは、これらを統一されたデータ表現に変換（パース・構造化）するためのフォーマットです。

UDMの主な特徴とメリット

• 形式の統一（標準化）
  • ベンダーごとに異なる形式のログ（例：IPアドレスが src_ip や source_address 、 src など多様に表現されているケース）を、共通のフィールド名（principal.ip や target.ip など）にマッピングします。
• エンティティ主体のスキーマ設計
  • イベントに関わる要素（通信元、攻撃対象、ユーザー、プロセスなど）が明確な名詞・役割で整理されます。
  • Principal: イベントを引き起こした主体（送信元IP、実行ユーザーなど）
  • Target: イベントの対象（送信先IP、アクセス対象のファイルなど）
  • Src / Noun: 補足的な通信ポイントや関連エンティティ
• 高速な検索と相関分析の実現
  • データがUDM形式に標準化されているため、異なる製品のログを横断した検索や統合分析（「あるユーザーがEDRで検出された直後にどのWebサイトにアクセスしたか」など）を迅速に行うことができます。
• YARA-L ルールとの親和性
  • Google SecOps の脅威検知ルール言語である YARA-L は、UDMフィールドを参照して記述されます。ログがUDMに変換されていることで、高精度な検知ルールを簡単に作成・運用可能です。

UDMの基本的な構造例

UDMイベントは主に Protocol Buffers（JSONライクな構造）で表現され、以下のような要素で構成されます。

• metadata: イベントの種類、ログの生成時刻（event_timestamp）、ログソースの製品名など
• principal: アクションを実行した主体（IP、ホスト名、ユーザー名など）
• target: アクションの影響を受けた対象（IP、URL、ファイルパスなど）
• security_result: セキュリティ製品による判定結果（Block、Allow、Alertレベルなど）

例（概念図）:

JSON
{
  "metadata": {
    "event_type": "NETWORK_CONNECTION",
    "event_timestamp": "2026-09-30T00:00:00Z",
    "product_name": "Firewall"
  },
  "principal": {
    "ip": "192.168.1.50",
    "user": { "userid": "alice" }
  },
  "target": {
    "ip": "203.0.113.5",
    "port": 443
  },
  "security_result": [
    { "action": "BLOCK" }
  ]
}

補足：Chronicle Forwarderとの関係

閲覧中のページ（Netenrichのドキュメント）にある通り、Chronicle Forwarder等で収集された非構造化ログは、Chronicleに送られた後にパーサーによってこの UDM形式 に取り込まれてインデックス化されます。これにより、高度な脅威検知やダッシュボードでの可視化が可能になります。