DEV Community: nabbisen

IDS/IPS を導入しても安心ではない —— Web サイトと API を守るために経営者・管理者が理解すべきこと

nabbisen — Sat, 31 Oct 2026 11:10:00 +0000

はじめに: セキュリティ製品は、導入しただけでは組織を守れない

IDS: 侵入検知システム, Intrusion Detection System
IPS: 侵入防止システム, Intrusion Prevention System

これらは、ネットワークやシステム上の通信・動作を監視し、不正な活動の兆候を検知するための仕組みです。IPS は、検知した通信を遮断するなど、防止動作まで行うことを目的とします。

しかし、検知できることと、被害を防げることは同じではありません。監視対象から外れた通信は見えず、アラートが出ても対応する人や権限がなければ状況は変わりません。さらに、装置の設定や証明書、ログ収集、検知ルールが適切に維持されていなければ、製品を導入していても期待した働きをしないことがあります。

この記事では、近年の検知技術と AI/ML の役割を整理し、最後に経営・管理側が整えるべき運用体制を考えます。

この記事シリーズの要点

IDS/IPS が検査できるのは、原則として製品が観測できる通信・動作に限られる。

検知はインシデント対応の入口であり、調査・判断・封じ込め・復旧までつながって初めて被害を抑えられる。

AI/ML や高価な監視製品を追加しても、データの不足、誤検知、見逃し、運用能力の不足はなくならない。

経営・管理側には、必要な予算・人員・判断権限と、現場が実行できる優先順位を整える役割がある。

1. IDS/IPS は何を検知し、何を防ぐのか

IDS/IPS は、攻撃をすべて止める装置ではありません。監視できる通信や動作について、不審な兆候を見つけ、必要に応じて遮断し、調査に使える情報を残すための防御手段です。

機能	主な働き	組織にとっての意味
IDS	不審な通信・動作を検知し、記録・通知する	攻撃の兆候を把握し、調査や対応を開始する手掛かりになる
IPS	検知した通信を遮断するなど、防止動作を行う	条件に合致した攻撃の一部を、対象システムへ到達する前に止められる
異常・振る舞い分析	通信量、接続先、利用パターン、プロトコルの逸脱などを分析する	既知の攻撃パターンだけでは捉えにくい活動を調査する手掛かりになる
ログ・アラート	検知内容や関連情報を記録・通知する	インシデント対応、監査、事後検証、検知ルールの改善に利用できる

IDS と IPS は、必ずしも別々の製品を意味するわけではありません。両方の機能を備える製品もあります。また、ネットワークの通信経路上で動作するネットワーク型だけでなく、個々のサーバーや端末上の動作を監視するホスト型もあります。 IPS の遮断機能を実際に使うには、通信経路上で制御できる構成や、ホスト側で防止動作を実行できる構成が必要です。製品名だけでなく、配置・設定・有効化されている機能を確認しなければなりません。[1]

2. 検知技術は広がったが、死角は残る

シグネチャ照合は、現在も重要な検知方式です。ただし、 IDS/IPS は既知の攻撃パターンだけで動くわけではありません。プロトコルの異常や通信の振る舞いを分析する方式も以前からあり、複数の手法を組み合わせて検知することが一般的です。したがって、検知技術を単純に「従来型のシグネチャ」と「新しい AI/ML」に二分するのは正確ではありません。[1]

検知・分析の手法	どのように判断するか	強みと限界
シグネチャ照合	既知の攻撃パターンや特徴と照合する	既知の脅威を比較的明確に検知できる一方、未登録・変化した攻撃には弱い場合がある
プロトコル異常分析	通信プロトコルの仕様や通常の利用方法から外れた動きを検知する	不正な形式や不自然な通信を捉えられるが、正規の手順を悪用した活動は判断しにくい
振る舞い・異常分析	通信量、接続先、利用時間、アクセス対象などの通常状態からの逸脱を検知する	未知の活動の手掛かりになる一方、正常な業務変更も異常と判定することがある
ログの相関分析	異なるシステムで発生した複数のイベントを時間軸や関係性で結び付ける	攻撃の一連の動きを把握しやすいが、ログが不足・不整合であれば分析できない
脅威情報との照合	公開・共有された不正な IP アドレス、ドメイン、ファイルハッシュなどと照合する	既知の脅威の手掛かりになるが、情報の鮮度や攻撃者の変化に左右される

NDR、 EDR、 SIEM、 XDR などは、こうした分析を異なる観測対象や情報源で支援する技術・製品群です。製品によっては機械学習や統計的な分析を使い、単一のシグネチャでは捉えにくい異常を検知します。ただし、 AI/ML がシグネチャやルールベースの検知を全面的に置き換えたわけではありません。

AI/ML や行動分析は検知能力を補う有力な手段ですが、環境の変化やデータの品質に左右されます。監視対象が増えれば自動的に検知が正確になるわけではありません。どの情報を集め、何を正常とみなし、どの変化を重大な兆候として扱うかは、組織の環境に合わせて継続的に調整する必要があります。[3][4]

3. AI/ML を活用しても、見逃しと誤検知がなくならない理由

1. 通常の活動に紛れる「Low-and-Slow」型の攻撃

攻撃者が短時間に大量のデータを持ち出せば、通信量の急増として検知されやすくなります。そこで、活動を長期間に分散し、普段の利用量に近い速度で少しずつデータを取得・送信する手法が使われることがあります。こうした活動は、一般に「Low-and-Slow」型と呼ばれます。

一回ごとの通信だけを見れば異常が小さく、単純な閾値では検知しにくい場合があります。一方、期間をまたいだ利用者の行動、アクセス先、データ取得量などを関連付ければ、異常の兆候を捉えられる可能性があります。重要なのは、単発のアラートだけでなく、時間軸と複数システムを横断した分析です。[3]

2. 正規の認証情報や権限の悪用

攻撃者が盗んだ ID/パスワード、セッショントークン、 API キーなどを使う場合、通信そのものは正規の利用者やシステムから発生したように見えることがあります。

認証に成功したという事実は、その利用者が対象データを閲覧・操作する正当な権限を持つことを保証しません。ネットワーク監視だけでなく、 ID の利用状況、権限、アクセス対象、操作の業務上の妥当性を組み合わせて確認する必要があります。利用者の通常業務から大きく外れる操作を検知するには、システムのログだけでなく、業務や役割についての理解も重要です。[2]

3. 「正常」の基準そのものが間違っている可能性

行動分析では、通常の通信や利用者の振る舞いを基準 (ベースライン) として学習・比較する方法があります。しかし、すでに侵害されている状態を「通常」として学習してしまえば、不正な活動が正常の一部として扱われる可能性があります。

英国の国家サイバーセキュリティセンター (NCSC) は、ベースラインを作る際に、そのシステムがすでに侵害されていないかを考慮するよう注意を促しています。ベースライン比較は有効な手法ですが、無条件に信頼できる基準ではありません。[7]

4. 偽陽性・偽陰性とアラート疲労

異常検知の感度を高くすれば、通常の業務変更、開発テスト、夜間バッチ処理なども警告対象になる場合があります。反対に、誤検知を減らそうとして検知条件を厳しくしすぎると、本物の攻撃の兆候を見逃す可能性があります。

偽陽性 (False Positive): 実際には問題がないのに、異常やインシデントとして警告すること。
偽陰性 (False Negative): 実際には問題が起きているのに、検知できず警告しないこと。

オーストラリアの公的サイバーセキュリティ機関が 2025 年に公表した SIEM/SOAR 実践ガイダンスは、ログが不完全・不整合である場合や、検知ルールの感度が適切でない場合には偽陰性が生じる一方、ログを過剰に取り込み、ルールやフィルターを適切に調整しなければ偽陽性が大量に発生すると説明しています。偽陽性が多すぎると、担当者が警告を処理しきれず、実際のインシデントへの対応が遅れる「アラート疲労」につながります。[4]

                    アラート疲労の悪循環

       ログの過剰収集・検知ルールの調整不足
                         |
                         v
              偽陽性を含む大量のアラート
                         |
                         v
                 担当者の確認負荷が増大
                         |
                         v
              優先順位付け・調査が形式化
                         |
                         v
               重要な兆候の見落とし・遅延
                         |
                         v
                被害の拡大・復旧コスト増大
                         |
                         +------> 運用がさらに疲弊

この問題は、 AI を導入すれば自動的に解消するものではありません。 NCSC は、アラートを担当者が調査できる量に抑え、複数の兆候を相関させ、検知ルールを定期的に見直し、演習などで検知の有効性を検証することを推奨しています。[3]

4. 高価な製品を増やす前に、検知から対応までの運用を設計する

IDS/IPS、 NDR、 EDR、 SIEM などは、それぞれ異なる情報を捉えます。重要なのは、すべての製品を導入することではありません。自組織が守るべき資産と想定する脅威に応じて、必要な情報が集まり、判断・対応につながる仕組みを作ることです。

       通信・端末・ID・クラウド・アプリケーションの情報
                              |
                              v
                    +------------------+
                    | 検知・分析        |
                    | ルール / 相関分析 |
                    +------------------+
                              |
                              v
                    +------------------+
                    | トリアージ        |
                    | 重要度・影響範囲  |
                    +------------------+
                              |
                              v
                    +------------------+
                    | 調査・判断        |
                    | 事実確認・承認    |
                    +------------------+
                              |
                              v
                    +------------------+
                    | 封じ込め・復旧    |
                    | 隔離・遮断・再開  |
                    +------------------+
                              |
                              v
                    +------------------+
                    | 振り返り・改善    |
                    | ルール・手順更新  |
                    +------------------+
                              |
                              +--------> 検知・分析へ反映

検知から対応までを一つの流れとして設計し、各段階の担当者・判断基準・引き継ぎ条件を明確にすることが重要です。

運用上の取り組み	具体的な内容	期待する効果
資産の重要度に基づく優先順位付け	個人情報・決済情報を扱うシステム、重要 API、管理者環境などを特定する	重要な資産に監視・対応リソースを集中する
ログと監視範囲の整備	ネットワーク、端末、ID、クラウド、アプリケーションの必要なログを選び、取得状況や欠損を定期確認する	検知の死角や、分析に必要な情報の不足を減らす
SIEM の収集対象の選定	セキュリティ分析に必要なログを優先し、保管・監査を主目的とする大量ログとは役割や保存先を分けて考える	不要なデータ量やコストを抑え、分析の質を保つ
アラートのトリアージ	重大度、影響資産、攻撃の進行状況、業務への影響などで優先順位を付ける	重要な警告を先に調査し、対応遅延を減らす
検知ルールの継続的な調整	偽陽性・偽陰性を振り返り、ルールの追加・修正・廃止を行う	環境や脅威の変化に追随する
対応手順と権限の明確化	誰が調査し、誰がアカウント停止・端末隔離・ネットワーク遮断・サービス停止を決定するか定める	検知から封じ込めまでの時間を短縮する
自動化の段階的な活用	明確な条件のある定型処理から自動化し、誤動作時の解除・復旧方法を用意する	人手の負担を減らしつつ、誤った自動遮断による業務影響を抑える
訓練と事後検証	アラート対応、連絡、封じ込め、復旧を演習で試し、検知ルールも検証する	手順の不備や責任分界の曖昧さを発見する

ログを大量に集めれば、分析の精度が必ず上がるわけではありません。 SIEM は、セキュリティ上の事象を見つけるために意味のあるログを選び、適切なルールやフィルターで分析する必要があります。オーストラリアの実践ガイダンスは、 SIEM を単なる全ログ保管場所として利用することによるコストや分析効率の問題にも注意を促しています。[4]

自動化も万能ではありません。誤った判定で正規利用者のアカウントや業務システムを自動隔離すれば、セキュリティ事故とは別の業務障害を引き起こす可能性があります。 SOAR などの自動対応は、組織の環境に合わせて設計・維持する必要があります。オーストラリアのガイダンスは、 SIEM の分析能力や運用経験が成熟していない環境では、 SOAR の導入を急ぐよりも、まずログ分析と検知運用を整えることを優先するよう勧めています。[4]

インシデント対応の計画、役割・権限、手順、訓練は、検知製品の導入とは別に整える必要があります。 NIST の SP 800-61 Rev. 3 も、インシデント対応を個別の技術作業に閉じず、組織全体のサイバーセキュリティリスクマネジメントに組み込む考え方を示しています。[5]

5. 経営者・管理者層が果たすべき役割

高度な IDS/IPS や AI を導入しても、それを運用する人員、判断権限、時間、予算が不足していれば、期待する効果は得られません。セキュリティを現場のエンジニアの努力だけに依存させず、経営・管理側が持続可能な運用条件を整える必要があります。

経営・管理側の役割	実施すべきこと	避けるべき状態
優先順位とトレードオフの決定	重要資産と事業影響に基づき、対応順序、期限、予算を決める	すべてを最優先とし、通常業務も納期も変えずに追加対策だけを現場へ要求する
対応権限の整備	緊急時にネットワーク遮断、アカウント停止、サービス停止を判断できる責任者を定める	技術担当に責任だけを負わせ、必要な判断権限を与えない
人員・専門性の確保	教育、交代要員、外部専門家、マネージドサービスなどを必要に応じて確保する	特定の担当者だけに監視・調査・対応の知識と作業を集中させる
失敗から学ぶ文化	インシデントや見逃しの原因を、個人の責任だけでなく仕組み・手順・情報共有から検証する	報告した人を責め、問題を隠す方が安全だと感じさせる
現場を守る調整役	顧客・営業・監査などからの要求をリスク評価に基づいて調整し、現実的なロードマップを提示する	矛盾する要求や過度なプレッシャーをそのまま現場に押し付ける

「やらないこと」を決めるのも経営の仕事

セキュリティ対策や監視範囲を拡大すれば、設計・開発・検証・運用に必要な時間も増えます。従来の納期や開発速度を一切変えずに、すべての追加要件を現場へ押し付けることは現実的ではありません。

新しい監視や対応プロセスを導入するなら、経営・管理側は、どの機能や作業の優先度を下げるのか、どのスケジュールを調整するのかを決定する必要があります。現場に「工夫して何とかする」ことだけを求めず、必要なトレードオフを組織として引き受けることが重要です。

アラートの件数ではなく、対応の質を見る

検知したアラートの数を、そのままセキュリティチームの成果として評価するのは適切ではありません。アラート数を増やすことは、必ずしも安全性を高めないからです。

経営・管理側は、次のような指標を組み合わせて、検知と対応が実際に機能しているかを確認するとよいでしょう。

指標	定義の例	確認時の注意
MTTD (Mean Time to Detect)	不審な活動が始まってから、組織が検知するまでの時間	攻撃の開始時点を正確に特定できない場合があるため、測定上の起点を定義する
MTTA (Mean Time to Acknowledge)	アラート発生から担当者が確認・受領するまでの時間	「受領」「調査着手」など、どの時点をもって対応開始とするかを明確にする
MTTC (Mean Time to Contain)	検知から封じ込めまでに要した時間	インシデントの重大度や対応内容によって単純比較しない
復旧時間	業務・システムを許容できる状態に戻すまでの時間	封じ込めと復旧を分けて計測する
誤検知・見逃しの傾向	不要な警告が多いルール、演習・事後調査で捉えられなかった兆候	アラート件数だけでなく、調査品質や検知範囲と合わせて見る
監視範囲の充足度	重要資産のログや通信が実際に取得され、分析対象になっている割合	取得できていることと、適切に分析できていることを分けて確認する

MTTR という略語は、文脈によって Response、 Resolution、 Recovery など異なる意味で使われます。組織内で利用する場合は、何を起点・終点として測るかを明記し、封じ込め時間や復旧時間と混同しないことが大切です。

数値だけを追うと、調査の質や重大度の違いが見えなくなることがあります。指標は現場を評価・懲罰するためではなく、運用の弱点を発見し、必要な人員や改善投資を決めるために使うべきです。

おわりに: 製品の高度さより、組織として使い続けられること

IDS/IPS は、ネットワーク上の不正な通信や既知の攻撃パターンを検知・遮断するうえで、今も重要な防御手段です。 NDR、 EDR、 SIEM、 AI/ML による分析などを適切に組み合わせれば、観測範囲や検知能力を広げられる場合もあります。

しかし、暗号化された通信、正規の認証情報の悪用、信頼されたソフトウェアや通信に紛れる攻撃、内部ネットワークでの横移動、そして検知後の対応不備といった課題は、製品を新しくするだけでは解決しません。監視装置が正常に動いているか、必要な情報を取得できているか、アラートが適切に処理されるか、侵入後の被害を抑えられるかを継続的に確認する必要があります。

経営者・管理者層の役割は、最新のセキュリティ製品を購入することだけではありません。守るべき資産と事業リスクを把握し、必要な予算・人員・判断権限を用意し、現場が対応できる優先順位と運用体制を整えることです。現場のエンジニアも、技術的な検知・防止だけでなく、何が見えていて何が見えていないのか、どのような対応が必要なのかを組織に伝えることが求められます。

IDS/IPS は「導入すれば守ってくれる装置」ではありません。監視を機能させ、警告を行動につなげ、弱点を継続的に見直す組織の仕組みがあって初めて、その価値を発揮します。

参考資料・出典

NIST SP 800-94, “Guide to Intrusion Detection and Prevention Systems (IDPS)” (2007 年 2 月) — ネットワーク型、無線型、ネットワーク振る舞い分析型、ホスト型の IDPS の分類と、設計・導入・設定・監視・保守の基礎資料。刊行年が古いため、現在の製品機能を網羅する資料ではなく、基本的な技術分類の参照先として使用。 NIST CSRC
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
UK National Cyber Security Centre, “Building a Security Operations Centre (SOC) — Detection practices” — ベースライン比較の限界、複数ログの相関、アラートのトリアージ、偽陽性への対応、検知ルールの継続的な見直し、演習による検証に関するガイダンス。 NCSC
Australian Signals Directorate / Australian Cyber Security Centre, “Implementing SIEM and SOAR platforms: Practitioner guidance” (2025 年 5 月 27 日) — SIEM のログ選定・分析、偽陽性・偽陰性、アラート疲労、 SOAR の自動対応に伴うリスク、運用に必要な人材・継続的な調整に関する実践ガイダンス。 Australian Cyber Security Centre
NIST SP 800-61 Rev. 3, “Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile” (2025 年 4 月 3 日) — インシデント対応を組織全体のサイバーセキュリティリスクマネジメントに組み込むための推奨事項。 NIST CSRC

本記事は IDS/IPS や AI を活用した監視製品の価値を否定するものではありません。各製品の検知範囲・対応方式は、製品、配置、設定、監視対象によって異なります。導入時には、実際の構成と運用条件を確認してください。

IDS/IPS are useful, but they do not provide complete protection: What Executives and Managers Need to Understand to Protect Websites and APIs

nabbisen — Sat, 31 Oct 2026 10:24:11 +0000

Introduction: Installing Security Products Does Not Protect an Organization by Itself

IDS: Intrusion Detection System
IPS: Intrusion Prevention System

These systems monitor network traffic or system activity to identify signs of potentially malicious behavior. An IPS is intended to go a step further by taking preventive action, such as blocking traffic that matches a detection condition.

