統合データモデルの概要

このドキュメントでは、統合データモデル（UDM）の概要について説明します。UDM フィールドの個別の説明を含む詳細については、UDM フィールド リストをご覧ください。パーサー マッピングの詳細については、パーサー マッピングに関する重要な UDM フィールドをご覧ください。

UDM は、ソースから受信したデータに関する情報を保存する Google Security Operations の標準データ構造です。これはスキーマとも呼ばれます。Google Security Operations は、受信した元のデータを、元の未加工ログと構造化 UDM レコードの 2 つの形式で保存します。UDM レコードは、元のログの構造化された表現です。

指定されたログタイプに対してパーサーが存在する場合は、未加工のログを使用して UDM レコードが作成されます。Ingestion API を使用して Google Security Operations にデータを送信する前に、未加工ログを構造化 UDM 形式に変換することもできます。

UDM には次のような利点があります。

• 同じセマンティクスを使用して、異なるベンダーの同じタイプのレコードを保存します。
• データは標準の UDM スキーマに正規化されるため、ユーザー、ホスト、IP アドレスの関係を簡単に識別できます。
• ルールはプラットフォームに依存しないため、ルールを簡単に作成できます。
• 新しいデバイスのログタイプを簡単にサポートできます。

注: Google Security Operations ルールエンジンは、同じ UDM フィールド名を使用します。ルールを作成するときに、これらの同じフィールド名を使用できます。

未加工ログ検索を使用してイベントを検索できますが、その特異性のために、UDM 検索によってより高速で正確な検索を行うことができます。

Google Security Operations は、収集するすべてのイベントに UDM スキーマを使用します。UDM には、イベントの記述と分類に使用される数千のフィールドが含まれています。 たとえば、UDM はネットワーク通信イベントと同じくらい簡単にエンドポイント プロセス イベントを処理できます。

UDM の構造

UDM イベントは複数のセクションで構成されます。すべての UDM イベントで最初に見つかるセクションは、metadata セクションです。イベントが発生したときのタイムスタンプや、Google Security Operations に取り込まれたときのタイムスタンプなど、イベントの基本的な説明を提供します。この情報には、プロダクト情報、バージョン、説明も含まれます。取り込みパーサーは、特定のプロダクト ログとは関係なく、事前定義されたイベントタイプに基づいて各イベントを分類します。メタデータ フィールドのみを使用して、データの検索をすばやく開始できます。

metadata セクションに加えて、他のセクションではイベントに関するその他の側面について説明します。不要なセクションは含まれず、メモリを節約できます。

• principal: イベント内のアクティビティを生成するエンティティ。 ソース（src）と宛先（target）を参照するセクションも含まれます。
• intermediary: プロキシ サーバーや SMTP リレーなど、イベントが通過するシステム。
• observer: トラフィックをパッシブにモニタリングするパケット スニファーなどのシステム。

UDM 検索の例

このセクションでは、UDM 検索の基本的な構文、特徴、機能を示す UDM 検索の例を示します。

例: 成功した Microsoft Windows 4624 ログインを検索する

次の検索では、2 つの UDM フィールドのみに基づいて、成功した Microsoft Windows 4624 ログイン イベントと、そのイベントの生成日時が一覧表示されます。

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624"

例: 成功したすべてのログインを検索する

次の検索では、ベンダーやアプリケーションに関係なく、成功したすべてのログイン イベントが一覧表示されます。

metadata.event_type = "USER_LOGIN" AND security_result.action = "ALLOW" AND target.user.userid != "SYSTEM" AND target.user.userid != /.*$/

例: 成功したユーザー ログインを検索する

次の例は、userid "fkolzig" を検索し、このユーザー ID を持つユーザーがログインに成功したかどうかを判別する方法を示しています。この検索は、target セクションを使用して完了できます。target セクションには、ターゲットを記述するサブセクションとフィールドが含まれます。たとえば、この場合のターゲットはユーザーであり、関連する多くの属性がありますが、ターゲットはファイル、レジストリ設定、またはアセットになる場合もあります。この例では、target.user.userid フィールドを使用して "fkolzig" を検索します。

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624" AND target.user.userid = "fkolzig"

