[データ健全性モニタリング] ダッシュボードを使用する」
このドキュメントでは、構成されたすべてのデータソースのステータスと健全性をモニタリングするための Google Security Operations の中心的な場所である [データ健全性モニタリング] ダッシュボードについて説明します。ダッシュボードには、異常なソースとログタイプに関する重要な情報が表示され、データ パイプラインの問題を診断して解決するために必要なコンテキストが提供されます。
[データ健全性モニタリング] ダッシュボードには、次の情報が表示されます。
- 取り込み量と取り込みの健全性。
- 未加工ログから統合データモデル(UDM)イベントへの解析量。
- コンテキストと、関連する追加情報や機能を含むインターフェースへのリンク。
異常なソースとログタイプ、失敗したソースとログタイプ。データ健全性モニタリング ダッシュボードは、お客様ごとに異常を検出します。取り込みデータを分析するために、30 日間のルックバック期間で統計的手法を使用します。不規則とマークされた項目は、Google SecOps によって取り込まれて処理されるデータの急増または急減を示します。
主なメリット
[データ ヘルス モニタリング] ダッシュボードを使用すると、次のことができます。
- データ全体の健全性を一目で確認できます。各フィード、データソース、ログタイプ、ソース(フィード ID)のコアの健全性ステータスと関連する指標を表示します。
次の集計されたデータ健全性指標をモニタリングします。
- 時間の経過に伴う取り込みと解析。フィルタされたダッシュボードにリンクするイベント(必ずしも異常とは限らない)がハイライト表示されます。
- 異常値 - 現在と経時的。
期間、ログタイプ、フィードでフィルタされた関連するダッシュボードにアクセスします。
フィード構成にアクセスして、問題を編集、修正、または解決します。
パーサー構成にアクセスして、問題を編集、修正、修復します。
[アラートを設定] リンクをクリックして Cloud Monitoring インターフェースを開き、そこから ステータスとログボリュームの指標を使用してカスタム API ベースのアラートを構成します。
主な質問事項
このセクションでは、インターフェース セクションで説明されている [データ ヘルス モニタリング] ダッシュボードのコンポーネントとパラメータについて説明します。
データ健全性モニタリング ダッシュボードを使用すると、データ パイプラインに関する次のような一般的な重要な質問に回答できます。
ログが Google SecOps に届いていますか?
ログが Google SecOps に到達しているかどうかを確認するには、[Last Ingested] 指標と [Last Normalized] 指標を使用します。これらの指標は、データが最後に正常に配信された日時を示します。また、取り込み量指標(ソースごと、ログタイプごと)には、取り込まれるデータ量が表示されます。
ログは正しく解析されていますか?
正しい解析を確認するには、[Last Normalized] 指標を表示します。この指標は、未加工ログから UDM イベントへの変換が最後に成功した日時を示します。
取り込みまたは解析が行われないのはなぜですか?
[Issue Details] 列のテキストは、特定の問題を識別します。これにより、アクションが実行可能(修正する)か、実行不可能(サポートが必要)かを特定できます。「Forbidden 403: Permission denied」というテキストは、フィード構成で指定された認証アカウントに必要な権限がない場合に表示される、対応可能なエラーの例です。テキスト Internal_error は、推奨される対応が Google SecOps にサポートケースを送信することである、対応できないエラーの例です。
取り込まれたログと解析されたログの数に大きな変化はありますか?
[ステータス] フィールドには、データ量に基づいて、データの健全性([正常] から [失敗] まで)が表示されます。[取り込みと解析が行われたログの合計数] グラフを表示して、急激な増加や減少を特定することもできます。
ソースが失敗した場合にアラートを受け取るにはどうすればよいですか?
データ健全性モニタリング ダッシュボードは、ステータスとログボリュームの指標を Cloud Monitoring にフィードします。[データ健全性モニタリング] ダッシュボードのいずれかのテーブルで、関連する [アラート] リンクをクリックして、Cloud Monitoring インターフェースを開きます。ここでは、ステータスとログボリュームの指標を使用して、API ベースのカスタム アラートを構成できます。
ログタイプの取り込みの遅延を推測するにはどうすればよいですか?
遅延は、[Last Event Time] が [Last Ingested] タイムスタンプより大幅に遅れている場合に示されます。[データ健全性モニタリング] ダッシュボードには、ログタイプごとに [Last Ingested] - [Last Event Time] デルタの 95thが表示されます。値が高い場合は、Google SecOps パイプライン内のレイテンシの問題を示します。値が正常な場合は、ソースが古いデータをプッシュしている可能性があります。
最近の構成の変更がフィードの失敗の原因になっているか?
[Config Last Updated] タイムスタンプが [Last Ingested] タイムスタンプに近い場合は、最近の構成更新が原因で障害が発生した可能性があります。この相関関係は、根本原因の分析に役立ちます。
取り込みと解析の健全性は時間とともにどのように変化していますか?
[取り込みと解析済みのログの合計数] グラフには、データの健全性の過去の傾向が表示され、長期的なパターンと不規則性を確認できます。
インターフェース
[データ健全性モニタリング] ダッシュボードには、次のウィジェットが表示されます。
数字(大)ウィジェット:
- 正常: 異常なく動作しているデータソースとパーサーの数。
- Failed: 直ちに対応が必要なデータソースの数。
- 不規則: 不規則なデータソースとパーサーの数。
取り込みと解析が行われたログの合計数: 解析済みログと取り込み済みログの 1 日あたりのログ数の推移を示す折れ線グラフ。
[Health Status by Data Source] テーブル - 次の列が含まれます。
- ステータス: データ量、構成エラー、API エラーから導き出されたフィードの累積ステータス(正常、失敗、不規則)。
- ソースタイプ: ソースタイプ(取り込みメカニズム)。たとえば、取り込み API、フィード、ネイティブ Workspace 取り込み、Azure Event Hub フィードなど。
- 名前: フィード名。
- ログタイプ: ログタイプ(CS_EDR、UDM、GCP_CLOUDAUDIT、WINEVTLOG など)。
- 問題の詳細: 問題がある場合、この列には詳細(ログの解析に失敗しました、構成認証情報の問題、正規化の問題など)が表示されます。記載された問題は、対応可能なもの(Incorrect Auth など)と対応不可能なもの(Internal_error など)があります。問題に対処できない場合は、Google SecOps にサポートケースを登録することをおすすめします。[ステータス] が [正常] の場合、値は空です。
- 問題の期間: データソースが異常な状態または失敗した状態になっている日数。[ステータス] が [正常] の場合、値は空です。
- Last Collected: 最後にデータを収集したタイムスタンプ。
- Last Ingested: 最後に正常に取り込まれたタイムスタンプ。この指標を使用して、ログが Google SecOps に到達しているかどうかを特定します。
- Config Last Updated: 指標が最後に変更されたときのタイムスタンプ。この値を使用して、構成の更新と観測された異常を関連付け、取り込みの問題や解析の問題の根本原因を特定できます。
- View Ingestion Details: 新しいタブで別のダッシュボードを開くリンク。このダッシュボードには、詳細な分析を行うための追加の履歴情報が含まれています。
- データソースを編集: 対応するフィード設定の新しいタブを開くリンク。設定関連の不整合を修正できます。
- アラートを設定: リンク。対応する Cloud Monitoring インターフェースの新しいタブが開きます。
[Health Status by Parser] テーブル - 次の列が含まれます。
- ステータス: 正規化率から導出された、ログタイプの累積ステータス(正常、失敗、異常)。
- 名前: ログタイプ(DNS、USER、GENERIC、AZURE_AD、BIND_DNS、GCP SECURITYCENTER THREAT、WEBPROXY など)。
- 問題の詳細: 問題がある場合、この列には解析の問題の詳細(ログの解析に失敗しました、構成認証情報の問題、正規化の問題など)が表示されます。記載された問題は、対応可能なもの(Incorrect Auth など)と対応不可能なもの(Internal_error など)があります。問題に対処できない場合は、Google SecOps にサポートケースを登録することをおすすめします。[ステータス] が [正常] の場合、値は空です。
- 問題の期間: データソースが異常な状態または失敗した状態になっている日数。[ステータス] が [正常] の場合、値は空です。
- Last Ingested: 最後に正常に取り込まれたタイムスタンプ。この指標を使用して、ログが Google SecOps に到達しているかどうかを判断できます。
Last Event Time: 最後に正規化されたログのイベント タイムスタンプ。
Last Normalized: ログタイプの最後の解析と正規化アクションのタイムスタンプ。この指標を使用すると、未加工のログが UDM イベントに正常に変換されたかどうかを判断できます。
Config Last Updated: 指標が最後に変更されたときのタイムスタンプ。この値を使用して、構成の更新と観測された異常を関連付け、取り込みの問題や解析の問題の根本原因を特定できます。
View Parsing Details: 別のダッシュボードを含む新しいタブを開くリンク。このダッシュボードには、より詳細な分析を行うための追加の履歴情報が含まれています。
パーサーを編集: リンク。対応するパーサー構成を含む新しいタブが開きます。ここで、構成関連の不規則性を修正できます。
アラートを設定: 対応する Cloud Monitoring インターフェースが新しいタブで開くリンク。
異常検出エンジン
データ健全性モニタリング ダッシュボードは、Google SecOps の異常検出エンジンを使用して、データの大きな変化を自動的に特定します。これにより、潜在的な問題を迅速に検出して対処できます。
データ取り込みの不規則性の検出
Google SecOps は、通常の週単位のパターンを考慮しながら、1 日あたりの量の変化を分析します。
異常検出エンジンは、次の計算を使用して、データ取り込みの異常な急増や急減を検出します。
- 日次と週次の比較: Google SecOps は、当日と前日の取り込み量の差と、当日と過去 1 週間の平均量の差を計算します。
標準化: これらの変更の重要性を理解するために、Google SecOps は次の z スコア式を使用して変更を標準化します。
z = (xi − x_bar) / stdevここで
zは、個々の差の標準化されたスコア(z スコア)です。xiは個々の差分値ですx_barは差の平均値です。stdevは差の標準偏差です。
異常のフラグ設定: 1 日単位と 1 週間単位の両方の標準化された変化が統計的に有意である場合、Google SecOps は異常にフラグを設定します。具体的には、Google SecOps は次のものを検索します。
- 減少: 1 日単位と週単位の両方の標準化された差が -1.645 未満です。
- 急増: 1 日単位と週単位の両方の標準化された差が 1.645 より大きい。
正規化比率
取り込まれたイベントと正規化されたイベントの比率を計算する際、異常検出エンジンは複合アプローチを使用して、正規化率の著しい低下のみがフラグ付けされるようにします。異常検出エンジンは、次の 2 つの条件が満たされた場合にのみアラートを生成します。
- 前日と比較して、正規化率が統計的に有意に低下しています。
- 絶対値で見ても、0.05 以上の大幅な減少です。
解析エラーの不規則性の検出
データ解析中にエラーが発生した場合、不規則性検出エンジンは比率ベースの方法を使用します。異常検出エンジンは、取り込まれたイベントの総数に対するパーサー エラーの割合が前日と比較して 5% 以上増加した場合にアラートをトリガーします。
次のステップ
さらにサポートが必要な場合 コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。