But the ability to detect an event is not the same as the ability to prevent damage. Traffic outside the monitoring scope remains invisible. An alert cannot change the situation unless someone has the responsibility and authority to respond. Even a well-chosen product may fail to perform as expected if its configuration, certificates, log collection, or detection rules are not properly maintained.

This article looks at the range of detection techniques available today, explains why AI/ML does not eliminate false positives or missed detections, and considers how organizations can build sustainable operations that connect detection to investigation, decisions, containment, and recovery. It also examines the responsibilities of executives and managers in making those operations workable.

Key points

An IDS/IPS can inspect only the traffic and activity it is able to observe.

Detection is the entry point to incident response. It must lead to investigation, decisions, containment, and recovery to help limit damage.

AI/ML and additional monitoring products do not eliminate data gaps, false positives, missed detections, or the need for operational expertise.

Management must provide the budget, people, decision-making authority, and practical priorities that allow teams to act.

1. What Do IDS and IPS Detect and Prevent?

IDS/IPS is not a device that stops every attack. It is one layer of defense: it identifies suspicious signs in the traffic or activity it can monitor, may block activity when configured to do so, and records information that can support investigation.

Function	What it does	Why it matters to the organization
IDS	Detects, records, and reports suspicious traffic or activity	Provides clues that can help the organization recognize an attack and begin investigating
IPS	Takes preventive action, such as blocking traffic that meets defined conditions	Can stop some matching attacks before they reach the protected system
Anomaly and behavior analysis	Examines traffic volume, destinations, usage patterns, and protocol deviations	Can provide leads on activity that does not match known attack patterns
Logs and alerts	Records detection details and notifies relevant people or systems	Supports incident response, audits, post-incident reviews, and improvements to detection rules

IDS and IPS do not necessarily refer to separate products. A single product may provide both capabilities. They can also be deployed as network-based systems that inspect traffic in transit, or as host-based systems that monitor activity on individual servers and endpoints. For an IPS to block activity, it must be deployed in a position where it can control the relevant traffic, or have the ability to take preventive action on the host. Organizations should therefore verify a product's placement, configuration, and enabled features rather than relying on its name alone. [1]

2. Detection Techniques Have Expanded, but Blind Spots Remain

Signature matching remains an important detection method. However, IDS/IPS has never relied exclusively on known attack patterns. Protocol anomaly detection and traffic behavior analysis have also been used for many years, and detection systems commonly combine multiple techniques. It is therefore inaccurate to divide detection into just two categories: “traditional signatures” and “new AI/ML.” [1]

Detection or analysis method	How it works	Strengths and limitations
Signature matching	Compares activity with known attack patterns or characteristics	Can identify known threats relatively clearly, but may be less effective against unregistered or modified attacks
Protocol anomaly analysis	Detects behavior that deviates from protocol specifications or normal protocol use	Can identify malformed or unusual communications, but may struggle to judge abuse of otherwise valid procedures
Behavior and anomaly analysis	Detects deviations from normal patterns in traffic volume, destinations, usage times, access targets, and other activity	Can provide clues about unknown activity, but legitimate business changes may also appear anomalous
Log correlation	Links events from different systems by time or other relationships	Helps reconstruct a sequence of activity, but analysis is limited when logs are missing or inconsistent
Threat intelligence matching	Compares activity with publicly available or shared indicators such as malicious IP addresses, domains, and file hashes	Provides clues about known threats, but depends on the freshness of the information and changes in attacker infrastructure

NDR, EDR, SIEM, and XDR are technology and product categories that support these forms of analysis across different observation points and information sources. Some products use machine learning or statistical analysis to detect anomalies that may be difficult to identify with a single signature. However, AI/ML has not completely replaced signature-based or rule-based detection.

AI/ML and behavior analysis can strengthen detection, but their effectiveness depends on the quality of the data and changes in the environment. Increasing the number of monitored sources does not automatically make detection more accurate. Organizations must continuously tune what they collect, what they consider normal, and which changes should be treated as significant signals in their particular environment. [3][4]

3. Why AI/ML Does Not Eliminate Missed Detections or False Positives

1. “Low-and-Slow” Activity Blends into Normal Operations

An attacker who exfiltrates a large amount of data in a short period may trigger an alert because of a sudden increase in traffic. One alternative is to spread the activity over a longer period, collecting and sending smaller amounts of data at a rate close to ordinary usage. This kind of activity is commonly described as “low and slow.”

Each individual communication may look unremarkable, making the activity difficult to detect with simple thresholds. However, correlating a user's behavior, destinations, and data access over a longer period may reveal suspicious patterns. The important point is to analyze activity across time and systems rather than relying only on isolated alerts. [3]

2. Abuse of Legitimate Credentials and Permissions

When attackers use stolen passwords, session tokens, or API keys, their communications may appear to originate from legitimate users or systems.

Successful authentication does not prove that a user is authorized to view or modify the data in question. Organizations need to examine identity activity, permissions, accessed resources, and the business context of operations, rather than relying on network monitoring alone. Understanding a user's role and normal responsibilities is also important when determining whether an operation is unusual. [2]

3. The Definition of “Normal” May Already Be Wrong

Behavior analysis may compare current network traffic and user activity with a baseline representing normal conditions. But if a system has already been compromised when that baseline is created, malicious activity may be learned as part of normal behavior.

The UK's National Cyber Security Centre (NCSC) advises organizations to consider whether a system may already be compromised when establishing a baseline. Baseline comparison can be useful, but the baseline should not be trusted unconditionally. [3]

4. False Positives, False Negatives, and Alert Fatigue

Increasing the sensitivity of anomaly detection may cause routine business changes, development tests, and overnight batch jobs to generate alerts. Conversely, making detection conditions too strict in an effort to reduce false positives may cause genuine signs of an attack to be missed.

False positive: An alert identifies activity as anomalous or malicious when there is no actual problem.
False negative: A real problem occurs, but the detection system fails to identify it and raises no alert.

Guidance on implementing SIEM and SOAR platforms published by Australia's national cybersecurity authorities in 2025 explains that false negatives can result from incomplete or inconsistent logs and poorly tuned detection rules. False positives can become widespread when excessive data is collected without appropriate tuning of rules and filters. Too many false positives can overwhelm analysts and delay responses to real incidents, leading to “alert fatigue.” [4]

                    The Alert Fatigue Cycle

       Excessive log collection and poorly tuned detection rules
                              |
                              v
                  Large volumes of alerts,
                  including false positives
                              |
                              v
                    Growing analyst workload
                              |
                              v
                 Triage and investigation become
                       increasingly mechanical
                              |
                              v
                  Important signals are missed
                       or handled too late
                              |
                              v
                 Greater damage and recovery costs
                              |
                              +------> Further operational fatigue

AI does not automatically solve this problem. NCSC recommends keeping alert volumes at a level that analysts can investigate, correlating multiple signals, reviewing detection rules regularly, and validating detection effectiveness through exercises and other testing. [3]

4. Design the Detection-to-Response Process Before Adding More Expensive Products

IDS/IPS, NDR, EDR, and SIEM each capture or process different types of information. The goal is not to deploy every available product. It is to build a system in which the information needed to protect the organization's important assets against its relevant threats is collected, assessed, and translated into decisions and action.

       Network, endpoint, identity, cloud, and application information
                              |
                              v
                    +------------------+
                    | Detection and    |
                    | analysis         |
                    | Rules / correlation |
                    +------------------+
                              |
                              v
                    +------------------+
                    | Triage           |
                    | Severity / scope |
                    +------------------+
                              |
                              v
                    +------------------+
                    | Investigation    |
                    | and decisions    |
                    | Verification /   |
                    | authorization    |
                    +------------------+
                              |
                              v
                    +------------------+
                    | Containment and  |
                    | recovery         |
                    | Isolation /      |
                    | blocking /       |
                    | restoration      |
                    +------------------+
                              |
                              v
                    +------------------+
                    | Review and       |
                    | improvement      |
                    | Updated rules    |
                    | and procedures   |
                    +------------------+
                              |
                              +--------> Feed improvements back into
                                         detection and analysis

Detection and response should be designed as one connected process. Ownership, decision criteria, and handoff conditions should be clear at every stage.

Operational practice	What it involves	Expected benefit
Prioritize assets by importance	Identify systems that handle personal or payment data, critical APIs, administrative environments, and other important assets	Concentrate monitoring and response resources where they matter most
Establish logging and monitoring coverage	Select the necessary network, endpoint, identity, cloud, and application logs; regularly check collection status and gaps	Reduce blind spots and shortages of information needed for analysis
Choose SIEM data sources deliberately	Prioritize logs needed for security analysis, and consider separating them from large datasets collected mainly for retention or audit purposes	Control unnecessary data volume and cost while maintaining analytical value
Triage alerts	Prioritize by severity, affected assets, attack progression, and potential business impact	Investigate the most important alerts first and reduce response delays
Tune detection rules continuously	Review false positives and false negatives; add, revise, or retire rules	Keep detection aligned with changes in the environment and threat landscape
Define response procedures and authority	Specify who investigates and who can disable accounts, isolate endpoints, block network traffic, or take services offline	Shorten the time from detection to containment
Introduce automation gradually	Start with repeatable actions that have clear conditions; prepare ways to reverse mistakes and restore service	Reduce manual workload while limiting disruption caused by incorrect automated actions
Conduct exercises and post-incident reviews	Practice alert handling, communication, containment, and recovery; also test detection rules	Identify procedural weaknesses and unclear areas of responsibility

Collecting more logs does not necessarily improve analytical accuracy. A SIEM needs to select logs that are meaningful for identifying security events and analyze them with appropriate rules and filters. The Australian guidance also warns about the cost and analytical inefficiency of using a SIEM merely as a repository for every available log. [4]

Automation is not a universal solution either. An incorrect decision that automatically isolates a legitimate user's account or a business-critical system can create an operational outage separate from the security incident itself. SOAR and similar automated response capabilities must be designed and maintained for the organization's actual environment. The Australian guidance recommends that organizations whose SIEM analytics and operational experience are not yet mature should first strengthen log analysis and detection operations rather than rushing into SOAR deployment. [4]

Incident response plans, roles, decision-making authority, procedures, and exercises must be established separately from the deployment of detection products. NIST SP 800-61 Rev. 3 likewise frames incident response as part of organization-wide cybersecurity risk management, rather than as a collection of isolated technical tasks. [5]

5. The Responsibilities of Executives and Managers

Even advanced IDS/IPS and AI systems cannot deliver their expected value if the organization lacks the people, decision-making authority, time, and budget to operate them. Security should not depend solely on the extra effort of frontline engineers. Management must create the conditions for sustainable operations.

Management responsibility	What management should do	What to avoid
Set priorities and make trade-offs	Set response priorities, deadlines, and budgets based on critical assets and business impact	Treat everything as the top priority and demand additional controls without changing existing workloads or delivery dates
Establish response authority	Assign accountable decision-makers who can authorize network isolation, account suspension, or service shutdown during an emergency	Hold technical staff responsible without giving them the authority needed to act
Provide staffing and expertise	Secure training, backup personnel, external specialists, or managed services where needed	Concentrate monitoring, investigation, and response knowledge and workload in one individual
Build a culture that learns from failure	Review incidents and missed detections in terms of systems, procedures, and information sharing as well as individual actions	Blame people who report problems and create incentives to hide issues
Protect frontline teams through coordination	Reconcile requests from customers, sales, and auditors against risk assessments, and provide a realistic roadmap	Pass contradictory demands and excessive pressure directly to the people doing the work

Deciding What Not to Do Is Also a Management Responsibility

Expanding security controls and monitoring coverage takes time for design, development, testing, and operations. It is not realistic to impose every additional requirement on frontline teams while leaving deadlines and delivery expectations completely unchanged.

When introducing new monitoring or response processes, management must decide which existing functions or tasks should be deprioritized and which schedules need to change. Rather than simply telling teams to “find a way,” the organization must take responsibility for the trade-offs involved.

Measure the Quality of Response, Not the Number of Alerts

The number of alerts detected is not, by itself, an appropriate measure of a security team's performance. Generating more alerts does not necessarily make an organization safer.

Executives and managers should use a combination of indicators to understand whether detection and response are working in practice.

Metric	Example definition	What to consider when interpreting it
MTTD (Mean Time to Detect)	Time from the start of suspicious activity to its detection by the organization	The actual start of an attack may not be known precisely, so define the measurement starting point
MTTA (Mean Time to Acknowledge)	Time from an alert being generated to a team member acknowledging or accepting it	Specify whether acknowledgement, review, or the start of investigation marks the beginning of response
MTTC (Mean Time to Contain)	Time from detection to containment	Avoid simplistic comparisons across incidents with different severity and response requirements
Recovery time	Time required to restore a system or business service to an acceptable state	Measure containment and recovery separately
False-positive and missed-detection trends	Rules that generate many unnecessary alerts, and signals that exercises or post-incident reviews show were missed	Consider investigation quality and monitoring coverage, not just alert counts
Monitoring coverage	The proportion of important assets whose logs or traffic are actually collected and analyzed	Distinguish between data being collected and data being analyzed effectively

The abbreviation MTTR is used in different contexts to mean Mean Time to Respond, Resolve, or Recover. Organizations should define the start and end points of the metric they use and avoid confusing response, containment, and recovery times.

Focusing only on numerical targets can obscure investigation quality and differences in incident severity. Metrics should not be used to punish frontline teams. They should help identify weaknesses in operations and inform decisions about staffing and improvement investments.

Conclusion: Sustainable Operations Matter More Than Product Sophistication

IDS/IPS remains an important defensive capability for detecting and blocking suspicious network traffic and known attack patterns. When used appropriately, NDR, EDR, SIEM, and AI/ML-based analysis can extend an organization's visibility and detection capabilities.

However, newer products alone cannot resolve the challenges posed by encrypted traffic, misuse of legitimate credentials, attacks concealed within trusted software or communications, lateral movement inside networks, or failures to act after detection. Organizations must continuously verify that monitoring systems are functioning, required information is being collected, alerts are being handled appropriately, and damage can be limited if an intrusion occurs.

The responsibility of executives and managers is not simply to purchase the latest security products. They must understand the assets that need protection and the business risks involved, provide the necessary budget and people, grant appropriate decision-making authority, and establish priorities and operating structures that frontline teams can actually carry out. Engineers, in turn, need to explain not only what their technology can detect or prevent, but also what remains outside its field of view and what action the organization needs to take.

An IDS/IPS is not a device that protects an organization simply because it has been installed. It delivers value when the organization keeps monitoring effective, turns alerts into action, and continuously reviews and improves its weaknesses.

References

NIST SP 800-94, “Guide to Intrusion Detection and Prevention Systems (IDPS)” (February 2007). Foundational material on network-based, wireless, network behavior analysis, and host-based IDPS, as well as design, deployment, configuration, monitoring, and maintenance. Because it is an older publication, it is used here for basic technical classifications rather than as a comprehensive description of current products. NIST CSRC
CISA, “AA20-352A: Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations” (December 17, 2020). Describes the SolarWinds Orion supply chain compromise, the malicious DLL signed with a legitimate code-signing certificate, and communications designed to resemble legitimate Orion traffic. CISA Advisory
UK National Cyber Security Centre, “Building a Security Operations Centre (SOC)—Detection Practices.” Guidance on the limitations of baselines, correlation across multiple logs, alert triage, handling false positives, continuous review of detection rules, and validation through exercises. NCSC
Australian Signals Directorate / Australian Cyber Security Centre, “Implementing SIEM and SOAR Platforms: Practitioner Guidance” (May 27, 2025). Practical guidance on SIEM log selection and analysis, false positives and false negatives, alert fatigue, risks associated with automated SOAR responses, staffing, and continuous tuning. Australian Cyber Security Centre
NIST SP 800-61 Rev. 3, “Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile” (April 3, 2025). Recommendations for integrating incident response into organization-wide cybersecurity risk management. NIST CSRC

This article does not dismiss the value of IDS/IPS or monitoring products that use AI. Detection coverage and response capabilities vary by product, deployment, configuration, and monitored environment. Always assess the actual architecture and operational conditions before deployment.

IDS/IPS を導入しても安心ではない —— IDS/IPS とは ? インシデント (事例) からの教訓

nabbisen — Fri, 30 Oct 2026 23:49:00 +0000

はじめに: セキュリティ製品は、導入しただけでは組織を守れない

IDS: 侵入検知システム, Intrusion Detection System
IPS: 侵入防止システム, Intrusion Prevention System

この記事では、IDS/IPS の基本と限界を整理したうえで、 Equifax、 Target、 SolarWinds の事例を確認します。

この記事シリーズの要点

IDS/IPS が検査できるのは、原則として製品が観測できる通信・動作に限られる。

検知はインシデント対応の入口であり、調査・判断・封じ込め・復旧までつながって初めて被害を抑えられる。

AI/ML や高価な監視製品を追加しても、データの不足、誤検知、見逃し、運用能力の不足はなくならない。

経営・管理側には、必要な予算・人員・判断権限と、現場が実行できる優先順位を整える役割がある。

1. IDS/IPS は何を検知し、何を防ぐのか

機能	主な働き	組織にとっての意味
IDS	不審な通信・動作を検知し、記録・通知する	攻撃の兆候を把握し、調査や対応を開始する手掛かりになる
IPS	検知した通信を遮断するなど、防止動作を行う	条件に合致した攻撃の一部を、対象システムへ到達する前に止められる
異常・振る舞い分析	通信量、接続先、利用パターン、プロトコルの逸脱などを分析する	既知の攻撃パターンだけでは捉えにくい活動を調査する手掛かりになる
ログ・アラート	検知内容や関連情報を記録・通知する	インシデント対応、監査、事後検証、検知ルールの改善に利用できる

監視技術は、観測対象と役割が異なる

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 are useful, but they do not provide complete protection: What Are IDS/IPS ? Lessons from Incidents

nabbisen — Fri, 30 Oct 2026 22:19:29 +0000

Introduction: Security Products Cannot Protect an Organization on Their Own

IDS: Intrusion Detection System
IPS: Intrusion Prevention System

But detecting suspicious activity and preventing damage are not the same thing. Traffic outside the monitored scope remains invisible. An alert does not change the situation unless someone has the responsibility and authority to act on it. A product may also fail to perform as expected when its configuration, certificates, log collection, or detection rules are not properly maintained.

This article explains the basic roles and limitations of IDS/IPS, examines incidents involving Equifax, Target, and SolarWinds, and considers what these cases reveal about modern detection technologies and security operations.

Key points

An IDS/IPS can inspect only the traffic and activity it is able to observe.

Detection is the beginning of incident response. Damage is limited only when detection leads to investigation, decisions, containment, and recovery.

Adding AI/ML or expensive monitoring products does not eliminate data gaps, false positives, missed detections, or operational shortcomings.

Management is responsible for providing the budget, people, decision-making authority, and practical priorities needed for the organization to respond.

1. What Do IDS and IPS Detect and Prevent?

An IDS/IPS is not a device that stops every attack. It is one layer of defense: it identifies suspicious signs in the traffic or activity it can monitor, may block activity when configured to do so, and records information that can support investigation.