例: ネットワーク データを検索する

次の例では、target.port のある RDP イベントのネットワーク データを検索します。

3389 と 35.235.240.5 のprincipal.ip。また、network セクションの UDM フィールド、データの方向（network.direction）も含まれます。

metadata.product_event_type = "3" AND target.port = 3389 AND network.direction = "OUTBOUND" and principal.ip = "35.235.240.5"

例: 特定のプロセスを検索する

サーバーで作成されたプロセスを調べるには、net.exe コマンドのインスタンスを検索し、予想されるパスでこの特定のファイルを検索します。検索するフィールドは target.process.file.full_path です。この検索では、target.process.command_line で発行された特定のコマンドを含めます。

] フィールドに入力します。また、about セクションにフィールドを追加することもできます。これは、Microsoft Sysmon イベントコード 1（ProcessCreate）の説明です。

UDM 検索は次のとおりです。

metadata.product_event_type = "1" AND target.process.file.full_path = "C:\Windows\System32\net.exe"

必要に応じて、次の UDM 検索フィールドを追加できます。

• principal.user.userid: コマンドを発行したユーザーを特定します。
• principal.process.file.md5: MD5 ハッシュを特定します。
• principal.process.command_line: コマンドライン。

例: 特定の部門に関連付けられた成功したユーザー ログインを検索する

次の例では、社内のマーケティング部門（target.user.department が marketing）に関連付けられているユーザー（metadata.event_type が USER_LOGIN）によるログインを検索します。target.user.department はユーザーのログイン イベントと直接関係しませんが、ユーザーに関して取り込まれる LDAP データには依然として存在します。

metadata.event_type = "USER_LOGIN" AND target.user.department = "Marketing"

論理オブジェクト: イベントとエンティティ

UDM スキーマは、データを格納する使用可能なすべての属性を記述します。各 UDM レコードは、イベントとエンティティのどちらを記述するかを識別します。データは、レコードによってイベントとエンティティのどちらが書き込まれるか、また、metadata.event_type フィールドと metadata.entity_type フィールドにどの値が設定されるかに応じて、異なるフィールドに保存されます。

• UDM イベントは、環境で発生したアクションのデータを保存します。元のイベントログには、ファイアウォールやウェブプロキシなど、デバイスによって記録されたアクションが記述されます。これは UDM イベント データモデルです。
• UDM Entity: 環境内のアセット、ユーザー、リソースなどの要素のコンテキスト表現。これは信頼できるデータソースから取得されます。これは UDM Entity データモデルです。

以下に、イベント データモデルとエンティティ データモデルの 2 つの視覚表現の概要を示します。

図: イベント データモデル

注: Noun という用語は、属性のタイプを表します。principal、target、src、intermediary、observer、about という用語は、データが保存されるフィールド名です。

図: エンティティ データモデル

注: Noun という用語は、属性のタイプを表します。asset、user、resource という用語は、データが格納されるフィールド名です。

UDM イベントの構造

UDM イベントには複数のセクションが含まれ、各セクションに 1 つのレコードのデータのサブセットが保存されます。セクションは次のとおりです。

• メタデータ
• プリンシパル
• ターゲット
• src
• observer
• intermediary
• 概要
• ネットワーク
• security_result

• extensions

  

  図: イベント データモデル

metadata セクションは、タイムスタンプを保存し、event_type を定義し、デバイスを説明します。

principal、target、src、observer、intermediary セクションには、イベントに関連するオブジェクトに関する情報が保存されます。オブジェクトはデバイス、ユーザー、またはプロセスです。ほとんどの場合、これらのセクションのサブセットのみが使用されます。データを保存するフィールドは、イベントの種類と各オブジェクトがイベントで果たす ロール によって決まります。

