ダッシュボードの概要

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

このドキュメントでは、Google Security Operations ダッシュボード エンジンを使用して、異なるテレメトリー ストリーム間でデータの可視化を構築するための技術ガイドを提供します。

ダッシュボード フレームワークは、個々のウィジェット（グラフ）が YARA-L 2.0 構文を使用して特定のデータソースとインターフェースするモジュラー アーキテクチャ上に構築されています。YARA-L スキーマ プロパティと集計関数を使用すると、リアルタイム モニタリング、脅威分析、運用監査の可視化を構築できます。

基盤となるダッシュボード インフラストラクチャの詳細については、ダッシュボードの概要をご覧ください。

始める前に

Google SecOps インスタンスが次の構成要件を満たしていることを確認します。

必要な IAM 権限

ダッシュボードにアクセスするには、次の権限が必要です。

IAM 権限 目的
chronicle.nativeDashboards.list すべてのダッシュボードのリストを表示する。
chronicle.nativeDashboards.get ダッシュボードを表示する、 ダッシュボード フィルタを適用する、 グローバル フィルタを適用する。
chronicle.nativeDashboards.create 新しいダッシュボードを作成する。
chronicle.nativeDashboards.duplicate 既存のダッシュボードのコピーを作成します。
chronicle.nativeDashboards.update グラフの追加と編集、 フィルタの追加、 ダッシュボード アクセスの変更、 グローバル タイム フィルタの管理。
chronicle.nativeDashboards.delete ダッシュボードを削除する。

ダッシュボードについて

ダッシュボードには、セキュリティ イベント、検出、関連データに関する分析情報が表示されます。このセクションでは、サポートされているデータソースの概要と、ロールベース アクセス制御（RBAC）がダッシュボード内の可視性とデータアクセスに与える影響について説明します。

事前定義のダッシュボード カタログ

Google Security Operations には、さまざまなセキュリティ ユースケースを可視化するために設計された、すぐに使用できるキュレートされたダッシュボードが用意されています。キュレートされたダッシュボードを編集または削除することはできませんが、コピーを作成して、組織の特定の要件に合わせてカスタマイズすることはできます。

使用可能なすべての事前定義ダッシュボードを探索し、グラフの説明を確認して、個々のウィジェットの基になる検索クエリを表示するには、すぐに使えるダッシュボードのカタログをご覧ください。一般的な事前定義ダッシュボードの運用概要については、一般的なキュレートされたダッシュボードの概要をご覧ください。

  • investigation
  • response_platform_info
  • case_name
  • feedback_summary
  • feedback_history
  • soar_alert
  • soar_alert_metadata

サポートされているデータソース

ダッシュボードには次のデータソースが含まれています。各データソースには、独自のクエリ時間制限と YARA-L 接頭辞があります。

データソース クエリの時間間隔 YARA-L 接頭辞 スキーマ ダッシュボードの例
ケース履歴 365 日 case_history フィールド（SOAR） | テンプレート 例
ケースとアラート 365 日 case フィールド（SOAR） | テンプレート 例
データテーブル スタンドアロンの時間制限なし（結合されたデータソースに則って管理） % ユーザー定義 例
検出 365 日 detection フィールド | テンプレート 例
エンティティ グラフ 365 日 graph フィールド | テンプレート 例
イベント 90 日 no prefix フィールド（UDM） | テンプレート 例
Ingestion metrics 365 日 ingestion フィールド | テンプレート 例
IOC 365 日 ioc フィールド | テンプレート 例
ハンドブック 365 日 playbook フィールド（SOAR） | テンプレート 例
ルールセット 365 日 ruleset フィールド | テンプレート 例
ルール 時間制限なし rules フィールド | テンプレート 例
トリアージと調査のためのエージェント 365 日 gemini_investigation、gemini_investigation_feedback フィールド | テンプレート 例

データ RBAC の影響

データのロールベース アクセス制御（RBAC）は、個々のユーザーロールを使用して、組織内のデータへのユーザー アクセスを制限するセキュリティ モデルです。データ RBAC を使用すると、管理者はスコープを定義してユーザーに割り当て、アクセスをジョブ機能に必要なデータのみに制限できます。ダッシュボード内のすべてのクエリは、データ RBAC ルールに従います。アクセス制御とスコープの詳細については、データ RBAC のアクセス制御とスコープをご覧ください。ダッシュボードのデータ RBAC の詳細については、ダッシュボードのデータ RBAC を構成するをご覧ください。

Events、Entity graph、IOCs の一致

これらのソースから返されるデータは、ユーザーに割り当てられたアクセス スコープに制限され、承認されたデータの結果のみが表示されます。ユーザーに複数のスコープがある場合、クエリには割り当てられたすべてのスコープのデータが含まれます。ユーザーのアクセス スコープ外のデータはダッシュボードの検索結果に表示されません。

ルール

ユーザーに表示されるのは、割り当てられたスコープに関連付けられたルールのみです。

Detection と detection を含むルールセット

検出は、受信セキュリティ データがルールで定義された条件に一致したときに生成されます。ユーザーに表示されるのは、自身に割り当てられたスコープに関連付けられたルールから発生した検出結果のみです。検出を含むルールセットは、グローバル ユーザーにのみ表示されます。

SOAR データソース

SOAR データ（ケース、ケース履歴、ハンドブック、アラートなど）を含むダッシュボードは、グローバル ユーザーにのみ表示されます。