Function	What it does	Why it matters to the organization
IDS	Detects, records, and reports suspicious traffic or activity	Provides clues that can help the organization recognize an attack and begin investigating
IPS	Takes preventive action, such as blocking traffic that meets defined conditions	Can stop some matching attacks before they reach the protected system
Anomaly and behavior analysis	Examines traffic volume, destinations, usage patterns, protocol deviations, and other signals	Can provide leads on activity that does not match known attack patterns
Logs and alerts	Records detection details and notifies relevant people or systems	Supports incident response, audits, post-incident reviews, and improvements to detection rules

Monitoring Technologies Have Different Roles and Areas of Visibility

IDS/IPS and related products may have similar-sounding names, but they do not all perform the same job. The table below summarizes their general roles. Actual capabilities vary by product and deployment. In particular, NDR overlaps with network-based IDS/IPS, while XDR capabilities may overlap with EDR and SIEM.

Technology	Information primarily handled	Main role	Important consideration
Network IDS/IPS	Network traffic visible at its observation point	Detects suspicious traffic and blocks it when configured to do so	Visibility depends on sensor placement and network paths
Host-based IDS/IPS	Events and activity on servers or endpoints	Monitors or prevents activity involving files, processes, and system behavior	The relevant software must be deployed and managed on each target host
EDR (Endpoint Detection and Response)	Endpoint and server processes, files, connections, and user or system activity	Detects and supports response to suspicious endpoint behavior	Sensors must be deployed on the relevant endpoints and their data must be delivered correctly
NDR (Network Detection and Response)	Network traffic and traffic metadata	Analyzes network behavior and helps investigate suspicious activity	Coverage depends on the segments and traffic that can be observed; response capabilities vary by product
SIEM (Security Information and Event Management)	Logs from networks, endpoints, identity systems, cloud services, applications, and other sources	Aggregates logs and supports detection and investigation through rules and correlation	Collecting logs is not enough: source selection, data quality, analytics, and operations all matter
XDR (Extended Detection and Response)	Telemetry from multiple security domains	Correlates information across domains to support detection and response	The integrations and capabilities vary by product; there is no single implementation boundary shared by all vendors

                 Network traffic and system activity
                              |
              +---------------+----------------+
              |                                |
              v                                v
     +------------------+             +------------------+
     | Network          |             | Endpoints and    |
     | IDS / IPS        |             | servers          |
     +------------------+             | EDR / Host IDS   |
              |                       +------------------+
              |                                |
              +---------------+----------------+
                              |
                              v
                 +--------------------------+
                 | SIEM / XDR and similar   |
                 | Log aggregation and      |
                 | correlation              |
                 +--------------------------+
                              |
                              v
                 +--------------------------+
                 | Human investigation and  |
                 | decisions                |
                 | Containment, recovery,   |
                 | and review               |
                 +--------------------------+

       NDR analyzes and correlates network information from another
       perspective. Integration and deployment vary by environment.

This is a conceptual diagram of how the roles can relate; it does not mean every organization should adopt the same product stack. The important thing is that the information needed to protect critical assets against the threats an organization faces is observed, analyzed, and delivered to the people responsible for responding.

A network-based IDS/IPS primarily inspects the traffic visible to its sensors. When traffic is encrypted, the system cannot inspect the details of the encrypted payload unless an appropriate decryption and inspection mechanism is in place. Similarly, activity that abuses legitimate credentials or follows valid communication procedures may be difficult to identify as malicious from network traffic alone.

IDS/IPS is an important defensive capability, but it does not guarantee complete protection. Organizations must continuously manage what is monitored, whether the monitoring system is working as intended, who responds to alerts, and how much damage can be contained if an intrusion occurs.

2. Incidents in Which Monitoring Products Failed to Prevent Damage

Real-world incidents show that the problem is not always the absence of security products. Blind spots in monitoring, detection information that did not reach the right people, alerts that did not lead to action, and inadequate containment after an intrusion can all contribute to an incident.

Case 1: The Equifax Data Breach (2017)—Certificate Management and Asset Visibility Failures

In 2017, the U.S. credit reporting agency Equifax suffered a major data breach affecting approximately 148 million people. According to an investigation by the U.S. House of Representatives, attackers exploited a vulnerability in Apache Struts to gain access to an internet-facing web application. The report describes how the affected system remained unpatched after the vulnerability had been disclosed, allowing attackers to obtain and exfiltrate personal information. [3]

Equifax had IDS and IPS systems in place. On March 14, 2017, it added a Snort rule to its IDS/IPS to detect attempts to exploit the Apache Struts vulnerability. However, the report records the introduction of the rule; it does not establish that the rule blocked multiple attacks that day. The following day, a vulnerability scan examined 958 externally facing IP addresses but failed to identify the vulnerable system. The report states that the scanning tool used during remediation did not identify the vulnerable Apache Struts installation. [3]

Another serious problem involved the SSL Visibility Appliance (SSLV), which decrypted encrypted traffic and passed it to inspection systems. The ACIS (Automated Consumer Interview System) was an internet-facing Equifax portal used to handle consumer disputes and related inquiries. According to the House report, the certificate used by the SSLV monitoring the ACIS environment expired on January 31, 2016. Under the appliance's default configuration, web traffic continued to pass through even after the certificate expired. As a result, the IDS/IPS systems behind it could not inspect the encrypted traffic. When Equifax renewed the certificate on July 29, 2017, suspicious traffic was identified almost immediately. The House report describes the monitoring gap as having lasted 19 months. [3]

                    Incoming HTTPS traffic
                            |
                            v
                 +----------------------+
                 | SSL Visibility       |
                 | Appliance (SSLV)     |
                 |                      |
                 | Certificate expired |
                 | Unable to decrypt    |
                 | traffic              |
                 +----------------------+
                            |
                  Encrypted traffic passes through
                            |
                            v
                 +----------------------+
                 | IDS / IPS            |
                 |                      |
                 | Unable to inspect    |
                 | the payload          |
                 +----------------------+
                            |
                            v
                 +----------------------+
                 | ACIS web system      |
                 +----------------------+

       The core failure: The monitoring appliance's problem did not
       stop traffic or surface as an obvious outage. Traffic continued
       without the intended inspection.

This case demonstrates that detection rules alone cannot provide effective protection. Certificate and appliance health, asset inventories, vulnerability scanning, patching, and network segmentation must work together. Even when a monitoring appliance appears to be running, the organization must verify that it is actually inspecting the traffic it is supposed to inspect. [3]

Case 2: The Target Data Breach (2013)—Alerts Did Not Lead to Investigation or Response

In 2013, the U.S. retailer Target suffered a major theft of payment card data and other information. A committee staff report included in a 2014 U.S. Senate hearing record summarized the publicly available reporting and expert analysis at the time. It described how attackers reportedly used credentials associated with a third-party HVAC service provider to gain access to Target's network and then expanded their activity into internal payment-related systems. The staff report also acknowledged that the full details of the incident had not been established from the public information then available. [4]

According to an investigative report by Bloomberg Businessweek cited in the Senate staff report, Target's FireEye malware detection system generated an urgent alert when malware intended to facilitate data exfiltration was installed. The report said that Target's security team did not act on the alert and that the automatic malware-removal feature had not been enabled. The alert reportedly carried the generic name malware.binary. The committee report suggested that, if similar alerts had appeared frequently, the warning might have been treated as a false positive. However, this is a possibility raised on the basis of contemporaneous reporting; it is not established fact that the staff who received the alert actually classified it as a false positive. [4]

The lesson is that the ability to detect an event and the ability to act on the resulting information are two different capabilities. A product may issue an alert, but defense will fail if no one is clearly responsible for reviewing it, assessing its significance, and deciding whether to contain the incident.

Case 3: The SolarWinds Supply Chain Attack (2020)—Threats Hidden in Trusted Software and Traffic

The SolarWinds Orion supply chain attack, which came to light in 2020, involved attackers inserting malicious code into the development and distribution process for Orion software. According to a CISA alert dated December 17, 2020, the malicious DLL was signed with a legitimate SolarWinds code-signing certificate and distributed through software updates. After installation, the malicious communications used techniques designed to imitate legitimate SolarWinds protocol traffic. [5]

In this attack, the apparent legitimacy of the software signature and the resemblance of the network traffic to normal product communications helped conceal the malicious activity. CISA also described initial access methods beyond the Orion compromise. It would therefore be inaccurate to simplify the event by claiming that every intrusion began through Orion, or to state categorically that a particular organization's IDS/IPS was bypassed despite being deployed. [5][6]

Defending against threats of this kind requires more than network monitoring. Organizations need to correlate information about software publishers, signatures and update histories with process execution, privileged account usage, unusual destinations, and changes in traffic volume. Even when software comes from a trusted source, its update path and behavior after execution need to be considered.

What the Three Incidents Tell Us

Incident	Main problem	What organizations should learn
Equifax (2017)	A vulnerable system was not identified and patched, while an expired certificate also left a monitoring path unable to inspect traffic	Continuously verify monitoring health, asset inventories, and vulnerability management as interconnected responsibilities
Target (2013)	Detection alerts did not lead to investigation and containment	Define alert priorities, ownership, response deadlines, and decision-making authority
SolarWinds (2020)	The attack was concealed within trusted software updates and traffic resembling legitimate communications	Correlate network monitoring with software supply-chain, identity, and endpoint activity

3. Structural Limitations of IDS/IPS

A system cannot make reliable decisions about traffic or activity that it cannot observe. In addition, even when communication follows a technically valid format, a network device alone may not be able to determine whether the purpose of that activity is legitimate in the context of the business.

Area that is difficult to detect or prevent	What can happen	Examples of complementary controls
Encrypted traffic (HTTPS/TLS)	Without decryption and inspection, the details of the encrypted payload cannot be examined	TLS visibility in managed environments, traffic metadata analysis, and endpoint, server, and application logs
Access using legitimate credentials	Stolen passwords, session tokens, or API keys may be used through normal procedures, making malicious activity difficult to distinguish from legitimate traffic alone	Multi-factor authentication, least privilege, correlation of authentication and activity logs, and additional checks for sensitive operations
Data exfiltration through legitimate cloud services	Data may be concealed within traffic to commonly used cloud storage or external services	Data-loss monitoring, contextual analysis of destinations, volume, and users, and access controls for sensitive data
Lateral movement inside the network	After an intrusion, attackers may use ordinary business protocols for host-to-host communication, making perimeter-only controls less effective	Network segmentation, endpoint and server monitoring, and restrictions on administrative privileges
New or modified attacks	Activity that does not match known patterns or the assumptions built into detection logic may be missed	Behavior analysis, updated threat intelligence, detection-rule reviews, and threat hunting

Encrypted Traffic Is Not Entirely Invisible, but Visibility Is Limited

HTTPS/TLS described above is essential for protecting communications. However, a product inspecting traffic in transit cannot read an encrypted payload as-is. It may be able to observe metadata such as destinations and traffic volumes, but the available information depends on the protocol version, configuration, and observation point. Metadata alone cannot establish the contents or purpose of a communication.

One way to inspect the contents of encrypted traffic is to establish appropriate decryption and re-encryption mechanisms, with suitable key management, in an environment controlled by the organization. However, that does not mean every connection should be decrypted without exception. Privacy, legal and contractual requirements, certificate and key management, compatibility with mutual TLS and certificate pinning, and the impact on systems all need to be considered.

With TLS 1.3, some passive decryption techniques used with earlier versions of TLS may no longer work in the same way. In 2025, NIST published a practice guide describing standards-based example architectures for monitoring and analyzing traffic within enterprise-controlled data centers while retaining TLS 1.3. The guide does not recommend decrypting all traffic indiscriminately; it presents options for gaining the visibility needed in managed environments. [2]

Encryption is therefore not a reason to give up on monitoring. The challenge is to decide what content should be inspected and what should be covered by metadata, endpoint information, and other sources, while taking privacy and business requirements into account.

Conclusion

This article explains the basic roles and limitations of IDS/IPS, and examines incidents.

In the next article, I will delve into the following aspects:

Recent detection technologies and the role of AI/ML
Proactive involvement from executives and managers, and the operational frameworks that need to be established

References

NIST SP 800-94, “Guide to Intrusion Detection and Prevention Systems (IDPS)” (February 2007). Foundational material on network-based, wireless, network behavior analysis, and host-based IDPS, as well as design, deployment, configuration, monitoring, and maintenance. Because it is an older publication, it is used here for basic technical classifications rather than as a comprehensive description of current products. NIST CSRC
NIST SP 1800-37, “Addressing Visibility Challenges with TLS 1.3 within the Enterprise” (September 17, 2025). A practice guide to maintaining visibility into communications in managed enterprise environments while using TLS 1.3. NIST CSRC
U.S. House Committee on Oversight and Government Reform, “The Equifax Data Breach: Majority Staff Report” (December 2018). Documents the Apache Struts vulnerability, introduction of the Snort rule, scans of externally facing IP addresses, SSLV certificate expiration, and the resulting monitoring gap. The 19-month period used in this article is based on the certificate records obtained by the committee. A footnote in the report notes that the Government Accountability Office (GAO) reported a different period of 10 months. Report PDF
U.S. Senate Committee on Commerce, Science, and Transportation, “Protecting Personal Consumer Information from Cyber Attacks and Data Breaches” (March 26, 2014 hearing record). Includes a committee staff report on Target's intrusion path, network segmentation, and FireEye alerts. The staff report drew on contemporaneous reporting and expert analysis, and noted that the full details of the incident had not been established. U.S. Government Publishing Office
CISA, “AA20-352A: Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations” (December 17, 2020). Describes the SolarWinds Orion supply chain compromise, the malicious DLL signed with a legitimate code-signing certificate, and communications designed to resemble legitimate Orion traffic. CISA Advisory
MITRE ATT&CK, “SUNBURST (S0559).” Summarizes SUNBURST, including its use of HTTP/DNS communications and techniques for imitating normal SolarWinds API traffic. MITRE ATT&CK

WAF は有効だが、完全な防御ではない —— Web サイトと API を守るために経営者・管理者が理解すべきこと

nabbisen — Fri, 30 Oct 2026 20:51:56 +0000

導入: WAF とは何か —— Web への通信を入口で検査する仕組み

WAF (Web Application Firewall) は、Web サイトや Web API に届く HTTP/HTTPS 通信を検査し、あらかじめ定めたルールに照らして、通信を通す・記録する・遮断するといった制御を行うセキュリティ機能です。Web サイトの前段に設置する「通信の検問所」と考えると分かりやすいでしょう。

要点: まず押さえるべきこと

要点	経営・管理上の意味
WAF は有効だが、完全な防御ではない	WAF が検査する通信と、設定されたルールで捉えられる攻撃に防御範囲は限られる
WAF は脆弱性そのものを直さない	仮想パッチとして一時的に攻撃を抑えられる場合はあるが、恒久対策はソフトウェア更新や設計修正である
正規のログイン状態を悪用する攻撃がある	通常の通信に見えるAPI操作や業務ロジックの悪用は、一般的なWAF だけでは判断しにくい
導入後の運用が必要	ルール更新、誤検知調整、ログ監視、適用範囲の確認、回避経路の検証が欠かせない
セキュリティは経営上の継続課題	資産把握、パッチ管理、アプリケーションの認可設計、監視・復旧に予算・責任者・期限を割り当てる必要がある

1. WAF の防御範囲には境界がある

WAF は通信の入口で働くため、通信の内容から判断できる攻撃には効果を発揮します。一方、アプリケーション内部の処理が業務上正しいか、ログインした利用者にそのデータを見る権限があるか、サーバーやミドルウェア自体に弱点がないか、といった判断はWAF の役割ではありません。

弱点・リスク	WAF だけでは解決できない理由	根本的な対応
ミドルウェアやライブラリの脆弱性	攻撃通信を一時的に遮断できる場合はあるが、ソフトウェア自体は脆弱なまま	セキュリティパッチの適用、サポート対象への更新、不要な機能の停止
アプリケーションの認可不備	リクエストが正しい形式でも、利用者にその情報・操作の権限があるかは業務ロジックで判断する必要がある	サーバー側で利用者・対象データ・操作ごとに認可を検証する
業務ロジックの悪用	正規の購入・予約・申請などを過剰に繰り返す行為は、単純な攻撃パターンに見えない場合がある	業務上の制限、レート制御、不正利用検知、追加確認を設計する
設定・公開範囲の不備	WAF を通らない管理画面やオリジンサーバーへの直接経路は、WAF の検査対象外になり得る	公開範囲の棚卸し、アクセス制御、不要サービスの停止、経路の制限
侵害後の内部活動	WAF はサーバー内部のプロセスや、侵害後の横展開を包括的に制御する仕組みではない	最小権限、ネットワーク分離、EDR等の監視、ログ分析、インシデント対応

「仮想パッチ」は恒久修正の代わりではない

WAF がミドルウェア固有の脆弱性に一切対応できない、という意味ではありません。特定の脆弱性を悪用する HTTP リクエストの特徴を識別できる場合、WAF のルールで攻撃を遮断し、修正までの時間を稼げることがあります。これは「仮想パッチ」と呼ばれる考え方です。

ただし、仮想パッチは脆弱なコードを直すものではありません。WAF が検査する通信であり、かつルールが認識できる攻撃パターンに対してのみ効果があります。攻撃方法や入力の形を変えられたり、WAF を通らない経路を使われたりすれば、保護が及ばない可能性があります。OWASP も、仮想パッチは恒久的なコード修正と並行して用い、回避可能性を検証するべきだと説明しています。[2]

したがって、WAF は「脆弱性を直さなくてもよい仕組み」ではありません。更新や改修に時間がかかる場合の一時的なリスク低減策として活用しつつ、恒久対策の期限と責任者を明確にする必要があります。

2. 正規の通信に見える攻撃は、WAF だけでは見抜きにくい

近年、Web サイトや API を標的とする攻撃では、必ずしも不正な文字列や明らかな異常リクエストを送り込むとは限りません。攻撃者が通常の会員登録やログインを行い、正規のセッションを取得したうえで、Web 画面を介さず API を直接呼び出し、許されていない情報の取得や操作を試みるケースがあります。

「サイト型攻撃」という言葉だけでは、攻撃の範囲や手法が一義的に定まりません。本記事では、こうした脅威を具体化するため、 「正規利用に見える API 悪用」 と呼びます。これは単一の攻撃手法ではなく、認証済み API の認可不備、業務フローの自動化、不正なセッション利用など、複数の問題を含みます。

例えば、どのようなことが起きるのか

攻撃者が一般利用者と同じように会員登録し、ログインする。
正規のログイン状態を使い、ブラウザーが通常利用時に送信する API リクエストを調べる。
リクエストに含まれる注文番号、会員番号、予約番号などを変更したり、通常の画面では表示されない API を直接呼び出したりする。
サーバー側の認可確認が不十分であれば、他人の情報を取得したり、本来許可されていない操作を実行したりできてしまう。
同じ操作を自動化・大量実行し、情報収集、予約枠の占有、在庫の買い占め、ポイントやクーポンの不正利用などにつなげる。

このとき、HTTP リクエストは形式上正しく、ログイン済みのセッションも付いているかもしれません。SQL インジェクションのような典型的な攻撃文字列も含まれないことがあります。WAF から見ると、一見通常の利用者が正規の API を呼び出しているように見える可能性があります。