network セクションには、メールやネットワーク関連の通信など、ネットワーク アクティビティに関連する情報が保存されます。

• メールデータ: to、from、cc、bcc、その他のメール フィールドの情報。
• HTTP データ: method、referral_url、useragent など。

security_result セクションには、ウイルス対策プロダクトなどのセキュリティ プロダクトによって記録されたアクションまたは分類が保存されます。

about セクションと extensions セクションには、他のセクションで取得されていない追加のベンダー固有のイベント情報が保存されます。extensions セクションは、自由形式の Key-Value ペアのセットです。

各 UDM イベントには、1 つの元の未加工ログイベントの値が保存されます。イベントのタイプに応じて、必須の属性と省略可能な属性があります。必須属性と省略可能属性は、metadata.event_type 値によって決まります。Google Security Operations は、metadata.event_type を読み取り、ログの受信後にそのイベントタイプに固有のフィールド検証を行います。

extensions セクションなど、UDM レコードのセクションにデータが格納されていない場合、そのセクションは UDM レコードに表示されません。

metadata フィールド

このセクションでは、UDM イベントの必須項目について説明します。

event_timestamp フィールド

UDM イベントには、metadata.event_timestamp のデータ（イベントが発生したときの GMT タイムスタンプ）が含まれている必要があります。値は、RFC 3339 または Proto3 のいずれかのタイムスタンプの標準を使用してエンコードする必要があります。

次の例は、RFC 3339 形式 yyyy-mm-ddThh:mm:ss+hh:mm（年、月、日、時、分、秒、および UTC 時間からのオフセット）を使用してタイムスタンプを指定する方法を示しています。ここでは UTC からのオフセットがマイナス 8 時間（PST）です。

metadata {
  "event_timestamp": "2019-09-10T20:32:31-08:00"
}

metadata {
  event_timestamp: "2021-02-23T04:00:00.000Z"
}

エポック形式を使用して値を指定することもできます。

metadata {
event_timestamp: {
  "seconds": 1588180305
 }
}

event_type フィールド

UDM イベントの最も重要なフィールドは metadata.event_type です。 この値は、実行されるアクションのタイプを識別し、ベンダー、プロダクト、プラットフォームには依存しません。値の例には、PROCESS_OPEN、FILE_CREATION、USER_CREATION、NETWORK_DNS などがあります。全一覧については、UDM フィールド リストのドキュメントをご覧ください。

metadata.event_type の値によって、UDM レコードに含める必要がある追加の必須フィールドとオプション フィールドが決まります。各イベントタイプに含めるフィールドについては、UDM 使用ガイドをご覧ください。

principal、target、src、intermediary、observer の各属性

principal、target、src、intermediary、observer の各属性は、イベントに関連するアセットを記述します。それぞれには、元の未加工ログに記録されている、アクティビティに関連するオブジェクトに関する情報が保存されます。これは、アクティビティを実行したデバイスやユーザー、またはアクティビティのターゲットとなるデバイスまたはユーザーです。メール プロキシやネットワーク ルーターなど、アクティビティをモニタリングしたセキュリティ デバイスを説明する場合もあります。

最も頻繁に使用されている属性は次のとおりです。

• principal: アクティビティを実行したオブジェクト。
• src: アクティビティを開始するオブジェクト（プリンシパルと異なる場合）。
• target: 対象となるオブジェクト。

すべてのイベントタイプでは、これらのフィールドの少なくとも 1 つにデータが含まれている必要があります。

補助フィールドは次のとおりです。

• intermediary: イベントで仲介役として機能したオブジェクト。これには、プロキシ サーバーやメールサーバーなどのオブジェクトが含まれる場合があります。
• observer: 対象のトラフィックと直接やり取りしないオブジェクト。これは、脆弱性スキャナやパケット スニファー デバイスの場合があります。
• about: イベントで役割を果たした他のオブジェクト（省略可）。

principal 属性

