統合データモデルの概要

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

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

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

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

UDM には次のようなメリットがあります。

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

未加工ログ検索を使用してイベントを検索できますが、その特異性のために、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 エンティティ データモデルです。

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

イベント データモデル

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

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

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

UDM イベントの構造

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

  • metadata
  • principal
  • ターゲット
  • src
  • observer
  • intermediary
  • about
  • ネットワーク
  • security_result

  • extensions

    イベント データモデル

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

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

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

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

  • Email metadata: 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 を読み取り、そのイベントタイプに固有のフィールド検証を実行します。

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

以下の例は、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 フィールドには、ユーザーとノートパソコンの関係の方向性（具体的にはその関係が双方向か単方向か）が保存されます。