「アラートが多すぎて、もう誰も見ていない」
「毎日100件以上の通知が来るけど、ほぼ全部誤検知」
「Sentinelを入れたのに、インシデントは手作業で気づいた」

SIEMは「入れたら終わり」ではありません。
運用設計の質で、“使えるSIEM"にも"うるさいだけの装置"にもなります。

1. なぜSentinelは"うるさい"のか

Sentinelのデフォルトルールを全部有効にすると、環境によっては1日数百件のアラートが発生します。
原因は大きく3つです。

  • ルールの閾値が低すぎる：正常な操作でもトリガーされる
  • コンテキストが考慮されていない：業務システムの特性を無視したルール
  • 通知先が設計されていない：全員に全アラートが飛ぶ

これが続くと、担当者は「アラート疲れ（Alert Fatigue）」に陥り、本当に危険な通知を見落とすようになります。

2. ルール品質を上げる3つのアプローチ

① ルールの優先度を分類する

すべてのルールを同じ重みで扱わないことが大前提です。
SentinelのAnalytics RulesはSeverityを設定できます。

  • High：即時対応必須（アカウント乗っ取り、ランサムウェア等）
  • Medium：業務時間内に確認（異常なログイン場所等）
  • Low/Informational：週次でレビューすれば十分

Highだけをオンコールで通知し、LowはLog Analytics Workspaceに蓄積するだけにするだけで、ノイズが劇的に減ります。

② 環境に合わせたチューニング

デフォルトルールをそのまま使うのは危険です。
たとえば「深夜のサインイン検知」というルールも、グローバル企業なら夜間の海外拠点アクセスが正常で起動します。

ルールごとに次を確認しましょう：

  • どんなときに発火するか（トリガー条件）
  • 自社環境ではそれが正常か異常か
  • 除外（Exception）リストを設定できるか

3. 通知設計：「誰が」「何を」「どこで」受け取るか

アラートの通知先設計は、運用フローそのものです。
よくある失敗：「全通知をメールで全員に送る」

代わりに、こう設計します：

  • High アラート → Microsoft Teams特定チャンネル + 担当者への直接メンション + PagerDutyなどのオンコール
  • Medium アラート → Teams通知のみ（翌営業日確認）
  • Low アラート → 週次レポートに集約してメール送付

Logic AppやPlaybookを使えば、アラートの内容に応じた通知先の振り分けを自動化できます。

4. 担当分界を決める

「誰がどのアラートに、何分以内に対応するか」を明文化しないと、SIEMは絵に描いた餅です。
「Sentinelがアラートを上げたあと、誰が調査し、誰がシステムを止める判断をするのか」を事前に決めておきましょう。

5. “回る監視"にするための継続改善

一度チューニングしたからといって、ルールは永遠に最適ではありません。

  • 新しいシステム・サービスが増えると、新しい誤検知パターンが生まれる
  • 攻撃手口が変化すると、検知ルールのカバレッジが落ちる

月次で「False Positive率」「アラート対応率」「SLO達成率」を振り返る仕組みを作りましょう。

6. Colorkrew Securityの考え方

Colorkrew Securityでは、Sentinelの「導入後の定着支援」を重視しています。

SIEMは道具です。それを"回る監視"にするのは、運用設計の力です。
ルール設計・通知設計・担当分界・SLO策定まで、一緒に仕組みを作ります。