アクティビティを発生させる主体となったエンティティまたはデバイスを表します。principal には、マシンの詳細（ホスト名、MAC アドレス、IP アドレス、CrowdStrike のマシンの GUID などのプロダクト固有の識別子）またはユーザーの詳細（ユーザー名など）を 1 つ以上含める必要があります。オプションでプロセスの詳細を含めることもできます。メール、ファイル、レジストリのキーまたは値のフィールドを含めることはできません。

イベントが単一のマシンで発生する場合、そのマシンについては、principal 属性でのみ記述されます。target または src 属性でマシンを記述する必要はありません。

注: セキュリティ デバイスはイベントを記録する場合がありますが、principal 属性に記述されません。オブザーバー属性または中間属性で記述されます。アクティビティが発生したデバイス上でセキュリティ ソフトウェア（Carbon Black など）が実行されている場合（Windows エンドポイントでマルウェアが検出された場合など）、Windows デバイスがプリンシパルになります。

次の JSON スニペットは、principal 属性がどのように入力されるかを示しています。

"principal": {
  "hostname": "jane_win10",
  "asset_id" : "Sophos.AV:C070123456-ABCDE",
    "ip" : "10.10.2.10",
    "port" : 60671,
    "user": {  "userid" : "john.smith" }
}

この属性は、イベントでプリンシパル アクターであったデバイスとユーザーに関する既知の情報をすべて記述します。この例には、デバイスの IP アドレス、ポート番号、ホスト名が含まれています。また、ベンダー固有のアセット識別子（Sophos の識別子）も含まれています。これは、サードパーティのセキュリティ プロダクトによって生成された固有の識別子です。

target 属性

イベントで参照されるターゲット デバイス、またはそのターゲット デバイス上のオブジェクトを表します。たとえば、デバイス A からデバイス B へのファイアウォール接続では、デバイス A は principal としてキャプチャされ、デバイス B は target としてキャプチャされます。

プロセス C からターゲット プロセス D へのプロセス インジェクションの場合、プロセス C が principal、プロセス D が target になります。

図: principal と target

以下の例は、target フィールドに値を入力する方法を示しています。

target {
   ip: "192.0.2.31"
   port: 80
}

ホスト名、追加の IP アドレス、MAC アドレス、独自のアセット識別子など、元の未加工ログに追加情報がある場合は、ターゲット フィールドとプリンシパル フィールドに含める必要もあります。

principal と target はどちらも、同じマシン上のアクターを表すことができます。たとえば、マシン X で実行されているプロセス A（principal）は、同じマシン X でのプロセス B（target）を処理できます。

src 属性

関与しているエンティティによって処理されるソース オブジェクト、およびソース オブジェクトのデバイスとプロセスのコンテキスト（ソース オブジェクトが存在するマシン）を表します。たとえば、ユーザー U がマシン X 上のファイル A をマシン Y 上にファイル B としてコピーする場合、ファイル A とマシン X の両方を UDM イベントの src に指定します。

intermediary 属性

イベントに記述されるアクティビティを処理する、1 つ以上の中間デバイスの詳細を表します。これには、プロキシ サーバーや SMTP リレーサーバーなどのデバイスに関するデバイスの詳細が含まれます。

observer 属性

直接の仲介ではなく、対象のイベントを監視して報告するオブザーバー デバイスを表します。これには、パケット スニファーやネットワーク ベースの脆弱性スキャナが含まれる場合があります。

about 属性

この属性は、principal、src、target、intermediary、または server のフィールドで説明されていないイベントによって参照されるオブジェクトの詳細が保存されます。たとえば、次の対象をキャプチャできます。

• メールの添付ファイル
• メール本文に埋め込まれているドメイン、URL、IP アドレス。
• PROCESS_LAUNCH イベント中に読み込まれる DLL。

security_result 属性

このセクションには、セキュリティ システムによって検出されるセキュリティ リスクや脅威と、それらのリスクや脅威を低減するために行ったアクションが含まれます。

security_result 属性に格納される情報の種類は次のとおりです。

