検知ルール設計入門｜SIEM/XDRで誤検知を減らすDetection RuleとCorrelation Ruleの作り分けを解説

現代のセキュリティ運用において、検知ルールはサイバー攻撃から組織を守るための神経系ともいえる重要な役割を担っています。しかし、その設計が不十分だと、かえって運用者の負担を増大させる原因にもなりかねません。

検知ルールは、膨大なログやイベントデータの中から、サイバー攻撃の兆候を早期に発見するための仕組みです。マルウェア感染、不正アクセス、内部不正といった脅威を自動的に検知し、セキュリティアナリストにアラートとして通知します。このアラートが、インシデント対応の起点となり、迅速な初動を可能にするのです。

しかし、多くの組織では、セキュリティ製品のデフォルト設定や安易に作成されたルールによって、「アラート疲れ」が深刻な問題となっています。これは、重要度の低いアラートや誤検知が大量に発生し、アナリストが本当に対応すべき脅威を見逃すリスクを高める状態です。

効果的な検知ルールを設計することは、単に脅威を見つけるだけでなく、セキュリティ運用の効率を最大化し、アナリストの負担を軽減するために不可欠な取り組みなのです。

優れた検知ルールを設計するには、その源泉となるデータ、すなわち「Telemetry（テレメトリー）データ」の質と量が鍵を握ります。Telemetryデータとは、ネットワーク機器、サーバー、PC、クラウドサービスなど、組織内のあらゆるIT資産から収集されるシステムログ、イベントログ、ネットワークフロー情報などを指します。

近年、EDR（Endpoint Detection and Response）やXDR（Extended Detection and Response）、SIEM（Security Information and Event Management）といったソリューションの普及により、収集できるTelemetryデータの種類と量は飛躍的に増加しました。PC上のプロセス実行履歴、ファイル操作、ネットワーク通信といった詳細なエンドポイントのデータから、ファイアウォール、プロキシ、認証サーバーのログまで、多様なデータを統合的に分析できます。検知ルールの精度は、これらの質の高いTelemetryデータをいかに活用できるかにかかっているのです。

検知ルールは、大きく「Detection Rule」と「Correlation Rule」の2種類に大別されます。この2つの特性を理解し、適切に使い分けることが、検知ルール設計の第一歩です。

Detection Ruleは、単一のイベントやログの中から、特定のパターンや値に合致した場合にアラートを発する、最も基本的な検知ルールです。「単発検知」とも呼ばれ、既知の脅威情報を基に作成されることが多く、比較的シンプルで実装が容易な点が特徴です。

Detection Ruleのメリットは、既知の脅威に対して迅速かつ確実に検知できる点です。一方、攻撃者がファイルハッシュ値やIPアドレスを少しでも変更すると検知できなくなる「もぐら叩き」に陥りやすく、文脈を考慮しないため誤検知が発生しやすい傾向があります。

Correlation Ruleは、複数の異なるデータソースから収集されたイベントやログを、時間軸やコンテキスト（文脈）で関連付けて分析し、一連の活動が攻撃シナリオに合致する場合にアラートを発する、より高度な検知ルールです。「相関検知」や「相関分析ルール」とも呼ばれます。

これらのイベントA, B, Cは単体では必ずしも異常とは限りませんが、短時間に連続して発生した場合、内部不正やアカウント乗っ取りによる情報漏洩の可能性が極めて高いと判断できます。これがCorrelation Ruleの力です。

メリットは、未知の脅威や巧妙な攻撃シナリオの検知に優れ、誤検知を大幅に低減できる点です。ただし、設計が複雑で、攻撃手法に関する深い知識と継続的なチューニングが求められます。

重要なのは、両者を組み合わせた多層的な検知体制です。既知の脅威はDetection Ruleで迅速にブロックし、すり抜けてくる巧妙な攻撃をCorrelation Ruleで捕捉するのがベストプラクティスです。

従来の検知は「IOC（Indicator of Compromise / 侵害指標）」ベースが主流でした。これはマルウェアのハッシュ値や悪性IPアドレスといった、攻撃の「痕跡」情報です。しかし、攻撃者はこれらを容易に変更できるため、検知は後手に回りがちです。

そこで近年注目されているのが、「IOB（Indicator of Behavior / 振る舞い指標）」に基づく検知です。IOBは、攻撃者が目的を達成するために取る「行動や手順」のパターンを指します。

例えば、「PowerShellを使い、難読化されたコマンドを実行する」といった振る舞いです。攻撃ツールが変わっても「手口」は共通していることが多く、IOBに着目することで未知の脅威にも対応しやすくなります。このIOBを捉えるには、Correlation Ruleの設計が極めて有効です。

IOBベースのルールを体系的に設計する上で強力な武器となるのが、「MITRE ATT&CK」フレームワークです。ATT&CKは、サイバー攻撃で利用される戦術（Tactics）と技術（Techniques）を体系化したナレッジベースです。

ATT&CKを活用し、自社の検知ルールがどの攻撃技術をカバーできているかを可視化（ルールマッピング）することで、「ランサムウェア攻撃で多用される『データの暗号化』技術への検知が手薄だ」といった弱点を客観的に把握できます。ATT&CKを羅針盤として、自社のリスクに応じた検知カバレッジを戦略的に向上させましょう。

検知ルールは、一度作ったら終わりではありません。「作成 → テスト → 展開 → 監視 → 評価 → 改善」というライフサイクルを継続的に回すことが重要です。

特に重要なのが「チューニング」です。誤検知が多いルールは、検知条件を厳しくしたり、特定のサーバーやユーザーを対象外とする例外設定（ホワイトリスト）を追加したりします。逆に、検知すべき脅威を逃している場合は、条件を緩和したり、新たなデータソースを追加したりする必要があります。この地道なチューニングこそが、検知の精度を高め、アナリストが重要なアラートに集中できる環境を作る鍵となります。

効果的なセキュリティ運用を実現するには、Detection RuleとCorrelation Ruleの特性を理解し、適切に使い分けることが不可欠です。既知の脅威はDetection Ruleで対応しつつ、巧妙化する攻撃に対しては、振る舞いに着目したIOBベースのCorrelation Ruleへと検知の軸足をシフトしていくことが重要です。

まずは、自社の環境でどのルールが最も多くの誤検知を生んでいるかを特定することから始めましょう。そして、この記事で紹介した設計パターンやMITRE ATT&CKフレームワークを参考に、ルールの見直しとチューニングに着手してみてください。継続的な改善サイクルを回し、脅威検知能力を向上させ続けることこそが、巧妙化するサイバー攻撃から組織を守る最善の対策です。

A1: 最低でも四半期に一度の定期的な見直しを推奨します。特に、誤検知が多いルールや、長期間アラートが発生していないルールは優先的にレビューすべきです。また、新しい攻撃手法の情報を得た際や、社内に新システムを導入した際には、都度見直しを行うのが理想的です。

A2: Sigmaルールなどはルール作成の出発点として非常に有用ですが、そのまま適用すると大量の誤検知が発生する可能性があります。自社の環境に合わせて、IPアドレスのホワイトリストを追加したり、特定の部署を除外したりといったチューニングを必ず行ってから本番運用することが重要です。

A3: 内部不正の検知には、Correlation Ruleが特に有効です。単発の操作は正常業務と見分けがつきにくいためです。例えば、「退職予定者による、業務時間外の大量ファイルダウンロード」「開発者アカウントによる、本番顧客データベースへのアクセス」など、複数の振る舞いやコンテキストを組み合わせたシナリオベースのルールが効果を発揮します。