拡充
拡充では、次の方法で統合データモデル（UDM）のインジケーターまたはイベントにコンテキストを追加します。
- インジケーター（通常は UDM フィールド）を記述するエイリアス エンティティを識別します。
- 特定されたエイリアスまたはエンティティから追加の詳細情報を取得して、UDM メッセージに入力します。
- GeoIP や VirusTotal などのグローバル エンリッチメント データを UDM イベントに追加します。
エンリッチメント ロジック パターンについて
Google SecOps は、エンリッチメントのタイプに応じて、さまざまな論理パターンをデータに適用します。次の表は、トラブルシューティングでこれらのパターンを理解し、特定のフィールドが入力、統合、上書きされる理由を説明するのに役立ちます。
| ロジックパターン | 説明 | 適用可能なエンリッチメント |
|---|---|---|
| 初戦 | 厳格な優先順位リストに従います。パイプラインは、シーケンスで見つかった最初の使用可能な値のみをクエリします。 | アーティファクト（ファイル ハッシュ） |
| 統合済み | 複数のフィールドから同時にデータを収集して結合し、単一の「ゴールデン」エンティティ レコードを構築します。 | アセット、ユーザー |
| 条件付きフォールバック | 特定のフィールドは、優先度の高い ID がない場合にのみエンリッチメントに使用されます。 | アセット（ip アドレス） |
| マッピングと上書き | 一意の ID（PSPI）を使用してエンティティを解決します。エンリッチメント ソースのエイリアス付きデータが、既存の解析済みデータを置き換えます。 |
プロセス |
アセットの拡充
アセットの拡充では、パイプラインは複数の UDM フィールドを評価して一意のアセットを識別します。アーティファクトの拡充（1 つを選択）とは異なり、アセットの拡充では、複数の ID のコンテキストを統合して完全なアセット プロファイルを作成します。
アセットの場合、特定のフォールバック シナリオを除き、ロジックは排他的ではなく累積的です。説明には次の詳細を使用します。
- ロジックタイプ: Merged または Fallback。パイプラインは、フォールバック条件（
asset_idチェックなど）が満たされない限り、使用可能なすべてのフィールドからデータを収集して、単一の「エンティティ」ビューを作成します。 - フィールド マッピング:
- ホスト名、MAC、
asset_id: プライマリ ID として扱われます。これらのすべてのフィールドのエイリアス結果がマージされ、最終的な強化されたアセット プロファイルが生成されます。 - IP アドレス:
asset_idが使用できない場合にのみ、エンリッチメント クエリに含まれます。
- ホスト名、MAC、
アセット イベントごとに、パイプラインは principal、src、target エンティティから次の UDM フィールドを抽出します。
| UDM フィールド | インジケーターのタイプ | ロジック / 優先順位 |
|---|---|---|
hostname |
HOSTNAME | 結合: これらのフィールドのエイリアス結果が結合され、最終的な拡充されたアセット レコードが生成されます。 |
asset_id |
PRODUCT_SPECIFIC_ID | 統合済み: アセット コンテキストの統合に使用されるプライマリ識別子。 |
mac |
MAC | 統合済み: 他の識別子と組み合わせてアセットの解決に使用されます。 |
ip |
IP | フォールバック: asset_id が利用できない場合にのみ、エンリッチメント クエリに含まれます。 |
ユーザーの拡充
ユーザー エンリッチメントは、特定の識別子を探して ID データを解決します。アーティファクトの拡充と同様に、このパイプラインは順序の優先度を使用して、ルックアップの主キーとして使用する ID を決定します。
ユーザー イベントごとに、パイプラインは principal、src、target から次の UDM フィールドを抽出します。
| UDM フィールド | インジケーターのタイプ | ロジックまたは優先順位 |
|---|---|---|
user.email_addresses |
最優先: パイプラインは、まずユーザーのメインまたは予備のメールアドレスに基づいて拡充を試みます。 | |
user.windows_sid |
WINDOWS_SID | 第 2 優先度: メールアドレスが使用できない場合、パイプラインは Windows セキュリティ識別子（SID）を使用します。 |
user.userid |
USER_ID | 第 3 優先度: メールアドレスと SID がない場合にのみ使用されます。通常は、ローカル ID またはアプリケーション固有の 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 | プロセス全体（インジケーターだけではない） |
Google SecOps は、正規化されたイベントの target.process フィールドに加えて、親プロセスの情報を収集してインデックスに登録します。
アーティファクトの拡充
アーティファクトの拡充では、VirusTotal のファイル ハッシュ メタデータと IP アドレスの位置情報データが追加されます。ファイル ハッシュの場合、パイプラインは優先順位付きリストで見つかった最初の値で停止しますが、IP アドレスの場合は、すべてのエントリを並行して処理します。パイプラインは、各 UDM イベントについて、principal、src、target エンティティから次のアーティファクト指標のコンテキスト データを抽出してクエリします。エンリッチメントの動作は指標のタイプによって異なります。
| インジケーターのタイプ | 抽出ロジック | 優先順位 / 演算の順序 |
|---|---|---|
| ファイル ハッシュ | 初戦 |
パイプラインは次の順序でハッシュを検索し、VirusTotal のクエリに使用できる最初のハッシュのみを選択します。
|
| IP アドレス | Parallel（繰り返し） | 一般公開またはルーティング可能な IP アドレスは、それぞれ独立したエントリとして扱われます。優先順位はありません。各 IP は独自のエンリッチメント結果を受け取ります。 |
パイプラインは、UNIX エポックとイベント時間を使用して、ファイル アーティファクト クエリの期間を定義します。位置情報データが利用可能な場合、パイプラインは位置情報データの送信元に基づいて、principal、src、target エンティティの次の UDM フィールドを上書きします。
artifact.ipartifact.locationartifact.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 ハッシュの両方があるのに、VirusTotal メタデータが SHA256 のみに表示される場合は、最初の一致ロジックが適用されています。パイプラインは、優先度の最も高いハッシュ（sha256）が見つかるとすぐに停止します。SHA256 が存在する場合、VirusTotal に MD5 のクエリは送信されません。
principal.ip の位置情報は表示されるが、target.ip の位置情報は表示されない場合、並列ロジックは各 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 のプロフェッショナルから回答を得ることができます。