• メール セキュリティ プロキシがフィッシング攻撃（security_result.category = MAIL_PHISHING）を検出し、メールをブロック（security_result.action = BLOCK）しました。
• メールのセキュリティ プロキシ ファイアウォールが、ウイルスに感染した添付ファイルを 2 つ検出し（security_result.category = SOFTWARE_MALICIOUS）、これらの添付ファイルを検疫してウイルス駆除（security_result.action = QUARANTINE または security_result.action = ALLOW_WITH_MODIFICATION）した後、ウイルス駆除したメールを転送しました。
• SSO システムは、ブロックされた（security_result.action = BLOCK）ログイン（security_result.category = AUTH_VIOLATION）を許可します。
• マルウェア サンドボックスは、ファイルがユーザーの受信トレイに配信されて（security_result.action = ALLOW）から 5 分後に、添付ファイル内のスパイウェア（security_result.category = SOFTWARE_MALICIOUS）を検出しました。

network 属性

network 属性には、ネットワーク関連のイベントに関するデータと、サブメッセージ内のプロトコルの詳細が保存されます。これには、送受信されるメールや HTTP リクエストなどのアクティビティが含まれます。

extensions 属性

この属性の下のフィールドには、元の未加工のログにキャプチャされたイベントに関する追加のメタデータが保存されます。脆弱性に関する情報や追加の認証に関連する情報が含まれる可能性があります。

UDM エンティティの構造

UDM エンティティ レコードには、組織内のエンティティに関する情報が保存されます。metadata.entity_type が USER の場合、レコードには、entity.user 属性にユーザーに関する情報が保存されます。metadata.entity_type が ASSET の場合、レコードには、ワークステーション、ノートパソコン、スマートフォン、仮想マシンなどのアセットに関する情報が保存されます。

図: イベント データモデル

metadata フィールド

このセクションでは、UDM エンティティに必要となる次のようなフィールドについて説明します。

• collection_timestamp: レコードが収集された日時。
• entity_type: エンティティのタイプ（アセット、ユーザー、リソースなど）。

entity 属性

entity 属性の下のフィールドには、特定のエンティティに関する情報（アセットの場合はホスト名や IP アドレス、ユーザーの場合は windows_sid やメールアドレスなど）が保存されます。フィールド名は「entity」ですが、フィールド タイプは Noun です。Noun は、エンティティとイベントの両方に情報を保存する、一般的に使用されるデータ構造です。

• metadata.entity_type が USER の場合、データは entity.user 属性の下に保存されます。
• metadata.entity_type が ASSET の場合、データは entity.asset 属性の下に保存されます。

relation 属性

relation 属性の下にあるフィールドには、primary エンティティが関連付けられている他のエンティティに関する情報が保存されます。たとえば、primary エンティティがユーザーで、ユーザーにノートパソコンが発行された場合。ノートパソコンは関連性を持つエンティティです。 ノートパソコンに関する情報は、metadata.entity_type = ASSET を持つ「エンティティ」レコードとして保存されます。ユーザーに関する情報は、metadata.entity_type = USER を持つ「エンティティ」レコードとして保存されます。

また、ユーザー エンティティ レコードは、「relation」属性の下にあるフィールドを使用してユーザーとノートパソコンの関係を取得します。relation.relationship フィールドには、ユーザーとノートパソコンの関係（具体的には、ユーザーがノートパソコンを所有すること）が保存されます。relation.entity_type フィールドには値 ASSET が保存されます。これは、ノートパソコンがデバイスであるためです。

relations.entity 属性の下のフィールドには、ノートパソコンに関する情報（ホスト名や MAC アドレスなど）が保存されます。ここでも、フィールド名が「entity」で、フィールド タイプが Noun であることがわかります。Noun は一般的に使用されるデータ構造です。relation.entity 属性の下のフィールドには、ノートパソコンに関する情報が保存されます。

relation.direction フィールドには、ユーザーとノートパソコンの関係の方向性（具体的にはその関係が双方向か単方向か）が保存されます。