拡充

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

拡充では、次の方法で統合データモデル（UDM）のインジケーターまたはイベントにコンテキストを追加します。

  • インジケーター（通常は UDM フィールド）を記述するエイリアス エンティティを識別します。
  • 識別されたエイリアスまたはエンティティから追加の詳細情報を UDM メッセージに入力します。
  • GeoIP や VirusTotal などのグローバルな拡充データを UDM イベントに追加します。

イベントの表示

イベントは、[イベント ビューア]の [イベント フィールド] タブで確認できます。このタブには、UDM イベント フィールドが階層ツリー構造で表示され、[選択済み] というラベルが付いています。各 UDM フィールドは、フィールドに拡充されたデータまたは拡充されていないデータが含まれることを示すアイコンでラベル付けされます。アイコンのラベルは次のとおりです。

  • U: 拡充されていないフィールドは、正規化プロセス中に元の未加工ログから直接値を取得します。
  • E: 拡充されたフィールドには、環境内のアーティファクトに関する追加のコンテキストを提供するために Google SecOps が生成する値が含まれます。

拡充されたフィールドには、検証、トラブルシューティング、監査、コンプライアンスに役立つように、関連するすべてのソースが表示されます。また、拡充ソースでフィールドをフィルタして、表示を絞り込むこともできます。

拡充ロジック パターンについて

Google SecOps は、拡充の種類に応じて、さまざまな論理パターンをデータに適用します。次の表を使用して、トラブルシューティングのためにこれらのパターンを理解し、特定のフィールドが入力、統合、上書きされる理由を説明します。

ロジック パターン 説明 適用可能な拡充
最初の一致 厳格な優先度リストに従います。パイプラインは、シーケンス内で最初に見つかった使用可能な値のみをクエリします。 アーティファクト（ファイル ハッシュ）
統合済み 複数のフィールドから同時にデータを収集して結合し、単一の「ゴールデン」エンティティ レコードを作成します。 アセット、ユーザー
条件付きフォールバック 優先度の高い識別子がない場合にのみ、特定のフィールドが拡充に使用されます。 アセット（ip アドレス）
マッピングと上書き 一意の ID（PSPI）を使用してエンティティを解決します。拡充ソースからのエイリアス データは、既存の解析済みデータを置き換えます。 プロセス

アセットの拡充

アセットの拡充では、パイプラインは複数の UDM フィールドを評価して一意のアセットを識別します。アーティファクトの拡充（1 つを選択）とは異なり、アセットの拡充では複数の ID のコンテキストを統合して完全なアセット プロファイルを作成します。

Google SecOps は、同じ Namespace で分類されたアセット イベントを拡充します。

アセットの場合、特定のフォールバック シナリオを除き、ロジックは排他的ではなく累積的です。説明には次の詳細を使用します。

  • ロジックタイプ: 統合またはフォールバック。フォールバック条件（asset_id チェックなど）が満たされない限り、パイプラインは使用可能なすべてのフィールドからデータを収集して、単一の「エンティティ」ビューを作成します。
  • フィールド マッピング:
    • ホスト名、MAC、asset_id: プライマリ ID として扱われます。これらのフィールドのエイリアス結果が統合され、最終的な拡充されたアセット プロファイルが生成されます。
    • IP アドレス: asset_id が使用できない場合にのみ、拡充クエリに含まれます。

パイプラインは、アセット イベントごとに、principal、src、target エンティティから次の UDM フィールドを抽出します。

UDM フィールド インジケーター タイプ ロジック / 優先順位
hostname HOSTNAME 統合済み: これらのフィールドのエイリアス結果が結合され、最終的な拡充されたアセット レコードが生成されます。
asset_id PRODUCT_SPECIFIC_ID 統合済み: アセット コンテキストの統合に使用されるプライマリ識別子。
mac MAC 統合済み: 他の識別子と組み合わせてアセットの解決に使用されます。
ip IP フォールバック: asset_id が使用できない場合にのみ、拡充クエリに含まれます。