ケースとケース履歴のダッシュボードは、SOAR アクセス メカニズム（環境や SOC ロールなど）をサポートしていません。ダッシュボードにアクセスする権限を持つユーザーは、すべての環境と SOC ロールのケースを表示できます。

Ingestion metrics

Ingestion のコンポーネントは、ソースログ フィードからプラットフォームにログを取り込むサービスまたはパイプラインです。各コンポーネントは、独自の取り込み指標スキーマ内で特定のログフィールドのセットを収集します。

管理者は、取り込み指標に RBAC を使用して、ユーザーのビジネス スコープに基づいて、取り込み量、エラー、スループットなどのシステム健全性データの可視性を制限できます。

[データの取り込みと Health] ダッシュボードでは、データアクセス スコープが使用されます。スコープ ユーザーがダッシュボードを読み込むと、システムは指標を自動的にフィルタして、割り当てられたラベルに一致するデータのみを表示します。

次のラベルを使用してフィルタできます。

  • Namespace: 分離の主な方法（例: Eu-Prod、Alpha-Corp）。
  • ログタイプ: ロールベースの分離（例: GCP_VPC_FLOW、CROWDSTRIKE_EDR）。
  • 取り込み元: 詳細なソース トラッキング（特定の転送 ID など）。

取り込み指標に予期しないログタイプが表示される

一部のダッシュボードには、UNSPECIFIED_LOG_TYPE などのログタイプや、LT_X（X は数字）などの内部 ID のエントリが表示されることがあります。これらの LT_X 識別子は、Google SecOps システム内で、お客様が作成したカスタム ログタイプを一意に識別するために使用されます。

これらのエントリは、これらの特定のログタイプの完全なデータの取り込みまたは解析が正常に完了していない場合でも表示されることがあります。これは、最終的な取り込みステータスに関係なく、特定のシステム指標が記録されるためです。

正常に取り込まれて解析されたデータに焦点を当てるには、ダッシュボード インターフェースのフィルタリング機能を使用して、ビューから UNSPECIFIED_LOG_TYPE やその他の予期しない内部ログタイプ識別子を除外するか、明示的にフィルタで除外します。

未加工のログ容量とダッシュボードのログ容量の不一致

ダッシュボード グラフに表示される ingestion.log_volume の合計（たとえば、過去 365 日間の ingestion.component = "Ingestion API" をフィルタするクエリ）は、次の理由により、累積未加工ログ量と異なる場合があります。

  • 期間とルックバックの上限: Google SecOps インターフェースには、インスタンスがプロビジョニングされた時点からの累積取り込みカウンタは表示されません。Google SecOps ダッシュボードでは、キュレートされた [取り込み - スループット（全期間）] グラフでも、365 日のクエリ上限を超える全期間の合計を計算することはできません。Bring Your Own Project（BYOP）インスタンスの場合、Cloud Monitoring で最大 24 か月間クエリできます。
  • データソースとパイプライン: 未加工ログの量は、ストレージ内の未加工ログバッチのバイトサイズを反映します。ダッシュボードは ingestion_metrics テーブルにクエリを実行します。このテーブルは、約 5 分間隔で非同期にテレメトリーを収集します。指標パイプラインでは、収集レイテンシや一時的な指標の低下が発生する可能性があるため、ダッシュボードの ingestion.log_volume の合計は、正確なバイト数ではなく、おおよその指標として扱ってください。取り込み量を計算する場所と、ツール間で値がどのように異なるかについては、取り込み量を計算する場所と、値がどのように異なるかをご覧ください。

制限事項

  • カスタムラベル: カスタムラベル（UDM 正規表現またはデータテーブルを使用して作成されたラベルなど）を含むユーザースコープを割り当てると、そのユーザーの取り込み指標の RBAC が自動的に無効になります。その結果、ユーザーのダッシュボードにデータが表示されなくなります。取り込みモニタリング スコープでは、ログタイプ、名前空間、取り込みソースなどの標準ラベルのみを使用する必要があります。

  • 取り込みソースの制限: 取り込みソースによるフィルタリングは、ログ数の指標にのみ適用されます。帯域幅（バイト）またはエラー率の指標を表示するグラフでは、取り込みソースで厳密にフィルタすると、データが表示されないことがあります。より広範なヘルス モニタリングを行うには、Namespace でフィルタすることをおすすめします。

上級者向け機能とモニタリング

検出を微調整して可視性を向上させるには、YARA-L 2.0 ルールや取り込み指標などの高度な構成を使用します。このセクションでは、これらの機能の分析情報を確認し、検出効率の最適化とデータ処理のモニタリングに役立てる方法について説明します。

YARA-L 2.0 のプロパティ

YARA-L 2.0 をダッシュボードで使用する際の独自プロパティ

  • エンティティ グラフ、取り込み指標、ルールセット、検出などの追加のデータソースは、ダッシュボードで使用できます。これらのデータソースの一部は、YARA-L ルールと統合データモデル（UDM）検索ではまだ使用できません。

  • Google Security Operations ダッシュボードの YARA-L 2.0 関数と、統計指標を含む集計関数をご覧ください。

  • YARA-L 2.0 のクエリには、match セクションまたは outcome セクション、あるいはその両方を含める必要があります。

  • YARA-L ルールの events セクションは暗黙的に指定されるため、クエリで宣言する必要はありません。

  • YARA-L ルールの condition セクションは、ダッシュボードでは使用できません。

  • ダッシュボードは、UEBA カテゴリのリスク分析のルールをサポートしていません。

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