検索のベスト プラクティス

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

このドキュメントでは、Google Security Operations の検索機能を使用する際の Google が推奨するベスト プラクティスについて説明します。検索を工夫しないと、大量の計算リソースが必要になることがあります。また、Google SecOps インスタンス内のデータのサイズや複雑さによってパフォーマンスも変わります。

インデックス付き UDM フィールドを使用して速度を最大化する

検索のパフォーマンスを向上させる最も効果的な方法は、インデックス付きフィールドを使用してクエリを作成することです。これらのフィールドは、高速取得用に最適化されています。インデックスに登録される既知の統合データモデル（UDM）フィールドは次のとおりです。

プリンシパル フィールド

  • principal.asset.hostname
  • principal.asset.ip
  • principal.asset.mac
  • principal.file.md5
  • principal.file.sha1
  • principal.file.sha256
  • principal.hostname
  • principal.ip
  • principal.mac
  • principal.process.file.md5
  • principal.process.file.sha1
  • principal.process.file.sha256
  • principal.process.parent_process.file.md5
  • principal.process.parent_process.file.sha1
  • principal.process.parent_process.file.sha256
  • principal.user.email_addresses
  • principal.user.product_object_id
  • principal.user.userid
  • principal.user.windows_sids

マッピング元の項目

  • source.user.userid
  • src.asset.hostname
  • src.hostname
  • src.ip

マッピング先の項目

  • target.asset.hostname
  • target.file.md5
  • target.file.sha1
  • target.file.sha256
  • target.hostname
  • target.ip
  • target.process.file.md5
  • target.process.file.sha1
  • target.process.file.sha256
  • target.user.email_addresses
  • target.user.product_object_id
  • target.user.userid
  • target.user.windows_sid

その他のフィールド

  • about.file.md5
  • about.file.sha1
  • about.file.sha256
  • intermediary.hostname
  • intermediary.ip
  • network.dns.questions.name
  • network.email.from
  • network.email.to
  • observer.hostname
  • observer.ip

パフォーマンスを向上させる効果的な検索クエリを作成する

最適化されたクエリを作成することは、セキュリティ データ全体で速度を最大化し、リソース消費を最小限に抑えるための鍵となります。すべてのクエリ条件は、この基本構造に厳密に準拠している必要があります。

udm-field operator value

次に例を示します。principal.hostname = "win-server"

Google SecOps は検索中に大量のデータを取り込む可能性があるため、クエリの対象期間を短くして検索範囲を絞り、検索のパフォーマンスを高める必要があります。

検索クエリで正規表現を使用する

UDM 検索クエリを作成するときに標準の論理演算子と比較演算子を使用して、複雑な式を作成できます。

  • 論理演算子:AND、OR、NOT を使用して条件を結合します。2 つの条件の間の演算子を省略すると、AND とみなされます。
  • 演算子の優先順位: 括弧（）を使用して、デフォルトの優先順位をオーバーライドします。かっこ内で使用できる論理演算子（OR、AND、NOT）の最大数は 169 個です。
  • 比較演算子: UDM フィールドの型（文字列、整数、タイムスタンプ）に応じて、フィールド演算子には =、!=、>=、>、<、<= などがあります。

大規模な値のセットを効率的に検索するには、参照リストを使用することもできます。

検索修飾子として nocase を使用する

文字列比較条件に nocase 修飾子を追加すると、大文字と小文字が区別されず、大文字と小文字が無視されるようになります。

たとえば、次の検索は無効です。

target.user.userid = "TIM.SMITH" nocase

列挙型フィールドに正規表現を使用しない

列挙型フィールド（事前定義された値の範囲を持つフィールド）を検索する際に、metadata.event_type や network.ip_protocol などの正規表現を使用することはできません。

次の例は無効な検索です。 metadata.event_type = /NETWORK_*/

一方、次の例は有効な検索です。 (metadata.event_type = "NETWORK_CONNECTION" または metadata.event_type = "NETWORK_DHCP")

Events フィールドであらゆるすべての演算子を使用する

検索では、一部の UDM フィールド（principal.ip や target.file.md5 など）が繰り返しとしてラベル付けされています。これは、単一のイベント内で値またはメッセージ タイプのリストを保持できるためです。繰り返しフィールドは、デフォルトで常に any 演算子として扱われます（all を指定するオプションはありません）。

any 演算子を使用すると、繰り返しフィールドの値のいずれかが条件を満たした場合に、述語が true と評価されます。たとえば、principal.ip != "1.2.3.4" という検索をした場合、検索結果のイベントに principal.ip = "1.2.3.4" と principal.ip = "5.6.7.8" の両方が含まれていても、一致が生成されます。これにより、すべての演算子に一致するのではなく、いずれかの演算子に一致する結果も含まれるように検索が拡張されます。

繰り返しフィールドの各要素は個別に処理されます。検索対象のイベントに繰り返しフィールドが含まれている場合、そのイベントはフィールド内の各要素ごとに評価されます。これは予期せぬ挙動を引き起こすことがあります。特に != 演算子で検索する場合に注意が必要です。

any 演算子を使用すると、繰り返しフィールドの値のいずれかが条件を満たした場合に、述語が true と評価されます。

タイムスタンプに Unix エポック時刻を使用する

タイムスタンプ フィールドは、Unix エポック時刻（1970 年 1 月 1 日木曜日の 00:00:00 UTC からの経過秒数の合計）を使用して照合されます。

特定のタイムスタンプを検索する場合、次の形式（エポック時刻）が有効です。

metadata.ingested_timestamp.seconds = 1660784400

次のタイムスタンプは無効です。

metadata.ingested_timestamp = "2022-08-18T01:00:00Z"

フィルタからフィールドを除外する

次のフィールドは、検索フィルタから意図的に除外されています。これらには重要なメタデータが含まれていますが、非常に一意性の高い値が含まれているため、不要な検索の詳細が追加され、クエリ エンジンの全体的な効率と有効性が低下する可能性があります。

  • metadata.id
  • metadata.product_log_id
  • *.timestamp

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