この種の問題は、OWASP の API セキュリティリスクでも明確に扱われています。例えば「Broken Object Level Authorization (オブジェクト単位の認可不備)」では、API に渡す ID を変更することで、他の利用者のデータにアクセスできてしまう問題が説明されています。また「Unrestricted Access to Sensitive Business Flows (重要な業務フローへの過度なアクセス)」では、商品購入や予約などの機能を自動化して悪用するリスクが挙げられています。[3]

自動化の広がりを示す一つの材料として、Thales の「2026 Bad Bot Report」は、同社が 2025 年に観測したデータにおいて、AI を利用したボット攻撃が前年比 12.5 倍に増え、ボット攻撃の 21 % がビジネスロジックを標的としていたと報告しています。ただし、これは同社の観測範囲に基づく数値であり、インターネット全体の攻撃比率を示す統計ではありません。それでも、単純な不正リクエストの遮断だけでなく、正規の機能がどのように自動化・悪用されるかを考える必要性を示しています。[4]

ここで区別すべきなのが、 認証 (Authentication) と認可 (Authorization) です。

認証 : 誰がアクセスしているのかを確認すること。
認可: その利用者が、 どの情報を閲覧し、どの操作を実行してよいのか を確認すること。

ログインに成功したことは、あらゆるデータや機能へのアクセスが許可されたことを意味しません。利用者本人の注文情報だけを見られるのか、管理者機能を呼び出せるのか、予約や決済をどの頻度・条件で実行できるのか。こうした判断は、アプリケーション側で業務ルールに基づいて行う必要があります。

また、盗まれたセッション ID や認証トークンが悪用される場合もあります。WAF が通信を検査できても、その通信を送っているのが本来の利用者本人なのか、正規のセッションを奪った第三者なのかを、HTTP リクエストだけで常に判別できるわけではありません。セッション管理、重要操作時の再認証、異常な利用パターンの検知などを組み合わせる必要があります。

サーバーへの侵入だけで被害が終わるとは限らない

アプリケーションやミドルウェアの脆弱性が悪用され、攻撃者がサーバー上でコードを実行できる状態 (RCE: Remote Code Execution) に至れば、影響はサーバー単体にとどまらない可能性があります。

Web サイトのコンテンツや配信ファイルが改ざんされる。
訪問者が偽サイトへ誘導されたり、悪意あるスクリプトを読み込まされたりする。
サーバーに保存された認証情報やデータベース情報が窃取される。
内部ネットワークや関連サービスへの侵入の足場にされる。
不正な通信やコンテンツ配信に使われ、ドメインやサービスの信用が損なわれる。

これらが必ず発生するという意味ではありません。しかし、Web サイトを提供する組織は、サーバーを守るだけでなく、そのサイトを利用する顧客、訪問者、連携先にどのような影響が及ぶかまで考える必要があります。

3. WAF 導入後にも、運用上の負担と盲点が残る

WAF は導入すれば自動的に最適な状態が続く製品ではありません。ルールセットの更新、検知ログの確認、誤検知の調整、サービス変更に伴うポリシー見直しが必要です。

運用上の論点	放置した場合に起こり得ること	必要な管理
誤検知 (False Positive)	正常な利用者のアクセスや業務処理まで遮断する	影響を確認し、例外ルールを期限・理由付きで管理する
検知のみの設定	攻撃を検知しても、実際には遮断されない	ルールの動作モードと本番環境での適用状況を確認する
ルールの陳腐化	新しい攻撃パターンやアプリケーション変更に追随できない	ルール更新と定期的な再評価を行う
適用範囲の漏れ	一部のドメイン、API、サブドメイン、接続経路が WAF を通らない	保護対象の一覧と通信経路を継続的に棚卸しする
パフォーマンスへの影響	遅延や利用者体験の悪化につながる	レイテンシやエラー率を監視し、負荷試験を行う
ログの未活用	攻撃の傾向や誤検知、見逃しに気づけない	アプリケーション・認証・サーバーのログと関連付けて分析する

特に注意したいのは、WAF の保護対象となる通信経路です。WAF を経由せずにオリジンサーバーへ直接アクセスできる経路が残っていれば、その経路からの通信には WAF の検査が適用されません。また、HTTPS 通信をどこで復号・検査しているのか、API や WebSocket など対象の通信方式が保護範囲に含まれるかも確認が必要です。

さらに、WAF の誤検知を避けるために例外ルールを追加し続けた結果、本来防ぎたい通信まで許可してしまうこともあります。WAF の導入費用や契約の有無だけでなく、実際にどの通信を検査し、何を遮断し、何を見逃す可能性があるのかを把握しなければなりません。

4. WAF を含む多層防御をどう組み立てるか

WAF を有効に活用するには、WAF の前後にある仕組みを含めて防御を設計する必要があります。重要なのは、高価な製品を一度に大量導入することではありません。自社の資産・脅威・事業影響を把握し、優先順位を付けて継続的に改善することです。

                         外部の利用者・攻撃者
                                  |
                                  v
                    +---------------------------+
                    | CDN / DDoS 対策 / 入口制御 |
                    +---------------------------+
                                  |
                                  v
                    +---------------------------+
                    | WAF                       |
                    | Web 通信の検査・遮断       |
                    +---------------------------+
                                  |
                                  v
                    +---------------------------+
                    | Web アプリケーション / API |
                    +---------------------------+
                                  |
                                  v
                    +---------------------------+
                    | 認証・認可・業務ルール     |
                    +---------------------------+
                                  |
                                  v
                    +---------------------------+
                    | DB / 内部サービス         |
                    +---------------------------+

  ---------------------------------------------------------------
  システム全体を支える横断的な管理

  [資産・依存関係の棚卸し]  [パッチ・設定管理]  [最小権限]
  [ログ監視・異常検知]      [インシデント対応]  [バックアップ]
  [復旧訓練・ネットワーク分離]

  注意: 公開サーバーへの直接アクセス経路が残っていると、
        WAF を通らない通信が発生する可能性がある。

防御・管理の層	主な取り組み	WAFとの関係
資産・脆弱性管理	Web サイト、API、サーバー、ミドルウェア、ライブラリを把握し、サポート状況と更新期限を管理する	WAF が守るべき対象を特定し、根本的な脆弱性を修正する
インフラ・基盤の保護	OS・Web サーバー・ミドルウェアの更新、不要サービス停止、設定強化、秘密情報管理	WAF の外側・内側に残る弱点を減らす
アプリケーションの安全性	セキュアな実装、コードレビュー、脆弱性診断、認証・認可、業務フローの検証	WAFでは判断できないアプリケーション固有の欠陥を修正する
WAF・入口対策	ルール適用、レート制限、ボット対策、通信経路の集約、ログ確認	HTTP 層の攻撃を検知・遮断し、リスクを低減する
内部防御・データ保護	ネットワーク分離、最小権限、DB アクセス制御、暗号化、バックアップ	WAF を突破された後の影響範囲を限定する
監視・対応・復旧	ログ相関、異常検知、インシデント手順、復旧訓練、顧客連絡	WAF の検知だけに依存せず、侵害の兆候と被害を把握する

WAF は、この構造の中で HTTP 層を担当する一つの防御点です。守る対象や機能に応じて、CDN、DDoS 対策、API ゲートウェイ、ボット管理などを組み合わせることは有効ですが、それぞれの役割と責任範囲を混同しないことが大切です。

5. 経営者・管理者層が確認すべきこと

WAF の性能やルール設定を現場に任せきりにせず、経営・管理側は次の事項を確認してください。

      +-----------------------+
      | 保護対象・資産の把握  |
      +-----------------------+
                  |
                  v
      +-----------------------+
      | 脅威と事業影響の分析  |
      +-----------------------+
                  |
                  v
      +-----------------------+
      | 対策の優先順位を決定  |
      +-----------------------+
                  |
                  v
      +-----------------------+
      | 予算・責任者・期限設定|
      +-----------------------+
                  |
                  v
      +-----------------------+
      | 実装・監視・検証      |
      +-----------------------+
                  |
                  v
      +-----------------------+
      | 結果を評価して見直す  |
      +-----------------------+
                  |
                  +-----------> 次の評価サイクルへ

確認事項	経営・管理側が確認する質問	求める状態・証拠
保護対象の把握	どの Web サイト、API、サブドメイン、委託先システムが公開されているか	資産台帳と責任者があり、更新されている
WAF の適用範囲	すべての外部向け通信がWAF を通るか。直接アクセスできる経路はないか	通信経路図、適用対象一覧、定期的な確認結果
ルールと運用	どのルールを有効にし、例外をなぜ認めているか。検知だけで終わっていないか	ルール更新履歴、例外の理由・期限、誤検知レビュー
脆弱性対応	WAF で一時的に遮断した脆弱性を、いつ恒久修正するか	修正計画、責任者、期限、未対応リスクの承認記録
API と業務ロジック	ログイン済み利用者が他人の情報や権限外の機能にアクセスできないか	オブジェクト・機能単位の認可テスト、業務フローの不正利用テスト
監視・インシデント対応	攻撃や不正操作を検知したとき、誰が判断し、誰に連絡するか	ログ監視、対応手順、連絡網、訓練記録
予算と責任分担	WAF、アプリ、基盤、委託先の管理責任は明確か	契約・責任分界、運用予算、改善計画

特に、次の三点は経営判断として明確にしておくべきです。

第一に、セキュリティ対策に優先順位を付けること。 すべてのシステムに同じ投資を行うのではなく、取り扱う情報、利用者数、公開範囲、停止時の事業影響、侵害時の損害を踏まえてリスクを評価します。顧客情報や決済情報を扱うシステム、事業継続に不可欠なシステムは、より高い保護水準が必要です。

第二に、WAF の導入を完了条件にしないこと。 WAF の契約や設置が終わっても、ルールが適切に適用され、ログが確認され、例外が管理され、対象システムの脆弱性が修正されていなければ、十分な対策とは言えません。導入後の運用責任者と評価指標を決めてください。

第三に、長期的な改善を予算化すること。 OS、Webサーバー、ミドルウェア、CMS、プラグイン、アプリケーションの更新には継続的な費用と人員が必要です。基盤の入れ替えがすぐには難しい場合でも、暫定策、恒久修正、移行・廃止の期限を分けて計画する必要があります。

結び: WAF を導入したことではなく、守り続けられることが重要

WAF は不要な製品ではありません。適切に導入・設定・運用すれば、Webアプリケーションに対する多くの攻撃を検知・遮断し、脆弱性修正までの時間を稼ぐ有効な防御策になります。

しかし、WAF は脆弱な基盤を健全な状態に変えるものではありません。正規のセッションを使ったAPI悪用や、アプリケーションの認可不備、内部ネットワークへの侵入、侵害後の不正活動まで、単独で完全に防ぐものでもありません。WAF を「導入したから安心」という免罪符にしてしまえば、根本的な弱点を見逃し、必要な対策を先送りする危険があります。

経営者・管理者層が取り組むべきことは、セキュリティ製品の導入数を増やすことだけではありません。自社のシステムとデータを把握し、どの脅威がどの事業リスクにつながるかを分析し、基盤・アプリケーション・利用者・運用の各層に対策を配置することです。そして、その対策を定期的に見直し、脆弱性の修正、監視、訓練、復旧を継続することです。

WAF は「完全な鎧」ではありません。多層防御の一部として正しく使い、残る弱点を把握し、埋め続けること。それが、顧客と事業を守るためのセキュリティマネジメントです。

参考資料・出典

AWS, “AWS WAF Documentation” — WAF が保護対象へ転送される Web リクエストを検査し、条件に応じてカウント、遮断、許可、チャレンジを行う機能の説明。製品ごとに機能・対応範囲は異なる。 https://docs.aws.amazon.com/waf/
OWASP, “Virtual Patching Cheat Sheet” — 仮想パッチの定義、既知の攻撃経路を一時的に遮断する利点、基礎となる脆弱性は残ること、回避可能性の検証と恒久修正の必要性。 https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html
OWASP API Security Top 10 – 2023 — API1「Broken Object Level Authorization」、API5「Broken Function Level Authorization」、API6「Unrestricted Access to Sensitive Business Flows」など、APIの認可不備や業務フロー悪用に関するリスク。 https://api-security.owasp.org/editions/2023/en/0x11-t10/
Thales, “2026 Bad Bot Report” — 2025年の同社観測データに基づくボット活動の分析。AIを利用したボット攻撃やビジネスロジックを狙う攻撃への関心を示す業界レポート。数値は同社の観測範囲に基づくもので、インターネット全体を代表する統計ではない。 https://cpl.thalesgroup.com/resources/application-security/2026-bad-bot-report
OWASP API Security Project, “API6:2023 Unrestricted Access to Sensitive Business Flows” — 商品購入、投稿、予約などの重要な業務フローが自動化・過剰利用されるリスクと対策の考え方。 https://api-security.owasp.org/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/

本記事は、WAF を否定するものではありません。WAF の有効性を認めたうえで、その防御範囲と限界を明確にし、他の対策と組み合わせる必要性を論じています。製品の具体的な機能・対応プロトコル・検知範囲は、利用するWAF の仕様と設定を確認してください。

WAF is useful, but it does not provide complete protection: What Executives and Managers Need to Understand to Protect Websites and APIs

nabbisen — Fri, 30 Oct 2026 11:13:10 +0000

Introduction: What Is a WAF ? A Checkpoint for Incoming Web Traffic

A WAF (Web Application Firewall) is a security function that inspects HTTP/HTTPS traffic reaching websites and Web APIs. It applies predefined rules to decide whether to allow, log, or block that traffic. A useful way to understand it is as a checkpoint placed in front of a website.

Key Takeaways: What to Understand First

Key point	Management implication
A WAF is useful, but it does not provide complete protection	Its protection is limited to the traffic it inspects and the attacks its configured rules can recognize
A WAF does not fix vulnerabilities themselves	It may temporarily suppress an exploit through virtual patching, but permanent remediation requires software updates or design changes
Attacks can abuse legitimate authenticated sessions	API operations and business-logic abuse that resemble normal traffic may be difficult for a conventional WAF to identify
Operations are required after deployment	Rule updates, false-positive tuning, log monitoring, coverage checks, and bypass-path testing are essential
Security is an ongoing management responsibility	Budgets, owners, and deadlines are needed for asset inventory, patch management, application authorization design, monitoring, and recovery

1. There Are Boundaries to What a WAF Can Protect

Because a WAF operates at the entry point for web traffic, it can be effective against attacks that can be identified from the contents of that traffic. However, determining whether an application's internal processing is correct, whether a logged-in user is entitled to access particular data, or whether a server or middleware component has an underlying weakness is not the WAF's role.

Weakness or risk	Why a WAF alone cannot resolve it	Fundamental response
Vulnerabilities in middleware or libraries	A WAF may temporarily block exploit traffic, but the software itself remains vulnerable	Apply security patches, upgrade to supported versions, and disable unnecessary features
Application authorization flaws	Even when a request is correctly formed, business logic must determine whether the user has permission to access the information or perform the action	Validate authorization on the server for each user, data object, and operation
Abuse of business logic	Repeatedly performing legitimate actions such as purchases, reservations, or applications may not look like a conventional attack pattern	Design business-specific limits, rate controls, abuse detection, and additional verification
Configuration and exposure errors	Administrative interfaces or direct routes to origin servers that bypass the WAF may remain outside its inspection scope	Inventory public exposure, enforce access controls, disable unnecessary services, and restrict network paths
Internal activity after compromise	A WAF is not designed to comprehensively control processes inside a server or lateral movement after a compromise	Apply least privilege, network segmentation, endpoint monitoring such as EDR, log analysis, and incident response

Virtual Patching Is Not a Substitute for a Permanent Fix

This does not mean that a WAF can never address vulnerabilities specific to middleware. When a WAF can identify characteristics of HTTP requests that exploit a particular vulnerability, a rule may block those requests and buy time until the underlying software can be fixed. This approach is known as virtual patching.

However, virtual patching does not fix vulnerable code. It is effective only against attack patterns that the WAF can recognize in traffic it inspects. If an attacker changes the attack method or input format, or uses a route that bypasses the WAF, the protection may no longer apply. OWASP also explains that virtual patching should be used alongside permanent code remediation, and that the possibility of bypass must be evaluated. [2]

A WAF is therefore not a mechanism that makes vulnerability remediation unnecessary. It can serve as a temporary risk-reduction measure when an update or code change takes time, but the organization must still establish a deadline and assign an owner for the permanent fix.

2. Attacks That Look Like Legitimate Traffic Are Difficult for a WAF to Recognize

Attacks targeting websites and APIs do not always involve malicious strings or obviously abnormal requests. An attacker may register and log in just like an ordinary user, obtain a legitimate session, and then call APIs directly—without going through the normal website interface—to retrieve information or perform actions they are not authorized to carry out.

The term “site-based attack” does not identify a single, clearly defined attack method. In this article, we use the more concrete term “legitimate-looking API abuse” to describe this class of threats. It is not one specific technique; it can include authorization flaws in authenticated APIs, automation of business workflows, misuse of sessions, and related issues.

What Might This Look Like ?

An attacker registers an account and logs in just like an ordinary user.
Using the legitimate logged-in session, the attacker examines API requests that a browser sends during normal use.
The attacker changes values in the requests—such as order numbers, customer IDs, or reservation numbers—or directly calls APIs that are not exposed through the normal user interface.
If the server does not adequately verify authorization, the attacker may retrieve another user's information or perform an action that should not be permitted.
The attacker automates or repeats the same operations at scale, potentially harvesting information, occupying reservation slots, buying up inventory, or abusing points and coupons.

In this situation, the HTTP requests may be correctly formatted and accompanied by a valid logged-in session. They may contain none of the typical attack strings associated with SQL injection. From the WAF's perspective, the traffic may look like an ordinary user calling a legitimate API.

OWASP's API Security risks explicitly address this type of problem. For example, Broken Object Level Authorization (BOLA) describes cases in which changing an ID supplied to an API allows access to another user's data. Unrestricted Access to Sensitive Business Flows addresses the risk that functions such as purchasing products or making reservations can be automated and abused. [3]

As one indication of the growth of automation, Thales's 2026 Bad Bot Report states that, in data observed by the company during 2025, AI-powered bot attacks increased 12.5-fold year over year, and 21% of bot attacks targeted business logic. These figures are based on Thales's own observation scope and should not be interpreted as statistics for the entire internet. Nevertheless, they illustrate why organizations need to consider not only the blocking of obviously malicious requests, but also how legitimate functions may be automated and abused. [4]

A key distinction here is the difference between authentication and authorization:

Authentication: Verifying who is accessing the system.
Authorization: Determining which information that user may view and which actions they may perform.

Successful login does not mean that access to all data and functions is permitted. Can a user view only their own order information ? Can they call administrative functions ? Under what frequency and conditions may they make reservations or payments ? These decisions must be enforced by the application according to its business rules.

Session IDs or authentication tokens may also be stolen and abused. Even when a WAF can inspect traffic, it cannot always determine from an HTTP request alone whether the person sending it is the legitimate user or a third party using a hijacked session. Session management, reauthentication for sensitive operations, and detection of abnormal usage patterns must be combined.

The Impact May Extend Beyond the Server Itself

