はじめに: セキュリティ製品は、導入しただけでは組織を守れない
- IDS: 侵入検知システム, Intrusion Detection System
- IPS: 侵入防止システム, Intrusion Prevention System
これらは、ネットワークやシステム上の通信・動作を監視し、不正な活動の兆候を検知するための仕組みです。IPS は、検知した通信を遮断するなど、防止動作まで行うことを目的とします。
しかし、検知できることと、被害を防げることは同じではありません。監視対象から外れた通信は見えず、アラートが出ても対応する人や権限がなければ状況は変わりません。さらに、装置の設定や証明書、ログ収集、検知ルールが適切に維持されていなければ、製品を導入していても期待した働きをしないことがあります。
この記事では、IDS/IPS の基本と限界を整理したうえで、 Equifax、 Target、 SolarWinds の事例を確認します。
この記事シリーズの要点
- IDS/IPS が検査できるのは、原則として製品が観測できる通信・動作に限られる。
- 検知はインシデント対応の入口であり、調査・判断・封じ込め・復旧までつながって初めて被害を抑えられる。
- AI/ML や高価な監視製品を追加しても、データの不足、誤検知、見逃し、運用能力の不足はなくならない。
- 経営・管理側には、必要な予算・人員・判断権限と、現場が実行できる優先順位を整える役割がある。
1. IDS/IPS は何を検知し、何を防ぐのか
IDS/IPS は、攻撃をすべて止める装置ではありません。監視できる通信や動作について、不審な兆候を見つけ、必要に応じて遮断し、調査に使える情報を残すための防御手段です。
| 機能 | 主な働き | 組織にとっての意味 |
|---|---|---|
| IDS | 不審な通信・動作を検知し、記録・通知する | 攻撃の兆候を把握し、調査や対応を開始する手掛かりになる |
| IPS | 検知した通信を遮断するなど、防止動作を行う | 条件に合致した攻撃の一部を、対象システムへ到達する前に止められる |
| 異常・振る舞い分析 | 通信量、接続先、利用パターン、プロトコルの逸脱などを分析する | 既知の攻撃パターンだけでは捉えにくい活動を調査する手掛かりになる |
| ログ・アラート | 検知内容や関連情報を記録・通知する | インシデント対応、監査、事後検証、検知ルールの改善に利用できる |
IDS と IPS は、必ずしも別々の製品を意味するわけではありません。両方の機能を備える製品もあります。また、ネットワークの通信経路上で動作するネットワーク型だけでなく、個々のサーバーや端末上の動作を監視するホスト型もあります。 IPS の遮断機能を実際に使うには、通信経路上で制御できる構成や、ホスト側で防止動作を実行できる構成が必要です。製品名だけでなく、配置・設定・有効化されている機能を確認しなければなりません。[1]
監視技術は、観測対象と役割が異なる
IDS/IPS と関連製品は、名称が似ていても同じ仕事をするわけではありません。以下は一般的な役割の整理です。実際の機能範囲は製品や構成によって異なり、特に NDR とネットワーク型 IDS/IPS、 XDR と EDR/SIEM の機能には重なりがあります。
| 技術 | 主に扱う情報 | 主な役割 | 留意点 |
|---|---|---|---|
| ネットワーク IDS/IPS | 観測地点を流れるネットワーク通信 | 不審な通信の検知、条件に応じた遮断 | センサーの配置や通信経路によって見える範囲が決まる |
| ホスト型 IDS/IPS | サーバー・端末上のイベントや動作 | ファイル、プロセス、システム活動などの監視・防止 | 対象ホストへの導入・管理が必要 |
| EDR (Endpoint Detection and Response) | 端末・サーバーのプロセス、ファイル、接続、操作など | エンドポイント上の不審な挙動の検知と対応 | 対象端末にセンサーが導入され、情報が適切に送られている必要がある |
| NDR (Network Detection and Response) | ネットワーク通信や通信メタデータ | ネットワーク全体の振る舞いを分析し、不審な活動を調査する | 観測できるセグメントや通信に依存する。対応機能の範囲は製品ごとに異なる |
| SIEM (Security Information and Event Management) | ネットワーク、端末、ID、クラウド、アプリケーションなどのログ | ログを集約し、ルールや相関分析によって検知・調査を支援する | ログを集めるだけでは不十分。対象選定、品質、分析ルール、運用が必要 |
| XDR (Extended Detection and Response) | 複数のセキュリティ領域から得られるテレメトリー | 複数領域の情報を関連付けて検知・対応を支援する | 製品によって統合対象や機能範囲が異なり、共通の実装境界が一様に定まっているわけではない |
組織内外の通信・システム活動
|
+---------------+----------------+
| |
v v
+------------------+ +------------------+
| ネットワーク上 | | 端末・サーバー上 |
| IDS / IPS | | EDR / Host IDS |
+------------------+ +------------------+
| |
+---------------+----------------+
|
v
+--------------------------+
| SIEM / XDR など |
| ログ・情報の集約と相関 |
+--------------------------+
|
v
+--------------------------+
| 担当者による調査・判断 |
| 封じ込め・復旧・振り返り |
+--------------------------+
NDR は、ネットワーク上の情報を別の観点から分析・関連付ける
役割を担う。各製品の連携方法や構成は環境によって異なる。
この図は役割の関係を示す概念図であり、すべての組織が同じ製品構成を採用すべきだという意味ではありません。重要なのは、守るべき資産と想定する脅威に対して、必要な情報が観測され、分析され、対応担当者へ届くことです。
ネットワーク型 IDS/IPS が主に確認するのは、センサーが観測できる通信です。通信内容が暗号化されている場合、適切な復号・検査の仕組みがなければ、暗号化されたペイロードの詳細までは確認できません。また、正規の認証情報や正規の通信手順を悪用する活動は、通信の形式だけでは不正と判断しにくいことがあります。
IDS/IPS は必要な防御手段ですが、完全な防御を約束するものではありません。 どこを監視しているか、正常に動作しているか、アラートに誰が対応するか、侵入された後の被害をどこまで抑えられるかを、組織として継続的に管理する必要があります。
2. 監視製品があっても被害を防げなかった事例
実際のインシデントを見ると、製品が存在しなかったことだけが原因ではありません。監視対象に死角があった、検知情報が有効に届かなかった、アラートが対応につながらなかった、侵入後の被害を限定できなかった、といった問題が重なっています。
事例 1: Equifax の大規模情報漏えい (2017 年) ——監視経路の証明書管理と資産把握の問題
2017 年、米国の信用情報機関 Equifax で、約 1 億 4,800 万人分に影響する大規模な情報漏えいが発生しました。米国下院の調査報告書によると、攻撃者は Apache Struts の脆弱性を悪用して、インターネットに公開されていた Web アプリケーションに侵入しました。同報告書は、脆弱性の公表後も該当システムへの修正が完了せず、攻撃者が個人情報を取得・持ち出した経緯を記録しています。[3]
この事件では、 IDS と IPS が設置されていました。 Equifax は 2017 年 3 月 14 日に Apache Struts の悪用試行を検知する Snort ルールを IDS/IPS に導入しました。しかし、これはルールを導入したという記録であり、同日に複数の攻撃を遮断したことを示す記述ではありません。さらに、翌 3 月 15 日に脆弱性スキャンを実施した際、外部向けの 958 個の IP アドレスを調べても、脆弱なシステムを発見できませんでした。報告書は、修正作業に使われたスキャンツールが脆弱な Apache Struts の存在を特定できなかったとしています。[3]
もう一つの重大な問題が、暗号化通信を復号して検査装置へ渡す SSL Visibility Appliance (SSLV) の証明書管理でした。ここでいう ACIS (Automated Consumer Interview System) は、 Equifax が消費者の異議申し立てなどを受け付けるインターネット公開ポータルです。下院の調査報告書によると、 ACIS 環境の通信を監視する SSLV の証明書は 2016 年 1 月 31 日に期限切れとなっていました。装置の既定設定では、証明書の期限が切れていても Web 通信をシステムへ通過させるため、背後に配置された IDS/IPS は暗号化された通信を検査できませんでした。 Equifax が 2017 年 7 月 29 日に証明書を更新すると、ほぼ直ちに不審な通信が確認されました。同報告書は、監視できない状態が 19 か月続いていたと記録しています。[3]
外部からの HTTPS 通信
|
v
+----------------------+
| SSL Visibility |
| Appliance (SSLV) |
| |
| 証明書の期限切れ |
| 通信を復号できない |
+----------------------+
|
暗号化された通信が通過
|
v
+----------------------+
| IDS / IPS |
| |
| ペイロードを検査 |
| できない状態 |
+----------------------+
|
v
+----------------------+
| ACIS Web システム |
+----------------------+
問題の本質: 監視装置の異常が、通信の遮断や明確な障害として
表面化せず、検査を行わないまま通信が続いていた。
この事例が示すのは、 IDS/IPS の検知ルールだけでは防御が成立しないということです。監視装置の証明書・稼働状態、資産台帳、脆弱性スキャン、パッチ適用、ネットワーク分離が一体として機能しなければなりません。監視装置が動いているように見えても、実際に必要な通信を検査できているかまで確認する必要があります。[3]
事例 2: Target の情報漏えい (2013 年) ——アラートが調査・対応につながらなかった
2013 年、米国の小売企業 Target で、決済カード情報などが大量に窃取されました。2014 年の米国上院公聴会資料に収録された委員会スタッフ報告書は、当時公表されていた報道や専門家の分析をもとに、攻撃者が第三者の取引先である HVAC 事業者の認証情報を経由して Target のネットワークへ侵入し、内部の決済関連システムへ活動範囲を広げた経緯を整理しています。同報告書は、当時の公開情報だけでは事件の全容が確定していないことも明記しています。[4]
同報告書が引用する Bloomberg Businessweek の調査報道によると、データ持ち出し用マルウェアが設置された際、 Target の FireEye マルウェア検知システムは緊急アラートを発していました。しかし、 Target のセキュリティチームはアラートに反応せず、自動削除機能も有効にしていなかったと報じられています。また、アラート名は一般的な malware.binary だったとされ、報告書は、警告が頻繁に出ていた場合には誤検知と受け取られた可能性があると述べています。ただし、これは当時の報道に基づく可能性の指摘であり、担当者が実際に誤検知と判断したことが確定しているわけではありません。[4]
この事例から得られる教訓は、検知できることと、検知した情報に基づいて行動できることは別の能力だという点です。製品が警告を出していても、誰が確認し、どの基準で重大性を判断し、誰が封じ込めを決定するのかが定まっていなければ、防御は機能しません。
事例 3: SolarWinds のサプライチェーン攻撃 (2020 年) ——信頼されたソフトウェアと通信に紛れる脅威
2020 年に明らかになった SolarWinds Orion のサプライチェーン攻撃では、攻撃者は Orion ソフトウェアの開発・配布過程に不正なコードを混入させました。 CISA の 2020 年 12 月 17 日付アラートによると、不正な DLL は正規の SolarWinds コード署名証明書で署名され、ソフトウェア更新を通じて配布されました。インストール後の不正な通信には、正規の SolarWinds プロトコルを模倣する仕組みが使われていました。[5]
この攻撃では、ソフトウェアの署名が正規であることや、通信が通常の製品通信に似ていることが、攻撃の隠蔽に利用されました。 CISA は、 Orion 以外の初期侵入経路も存在したと説明しています。そのため、この事例を「すべての侵入が Orion 経由だった」と単純化することも、「特定の組織の IDS/IPS が導入されていたのに突破された」と一律に断定することも適切ではありません。[5][6]
このような脅威に備えるには、ネットワーク通信だけでなく、ソフトウェアの配布元・署名・更新履歴、実行プロセス、特権アカウントの利用状況、通常とは異なる接続先や通信量などを関連付けて確認する必要があります。信頼されたソフトウェアであっても、更新経路や実行後の挙動を検証する視点が欠かせません。
3 つの事例から見える違い
| 事例 | 主な問題 | 組織が学ぶべきこと |
|---|---|---|
| Equifax (2017 年) | 脆弱なシステムの特定・修正ができず、監視経路の証明書失効にも気付けなかった | 監視装置の稼働確認、資産管理、脆弱性管理を一体として継続する |
| Target (2013 年) | 検知アラートが調査・封じ込めにつながらなかった | アラートの優先順位、担当者、対応期限、判断権限を定める |
| SolarWinds (2020 年) | 正規のソフトウェア更新や通常通信に紛れる攻撃が行われた | 通信だけでなく、ソフトウェア供給網、ID、端末の挙動も関連付けて監視する |
3. IDS/IPS にも構造的な限界がある
検知・防止の対象となる通信や動作を観測できなければ、装置は適切に判断できません。また、通信が正常な形式で行われていても、その利用目的や業務上の正当性までネットワーク機器だけで判断できるとは限りません。
| 検知・防御が難しくなる領域 | 何が起きるのか | 補完策の例 |
|---|---|---|
| 暗号化された通信 (HTTPS/TLS) | 復号・検査を行わなければ、暗号化されたペイロードの詳細は確認できない | 管理された環境での TLS 可視化、通信メタデータの分析、端末・サーバー・アプリケーションのログ活用 |
| 正規の認証情報を使ったアクセス | 盗まれた ID / パスワード、セッショントークン、API キーなどで正規の手順を使われると、通信形式だけでは不正と判断しにくい | 多要素認証、最小権限、認証・操作ログの相関、重要操作時の追加確認 |
| 正規のクラウドサービスを使ったデータ持ち出し | 通常利用されるクラウドストレージや外部サービスへの通信にデータを紛れ込ませることがある | データ持ち出しの監視、送信先・送信量・利用者の文脈分析、機密データへのアクセス制御 |
| 内部ネットワークでの横移動 | 侵入後の端末間通信が通常の業務用プロトコルを使うと、境界に置いた装置だけでは検知・遮断しにくい | ネットワーク分離、端末・サーバー側の監視、管理者権限の制限 |
| 新しい攻撃や変化した攻撃 | 既知のパターンや検知ロジックの想定と一致しない活動は、見逃される可能性がある | 振る舞い分析、脅威情報の更新、検知ルールの見直し、脅威ハンティング |
暗号化通信は「見えない」のではなく、見える範囲と方法に制約がある
上述の HTTPS/TLS は、通信内容を保護するために不可欠です。一方、ネットワークの途中で通信内容を検査する製品にとっては、暗号化されたペイロードをそのまま読むことはできません。接続先や通信量などのメタデータを観測できる場合はありますが、見える情報はプロトコルのバージョン、設定、観測地点などによって変わります。メタデータだけで通信内容や利用目的を確定できるわけではありません。
暗号化通信の内容まで検査する方法の一つは、組織が管理する環境で、適切な鍵管理や復号・再暗号化などの仕組みを用意することです。ただし、すべての通信を無条件に復号すればよいわけではありません。プライバシー、法令・契約上の要件、証明書や鍵の管理、相互 TLS 認証や証明書ピンニングとの互換性、システムへの影響などを考慮する必要があります。
TLS 1.3 では、 TLS 1.2 以前に使われていた一部の受動的な復号手法がそのまま利用できない場合があります。 NIST は 2025 年に、 TLS 1.3 を維持しながら、企業の管理下にあるデータセンター内の通信を監視・分析するための標準準拠の構成例をまとめた実践ガイドを公開しました。これは「すべての通信を一律に復号する」ことを推奨するものではなく、管理された環境で必要な可視性を確保するための選択肢を示すものです。[2]
したがって、暗号化は「監視を諦める理由」ではありません。通信内容をどこまで検査するか、メタデータや端末側の情報で何を補うかを、プライバシーや業務要件と合わせて設計する課題です。
おわりに
この記事では、IDS/IPS の基本と限界を整理したうえで、事例を確認しました。
次回は次のことを掘り下げます。
- 近年の検知技術と AI/ML の役割
- 経営者・管理者の主体的な関わり、整えるべき運用体制
参考資料・出典
- NIST SP 800-94, “Guide to Intrusion Detection and Prevention Systems (IDPS)” (2007 年 2 月) — ネットワーク型、無線型、ネットワーク振る舞い分析型、ホスト型の IDPS の分類と、設計・導入・設定・監視・保守の基礎資料。刊行年が古いため、現在の製品機能を網羅する資料ではなく、基本的な技術分類の参照先として使用。 NIST CSRC
- NIST SP 1800-37, “Addressing Visibility Challenges with TLS 1.3 within the Enterprise” (2025 年 9 月 17 日) — TLS 1.3 を利用しながら、管理された企業ネットワーク内で通信の可視性を確保するための実践ガイド。 NIST CSRC
- U.S. House Committee on Oversight and Government Reform, “The Equifax Data Breach: Majority Staff Report” (2018 年 12 月) — Apache Struts の脆弱性、 Snort ルールの導入、外部向け IP アドレスのスキャン、 SSLV の証明書期限切れ、監視不能期間などを記録。本文の 19 か月という期間は、同報告書が入手した証明書一覧に基づく記述を採用。同報告書の脚注には、 GAO が別の報告書で 10 か月としたことも記されている。 報告書 PDF
- U.S. Senate Committee on Commerce, Science, and Transportation, “Protecting Personal Consumer Information from Cyber Attacks and Data Breaches” (2014 年 3 月 26 日公聴会資料) — Target の侵入経路、ネットワーク分離、 FireEye のアラートなどに関する委員会スタッフ報告書を収録。スタッフ報告書は当時の報道・専門家分析をもとに作成され、事件の全容が確定していないことを明記している。 U.S. Government Publishing Office
- CISA, “AA20-352A: Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations” (2020 年 12 月 17 日) — SolarWinds Orion のサプライチェーン侵害、正規のコード署名証明書で署名された不正 DLL、正規の Orion 通信を模倣する通信などを説明。 CISA Advisory
- MITRE ATT&CK, “SUNBURST (S0559)” — SUNBURST の概要と、 HTTP/DNS を利用した通信、通常の SolarWinds API 通信を模倣する手法を整理。 MITRE ATT&CK
本記事は IDS/IPS や AI を活用した監視製品の価値を否定するものではありません。各製品の検知範囲・対応方式は、製品、配置、設定、監視対象によって異なります。導入時には、実際の構成と運用条件を確認してください。