コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

ログデータを UDM としてフォーマットする

すべての統合データモデル(UDM)イベントには、パートナーがイベントタイプに関係なく入力できる共通のフィールド セットとメッセージが存在します。次のようなフィールドがあります。

  • Entities: イベントに関連するデバイス、ユーザー、プロセス。
  • Network metadata: イベントの発生日時、イベントの種類、送信元など
  • Network metadata: ネットワーク指向のイベントに関するネットワーク メタデータの概要とサブメッセージ内のプロトコルの詳細。
    • Email metadata: to、form、cc、bcc、その他のメール フィールドの情報。
    • HTTP metadata: メソッド、referral_url、useragent など。
  • Security results: セキュリティ製品による分類やアクション。
  • Additional metadata: UDM モデルの正式なセクション内で適切に表現できない重要なベンダー固有のイベントデータは、自由形式の json ペイロード フィールドを使用して追加できます。

統合データモデル(UDM)のイベントをエンコード、フォーマットする方法について説明します。

UDM のエンコード

UDM イベントは、次のいずれかの形式で Chronicle に送信する必要があります。

本ドキュメントでは、フィールドをドット表記で表しています。 例として次の JSON 構文をご覧ください。

{"menu":
  {
    "id": "file",
    "value": "File",
    "popup": {
      "menuitem": [
        {"value": "New", "onclick": "CreateNewDoc()"}
      ]
    }
  }
}

上記の JSON 構文は次のように表されます。

menu.id = "file"
menu.value = "File"
menu.popup.menuitem.value = "New"
menu.popup.menuitem.onclick = "CreateNewDoc()"

UDM イベントのフォーマット

UDM イベントを Google に送信できる形にフォーマットするには、次の手順を行う必要があります。

  1. イベントタイプを指定する: 選択するイベントタイプによって、イベントに含める必要がある追加のフィールドが決まります。
  2. イベントのタイムスタンプの指定 -metadata-position="body" } - イベントのタイムスタンプを指定します。
  3. 名詞(エンティティ)を指定する: 各イベントには、イベントに関与しているデバイスまたはユーザーについて説明する 1 つ以上の名詞を含める必要があります。
  4. セキュリティ結果を指定する: (省略可)セキュリティ結果を指定します。その場合、セキュリティ システムによって検出された、またはセキュリティ上のリスクや脅威を低減するために行ったアクションによって検出されたセキュリティ上のリスクや脅威の詳細を含めます。
  5. UDM イベント フィールドを使用して、必須のイベント情報とオプションのイベント情報の残りの項目を入力します。

イベントタイプを指定する

UDM のフォーマットでイベントを送信する際に定義する値のうち、最も重要なのはイベントタイプです。イベントタイプは、Metadata.event_type に設定可能ないずれかの値で指定します。 設定可能な値には、PROCESS_OPEN、FILE_CREATION、USER_CREATION、NETWORK_DNS などがあります(全一覧については Metadata.event_type をご覧ください)。各イベントタイプには、元のイベントに関連付けられた情報を他のフィールドと値のセットにも入力する必要があります。各イベントタイプに含めるフィールドの詳細については、各 UDM イベントタイプの必須フィールドとオプション フィールドをご覧ください。次の例は、Proto3 のテキスト表記で PROCESS_OPEN をイベントタイプとして指定する方法を表しています。

metadata {
    event_type: PROCESS_OPEN
}

イベントのタイムスタンプを指定する

Metadata.event_timestamp を使用して UDM のフォーマットでイベントを送信する場合、タイムスタンプは GMT で指定する必要があります。 タイムスタンプは、次のいずれかの標準を使用してエンコードする必要があります。

  • RFC 3339(JSON の場合)
  • Proto3 タイムスタンプ

以下の例は RFC 3339 のフォーマットでタイムスタンプを指定する方法を示しており、 この例では「yyyy-mm-ddThh:mm:ss+hh:mm—year」は、年、月、日、時、分、秒、UTC 時間からのオフセットを表しています。ここでは UTC からのオフセットがマイナス 8 時間(PST)です。

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