ユーザーの拡充

ユーザーの拡充では、特定の識別子を検索して ID データを解決します。アーティファクトの拡充と同様に、このパイプラインでは優先順位を使用して、ルックアップの主キーとして使用する識別子を決定します。

パイプラインは、ユーザー イベントごとに、principal、src、target から次の UDM フィールドを抽出します。

UDM フィールド インジケーター タイプ ロジックまたは優先順位
user.email_addresses EMAIL 最優先: パイプラインは、まずユーザーのメインまたはセカンダリのメールアドレスに基づいて拡充を試みます。
user.windows_sid WINDOWS_SID 2 番目の優先順位: メールが使用できない場合、パイプラインは Windows セキュリティ識別子（SID）を使用します。
user.userid USER_ID 3 番目の優先順位: メールと SID がない場合にのみ使用されます。通常は、ローカルまたはアプリケーション固有の ID にマッピングされます。
user.employee_id EMPLOYEE_ID 最低優先順位: ユーザー ID を解決するための最終的なフォールバック。

パイプラインは、インジケーターごとに次の処理を行います。

  • ユーザー エンティティのリストを取得します。たとえば、principal.email_address と principal.userid のエンティティは同じ場合もあれば、異なる場合もあります。
  • 優先順位の高いインジケーター タイプからエイリアスを選択します。優先順位は WINDOWS_SID、EMAIL、USERNAME、EMPLOYEE_ID、PRODUCT_OBJECT_ID の順です。
  • noun.user に、有効期間がイベント時間と交差するエンティティを入力します。

プロセスの拡充

プロセスの拡充は、実行イベントの可視化に重点を置いています。 パイプラインはプロセスの詳細を抽出し、ファイル評価と親子関係を相互参照して拡充します。

プロセスの拡充を使用して、プロダクト固有のプロセス ID（product_specific_process_id）、つまり PSPI を実際のプロセスにマッピングし、親プロセスの詳細を取得します。このプロセスは EDR イベント バッチタイプに依存します。

UDM エンティティ フィールド ソース ロジックまたは優先順位
プライマリ エンティティ principal、src、 target 抽出: パイプラインは、これらの最上位エンティティから PSPI を抽出してルックアップを開始します。
親プロセス principal.process.parent_process、
、src.process.parent_process、
、target.process.parent_process 		マッピング: PSPI は、プロセス エイリアスを使用して親プロセスの詳細を取得します。
データの統合 noun.process （principal.process など） 上書きルール: エイリアス フィールドが絶対的な優先順位を持ちます。同じフィールドに解析済みデータとエイリアス データが存在する場合、パイプラインは解析済みデータをエイリアス データに置き換えます。

パイプラインはプロセス エイリアスを使用して、PSPI から実際のプロセスを識別し、親プロセスに関する情報を取得します。次に、このデータを拡充されたメッセージ内の対応する noun.process フィールドに統合します。

プロセス エイリアスの EDR インデックス フィールド

プロセスが起動すると、システムはメタデータ（コマンドライン、ファイル ハッシュ、親プロセスの詳細など）を収集します。マシンで実行されている EDR ソフトウェアは、ベンダー固有のプロセス UUID を割り当てます。

次の表に、プロセス起動イベント中にインデックスが作成されるフィールドを示します。

UDM フィールド インジケーター タイプ
target.product_specific_process_id PROCESS_ID
target.process プロセス全体（インジケーターのみではない）

正規化されたイベントの target.process フィールドに加えて、Google SecOps は親プロセスの情報を収集してインデックスを作成します。

アーティファクトの拡充

アーティファクトの拡充では、VirusTotal のファイル ハッシュ メタデータと IP アドレスの位置情報データが追加されます。ファイル ハッシュの場合、パイプラインは優先順位リストで見つかった最初の値で停止しますが、IP アドレスの場合は、すべてのエントリを並行して処理します。パイプラインは、UDM イベントごとに、principal、src、target エンティティから次のアーティファクト インジケーターのコンテキスト データを抽出してクエリします。拡充の動作はインジケーター タイプによって異なります。

