4つの語の違い:監視する層と動作
IDS・IPS・WAF・EDRは、どれも攻撃を見つける仕組みです。違いは、監視する場所と、見つけた後の動きにあります。ここを取り違えると、導入済みの製品で防げると思っていた攻撃が、実際には素通りします。
| 用語 | 主な設置場所 | 見ているもの | 見つけた後の動作 | 止められないものの例 |
|---|---|---|---|---|
| IDS(侵入検知システム) | ネットワークの複製トラフィック | パケットや通信のパターン | アラートを出すだけ | すべて(遮断しない) |
| IPS(侵入防止システム) | 通信経路の途中(インライン) | IDSと同じ | 該当通信を遮断する | 暗号化された中身、正規の認証情報を使った操作 |
| WAF(Webアプリケーションファイアウォール) | Webサーバーの手前 | HTTPリクエストの中身 | リクエストを遮断・記録する | HTTP以外の通信、アプリの権限設計の不備 |
| EDR(エンドポイント検知・対応) | PCやサーバーの中(エージェント) | プロセス、ファイル、レジストリ、通信元のプログラム | プロセス停止、端末のネットワーク隔離 | エージェントが入っていない機器、ネットワーク機器そのもの |
IDSとIPSの差は「検知」か「遮断」か
IDSとIPSは、同じ検知エンジンを使う製品が多くあります。違いは設置方法です。IDSはスイッチのミラーポートなどから通信の複製を受け取るため、通信を止める位置にいません。IPSは通信経路に挟まるため、遮断できます。その代わり、誤検知すると正常な業務通信も止まります。
このため、IPSを導入しても、当面は「検知のみ」モードで運用している組織は珍しくありません。製品の管理画面で各ルールの動作が alert なのか drop なのかを確認しない限り、IPSが実際に遮断しているかどうかは分かりません。
どちらにも共通する限界があります。通信がTLSで暗号化されていると中身を検査できません。また、盗まれたIDとパスワードによる正規のログインは、通信としては正常に見えます。
WAFはHTTPの中身を見るが、アプリの論理は見えない
WAFは、HTTPリクエストのURL、パラメータ、ヘッダー、本文を検査します。SQLインジェクションやクロスサイトスクリプティングのような、入力値に特徴が出る攻撃に強い仕組みです。HTTPSの中身を見るため、WAFかその手前でTLSを終端(復号)する構成が必要です。
一方で、他人のIDに書き換えると他人の注文履歴が見えてしまう、といった認可の不備は、リクエストの形が正常と変わらないため検知が困難です。SSHやデータベースへの直接接続など、HTTP以外の通信も対象外です。こうしたWebアプリのリスク分類はOWASP Top 10が参考になります。
EDRは端末の中で起きたことを見る
EDRは端末に入れたエージェントで、どのプロセスがどのプロセスを起動し、どのファイルに触れ、どこへ通信したかを記録します。ネットワーク機器では見えない暗号化後の動きや、正規ツールを悪用した操作も、端末上の振る舞いとして捉えられます。
限界は、エージェントが動いていない機器です。VPN装置、ルーター、NAS、複合機、一部のLinuxサーバーは対象外になりやすく、執筆時点でもこうした機器が侵入口になる事例が繰り返し報告されています。
一つの攻撃の流れに当てはめる
公開Webサーバーの脆弱性が突かれ、社内へ被害が広がる流れを例にします。
最初の段階は、外部からの脆弱性を狙ったリクエストです。ここではWAFのログに、該当ルールIDとリクエストURIが残ります。WAFが検知モードなら、記録はされても通ってしまいます。次に、Webサーバー上でWebサーバーのプロセスがシェルを起動します。これはEDRがプロセスツリーとして記録する領域で、WAFやIPSには見えません。続いて、攻撃者が社内の他サーバーへ管理用プロトコルで接続を試みます。社内セグメントにIDS/IPSがあれば、通常ありえない通信元からの接続として検知できる可能性があります。最後に外部へのデータ送信が起きます。宛先がHTTPSであれば、IPSは中身を見られず、EDRの通信記録や外部向けプロキシのログが手がかりになります。
攻撃の段階ごとの整理には、MITRE ATT&CKの分類が多くの製品資料で使われています。
製品資料・脆弱性情報・見積もりの読み方
製品資料で「次世代ファイアウォール(NGFW)にIPS機能を搭載」とあれば、IPSは追加ライセンスやシグネチャ更新契約が別途必要な場合があります。「XDR」は、EDRの情報にネットワークやクラウドのログを組み合わせて分析する製品群の呼称で、範囲は製品ごとに異なります。「MDR」は製品ではなく、外部の専門家がEDR等のアラートを監視・対応するサービスです。
脆弱性情報の回避策に「WAFで該当パスへのアクセスを制限する」とある場合、それは修正パッチ適用までの時間稼ぎです。WAFのルールで防げるのは既知の攻撃パターンに限られるため、パッチ適用の予定は別に立てる必要があります。最新の回避策は、ベンダーの公式アドバイザリやIPA、JPCERT/CCの情報で確認してください。
見積もりでは、課金単位を確認します。IPSは処理帯域、WAFは保護するFQDN数やリクエスト量、EDRは端末台数が一般的です。そのうえで、シグネチャ更新、24時間の監視、検知時の隔離操作を誰が行うかが含まれているかを確認します。製品だけ導入してアラートを誰も見ない状態は、IDSを置いただけと同じです。
アラートとログで最初に確認する項目
IDS/IPSのアラートでは、シグネチャ名、送信元と宛先、そして動作(検知のみか遮断か)を最初に見ます。宛先のサーバーに該当する脆弱性がなければ、試行だけで終わった可能性が高いと判断できます。
WAFでは、ルールID、リクエストURI、応答ステータスを確認します。遮断済みで403が返っていれば到達していません。検知モードで200が返っていれば、サーバー側のログとEDRで実行の痕跡を追います。正常な業務リクエストが繰り返し引っかかる場合は、ルール単位の除外設定を記録付きで行います。
EDRでは、親プロセスとコマンドラインを確認します。Webサーバーや文書作成ソフトのプロセスからシェルが起動していれば、優先度を上げて端末の隔離を検討します。
自組織に欠けている層を判断する基準
まず、外部公開している機器とサービスを一覧にし、それぞれの通信がWAF・IPS・EDRのどれの監視下にあるかを対応付けます。どれにも当てはまらない機器、特にVPN装置やエージェントを入れられない機器が残ったら、そこが優先的に対策すべき箇所です。次に、各製品が検知モードか遮断モードか、アラートを誰がいつ確認するかを確認します。製品の有無ではなく、この対応表の空白と運用体制で、次の投資先を判断してください。