名詞(エンティティ)を指定する

各 UDM イベントに対して、1 つ以上の名詞を定義する必要があります。 名詞は UDM イベントに関与するエンティティを表します。 たとえば、イベントに記述されたアクティビティを実行するデバイスやユーザー、またはそのようなアクティビティの対象となるデバイスやユーザーを名詞として指定できます。 名詞は添付ファイルや URL などであることもあります。最後に、イベントで説明されているアクティビティをモニタリングしたセキュリティ デバイス(メールプロキシやネットワーク ルーターなど)を記述するために、名詞を使用することもできます。

UDM イベントには、以下のうち 1 つ以上の名詞を指定する必要があります。

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

すべてのイベントが同じマシン上で発生する場合、そのマシンは principal で記述される必要があります。targetsrc でもマシンを記述する必要はありません。

次の例では、[principal] フィールドに値を設定しています。

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

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

ターゲット: イベントで参照されるターゲット デバイス、またはそのターゲット デバイス上のオブジェクトを表します。たとえば、デバイス A からデバイス B へのファイアウォール接続で、A がプリンシパルとして記述され、B がターゲットとして記述されます。プロセス C によるターゲット プロセス D へのプロセス インジェクションでは、プロセス C がプリンシパルとして記述され、プロセス D がターゲットとして記述されます。

UDM の principal と target UDM のプリンシパルとターゲット

次の例は、ターゲットのフィールドに入力される方法を示しています。

target {
   ip: "198.51.100.31"
   port: 80
}

ここでも、ホスト名、追加の IP アドレス(複数可)、MAC アドレス(複数可)、独自のアセット識別子などの追加情報がある場合は、それらも target に含める必要があります。

principaltarget(およびその他の名詞)は、両方とも同じマシンのアクターを参照できます。たとえば、マシン X で実行されているプロセス A(principal)は、マシン X でもプロセス B(target)を処理します。

  • src: 関与しているエンティティによって処理されるソース オブジェクト、およびソース オブジェクトのデバイスとプロセスのコンテキスト(ソース オブジェクトが存在するマシン)を表します。たとえば、ユーザー U がマシン X 上のファイル A をマシン Y 上にファイル B としてコピーする場合、ファイル A とマシン X の両方を UDM イベントの src に指定します。
  • intermediary: イベントに記述されるアクティビティを処理する、1 つ以上の中間デバイスの詳細を表します。これには、プロキシ サーバーや SMTP リレーサーバーなどのデバイスの詳細が含まれます。
  • observer: 監視デバイス(パケット スニッファやネットワーク ベースの脆弱性スキャナなど)です。直接的な仲介機能はありませんが、対象のイベントを監視して報告します。
  • about: イベントで参照されるすべてのオブジェクトの詳細を保存するために使用されます。ただし、それとは異なる内容が participantsrctargetintermediaryobserver に記述されている場合は除きます。たとえば、次の対象を追跡するために使用できます。
    • メールの添付ファイル
    • メールの本文に埋め込まれたドメイン、URL、IP
    • PROCESS_LAUNCH イベント中に読み込まれる DLL

UDM イベントのエンティティ セクションには、イベントに記述されるさまざまなエンティティ(デバイス、ユーザー、オブジェクト(URL やファイルなど))の情報が含まれます。 Chronicle UDM では、名詞のフィールドを入力する際に要件があります。 これらの要件については、各 UDM イベントタイプの必須フィールドとオプション フィールドをご覧ください。入力が必要な一連のエンティティ フィールドは、イベントタイプによって異なります。

セキュリティ結果を指定する

オプションで、SecurityResult フィールドに入力することでセキュリティ結果を指定することもできます。その場合、セキュリティ システムによって検出された、またはセキュリティ上のリスクや脅威を低減するために行ったアクションによって検出されたセキュリティ上のリスクや脅威の詳細を含めます。 以下に、SecurityResult フィールドに値を入力する必要があるセキュリティ イベントの例を示します。

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