このページは Cloud Translation API によって翻訳されました。

統合データモデルの概要

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

Google SecOps SIEM

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

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

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

UDM のメリットは次のとおりです。

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

未加工ログ検索を使用してイベントを検索できますが、その特異性のために、UDM 検索によってより高速で正確な検索を行うことができます。Google SecOps は未加工のログデータを収集し、イベントログの詳細を UDM スキーマに保存します。UDM は、エンドポイントプロセスイベントやネットワーク通信イベントなど、さまざまなイベントタイプを記述して分類するための数千のフィールドの包括的なフレームワークを提供します。

UDM の構造

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

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 が 3389 で principal.ip が 35.235.240.5 の RDP イベントのネットワークデータを検索します。また、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 Entity: 環境内のアセット、ユーザー、リソースなどの要素のコンテキスト表現。これは信頼できるデータソースから取得されます。

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

イベントデータモデル

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

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

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

UDM イベントの構造

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

metadata
principal
ターゲット
src
observer
intermediary
about
ネットワーク
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 SecOps は metadata.event_type を読み取り、ログの受信後にそのイベントタイプに固有のフィールド検証を実行します。

UDM レコードのセクション（拡張機能セクションなど）にデータが保存されていない場合、そのセクションは UDM レコードに表示されません。

metadata フィールド

このセクションでは、UDM イベントに必要なフィールドについて説明します。

event_timestamp フィールド

UDM イベントには、イベントが発生したときの GMT タイムスタンプである metadata.event_timestamp のデータを含める必要があります。値は、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 つ以上含める必要があります。オプションでプロセスの詳細を含めることもできます。メール、ファイル、レジストリのキーまたは値のフィールドを含めることはできません。

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

次の 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

図: principal と target

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

target {
   ip: "192.0.2.31"
   port: 80
}

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

プリンシパルとターゲットは、両方とも同じマシンのアクターを表すことができます。たとえば、マシン 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 or 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 を持つ entity レコードとして保存されます。ユーザーに関する情報は、metadata.entity_type = USER を持つ entity レコードとして保存されます。

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

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

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

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

統合データモデルの概要

UDM の構造

UDM 検索の例

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

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

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

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

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

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

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

UDM イベントの構造

metadata フィールド

event_timestamp フィールド

event_type フィールド

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

principal 属性

target 属性

src 属性

intermediary 属性

observer 属性

about 属性

security_result 属性

network 属性

extensions 属性

UDM エンティティの構造

metadata フィールド

entity 属性

relation 属性

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

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

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