If an application or middleware vulnerability is exploited and an attacker gains the ability to execute code on a server—a condition known as remote code execution (RCE)—the impact may extend beyond that individual server.

Website content or files delivered to visitors may be altered.
Visitors may be redirected to fraudulent websites or served malicious scripts.
Credentials and database information stored on the server may be stolen.
The server may become a foothold for attacks against internal networks or related services.
The server may be used to send malicious traffic or distribute malicious content, damaging the reputation of the domain or service.

These outcomes are not inevitable in every incident. However, organizations that operate websites need to consider not only how to protect their servers, but also how an incident could affect customers, visitors, and connected partners.

3. Operational Burdens and Blind Spots Remain After WAF Deployment

A WAF does not automatically remain in an optimal state after installation. Rule sets must be updated, detection logs reviewed, false positives tuned, and policies reconsidered as services change.

Operational issue	What may happen if it is neglected	Required management
False positives	Legitimate user access and business operations may be blocked	Assess the impact and manage exception rules with documented reasons and expiration dates
Detection-only configuration	An attack may be detected but not actually blocked	Check rule modes and how policies are applied in production
Outdated rules	New attack patterns or application changes may not be covered	Update rules and reassess them regularly
Gaps in coverage	Some domains, APIs, subdomains, or network paths may not pass through the WAF	Maintain an inventory of protected assets and traffic routes
Performance impact	Latency may increase and user experience may deteriorate	Monitor latency and error rates, and conduct load testing
Unused logs	Attack trends, false positives, or missed activity may go unnoticed	Correlate WAF logs with application, authentication, and server logs

Particular attention should be paid to the traffic paths that the WAF actually protects. If a route remains that allows direct access to the origin server without passing through the WAF, traffic using that route will not be inspected by the WAF. Organizations should also verify where HTTPS traffic is decrypted and inspected, and whether communication types such as APIs and WebSockets are within the product's protection scope.

In addition, continually adding exception rules to avoid false positives may eventually allow traffic that should have been blocked. Organizations must understand not merely whether they have purchased or deployed a WAF, but what traffic it inspects, what it blocks, and what it may fail to detect.

4. How to Build Defense in Depth with a WAF as One Component

To use a WAF effectively, protection must be designed to include the systems and controls both before and behind it. The objective is not to deploy many expensive products all at once. It is to understand the organization's assets, threats, and business impact, set priorities, and improve continuously.

                         External users and attackers
                                  |
                                  v
                    +---------------------------+
                    | CDN / DDoS protection /   |
                    | ingress controls          |
                    +---------------------------+
                                  |
                                  v
                    +---------------------------+
                    | WAF                       |
                    | Web traffic inspection    |
                    | and blocking              |
                    +---------------------------+
                                  |
                                  v
                    +---------------------------+
                    | Web application / API     |
                    +---------------------------+
                                  |
                                  v
                    +---------------------------+
                    | Authentication,           |
                    | authorization, and        |
                    | business rules            |
                    +---------------------------+
                                  |
                                  v
                    +---------------------------+
                    | Databases / internal      |
                    | services                  |
                    +---------------------------+

  ---------------------------------------------------------------
  Cross-cutting management supporting the entire system

  [Asset and dependency inventory]  [Patch and configuration management]
  [Least privilege]
  [Log monitoring and anomaly detection]
  [Incident response]               [Backups]
  [Recovery exercises]              [Network segmentation]

  Note: If a direct route to a public-facing server remains,
        traffic may be able to bypass the WAF.

Defense and management layer	Main activities	Relationship to the WAF
Asset and vulnerability management	Identify websites, APIs, servers, middleware, and libraries; manage support status and update deadlines	Identifies what the WAF should protect and addresses underlying vulnerabilities
Infrastructure and platform protection	Update operating systems, web servers, and middleware; stop unnecessary services; harden configurations; manage secrets	Reduces weaknesses that remain outside or behind the WAF
Application security	Secure implementation, code review, vulnerability assessment, authentication and authorization, and business-flow testing	Fixes application-specific flaws that a WAF cannot judge or correct
WAF and perimeter protection	Apply rules, rate limits, and bot controls; consolidate traffic paths; review logs	Detects and blocks attacks at the HTTP layer and reduces risk
Internal defense and data protection	Network segmentation, least privilege, database access controls, encryption, and backups	Limits the impact if an attacker gets past the WAF
Monitoring, response, and recovery	Log correlation, anomaly detection, incident procedures, recovery exercises, and customer communications	Helps identify signs of compromise and assess damage without relying only on WAF detection

The WAF is one defense point in this structure, responsible for the HTTP layer. Depending on the assets and functions being protected, it may be useful to combine it with a CDN, DDoS protection, an API gateway, or bot management. However, it is important not to confuse the roles and responsibilities of these different components.

5. What Executives and Managers Should Verify

Executives and managers should not leave WAF performance and rule configuration entirely to the engineering team. Management should verify the following areas.

      +-----------------------+
      | Identify protected    |
      | assets and services   |
      +-----------------------+
                  |
                  v
      +-----------------------+
      | Analyze threats and   |
      | business impact       |
      +-----------------------+
                  |
                  v
      +-----------------------+
      | Set priorities for    |
      | security measures     |
      +-----------------------+
                  |
                  v
      +-----------------------+
      | Assign budget, owners,|
      | and deadlines         |
      +-----------------------+
                  |
                  v
      +-----------------------+
      | Implement, monitor,   |
      | and verify controls  |
      +-----------------------+
                  |
                  v
      +-----------------------+
      | Evaluate results and  |
      | revise the plan       |
      +-----------------------+
                  |
                  +-----------> Next assessment cycle

Area to verify	Questions for executives and managers	Expected state or evidence
Identification of protected assets	Which websites, APIs, subdomains, and vendor-managed systems are publicly accessible ?	An up-to-date asset inventory with accountable owners
WAF coverage	Does all external-facing traffic pass through the WAF ? Are there routes that allow direct access ?	Traffic-flow diagrams, a list of protected assets, and periodic verification results
Rules and operations	Which rules are enabled, and why are exceptions allowed ? Are rules only detecting rather than blocking ?	Rule-update history, reasons and expiration dates for exceptions, and false-positive reviews
Vulnerability remediation	If the WAF temporarily blocks an exploit, when will the underlying vulnerability be permanently fixed ?	Remediation plans, owners, deadlines, and records of accepted unresolved risks
APIs and business logic	Can a logged-in user access another person's information or functions outside their permissions ?	Object-level and function-level authorization tests, and tests for abuse of business workflows
Monitoring and incident response	Who makes decisions and who is notified when an attack or unauthorized operation is detected ?	Log monitoring, response procedures, contact lists, and exercise records
Budget and responsibilities	Are responsibilities for the WAF, application, infrastructure, and service providers clear ?	Contracts and responsibility boundaries, operating budgets, and improvement plans

In particular, three matters should be made explicit as management decisions.

First, prioritize security measures. Do not make the same level of investment in every system by default. Assess the information handled, number of users, exposure, business impact of downtime, and potential damage from compromise. Systems handling customer or payment information, and systems essential to business continuity, may require a higher level of protection.

Second, do not treat WAF deployment as the completion of security work. Even after a WAF has been contracted and installed, protection cannot be considered sufficient unless rules are properly applied, logs are reviewed, exceptions are managed, and vulnerabilities in the protected systems are remediated. Assign an owner for ongoing operations and define performance and effectiveness measures.

Third, budget for long-term improvement. Updating operating systems, web servers, middleware, CMS platforms, plugins, and applications requires continuing investment in people and time. Even when replacing the underlying platform is not immediately possible, set separate plans and deadlines for interim controls, permanent remediation, and migration or retirement.

Conclusion: What Matters Is Not Having Deployed a WAF, but Being Able to Maintain Protection

A WAF is not an unnecessary product. When properly deployed, configured, and operated, it can detect and block many attacks against web applications and buy time for vulnerability remediation.

However, a WAF does not turn a vulnerable platform into a secure one. It cannot, by itself, completely prevent API abuse through legitimate sessions, application authorization flaws, intrusion into internal networks, or malicious activity after a compromise. Treating WAF deployment as a reason to say “we are secure” risks overlooking fundamental weaknesses and postponing necessary work.

The responsibility of executives and managers is not simply to increase the number of security products deployed. They must understand their organization's systems and data, analyze which threats create which business risks, and put controls in place across infrastructure, applications, users, and operations. They must then review those controls regularly and continue vulnerability remediation, monitoring, exercises, and recovery preparation.

A WAF is not an impenetrable suit of armor. Use it properly as one part of defense in depth, understand the weaknesses that remain, and keep addressing them. That is what security management requires to protect customers and the business.

References

AWS, “AWS WAF Documentation” — Describes how WAF inspects web requests forwarded to protected resources and can count, block, allow, or challenge requests according to configured conditions. Features and coverage vary by product. https://docs.aws.amazon.com/waf/
OWASP, “Virtual Patching Cheat Sheet” — Explains virtual patching, its value in temporarily blocking known exploit paths, the fact that the underlying vulnerability remains, and the need to test for bypasses and implement permanent fixes. https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html
OWASP API Security Top 10 – 2023 — Covers API1, “Broken Object Level Authorization”; API5, “Broken Function Level Authorization”; and API6, “Unrestricted Access to Sensitive Business Flows,” among other risks involving API authorization flaws and abuse of business workflows. https://api-security.owasp.org/editions/2023/en/0x11-t10/
Thales, “2026 Bad Bot Report” — Industry report analyzing bot activity based on data observed by Thales during 2025, including AI-powered bot activity and attacks targeting business logic. The figures represent Thales's observation scope and are not statistics for the entire internet. https://cpl.thalesgroup.com/resources/application-security/2026-bad-bot-report
OWASP API Security Project, “API6:2023 Unrestricted Access to Sensitive Business Flows” — Explains the risks and mitigations associated with the automation and excessive use of sensitive business workflows such as purchases, posts, and reservations. https://api-security.owasp.org/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/

This article does not reject WAFs. It recognizes their value while clarifying the limits of their protection and the need to combine them with other controls. Always verify the specific features, supported protocols, and inspection coverage against the specifications and configuration of the WAF product in use.

WAF は有効だが、完全な防御ではない —— WAF とは ? インシデント (事例) からの教訓

nabbisen — Fri, 30 Oct 2026 04:06:46 +0000

導入: WAF とは何か —— Web への通信を入口で検査する仕組み

インターネットに公開された Web サイトには、SQL インジェクションやクロスサイトスクリプティング (XSS) など、よく知られた攻撃を狙う通信が届きます。WAF は、こうした通信に含まれる特徴を検査し、既知の攻撃パターンに合致するリクエストを検知・遮断することで、Webアプリケーションに攻撃が届く可能性を下げます。製品や契約内容によっては、アクセス頻度の制限、ボット対策、通信ログの可視化なども担います。[1]

経営者・管理者層が押さえるべきWAF の役割は、次のように整理できます。

WAF が担える役割	組織にとっての効果	留意点
既知の攻撃パターンの検知・遮断	不審なWeb リクエストをアプリケーションに到達する前に止める	ルールが認識できる通信が対象。すべての攻撃を識別できるわけではない
一部の脆弱性への仮想パッチ	恒久修正までの間、特定の攻撃リクエストを一時的に遮断できる場合がある	脆弱なプログラム自体は修正されない。適用範囲と回避可能性の確認が必要
アクセス頻度・ボットの制御	大量アクセスや自動化されたリクエストを抑制できる場合がある	正常な自動処理との区別や業務影響の検証が必要。機能は製品により異なる
通信の記録・可視化	攻撃の傾向や遮断状況を把握する手掛かりになる	ログを分析し、対応する運用がなければ十分に活用できない

つまり WAF は、Web への入口で通信を検査し、既知の攻撃や不審なアクセスを減らすための対策です。Web サイトを安全にするために有用ですが、サーバー、ミドルウェア、アプリケーション、データそのものを包括的に守る仕組みではありません。

                 Web サイトに向かう通信
                          |
                          v
             +--------------------------+
             | CDN・DDoS 対策など         |
             | (利用している場合)        |
             +--------------------------+
                          |
                          v
             +--------------------------+
             | WAF                      |
             | HTTP/HTTPS 通信を検査     |
             | ルールに応じて許可・記録  |
             | または遮断               |
             +--------------------------+
                          |
                          v
             +--------------------------+
             | Web サイト / Web API      |
             +--------------------------+
                          |
                          v
             +--------------------------+
             | 認証・認可・業務ルール    |
             +--------------------------+
                          |
                          v
             +--------------------------+
             | データベース・内部サービス|
             +--------------------------+

  注意: WAF を経由せず、公開サーバーへ直接届く経路があれば、
        その通信は WAF による検査を受けない可能性があります。

WAF が守れるのは、基本的に WAF を通過する通信、すなわち WAF 製品が検査できる通信です。下記のものなどは WAF だけでは解決できません:

正規のログイン状態を使った不正操作
アプリケーション内部の認可不備
未修正のミドルウェアの弱点
侵害後のサーバー内部の活動

WAF は「完全な鎧」ではなく、多層防御を構成する一つの防御点です。 製品を導入した事実で安心するのではなく、自組織の脅威と事業リスクを把握し、基盤・アプリケーション・運用を含めた対策を継続する必要があります。

インシデントから学ぶ —— WAF と異なるレイヤーで起きた問題

WAF の限界を考えるうえでは、WAF そのものや設定に関係する事例だけでなく、WAF とは異なるレイヤーの不備が原因となった事例も参考になります。ここでは、WAF / クラウド設定と、アプリケーションの API 権限設定という、異なる二つの事例を取り上げます。

事例 1: Capital One —— WAF の設定不備がデータへのアクセス経路になった (2019 年)

2019 年、米国の金融機関 Capital One で、クレジットカード申込者や顧客に関する情報への不正アクセスが発生しました。米国司法省の事件概要によると、侵入は、データへのアクセスを可能にする設定不備のある WAF を経由して行われました。

この事例は、WAF が存在すれば安全というわけではなく、WAF やその周辺の設定が不適切であれば、意図しないアクセス経路になり得ることを示しています。境界で通信を検査するだけでは不十分であり、クラウド上の認証情報やアクセス権限、データ保管領域へのアクセス制御も独立して適切に設計・検証する必要があります。

ここから得られる教訓は、WAF の導入有無だけを確認するのではなく、保護対象への通信経路、WAF の設定、クラウドの権限、データへのアクセス制御を一体として管理することです。WAF が通過させた通信や、WAF の設定不備によって生じた経路の先で、どこまでの操作が可能になるのかを考えなければなりません。[2]

事例 2: T-Mobile —— API のアクセス権限設定不備 (2023 年)

2023 年 1 月、米国の通信事業者 T-Mobile は、単一の API を通じて顧客情報が不正に取得されたと公表しました。米国連邦通信委員会 (FCC) の調査資料によると、人的な設定ミスによって API の権限設定が不適切になり、攻撃者が API にクエリを送信して顧客アカウント情報を取得できる状態になっていました。影響したのは約 3,700 万件の現行のポストペイドおよびプリペイド顧客アカウントで、取得された情報の項目はアカウントごとに異なっていました。

この事例の中心は、典型的な攻撃文字列やサーバーの脆弱性ではなく、API がどの情報へのアクセスを許可してよいかという権限管理でした。リクエストの形式が正しく、API 自体も正規の機能であっても、サーバー側の認可確認が不十分であれば、本来許可されていない情報取得が成立してしまいます。

なお、公開資料からは、この API に WAF が導入されていたか、あるいは WAF を迂回したのかまでは確認できません。したがって、この事件を「WAF が突破された事例」と説明することは適切ではありません。ここでの教訓は、 WAF が通信を検査していても、利用者がそのデータを取得する権限を持つかどうかは、アプリケーション側で検証しなければならない という点です。[3]

二つの事例から分かること

事例	問題があったレイヤー	経営・管理上の教訓
Capital One (2019 年)	WAF の設定と、クラウド上のアクセス経路・権限管理	WAF の設定だけでなく、その先のクラウド資産やデータへのアクセス権限も検証する
T-Mobile (2023 年)	API のアクセス権限・アプリケーションの認可管理	正規の API 通信であっても、利用者ごと・データごとの認可をサーバー側で確認する

二つの事例は、異なる場所にある設定や制御の不備が、情報漏えいにつながり得ることを示しています。WAF は入口の通信を検査する重要な防御点ですが、クラウドの権限管理やアプリケーションの認可判断まで代行するものではありません。組織は、各レイヤーに適切な責任者と検証手順を置き、それぞれの対策が機能していることを確かめる必要があります。

要点: まず押さえるべきこと

要点	経営・管理上の意味
WAF は有効だが、完全な防御ではない	WAF が検査する通信と、設定されたルールで捉えられる攻撃に防御範囲は限られる
WAF は脆弱性そのものを直さない	仮想パッチとして一時的に攻撃を抑えられる場合はあるが、恒久対策はソフトウェア更新や設計修正である
正規のログイン状態を悪用する攻撃がある	通常の通信に見えるAPI操作や業務ロジックの悪用は、一般的なWAF だけでは判断しにくい
導入後の運用が必要	ルール更新、誤検知調整、ログ監視、適用範囲の確認、回避経路の検証が欠かせない
セキュリティは経営上の継続課題	資産把握、パッチ管理、アプリケーションの認可設計、監視・復旧に予算・責任者・期限を割り当てる必要がある

次の記事ではこれらを掘り下げます。

参考資料・出典

AWS, “AWS WAF Documentation” — WAF が保護対象へ転送される Web リクエストを検査し、条件に応じてカウント、遮断、許可、チャレンジを行う機能の説明。製品ごとに機能・対応範囲は異なる。 https://docs.aws.amazon.com/waf/
U.S. Department of Justice, “United States v. Paige Thompson” — Capital Oneの情報への侵入が、データへのアクセスを可能にする設定不備のあるWeb Application Firewallを経由して行われたとする事件概要。また、Capital Oneの2019年7月29日付公表資料は、同社が設定上の脆弱性を悪用した不正アクセスを確認したことを説明している。 DOJ case summary · Capital One incident announcement
Federal Communications Commission (FCC), “In the Matter of T-Mobile US, Inc.”, DA 24-860 (2024) — 2023年1月に発覚したAPI経由の情報取得について、人的な設定ミスによる権限設定不備と、約3,700万件の顧客アカウントへの影響を記録した調査・同意命令。補足として、T-Mobileの2023年1月19日付公表資料も参照。 FCC document · T-Mobile announcement

WAF is useful, but it does not provide complete protection: What Is a WAF ? Lessons from Incidents

nabbisen — Fri, 30 Oct 2026 04:05:44 +0000

Introduction: What Is a WAF ? A Checkpoint for Incoming Web Traffic

Websites exposed to the internet receive requests that may contain well-known attack patterns, such as SQL injection and cross-site scripting (XSS). A WAF examines characteristics of these requests and can detect or block those that match known attack patterns, reducing the likelihood that some attacks reach the web application. Depending on the product and service plan, a WAF may also provide rate limiting, bot controls, and traffic-log visibility. [1]

The main roles of a WAF, from an executive and management perspective, can be summarized as follows.