インジケーター タイプ 抽出ロジック 優先順位 / オペレーションの順序
ファイル ハッシュ 最初の一致 パイプラインは次の順序でハッシュを検索し、VirusTotal のクエリに使用できる最初のハッシュのみを選択します。
  1. file.sha256
  2. file.sha1
  3. file.md5
  4. process.file.sha256
  5. process.file.sha1
  6. process.file.md5
IP アドレス 並列（繰り返し） すべてのパブリック IP アドレスまたはルーティング可能な IP アドレスは、独立したエントリとして扱われます。優先順位はありません。各 IP は独自の拡充結果を受け取ります。

パイプラインは、UNIX エポックとイベント時間を使用して、ファイル アーティファクト クエリの期間を定義します。位置情報データが使用可能な場合、パイプラインは位置情報データの発生元に基づいて、principal、src、target エンティティの次の UDM フィールドを上書きします。

  • artifact.ip
  • artifact.location
  • artifact.network（データに IP ネットワーク コンテキストが含まれている場合のみ）
  • location（元のデータにこのフィールドが含まれていない場合のみ）

パイプラインがファイル ハッシュ メタデータを検出すると、インジケーターの発生元に応じて、そのメタデータをファイルまたは process.file フィールドに追加します。パイプラインは、新しいデータと重複しない既存の値を保持します。

IP 位置情報の拡充

地理的エイリアスは、外部 IP アドレスの位置情報データを提供します。UDM イベントの principal、target、src フィールドのエイリアスが設定されていない IP アドレスごとに、関連するロケーションと ASN 情報を含む ip_geo_artifact サブプロトコル バッファが作成されます。

地理的エイリアスでは、ルックバックやキャッシュは使用されません。イベントの量が多いため、Google SecOps はメモリにインデックスを保持します。

VirusTotal ファイルのメタデータを使用してイベントを拡充する

Google SecOps は、ファイル ハッシュを UDM イベントに拡充し、調査中に追加のコンテキストを提供します。ハッシュ エイリアスは、すべての種類のファイル ハッシュを組み合わせて UDM イベントを拡充し、検索中にファイル ハッシュに関する情報を提供します。

Google SecOps は、VirusTotal のファイル メタデータと関係の拡充を統合して、悪意のあるアクティビティのパターンを特定し、ネットワーク全体でのマルウェアの動きを追跡します。

未加工ログでは、ファイルに関する情報は限られています。VirusTotal は、悪意のあるハッシュやファイルの詳細など、ファイル メタデータでイベントを拡充します。 メタデータには、ファイル名、タイプ、インポートされた関数、タグなどの情報が含まれます。この情報を利用して、YARA-L を使用した UDM 検索エンジンで、悪意のあるファイル イベントを把握することや、脅威ハンティングで使用することが可能です。たとえば、脅威検出にファイル メタデータを使用する元のファイルに対する変更を検出できます。

次の情報はレコードとともに保存されます。 すべての有効な UDM フィールドの一覧については、統合データモデルのフィールド リストをご覧ください。

