アラート疲労

TL;DR

アラート疲労は、チームがあまりにも多くの通知を受け取ることで、それに注意を払わなくなる現象です。

アラート疲労とは？

アラート疲労とは、セキュリティや運用チームが毎日アラートに溢れる状況で発生するものです。時間が経つにつれて、人々は疲れ、ストレスを感じ、それらを無視し始めます。

セキュリティにおいては、これは通常、すべてにアラートを出すツールから来ます。実際の問題、小さな問題、そして全く問題でないものまで。

すべてのアラートが重要に感じられると、どれも本当に緊急には感じられなくなります。脳はそれらを無視することを学び、頻繁に鳴るアラームのようになります。

アラート疲労が危険な理由

アラート疲労は単に迷惑なだけではありません。それは危険です。

多くの大規模なセキュリティ侵害は、アラートがトリガーされていたにもかかわらず発生しました。問題は、誰もそれに気づかず、適時に反応しなかったことです。

主なリスク：

1. 実際の脅威が無視される。

ほとんどのアラートが誤報であると、実際の攻撃も同じように見え、見逃されます。

2. 対応の遅れ

無駄なアラートを確認する時間は、実際の問題を解決するために費やされるべき時間です。

3. 人為的ミス

疲れたチームはミスを犯し、手順を省略したり、リスクを誤判断したりします。

アラート疲労が発生する理由

アラート疲労は通常、悪いツールと不適切な設定の組み合わせから発生します。

一般的な原因：

多すぎる誤検知
ツールは、実際に悪用可能かどうかを確認せずに問題を指摘します。
優先順位の欠如
リスクが非常に異なる場合でも、すべてが同じ重大度を持ちます。
重複するアラート
複数のツールが同じ問題を異なる方法で報告します。
固定的なルール
アラートは、実際の動作ではなく固定された限界に基づいてトリガーされます。

アラート疲労を軽減する方法

唯一の本当の解決策は、ノイズを減らし、重要なことに集中することです。

実際のリスクに焦点を当てる

すべての問題が同等ではありません。Plexicusは、脆弱性の優先順位を付けるためのいくつかの指標を提供します。

1) 優先順位指標

測定内容: 修正の緊急性全体

スコア (0-100) は、技術的な重大度 (CVSSv4)、ビジネスへの影響、悪用可能性を一つの数値に組み合わせたものです。これはあなたのアクションキューです - 優先順位でソートして、すぐに対処すべきことを知ることができます。優先順位85は「すべてを中断して今すぐこれを修正する」を意味し、優先順位45は「次のスプリントに予定を組む」を意味します。

例: 社内の生産性ツールにおけるSQLインジェクション、企業VPNからのみアクセス可能で、機密データを含まない

CVSSv4: 8.2 (高い技術的重大度)
ビジネスへの影響: 45 (社内ツール、データ露出が限定的)
悪用可能性: 30 (認証されたアクセスが必要)
優先順位: 48

優先度を探す理由: CVSSv4 (8.2) が高いにもかかわらず、Priority (48) はビジネスへの影響が限定的であり、悪用の可能性が低いため、緊急性を正しく引き下げます。CVSSだけを見ていたら、不必要にパニックになるでしょう。Priorityは「次のスプリントでスケジュールする」と約45のスコアで示しています。

これにより、「次のスプリント」の推奨がはるかに合理的になります。これは修正が必要な実際の脆弱性ですが、影響が少なく、露出が限定的な内部ツールであるため、緊急ではありません。

2) 影響

何を測定するか: ビジネスへの影響

影響 (0-100) は、脆弱性が悪用された場合に何が起こるかを評価し、データの機密性、システムの重要性、ビジネス運営、規制遵守など、特定のコンテキストを考慮します。

例: SQLインジェクションが公開されている顧客データベースにある場合、影響は95ですが、同じ脆弱性が内部テスト環境にある場合、影響は30です。

3) EPSS

何を測定するか: 現実世界での脅威の可能性

EPSSは、特定のCVEが次の30日間で実際に悪用される可能性を予測するスコア (0.0-1.0) です。

例: 10年前の脆弱性はCVSS 9.0（非常に深刻）かもしれませんが、誰もそれを悪用していない場合、EPSSは低く（0.01）なります。逆に、CVSS 6.0の新しいCVEは、攻撃者が積極的に使用しているため、EPSS 0.85かもしれません。

これらの指標を優先順位付けのために確認するには、次の手順に従ってください。

リポジトリが接続され、スキャンプロセスが完了していることを確認してください。
次に、Findings メニューに移動し、優先順位付けに必要なメトリクスを見つけます。

priority engine in plexicus

主な違い

メトリクス	回答	スコープ	範囲
EPSS	「攻撃者はこれを使用していますか？」	グローバルな脅威の状況	0.0-1.0
優先度	「何を最初に修正しますか？」	緊急度の総合スコア	0-100
影響	「私のビジネスにとってどれほど悪いか？」	組織固有	0-100

コンテキストを追加

脆弱なライブラリが存在しても、アプリがそれを使用しない場合、そのアラートは高優先度であるべきではありません。

調整と自動化

ツールに時間をかけて安全なものとそうでないものを教えます。簡単な修正を自動化し、人々が実際の脅威にのみ対処するようにします。

一つの明確なビューを使用

Plexicusのような単一のプラットフォームを使用することで、重複したアラートを削除し、アクションが必要なものだけを表示します。

現実のアラート疲労

状況	ノイズコントロールなし	スマートアラートあり
毎日のアラート	1,000以上	15–20
チームの気分	圧倒される	集中
見逃したリスク	一般的	まれ
目標	明確なアラート	実際の問題を修正

FAQ

アラートはどれくらいが多すぎるのか？

ほとんどの人は1日に10〜15件のアラートしか適切に確認できません。それ以上になると、問題を見逃すことが通常あります。

アラート疲れはセキュリティの問題だけですか？

いいえ。これは医療、IT運用、カスタマーサポートでも発生します。セキュリティでは、見逃したアラートが重大な侵害につながる可能性があるため、影響がより深刻です。

アラートをオフにすると状況は悪化しますか？

考えなしにアラートをオフにすると、はい、悪化します。

しかし、実際のリスクとコンテキストに基づいてアラートを減らすと、セキュリティは実際に改善されます。