WAF capability	Organizational benefit	Important consideration
Detecting and blocking known attack patterns	Stops suspicious web requests before they reach the application	Protection applies to traffic the rules can recognize; a WAF cannot identify every attack
Virtual patching for certain vulnerabilities	May temporarily block specific exploit requests while a permanent fix is being prepared	The vulnerable software itself remains unpatched; coverage and bypass possibilities must be checked
Rate limiting and bot controls	May reduce excessive traffic and automated requests	Legitimate automation must be distinguished from abuse, and business impact must be tested; capabilities vary by product
Traffic logging and visibility	Provides clues about attack trends and blocking activity	Logs cannot be fully utilized without analysis and an operational response

In short, a WAF is a measure for inspecting traffic at the entry point to a website and reducing known attacks and suspicious access. It is useful for protecting websites, but it is not a comprehensive mechanism for protecting servers, middleware, applications, or data.

                 Traffic destined for a website
                          |
                          v
             +--------------------------+
             | CDN / DDoS protection    |
             | (if deployed)            |
             +--------------------------+
                          |
                          v
             +--------------------------+
             | WAF                      |
             | Inspects HTTP/HTTPS      |
             | Allows, logs, or blocks  |
             | traffic based on rules   |
             +--------------------------+
                          |
                          v
             +--------------------------+
             | Website / Web API        |
             +--------------------------+
                          |
                          v
             +--------------------------+
             | Authentication,          |
             | authorization, and       |
             | business rules           |
             +--------------------------+
                          |
                          v
             +--------------------------+
             | Databases / internal     |
             | services                 |
             +--------------------------+

  Note: If a route allows direct access to a public-facing server
        without passing through the WAF, that traffic may not be
        inspected by the WAF.

A WAF can protect only traffic that passes through it and that the product is capable of inspecting. Among other things, a WAF alone cannot resolve:

Unauthorized operations carried out through a legitimate authenticated session
Authorization flaws inside an application
Weaknesses in unpatched middleware
Activity inside a server after it has been compromised

A WAF is not an impenetrable suit of armor; it is one control within a defense-in-depth strategy. Organizations should not assume they are secure simply because a product has been deployed. They need to understand their own threats and business risks, and continuously maintain appropriate controls across infrastructure, applications, and operations.

4. Lessons from Incidents: Problems That Occurred at Different Layers from the WAF

When considering the limits of a WAF, it is useful to examine not only incidents involving the WAF itself or its configuration, but also incidents caused by weaknesses at other layers. This section looks at two distinct cases: a WAF/cloud configuration problem and an application API authorization problem.

Case 1: Capital One — A WAF Configuration Error Became a Path to Data (2019)

In 2019, unauthorized access to information concerning credit card applicants and customers occurred at Capital One, a U.S. financial institution. According to the U.S. Department of Justice's case summary, the intrusion took place through a misconfigured Web Application Firewall (WAF) that enabled access to the data.

This case shows that the presence of a WAF does not guarantee security: if the WAF or its surrounding configuration is incorrect, it can become part of an unintended access path. Inspecting traffic at the perimeter is not enough. Cloud credentials and permissions, as well as access controls for data storage, must be independently and properly designed and verified.

The lesson is not merely to check whether a WAF has been deployed. Organizations must manage the traffic paths to protected assets, WAF configuration, cloud permissions, and data-access controls as a connected whole. They must consider what operations become possible beyond the point where the WAF allows traffic—or beyond a path created by a WAF configuration error. [2]

Case 2: T-Mobile — Improper API Access-Control Configuration (2023)

In January 2023, T-Mobile, a U.S. telecommunications provider, disclosed that customer information had been improperly obtained through a single API. According to an investigation document issued by the U.S. Federal Communications Commission (FCC), a human configuration error resulted in improper API access controls, allowing an attacker to send queries to the API and obtain customer account information. Approximately 37 million current postpaid and prepaid customer accounts were affected. The specific information obtained varied by account.

The central issue in this case was not a conventional attack string or a server vulnerability. It was the management of which information an API should allow a user to access. Even when a request is correctly formatted and the API itself is a legitimate function, inadequate server-side authorization checks can allow access to information that should not be available to the requester.

The public materials do not establish whether a WAF was deployed in front of this API or whether a WAF was bypassed. It would therefore be inappropriate to describe this incident as a case in which “a WAF was bypassed.” The lesson here is that even when a WAF inspects traffic, the application itself must verify whether the user is authorized to obtain the requested data. [3]

What the Two Cases Tell Us

Incident	Layer where the problem occurred	Management lesson
Capital One (2019)	WAF configuration and cloud access paths and permissions	Verify not only WAF configuration, but also permissions for cloud assets and data beyond it
T-Mobile (2023)	API access controls and application authorization	Verify authorization on the server for each user and each data object, even when the API request is legitimate

These two incidents show that weaknesses in settings and controls at different layers can lead to data exposure. A WAF is an important defense point for inspecting incoming traffic, but it does not replace cloud permission management or application authorization. Organizations need accountable owners and verification procedures for each layer, and must confirm that each control is actually working.

Key Takeaways: What to Understand First

Key point	Management implication
A WAF is useful, but it does not provide complete protection	Its protection is limited to the traffic it inspects and the attacks its configured rules can recognize
A WAF does not fix vulnerabilities themselves	It may temporarily suppress an exploit through virtual patching, but permanent remediation requires software updates or design changes
Attacks can abuse legitimate authenticated sessions	API operations and business-logic abuse that resemble normal traffic may be difficult for a conventional WAF to identify
Operations are required after deployment	Rule updates, false-positive tuning, log monitoring, coverage checks, and bypass-path testing are essential
Security is an ongoing management responsibility	Budgets, owners, and deadlines are needed for asset inventory, patch management, application authorization design, monitoring, and recovery

I will delve into these in the next article.

References

AWS, “AWS WAF Documentation” — Describes how WAF inspects web requests forwarded to protected resources and can count, block, allow, or challenge requests according to configured conditions. Features and coverage vary by product. https://docs.aws.amazon.com/waf/
U.S. Department of Justice, “United States v. Paige Thompson” — Case summary stating that the intrusion into Capital One's data occurred through a misconfigured Web Application Firewall that enabled access to the data. See also Capital One's announcement dated 29 July 2019, which describes unauthorized access involving the exploitation of a configuration vulnerability. DOJ case summary · Capital One incident announcement
Federal Communications Commission (FCC), “In the Matter of T-Mobile US, Inc.”, DA 24-860 (2024) — Investigation and consent order documenting the API data-access incident identified in January 2023, including improperly configured access controls resulting from human error and the impact on approximately 37 million customer accounts. See also T-Mobile's announcement dated 19 January 2023. FCC document · T-Mobile announcement

OpenBSD 7.9 を 8.0 へアップグレード

nabbisen — Thu, 29 Oct 2026 06:30:00 +0000

はじめに

OpenBSD プロジェクトから 2026 年 10 月 20 日に OS の 8.0 がリリースされました 🌷 61 回目のリリースに当たります。

What's New (英語) | Changelog (英語)

本記事で OpenBSD 7.9 を 8.0 にアップグレードする手順を説明します。
各手順はすばらしい公式ガイド (英語) に基づいています。

チュートリアル

実行するコマンド一式を示しながら、ステップ・バイ・ステップ形式で書いた、アップグレード用のガイドです。

🌷 🐡 🌅

1. アップグレード前準備: 検証とカスタイマイズ

公式のチュートリアルには Before using any upgrade method (私訳: アップグレード方法に関わらずその前に行うこと) セクションが設けられています。

アップグレード方法としては sysupgrade を使うのが、たいていの場合、良い選択になるでしょう。

ディスク空き容量の確認

/usr に 1.1GB 以上の空きがあることが必要です。

$ df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
(...)
/dev/sd0e      7.8G    1.8G    5.5G    26%    /usr

OK のようです :)

現在の利用内容がアップグレード結果に適合することの確認

設定と構文の変更 (英語) と特別なパッケージ (英語) を確認しましょう。

バックアップ (必要な場合)

適宜、事前にバックアップを取得しておきましょう。

アップグレード内容のカスタマイズ (必要な場合)

2. `sysupgrade` によるアップグレード

準備は良いですか。

* 注意: 以下のコマンド sysupgrade は、ひとたび実行すると中断はできません。

準備ができたら、以下のコマンドを実行しましょう。実行するのはこれだけです:

$ doas sysupgrade

以下のように出力されるでしょう:

Fetching from https://cdn.openbsd.org/pub/OpenBSD/8.0/amd64/
SHA256.sig   100% |******************************|  2144       00:00
Signature Verified
BUILDINFO    100% |******************************|    54       00:00
Verifying old sets.
INSTALL.amd64 100% |*****************************| 44889       00:00
base80.tgz   100% |******************************|   530 MB    00:18
bsd          100% |******************************| 32494 KB    00:01
bsd.mp       100% |******************************| 32653 KB    00:00
bsd.rd       100% |******************************|  4782 KB    00:00
comp80.tgz   100% |******************************|    99 MB    00:02
game80.tgz   100% |******************************|  2743 KB    00:00
man80.tgz    100% |******************************|  8417 KB    00:00
xbase80.tgz  100% |******************************| 47568 KB    00:01
xfont80.tgz  100% |******************************| 23022 KB    00:00
xserv80.tgz  100% |******************************| 11739 KB    00:00
xshare80.tgz 100% |******************************|  4568 KB    00:00
Verifying sets.
Fetching updated firmware.
fw_update: add none; update intel,vmm
Upgrading.

マシンの再起動とシステムのアップグレードが行われます。ふたたび再起動が行われて、sysmerge が自動で実行されます。それから sshd 等のデーモンが、従来のように起動されます。"Checking for available binary patches..." と出力されて、もし対象が存在すれば "Run syspatch(8) to install:" と表示されるでしょう。

最終的に以下が表示されます:

starting local daemons: cron.
Thu Oct 29 08:40:00 JST 2026

OpenBSD/amd64 ... (ttyC0)

login:

ログインメッセージが表示されています。"OpenBSD 8.0 (GENERIC.MP)" とあります。

3. アップグレード後の操作: `sysmerge` (必要に応じて)

公式ドキュメントにアップグレード後に行うこと (英語) が書かれています。大いに参考になるでしょう。

In some cases, configuration files cannot be modified automatically. Run
# sysmerge
to check and perform these configuration changes.

ここで言われているのは、手動で sysmerge を実行することが必要な場合もある、ということです。
以下のような conf ファイルを、手動でマージすることが必要な場合もあります。気を付けてください:

/etc/login.conf

コマンドを実行しましょう:

$ doas sysmerge

差分がある場合、手動によるマージが必要になります。

4. `syspatch` の適用 (スキップ可能)

ここからの 2 つのタスクは、日常的なメンテナンスで、システムをアップデートする時にも実施するものです。

syspatch は重要なコマンドです。OpenBSD から、必要と判明し次第都度、継続的に提供される公式のバイナリ・パッチです。

$ doas syspatch

5. パッケージのアップデート

What's new (英語) セクションがリリースページにありますが、そこの "Ports and packages" (Ports とパッケージ (英語)) に "Some highlights" (注目点 (英語)) が記載されています。例えば、VMM/VMD が今回も更新されています。

次のコマンドはマシンにインストールされているすべてのパッケージをアップデートします:

$ doas pkg_add -u

大量の出力が現れるでしょう。これらは慎重に読む必要があります。終わりの部分は特に、です。そこに重要な変更点や実施すべきアクションが書かれているかもしれません。私の場合、fish をデフォルトのシェルとして使っているのですが、こちらが正常に起動することをいつも確認しています。というのも、かつて Python のアップグレードの影響でクラッシュするようになったことがあるからです 😅

6. 設定と構文の変更

必要に応じて conf を更新して、設定と構文の変更 (英語) に書かれている内容を適用しましょう。

7. 古くなったファイルの削除

ここはシンプルな手順です。公式チュートリアルの削除すべきファイル (英語) に書かれていることを行うだけです。

今回の対象はありません。

8. 特別なパッケージ

公式チュートリアルの特別なパッケージ (英語) を確認しましょう。使っているものがあるかもしれません:

firefox
kea
libmaxminddb
stalwart-mail

9. 再起動

ゴールが見えて来ました ! 最後に必須では無いですが再起動しておくと良いしれません:

$ doas reboot

おわりに

新しいシステムとあなたが長く楽しい時間を過ごせますように :)

OpenBSD プロジェクトとコミュニティへの深い感謝を込めつつ。

脚注

アップグレードのカスタマイズ方法

ここは参照用であり、標準のアップグレードではスキップできます。

/auto_upgrade.conf をレスポンス・ファイルとして利用できます。
OpenBSD の autoinstall のドキュメントに、次のように書かれています:

If either /auto_install.conf or /auto_upgrade.conf is found on bsd.rd's built-in RAM disk, autoinstall behaves as if the machine is netbooted, but uses the local response file. In case both files exist, /auto_install.conf takes precedence.

(私訳: /auto_install.conf または /auto_upgrade.conf が bsd.rd 内蔵の RAM ディスクに存在する場合、autoinstall は、ネットブートモードで起動されたマシンのように振る舞いますが、ローカルにあるレスポンス・ファイルを使用します。両方のファイルが存在する場合、/auto_install.conf が優先されます。)

/auto_upgrade.conf の完全な内容の一例は次のようなものです:

Location of sets = disk
Pathname to the sets = /home/_sysupgrade/
Set name(s) = -x*
Set name(s) = +xbase*
Set name(s) = -game*
Set name(s) = done
Directory does not contain SHA256.sig. Continue without verification = yes

この場合、xbase を除く x 一式と game が、インストール対象外になります。

それから /upgrade.site を用いた指定も可能です。

`sysmerge` 差分マージ

まず差分が出力されます。それから以下のようにたずねられます:

  Use 'd' to delete the temporary ./etc/login.conf
  Use 'i' to install the temporary ./etc/login.conf
  Use 'm' to merge the temporary and installed versions
  Use 'v' to view the diff results again

  Default is to leave the temporary file to deal with by hand

How should I deal with this? [Leave it for later]

最初の 3 つは、以下のような挙動になります:

d: 現在の (ローカルの) ファイルを保持する。
i: sysupgrade が取得した新しいファイルでローカルを上書きする。
m: 対話型形式で手動でマージする。

m を入力するとマージモードが立ち上がります。一つ一つの差分について、いずれを採用するのかを確認されるでしょう:

l を入力すると左側が採用されます。
r は右側です。

その後に、マージ結果ファイルに対して、どの操作を行うのかをたずねられます:

  Use 'e' to edit the merged file
  Use 'i' to install the merged file
  Use 'n' to view a diff between the merged and new files
  Use 'o' to view a diff between the old and merged files
  Use 'r' to re-do the merge
  Use 'v' to view the merged file
  Use 'x' to delete the merged file and go back to previous menu
  Default is to leave the temporary file to deal with by hand

===> How should I deal with the merged file? [Leave it for later]

e を入力すると、エディタが起動されてマージ結果ファイルを編集できるようになります。

i を入力すると、マージ結果ファイルをマシンにインストールします:

===> Merging /etc/login.conf (running cap_mkdb(1), needs a relog)

OpenBSD Upgrade 7.9 to 8.0

nabbisen — Thu, 29 Oct 2026 03:02:23 +0000

Summary

The OpenBSD project released 8.0 of their OS on 20 October 2026, as their 61th release 💫

What's New | Changelog

This post shows how to upgrade OpenBSD 7.9 to 8.0.
The steps are based on their official guide with appreciation to them.

Tutorial

Here is a step-by-step guide with a set of command-lines to run.

🌷 🐡 🌅

1. Pre-upgrade: Validate and customize

The official tutorial includes Before using any upgrade method section.

Using sysupgrade is usually a good choice.

Validate available disk size

/usr should be greater than 1.1GB.

$ df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
(...)
/dev/sd0e      7.8G    1.8G    5.5G    26%    /usr

OK :)

Validate compatibility with the current usage

See Configuration and syntax changes and Special packages.

Backups (Optional)

You might have to create some backups.

Customize upgrade (Optional)

2. Upgrade with `sysupgrade`

OK. You must be ready.

* Caution: The command below, sysupgrade, is unable to stop once it is run.

Let's just run it, if ready:

$ doas sysupgrade

It will print out like this:

Fetching from https://cdn.openbsd.org/pub/OpenBSD/8.0/amd64/
SHA256.sig   100% |******************************|  2144       00:00
Signature Verified
BUILDINFO    100% |******************************|    54       00:00
Verifying old sets.
INSTALL.amd64 100% |*****************************| 44889       00:00
base80.tgz   100% |******************************|   530 MB    00:18
bsd          100% |******************************| 32494 KB    00:01
bsd.mp       100% |******************************| 32653 KB    00:00
bsd.rd       100% |******************************|  4782 KB    00:00
comp80.tgz   100% |******************************|    99 MB    00:02
game80.tgz   100% |******************************|  2743 KB    00:00
man80.tgz    100% |******************************|  8417 KB    00:00
xbase80.tgz  100% |******************************| 47568 KB    00:01
xfont80.tgz  100% |******************************| 23022 KB    00:00
xserv80.tgz  100% |******************************| 11739 KB    00:00
xshare80.tgz 100% |******************************|  4568 KB    00:00
Verifying sets.
Fetching updated firmware.
fw_update: add none; update intel,vmm
Upgrading.

The machine will reboot and upgrade the system. It will reboot again and sysmerge will follow automatically. Then daemons such as sshd will be started as usual. It will print out "Checking for available binary patches...", and you will see "Run syspatch(8) to install:" if there are.

Finally, you will see:

starting local daemons: cron.
Thu Oct 29 08:40:00 JST 2026

OpenBSD/amd64 ... (ttyC0)

login:

After all, when login is successful, you will see the login message including "OpenBSD 8.0 (GENERIC.MP)".

3. Post-upgrade: `sysmerge` if necessary

The official documentation describes on them and helps a lot.

In some cases, configuration files cannot be modified automatically. Run
# sysmerge
to check and perform these configuration changes.

It means manually running sysmerge in addition may be sometimes necessary.
Remember you sometimes have to manually merging conf files such as:

/etc/login.conf

Run:

$ doas sysmerge

When there are any difference which are not automatically resolved, it will be necessary to manually merge them.

4. Apply `syspatch` (skippable)

The next two tasks below are usual just in order to update the system, too.

syspatch is an important command to install binary patches officially offered by OpenBSD successively as found to be needed.

$ doas syspatch

5. Update packages

What's new section in the release page also shows "Some highlights" in "Ports and packages". For example, VMM/VMD was improved this time, too.

The command-line below will update all of the packages installed in the machine:

$ doas pkg_add -u

You will see a lot printed out, but should be careful to read, especially the trailings. They may tell there are some important changes or tasks to do. As to me, I always check if fish, my default shell, starts normally, because I have experienced trouble which crashed it with Python upgrade 😅

6. Configuration and syntax changes

Update some conf as needed to apply what Configuration and syntax changes describes.

7. Remove old files

This is a simple step. All what to do is just follow Files to remove in the official tutorial.

There is nothing this time.

8. Special packages

Check Special packages in the official tutorial. You may use some of:

firefox
kea
libmaxminddb
stalwart-mail