データの種類 UDM フィールド
sha-256 ( principal | target | src | observer ).file.sha256
md5 ( principal | target | src | observer ).file.md5
sha-1 ( principal | target | src | observer ).file.sha1
サイズ ( principal | target | src | observer ).file.size
ssdeep ( principal | target | src | observer ).file.ssdeep
vhash ( principal | target | src | observer ).file.vhash
authentihash ( principal | target | src | observer ).file.authentihash
PE ファイル メタデータ Imphash ( principal | target | src | observer ).file.pe_file.imphash
security_result.threat_verdict ( principal | target | src | observer ).(process | file).security_result.threat_verdict
security_result.severity ( principal | target | src | observer ).(process | file).security_result.severity
last_modification_time ( principal | target | src | observer ).file.last_modification_time
first_seen_time ( principal | target | src | observer ).file.first_seen_time
last_seen_time ( principal | target | src | observer ).file.last_seen_time
last_analysis_time ( principal | target | src | observer ).file.last_analysis_time
exif_info.original_file ( principal | target | src | observer ).file.exif_info.original_file
exif_info.product ( principal | target | src | observer ).file.exif_info.product
exif_info.company ( principal | target | src | observer ).file.exif_info.company
exif_info.file_description ( principal | target | src | observer ).file.exif_info.file_description
signature_info.codesign.id ( principal | target | src | observer ).file.signature_info.codesign.id
signature_info.sigcheck.verfied ( principal | target | src | observer ).file.signature_info.sigcheck.verified
signature_info.sigcheck.verification_message ( principal | target | src | observer ).file.signature_info.sigcheck.verification_message
signature_info.sigcheck.signers.name ( principal | target | src | observer ).file.signature_info.sigcheck.signers.name
signature_info.sigcheck.status ( principal | target | src | observer ).file.signature_info.sigcheck.signers.status
signature_info.sigcheck.valid_usage ( principal | target | src | observer ).file.signature_info.sigcheck.signers.valid_usage
signature_info.sigcheck.cert_issuer ( principal | target | src | observer ).file.signature_info.sigcheck.signers.cert_issuer
file_type ( principal | target | src | observer ).file.file_type

拡充のトラブルシューティング

UDM イベントに想定される拡充データがない場合は、次の提案を参考にして問題を解決してください。

一般的な拡充

一部のイベントがまったく拡充されない場合、Google SecOps が配信速度を優先していることが原因である可能性があります。最初のパスでは、イベントの 1% 未満が拡充をスキップする場合があります。この問題を解決するには、数分後にもう一度ご確認ください。これらのイベントは自動的に再処理されます。1 時間経過しても拡充が行われない場合は、ログソースが UDM に正しく解析されていることを確認してください。

アーティファクトの拡充（最初の一致ロジック）

イベントに MD5 ハッシュと SHA256 ハッシュがあるのに、SHA256 の VirusTotal メタデータしか表示されない場合は、最初の一致ロジックです。パイプラインは、優先順位の高いハッシュ（sha256）が見つかるとすぐに停止します。SHA256 が存在する場合、MD5 の VirusTotal のクエリは行いません。

principal.ip の位置情報が表示されるが、target.ip の位置情報が表示されない場合、並列ロジックは各 IP を個別に処理します。一方の IP が内部またはプライベート（ルーティング不可）で、もう一方がパブリックの場合、パブリック IP のみが位置情報の拡充を受け取ります。

アセットの拡充（統合ロジックとフォールバック ロジック）

アセットの IP アドレス フィールドに拡充データが表示されない場合は、条件付きフォールバック ロジックです。IP は、asset_id（PSID）がない場合にのみ、拡充クエリに使用されます。asset_id が存在する場合、システムはそれに依存し、冗長なデータや競合するデータを防ぐために、その特定のクエリの IP を無視します。

ユーザーの拡充（優先順位）

ローカルログに "Security" と表示されているのに、Department フィールドに "IT" と表示される場合は、ユーザーの拡充でエイリアス フィールドよりも解析済みフィールドが優先されていることを意味します。未加工ログが "IT" で解析された場合、拡充パイプラインは ID ソース（Okta や AD など）の "Security" 値で上書きしません。

プロセスの拡充（マッピングと上書き）

未加工ログにプロセス名が表示されているのに、UDM 検索で別の名前に置き換えられている場合は、上書きロジックです。プロセスの拡充では、エイリアス フィールドが優先されます。PSPI ルックアップで EDR コンテキストからより正確なプロセス名が返された場合、元の解析済み値は完全に置き換えられます。

次のステップ

他の Google SecOps 機能で拡充データを使用する方法については、以下をご覧ください。

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