9. Reboot

Almost done ! Finally and optionally run:

$ doas reboot

Conclusion

Hope the new system and you enjoy together long :)

With great appreciation to the OpenBSD project and the community.

Footer notes

How to customize upgrade

This step is just for reference, skippable with standard upgrade.

/auto_upgrade.conf is available as the response file.

Of course, you can skip this and go next if it's unnecessary. The default behavior is sufficient in most cases.

Well, the OpenBSD manual page on autoinstall says:

If either /auto_install.conf or /auto_upgrade.conf is found on bsd.rd's built-in RAM disk, autoinstall behaves as if the machine is netbooted, but uses the local response file. In case both files exist, /auto_install.conf takes precedence.

The whole example of /auto_upgrade.conf is like:

Location of sets = disk
Pathname to the sets = /home/_sysupgrade/
Set name(s) = -x*
Set name(s) = +xbase*
Set name(s) = -game*
Set name(s) = done
Directory does not contain SHA256.sig. Continue without verification = yes

In this case, x sets except xbase and game are excluded.

Also, /upgrade.site can be applied.

How to merge in `sysmerge`

When there is difference to be manually merged, you will see the results first. Then you will be asked:

  Use 'd' to delete the temporary ./etc/login.conf
  Use 'i' to install the temporary ./etc/login.conf
  Use 'm' to merge the temporary and installed versions
  Use 'v' to view the diff results again

  Default is to leave the temporary file to deal with by hand

How should I deal with this? [Leave it for later]

Each of the top 3 options work like:

d: to preserve the current file.
i: to overwrite it with the new file sysupgrade brought.
m: to merge them manually and interactively.

If you type m to start merge mode, you will be asked to type each of them at each difference:

l to choose the left diff,
r to choose the right.

Then you will see the options to deal with the merged file:

  Use 'e' to edit the merged file
  Use 'i' to install the merged file
  Use 'n' to view a diff between the merged and new files
  Use 'o' to view a diff between the old and merged files
  Use 'r' to re-do the merge
  Use 'v' to view the merged file
  Use 'x' to delete the merged file and go back to previous menu
  Default is to leave the temporary file to deal with by hand

===> How should I deal with the merged file? [Leave it for later]

If you type e, editor will run with the merged file.

If you type i, the merged file will be installed directly:

===> Merging /etc/login.conf (running cap_mkdb(1), needs a relog)

PHP のサポート切れがもたらす経営リスク —— 「PHP2shell」から考える更新責任

nabbisen — Wed, 28 Oct 2026 10:42:07 +0000

Web サイトや商用サービスあるいは業務システムにとって、 ソフトウェアのサポート期限は技術部門だけの問題ではありません 。未修正の脆弱性 (ぜいじゃくせい) の放置は、事業停止・顧客の信頼・予算に直結する、経営・管理上の課題です。

本記事では、PHP を題材に、そのサポート切れがなぜ経営上のリスクになるのか、実際の脆弱性悪用事例から何を学ぶべきかを整理します。それから経営陣・管理者層と現場のエンジニアが、何を確認すべきかを記載します。

PHP はサーバーアプリエンジンの代表的なものの一つです。今回はこちらを題材にしています。しかしながら、他のソフトウェアやインフラについても、同様の注意と配慮、さらには実践的な取組みが必要です。

要点: まず経営陣・管理者層が押さえるべきこと

要点	組織にとっての意味	まず確認すること
サポート終了は、ただちに停止するという意味ではない	動作し続けていても、今後の修正が提供されない可能性がある	PHP のバージョンと公式サポート期限
サポート中でも修正前なら危険がある	PHP2shell のような重大な脆弱性には、サポート中のバージョンでも緊急対応が必要	PHP2shell の影響有無と修正バージョン
更新はエンジニアだけでは完結しない	試験、業務調整、予算、委託先との責任分担が必要	責任者、期限、予算、切り替え判断権限
「今まで被害がない」は安全の証明にならない	未把握のシステムや未検知の侵害が残っている可能性がある	管理対象の棚卸しと、ログ・復旧手順の確認

背景: PHP2shell とサポート切れをめぐる状況

2026 年 10 月、PHP に関する 2 件の重大な脆弱性が公表され、組合せて「PHP2shell」と呼ばれています。悪用された場合、認証されていない第三者が遠隔から任意のコードを実行する可能性があります。PHP 開発チームは修正版を公開し、速やかな更新を強く推奨しました。さらに、2026 年 10 月 26 日には、米国の公的サイバーセキュリティ機関である CISA (Cybersecurity and Infrastructure Security Agency) が、この 2 件を「実際に悪用された脆弱性」のカタログに追加しました。[1][2]

一方、日本の公的な情報セキュリティ専門機関である IPA (情報処理推進機構) は、2026 年 10 月 27 日時点で日本における PHP2shell の攻撃被害を把握していないとしつつ、対策済みバージョンへの移行を呼びかけています。「日本で 被害が確認されていない 」ことは、 「危険がない」ことを意味しません。 [2]

PHP2shell は、サポート切れのバージョンだけの問題でもありません。サポート中のバージョンでも修正前のリリースを使用していれば影響を受ける可能性があります。

一方、サポートが終了したバージョンでは、新たな脆弱性が発見されても、PHP 開発チームから修正プログラムが提供されない場合があります。そのため組織は、サポート対象のリリースへ移行するか、あるいは利用しているオペレーティングシステムやホスティングプロバイダーが独自に保守しているパッケージを提供しているか、またそのサポート範囲がどこまで及ぶのかを確認する必要があります。

1. 放置された古いバージョンが抱えるリスク

PHP (あるいは一般的なソフトウェア) では、すべてのバージョンが無期限に保守されるわけではありません。PHP 開発チームは、各リリース系列について一定期間の通常サポートとセキュリティサポートを提供し、その期間が終わるとサポート終了（End of Life、EOL）として扱います。サポート終了後もシステムが急に動かなくなるわけではありません。むしろ、従来どおり動いて見えるために、問題が表面化しないまま使われ続けることがあります。[4]

PHP のサポート状況を確認する

2026 年 10 月 28 日時点の PHP 公式情報では、PHP 8.2〜8.5がサポート対象です。ただし、PHP 8.2 系のセキュリティサポートは 2026 年 12 月 31 日に終了する予定です。サポート対象の系列を使っていても、期限が迫っていないかを確認する必要があります。

PHP 系列	公式サポート終了日	2026 年 10 月 28 日時点の見方
PHP 5.6	2018 年 12 月 31 日	サポート終了
PHP 7.4	2022 年 11 月 28 日	サポート終了
PHP 8.0	2023 年 11 月 26 日	サポート終了
PHP 8.1	2025 年 12 月 31 日	サポート終了
PHP 8.2	2026 年 12 月 31 日	セキュリティサポート終了が目前
PHP 8.3	2027 年 12 月 31 日	サポート中。次の移行計画が必要
PHP 8.4	2028 年 12 月 31 日	サポート中
PHP 8.5	2029 年 12 月 31 日	サポート中

出典: PHP 公式「Supported Versions」「Unsupported Branches」[4][5]。利用している OS ディストリビューションやホスティング事業者が独自の延長サポートを提供している場合は、その適用条件と責任範囲も別途確認してください。

サポート終了したバージョンを使い続ける主なリスクは、次のように整理できます。

リスク	何が起こり得るか	経営・管理上の影響
修正プログラムが提供されない	新たな脆弱性が判明しても、公式修正を入手できない場合がある	既知のリスクを抱えたまま運用を続けることになる
既知の弱点を狙われる	攻撃者が公開情報や自動スキャンを使って、脆弱な環境を探す可能性がある	Web サイト改ざん、情報漏えい、業務停止などの被害につながり得る
周辺ソフトウェアも更新しにくい	PHP 本体が古いため、CMS・フレームワーク・プラグイン・ライブラリの更新が難しくなることがある	移行費用や保守作業が増え、選択肢が狭まる
保守体制が失われる	設計資料や担当者がいない、委託先との契約が終わっているなどの事情が重なる	更新に要する時間と費用がさらに増える

古いバージョンについて「脆弱性が何件あるか」だけを数えても、リスクを十分に評価できません。件数はデータベースの集計方法や対象範囲によって変わります。経営上重要なのは、現在のシステムがサポートを受けているか、修正版を適用できるか、そして継続的に保守する体制があるかです。

なぜ古い PHP が放置されやすいのか

システムは、動いている間は問題が見えにくいものです。特に、何年も変更されていない Web サイトでは、「止めると困る」「更新すると壊れるかもしれない」「担当者がいない」といった理由で、更新が先送りされがちです。しかし、先送りはリスクを消すのではなく、移行しなければならない時点まで課題を積み上げることがあります。

【リスクの流れ】
[PHP のサポート終了]
       │
       ▼
[公式修正を受けられない可能性]
       │
       ▼
[脆弱性が残る・周辺部品も更新しにくい]
       │
       ▼
[侵害・停止・復旧長期化のリスク]

この図は、サポート終了が必ず侵害を引き起こすという意味ではありません。サポート終了により修正の選択肢が狭まり、リスク管理が難しくなる流れを示しています。次の図は、組織が取るべき対応を示しています。

【対策のフロー】
[資産の棚卸しと移行計画]
       │
       ▼
[責任者・予算・期限を決定]
       │
       ▼
[サポート対象へ移行し、継続保守]
       │
       ▼
[残余リスクを定期確認]

2. 実際の事例から見る PHP の脆弱性対応

事例 1: CVE-2024-4577 を悪用したWebシェル設置

2024 年、日本の公的な情報セキュリティ専門機関は、PHP の脆弱性 CVE-2024-4577 を悪用した攻撃による被害を確認したと公表しました。発表によると、日本の複数組織でこの脆弱性が悪用され、PHP が稼働する Web サービスに Web シェルが設置されていたとの情報がありました。

Web シェルとは、攻撃者が侵入したサーバーを遠隔から操作するために設置する不正なプログラムです。設置された場合、追加の操作や組織内の別システムへの侵入、他組織への攻撃を中継する足場になる可能性があります。Web サイトの改ざんや情報窃取だけでなく、被害が当初の Web サイトにとどまらないおそれもあります。

この事例は「古い PHP なら必ず侵害される」という意味ではありません。外部から到達できるシステムに脆弱性があり、それを適切なタイミングで修正できなければ、Web サイトが組織への侵入口になる可能性があるということです。CVE-2024-4577 には特定の Windows 上の PHP 構成などの影響条件があるため、すべてのPHP環境が同じ条件で影響を受けるわけではありません。脆弱性ごとに、対象となる OS・実行方式・バージョンを確認することが重要です。[6]

事例 2: PHP2shell —— サポート中でも緊急対応が必要になる

2026 年 10 月に公表された PHP2shell は、メモリ不足時のエラー処理に関連する脆弱性 (CVE-2026-109618) と、リクエスト処理に関連する脆弱性 (CVE-2026-109619) の組み合わせです。悪用された場合、遠隔の第三者が任意のコードを実行する可能性があります。

PHP 開発チームは、次の修正版を 2026 年 10 月 21 日に公開し、速やかな更新を強く推奨しました。

使用している系列	PHP2shell 修正済みの最低バージョン	サポート上の注意
PHP 8.2	8.2.35	セキュリティサポートは 2026 年 12 月 31 日に終了予定
PHP 8.3	8.3.36	セキュリティサポートは 2027 年 12 月 31 日までの予定
PHP 8.4	8.4.27	セキュリティサポートは 2028 年 12 月 31 日までの予定
PHP 8.5	8.5.12	セキュリティサポートは 2029 年 12 月 31 日までの予定
PHP 8.1 以前	系列ごとに要確認	PHP 公式の通常サポートは終了。移行や提供元の延長サポートを確認

出典：PHP 公式の 2026 年リリース情報、および日本の情報処理推進機構による注意喚起。[1][2][4][5] これは修正済みかどうかを確認するための最低バージョンです。実際の適用時には、利用している配布元・OS・ホスティング事業者が提供する最新の修正版も確認してください。

PHP2shell はサポート中の系列でも修正前なら影響を受ける問題です。サポートが終了した古い系列では状況はさらに深刻です。脆弱性の調査に関与したセキュリティ企業 Wiz は、PHP 5.4 以降のバージョンでは、2 件の脆弱性の少なくとも一方の影響を受けると報告しています。サポートが終了した古い系列では、今回の脆弱性に対する PHP 公式の修正が提供されません。そのため、通常のパッチ適用では解決できず、サポート対象への移行などが必要になる場合があります。

2026 年 10 月 26 日、CISA は両脆弱性を「Known Exploited Vulnerabilities (KEV) Catalog」に追加しました。これは、脆弱性が実際の攻撃で悪用されていることを示す重要な注意情報です。一方、日本の情報処理推進機構は10月27日時点で、日本における PHP2shell の攻撃被害を把握していないと発表しています。[2][7]

「日本で被害が確認されていない」ことを、対策を先送りする根拠にしてはいけません。

ここから経営陣が読み取るべきこと

重大な脆弱性が公表されると、現場は影響するシステムの特定、修正の適用、動作確認、切り替えなどを短期間で進めなければならない場合があります。それらを実行するには、技術的な作業だけでなく、業務側の協力、停止や切り替えの承認、予算や人員、委託先との責任分担が必要です。

したがって、脆弱性対応をエンジニアに「更新しておいて」と指示するだけでは不十分です。経営・管理側には、必要な対応を優先できる意思決定の仕組みと、実行に必要な資源を用意する責任があります。

3. 多層防御の観点から考えるセキュリティの現実

セキュリティの基本の一つは 多層防御 です。家に例えるなら、玄関に頑丈な鍵を付けても、裏口や窓が開いたままでは安全とは言えません。また、今日侵入されなかったからといって、明日も安全だとは限りません。

サポート切れの PHP を使い続けることは、弱点が残っているのに、その弱点を修正する手段が限られている状態に似ています。外部からアクセスできる Web サイトでは、攻撃者が脆弱な環境を探し続けている可能性を前提に、弱点を減らす必要があります。

防御の層	具体的な対応	できること・限界
更新・保守	PHP 本体、CMS・フレームワーク・プラグイン・ライブラリをサポート対象に保つ	脆弱性の修正が基本。更新後の動作確認も必要
公開範囲の制限	不要なサービスを閉じる。管理画面などへのアクセスを制限する	攻撃可能な範囲を減らせるが、修正の代わりにはならない
検知・監視	アクセスログ、不審なファイル、予期しない通信、未知のアカウントなどを確認する	不審な活動の発見に役立つが、監視だけで侵害を防げるわけではない
バックアップ・復旧	バックアップを保護し、復元と再構築の手順を実際に試す	被害後の復旧を助ける。バックアップが存在するだけでは復旧可能とは限らない
インシデント対応	影響範囲の調査、証拠保全、認証情報の更新、復旧判断を行う	侵害が疑われる場合に、単純な再起動やパッチ適用だけで済ませない

どの対策も、サポート切れのソフトウェアを放置する理由にはなりません。ネットワーク側の制限や監視の強化は一時的なリスク低減に役立つことがありますが、長期的な安全を保証するものではありません。暫定対策と並行して、サポート対象の環境へ移行する計画を立てる必要があります。[2][6][8]

4. 経営陣・管理者層が今すぐ確認すべきこと

PHP の更新・移行を現場任せにしないために、組織として次の項目を確認してください。最初からすべてを一度に解決できなくても、責任者と期限を決めて可視化することが重要です。

優先度	確認事項	求める成果物・決定事項	主な責任者
最優先	PHP2shell の影響を受けるシステムがあるか	稼働バージョン、公開状況、修正状況の一覧	システム管理者・保守委託先
最優先	管理対象の Web システムを把握しているか	公式サイト、採用・キャンペーン・ブランド別サイト、サブドメイン、委託先管理サイトを含む台帳	IT 責任者・各事業部門
高	サポート終了した PHP が残っていないか	バージョン、サポート期限、業務重要度、外部公開の有無	システム管理者
高	更新・移行の責任と期限が明確か	責任者、実施期限、検証担当、切り替え判断権限	IT 責任者・事業責任者
高	移行に必要な費用と人員を確保できるか	移行計画、予算、社内外の担当範囲	経営陣・管理者層
継続	更新後も保守を続けられるか	定期的なサポート期限レビュー、更新方針、復旧試験の記録	IT 責任者・システム管理者

1. PHP が使われているシステムを把握できているか

公式 Web サイトだけでなく、採用サイト、キャンペーンサイト、ブランド別サイト、グループ会社のサイト、古いサブドメイン、委託先が管理するシステムにも目を向けます。採用サイトやキャンペーンサイト、製品・ブランドサイト、子会社のサイト、古いサブドメイン、さらには外部の代理店やホスティングプロバイダーが管理しているシステムなども対象に含める必要があります。こうした資産は、それぞれ所有者や管理体制が異なる場合があります。また、WordPress、Drupal、Joomla をはじめとする広く利用されているコンテンツ管理システム (CMS) の多くで PHP が採用されているため、資産の棚卸しを行う際には、メインのランタイムだけでなく、アプリケーション本体やそれらが依存するコンポーネントまで含めて確認することが重要です。

W3Techs によるとサーバーサイドプログラミング言語の中で PHP が占めるシェアは約 70 % で、2 位を大きく引き離しての 1 位です。そのうちの 2 つに 1 つの Web サイトでサポート期限切れのバージョンが使われています。[3]

2. 実際に動いているバージョンを確認できているか

サーバー上のコマンドで確認した PHP のバージョンと、Web サイトのリクエストを処理している実行環境のバージョンが異なる場合があります。ホスティング事業者、クラウド事業者、保守委託先にも確認し、実際に稼働している環境を特定してください。

3. PHP2shell への影響と修正状況を確認したか

PHP 公式の注意喚起にある修正バージョンと利用環境を照合します。PHP 8.1 以前など、公式サポートが終了した系列については、パッチの提供を前提にせず、サポート対象への移行や対策済みの製品・サービスへの切り替えを検討してください。更新が完了するまでの間は、公開範囲の制限などの暫定策を検討し、それでも十分にリスクを下げられない場合は、外部からのアクセス遮断やサービスの一時停止も判断対象にします。[2]

4. 移行に必要な人員・予算・期限が決まっているか

「いずれ更新する」という方針だけでは、先送りを招きます。責任者、期限、予算、検証担当、停止や切り替えの判断権限を明確にしてください。古いシステムでは、改修の継続だけでなく、別製品への移行、機能縮小、公開終了や廃止も選択肢として比較する必要があります。[2]

5. 移行後も継続して保守できるか

一度だけ新しいバージョンに更新しても、次のサポート終了までに同じ問題が起きれば意味がありません。PHP と周辺ソフトウェアのサポート期限を定期的に確認し、更新を計画・検証・実施する体制を整えてください。保守できる人員や委託先を確保できないシステムは、使い続ける前提そのものを見直す必要があります。

まとめ: サポート切れは、技術部門だけの問題ではない

PHP のサポート切れは、単に「古いバージョンを使っている」という技術上の問題ではありません。修正されない脆弱性にさらされる可能性、攻撃を受けた場合の事業影響、更新・移行の費用、保守を担う人材の不足が重なった、組織的なリスクです。

PHP2shell が示すのは、サポート中のバージョンでも修正前のリリースなら緊急対応が必要になり得る一方、サポート終了したバージョンでは必要な修正を入手できない場合がある、という現実です。影響範囲を確認し、脆弱性を修正し、必要に応じて公開範囲を制限し、復旧できる状態を保つことを、日常の運用に組み込まなければなりません。

経営陣・管理者層に求められるのは、更新を現場に命じるだけでなく、そのための予算・人員・権限を確保し、移行が困難なシステムについては継続の是非を決めることです。現場のエンジニアには、稼働環境と依存関係を正確に把握し、リスクと選択肢を説明し、安全に更新・移行できる手順を整える役割があります。

「今も動いている」ことと「今後も安全に運用できる」ことは同じではありません。 サポート期限を確認し、リスクを評価し、必要な対応を実行すること。それが、顧客の信頼と事業の継続性を守るための出発点です。

参考資料・出典

以下の資料を、本文中の番号と対応させています。PHP のバージョンや脆弱性対応については、公開時にも必ず最新版を確認してください。

The PHP Group, “PHP 8.5.12 Released!”, “PHP 8.4.27 Released!”, “PHP 8.3.36 Released!”, “PHP 8.2.35 Released!”（2026年10月21日） — CVE-2026-109618 / CVE-2026-109619の説明、修正版および緊急更新の推奨。 PHP News Archive 2026
情報処理推進機構（IPA）「PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619：PHP2shell）」（2026年10月22日公開、10月27日更新）— 影響対象、修正バージョン、日本での被害把握状況、サポート切れバージョンへの対応方針。公式注意喚起
W3Techs Usage statistics of PHP for websites 28 October 2026.
The PHP Group, “Supported Versions” — PHP系列の通常サポートおよびセキュリティサポートの考え方、サポート対象系列。公式ページ
The PHP Group, “Unsupported Branches” — PHP 8.1以前など、サポート終了済み系列のEOL日と最終リリース。公式ページ
情報処理推進機構（IPA）「PHPの脆弱性（CVE-2024-4577）を狙う攻撃について」（2024年7月5日公開、7月12日更新）— 日本の複数組織における悪用とWebシェル設置に関する注意喚起。公式注意喚起
Cybersecurity and Infrastructure Security Agency（CISA）, “CISA Adds Two Known Exploited Vulnerabilities to Catalog”（2026年10月26日）— CVE-2026-109618およびCVE-2026-109619のKEVカタログ追加。公式告知
Cybersecurity and Infrastructure Security Agency（CISA）ほか, “#StopRansomware Guide” — バックアップ保護、復旧準備、対応計画に関する一般的な指針。 CISA Ransomware Guide

本記事のサポート状況および PHP2shell に関する記述は、2026 年 10 月 28 日時点の公開情報に基づいています。実際の対応では、利用環境の提供元が公表する最新情報と適用条件を確認してください。

PHP End-of-Life Is a Business Risk: What “PHP2shell” Reveals About Patch Responsibility

nabbisen — Wed, 28 Oct 2026 09:57:03 +0000

For websites, commercial services, and enterprise systems, support deadlines are not merely a technical concern. Leaving vulnerabilities unpatched is a management and operational challenge that can directly lead to business disruption, a loss of customer trust, and budgetary impact.

This article uses PHP as a case study to explain why the expiration of software support poses a business risk, and what lessons can be drawn from real-world instances where vulnerabilities were exploited. It also outlines the key points that management, administrators, and engineers on the front lines should verify.

While this article focuses on PHP—a prominent example of a server-side application engine—it is important to note that similar levels of caution, consideration, and proactive measures are required for all other software and infrastructure components.

Key takeaways for executives and managers

Key point	Why it matters to the organization	What to check first
End of support does not mean a system will stop running immediately	A system may continue to work while no further fixes are provided for its version	Installed PHP versions and their official support deadlines
A supported version can still be vulnerable before a fix is applied	Critical vulnerabilities such as PHP2shell can require urgent action even on supported branches	Whether each system is affected and whether the fixed release is installed
Upgrades are not an engineering-only task	Testing, business coordination, budget, and vendor responsibilities all matter	Named owners, deadlines, budget, and authority to approve a cutover
“We have not had an incident” is not proof of safety	Unknown systems and undetected compromise may remain	Asset inventory, logs, and recovery procedures

Background: PHP2shell and the risks of unsupported versions

On 21 October 2026, the PHP development team released security updates for two critical vulnerabilities that became known collectively as PHP2shell. If exploited, the flaws could allow an unauthenticated remote attacker to execute code. On 26 October, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added both vulnerabilities to its Known Exploited Vulnerabilities (KEV) Catalog, which lists vulnerabilities for which there is evidence of exploitation. [1][3]

The reporting picture continued to develop. In an update dated 27 October, Wiz Research said it had observed a limited number of related attempts in its telemetry but had not observed successful attempts in that telemetry as of publication. It also noted that partners had privately shared working exploits. A lack of observed success in one telemetry source should not be interpreted as proof that exploitation has not occurred elsewhere. [2]

PHP2shell is not exclusively an end-of-life problem. A supported PHP branch can still be vulnerable if it is running a release from before the fix.

Conversely, when a branch is no longer supported, a newly discovered vulnerability may not receive a fix from the PHP project. Organizations may then need to migrate to a supported release or establish whether their operating-system or hosting provider offers a separately maintained package and what that support covers. [1][4][5]

1. The risks of leaving old versions in place

Versions of PHP (or general-purpose software) are not supported indefinitely. The PHP project provides a period of active support followed by a period of security support. Once a branch reaches end of life (EOL), it is no longer supported by the PHP project. The application does not necessarily stop working on that date. That can make an unsupported installation easy to overlook: it appears to work normally even though its maintenance options have narrowed.

Check PHP’s support status

As of 28 October 2026, PHP 8.2 through 8.5 are within the PHP project’s supported branches. However, security support for PHP 8.2 is scheduled to end on 31 December 2026. Even organizations using a supported branch should know when its support window closes and plan the next upgrade before it becomes urgent.

PHP branch	End of official security support	Status as of 28 October 2026
PHP 5.6	31 December 2018	Unsupported
PHP 7.4	28 November 2022	Unsupported
PHP 8.0	26 November 2023	Unsupported
PHP 8.1	31 December 2025	Unsupported
PHP 8.2	31 December 2026	Supported, but security support ends soon
PHP 8.3	31 December 2027	Supported; plan the next migration
PHP 8.4	31 December 2028	Supported
PHP 8.5	31 December 2029	Supported

Sources: the PHP project’s Supported Versions and Unsupported Branches pages. [4][5] Some operating-system distributions, hosting providers, or commercial vendors may supply their own extended maintenance. Verify the terms, affected packages, and responsibility boundaries rather than assuming such coverage exists.

The main risks of continuing to run an unsupported version include:

Risk	What may happen	Business or management impact
No upstream fixes	A newly disclosed vulnerability may not receive an official fix for the branch	The organization may have to keep operating with a known, unresolved risk
Exposure to known weaknesses	Attackers may use public information and automated scanning to find vulnerable systems	Website defacement, data exposure, or business interruption may result
Related software becomes harder to update	An old PHP runtime may prevent upgrades to a CMS, framework, plugin, or library	Migration work becomes more expensive and options become more limited
Maintenance capability erodes	Documentation is missing, the original developer has left, or a maintenance contract has ended	Response time and cost increase further

Counting the number of published vulnerabilities in an old release is not, by itself, a sufficient risk assessment. Counts vary with the database and inclusion criteria. The management questions are more practical: Is the system supported? Can a fix be applied? Is there a team or vendor able to maintain it continuously?

Why old PHP installations are left behind

A system that continues to run can make its risks less visible. Updates are often postponed because a service is difficult to take offline, an upgrade might break old application code, or nobody remains who understands the original implementation. Postponement does not remove the risk; it can accumulate work until a migration becomes urgent.

=== RISK & IMPACT PATH ===

  [ PHP branch reaches end of support ]
                   |
                   v
  [ Upstream fixes may no longer be available ]
                   |
                   v
  [ Known weaknesses remain and related ]
  [ components become harder to update  ]
                   |
                   v
  [ Higher risk of compromise, interruption, ]
  [ and prolonged recovery                   ]

This diagram does not mean that end of support automatically leads to a compromise. It shows how the loss of upstream maintenance can narrow an organization’s options. The next oneshows how a managed migration can improve its position.

=== MIGRATION & MITIGATION PATH ===

  [ Inventory assets and plan migration ]
                   |
                   v
  [ Assign an owner, budget, and deadline ]
                   |
                   v
  [ Migrate to a supported release and maintain it ]
                   |
                   v
  [ Review residual risk regularly ]

2. What real incidents teach us about PHP vulnerability response

Case 1: Web shells associated with CVE-2024-4577

In July 2024, Japan’s Information-technology Promotion Agency (IPA), a public information-security organization, reported that CVE-2024-4577 had been exploited against multiple organizations in Japan and that web shells had reportedly been installed on affected web services. International advisories also reported active exploitation of the vulnerability.

A web shell is malicious code placed on a compromised web server to let an attacker issue commands or otherwise operate the server remotely. It can provide a foothold for further activity, including attempts to move into other systems or use the compromised server as infrastructure for attacks against others. The consequences may therefore extend beyond defacement of the original website.

This example does not mean that every old PHP installation will be compromised. It shows that a remotely reachable system with an exploitable flaw can become an entry point when the flaw is not fixed in time. CVE-2024-4577 had specific conditions: it affected certain PHP versions when running in CGI mode on Windows, particularly with Apache and particular code-page configurations. It did not affect every PHP deployment equally. As with any vulnerability, teams must verify the affected versions, operating system, and execution configuration rather than making assumptions based only on the language name. [6]

Case 2: PHP2shell—urgent fixes may be needed even on supported branches

PHP2shell comprises two vulnerabilities: CVE-2026-109618, associated with out-of-memory error handling, and CVE-2026-109619, associated with request processing and stale internal state. Successful exploitation could allow a remote, unauthenticated party to execute code.

On 21 October 2026, the PHP project released fixes in the following versions and strongly urged users to update.

PHP branch	Minimum release containing the PHP2shell fixes	Support note
PHP 8.2	8.2.35	Security support is scheduled to end on 31 December 2026
PHP 8.3	8.3.36	Security support is scheduled to end on 31 December 2027
PHP 8.4	8.4.27	Security support is scheduled to end on 31 December 2028
PHP 8.5	8.5.12	Security support is scheduled to end on 31 December 2029
PHP 8.1 and earlier	Check branch and vendor status	The PHP project no longer supports these branches; plan migration or verify separately maintained vendor support

Sources: PHP’s official 2026 release archive, the PHP support-status pages, and security research by Wiz. [1][2][4][5] These are minimum versions that include the fixes. Before deploying, check the current release supplied by the relevant operating-system distribution, hosting provider, or vendor.

Wiz Research reported that versions of PHP going back to 5.4 were affected by at least one of the two vulnerabilities. For unsupported branches, the PHP project’s normal release process does not provide the necessary fixes; a migration to a supported branch or a verified vendor-maintained product may therefore be required.

On 26 October 2026, CISA added both CVEs to its KEV Catalog. On 27 October, Wiz published an update describing the limited attempts seen in its telemetry, the absence of observed successful attempts in that telemetry at the time, and information from partners who had privately shared working exploits. These are different kinds of observations; organizations should follow current advisories and should not delay remediation while waiting for public reports of a successful attack against a particular target. [2][3][5]

What executives should take from these cases

When a serious vulnerability is disclosed, engineers may need to identify every affected system, apply a fix, test it, and arrange a cutover under time pressure. That work depends on more than technical skill: business teams may need to approve a maintenance window, vendors may need to coordinate, and staff and budget must be available.

It is therefore not enough to tell engineers to “apply the update.” Management must provide a decision-making process that allows urgent work to be prioritized and the resources needed to carry it out.

3. The reality of defense in depth

One of the basic principles of security is defense in depth. Think of a house: a strong lock on the front door does not make the house secure if a back door or window is left open. And the fact that no one broke in today does not guarantee safety tomorrow.

Continuing to run an unsupported PHP release is similar to leaving a weakness in place while having fewer options to repair it. For internet-facing systems, organizations should assume that vulnerable services may be discovered through ongoing scanning and reduce weaknesses wherever possible.

Layer of defense	Example actions	What it helps with—and its limits
Patching and maintenance	Keep PHP, the CMS, frameworks, plugins, and libraries on supported releases	Fixes known vulnerabilities; changes still need to be tested
Restricting exposure	Disable unnecessary services and limit access to administrative interfaces	Reduces attack surface, but does not replace patching
Detection and monitoring	Review access logs, unexpected files or accounts, and unusual network activity	Helps identify suspicious activity, but monitoring alone cannot prevent compromise
Backup and recovery	Protect backups and test restoration and environment-rebuild procedures	Supports recovery; having a backup does not prove it can be restored successfully
Incident response	Investigate scope, preserve evidence, rotate credentials when appropriate, and make a deliberate recovery decision	Avoids treating a suspected compromise as a problem that can always be solved by a restart or patch alone

None of these measures is a reason to leave unsupported software in place indefinitely. Network restrictions and stronger monitoring may reduce risk temporarily, but they do not guarantee long-term safety. Pair interim controls with a plan to migrate to a supported environment. [3][6][7]

4. What executives and managers should verify now

Do not leave PHP upgrades and migrations solely to the engineering team. The organization should make the following items visible, assign owners, and set deadlines. It may not be possible to resolve every issue immediately, but uncertainty should not be allowed to remain ownerless.

Priority	Question	Expected evidence or decision	Primary owner
Urgent	Is any system affected by PHP2shell?	List of installed versions, exposure, and patch status	System administrators and maintenance providers
Urgent	Do we know all the web systems we operate?	Inventory including corporate, recruitment, campaign, brand, subsidiary, subdomain, and vendor-managed sites	IT leadership and business units
High	Are unsupported PHP branches still in use?	Version, support deadline, business criticality, and internet exposure	System administrators
High	Are migration ownership and deadlines clear?	Named owner, target date, test lead, and cutover authority	IT and business service owners
High	Are people and budget available for migration?	Approved plan, funding, and responsibilities across internal teams and suppliers	Executives and managers
Ongoing	Can the system be maintained after the upgrade?	Regular support-lifecycle reviews, an update policy, and recovery-test records	IT leadership and system administrators

1. Do we know where PHP is used?

Look beyond the main corporate website. Include recruitment and campaign sites, product and brand sites, subsidiary sites, old subdomains, and systems maintained by external agencies or hosting providers. These assets may have different owners and maintenance arrangements. PHP is also used by many widely deployed content-management systems, including WordPress, Drupal, and Joomla, so inventory work should include the applications and their dependencies—not just the main runtime.

According to W3Techs, PHP accounts for approximately 70% of the market share among server-side programming languages, placing it firmly in first place—well ahead of the runner-up. One out of every two websites using PHP relies on a version that is no longer supported. [2][8]

2. Have we confirmed the version that actually serves requests?

The PHP version reported by a command-line shell may differ from the version used to handle web requests. Confirm the runtime in the actual hosting environment with the cloud provider, hosting company, or maintenance vendor. Do not rely on a version number observed on one machine if the service uses multiple instances or execution environments.

3. Have we checked PHP2shell exposure and patch status?

Compare the running environment with the affected and fixed versions in PHP’s official advisory. For PHP 8.1 and earlier, do not assume that an upstream patch will be available: verify the support status and plan to migrate to a supported release or a product with clearly documented maintenance. Until the update is complete, consider appropriate interim controls, including restricting exposure. If effective controls cannot be put in place, management may need to consider blocking external access or temporarily suspending the service, based on potential harm and business impact. [1][3][4][5]

4. Are resources, deadlines, and decision authority in place?

A statement such as “we will upgrade eventually” invites further delay. Name an accountable owner and set a deadline, budget, testing responsibility, and authority to approve a shutdown or cutover. For a legacy system, compare continued maintenance with other options: refactoring, replacing the product, reducing functionality, ending public access, or retiring the system. The decision should reflect the system’s current business purpose and whether it can be maintained safely. [3]

5. Can we continue maintaining the system after migration?

A one-time upgrade is not enough if the same problem returns at the next end-of-support date. Track the support lifecycles of PHP and its dependencies, and establish a repeatable process for planning, testing, and deploying updates. If no internal team or supplier can maintain a system, reconsider whether it should continue to operate at all.

Conclusion: End of support is not just an IT problem

PHP end of life is not merely a technical issue of running an old version. It is an organizational risk involving potential exposure to unpatched vulnerabilities, the business impact of an attack, the cost of upgrades and migration, and the availability of people able to maintain the system.

PHP2shell demonstrates two realities: even a supported branch may require urgent action when a vulnerable release is in use, while an unsupported branch may not receive the fixes needed to address the problem. Organizations need to identify affected assets, apply the appropriate fixes, restrict exposure when necessary, and maintain a credible recovery capability as part of normal operations.

Executives and managers should not simply instruct engineers to upgrade. They must provide budget, people, authority, and a clear decision for systems that are difficult to migrate. Engineers, in turn, need to identify the actual runtime and its dependencies, explain risks and options, and establish safe procedures for updating and migration.

“It still runs” does not mean “it can be operated safely in the future.” Knowing the support deadline, assessing the risk, and acting on it are essential steps in protecting customer trust and business continuity.

References

The source list below supports the numbered citations in the article. Recheck official advisories and vendor release notes before publishing or acting on this information.

The PHP Group, “PHP 2026 News Archive” — Security releases dated 21 October 2026 for PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12, addressing CVE-2026-109618 and CVE-2026-109619. Official PHP release archive
Wiz Research, “PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet” (21 October 2026), and “PHP2Shell: Exploitation Attempts and Remediation Trends” (27 October 2026) — Vulnerability research, affected-version analysis, and observed exploitation activity. Initial research · Follow-up on observed activity
Cybersecurity and Infrastructure Security Agency (CISA), “CISA Adds Two Known Exploited Vulnerabilities to Catalog” (26 October 2026) — Addition of CVE-2026-109618 and CVE-2026-109619 to the KEV Catalog. CISA announcement
The PHP Group, “Supported Versions” — PHP’s active-support and security-support lifecycle and current supported branches. Official support schedule
The PHP Group, “Unsupported Branches” — End-of-life dates and last releases for unsupported PHP branches. Official EOL list
Japan’s Information-technology Promotion Agency (IPA), “Attacks Targeting PHP Vulnerability CVE-2024-4577” (5 July 2024; updated 12 July 2024), alongside CERT-EU, “Vulnerabilities in PHP” (Security Advisory 2024-058, 13 June 2024) — Reporting on exploitation and web shells associated with CVE-2024-4577. IPA report (Japanese) · CERT-EU advisory (English)
CISA and partner agencies, “#StopRansomware Guide” — General guidance on backup protection, recovery preparation, and incident response. CISA guide
W3Techs Usage statistics of PHP for websites 28 October 2026.

The version-status and PHP2shell statements in this article reflect public information available as of 28 October 2026. For a specific deployment, confirm the latest release and support terms from the software, operating-system, hosting, or product vendor.