ペネトレーションテスト後の安全性判断で失敗する企業と成功する企業の差とは
福岡ECサイト株式会社
代表 鳥井 敏史
福岡ECサイト株式会社 代表 鳥井 敏史
ECサイト制作・AI検索対策の実務コンサルタント。15年以上にわたりECサイトの売上構造改善と集客設計を支援。売上改善・集客改善の実務支援を中心に企業のECサイト構造の再設計を行う。
専門分野
ECサイト制作 ECサイトリニューアル AI検索対策 SEO / コンテンツ設計ECサイト改善の主な実績
この記事の監修
福岡ECサイト株式会社 代表 鳥井 敏史
ペネトレーションテストで脆弱性が見つからないのに被害が発生する理由
ペネトレーションテストで脆弱性が検出されなかったのに、その後サイバー攻撃被害が発生する企業は意外と多いです。管理画面を確認したときに「テスト済み」というステッカーをもらったから安心している、そんな状況ではないでしょうか。
セキュリティ評価とは、脆弱性の有無を調べることではなく、ビジネス影響度の観点から組織全体のリスク優先順位を設計し、限られたリソースで最も危機的な状況を回避できる構造を作ることです。
ペネトレーションテストは「脆弱性を見つけるツール」です。しかし被害の大半は、脆弱性そのものではなく、脆弱性の放置期間、検出後の対応遅延、組織的な運用の欠落から発生します。つまり問題は「テスト結果」ではなく「テスト後の構造」にあります。現場ではここが見落とされがちですが、実はこのポイントで大きく差がつくところなんです。
セキュリティ評価の優先順位とは何か
セキュリティ対策における優先順位とは、費用対効果ではなく、ビジネス継続性への影響度で決まる概念です。福岡ECサイト株式会社のクライアント支援でも、このポイントで判断を誤る企業が目立ちます。
セキュリティ評価の優先順位は「脆弱性の深刻度→組織への影響範囲→検出から対応までの時間」の3つの軸で判断します。多くの企業がこのうち脆弱性の深刻度だけを見ているため、実際の被害リスクを見誤っています。
例えば、重大な脆弱性が見つかったとしても、その脆弱性が利用されるまでに検出・修正できる時間があれば、リスクは低下します。 一方で、軽微な脆弱性でも、検出から放置される期間が1年続けば、その間ずっと攻撃機会が存在することになります。 つまり、セキュリティリスクは「脆弱性の種類」ではなく「脆弱性が存在する期間と組織の気付く仕組み」で決まるのです。
セキュリティ評価を誤る4つの構造的理由
ペネトレーションテストで脆弱性が見つからないのに被害が発生するケースは、以下の4つの構造的問題から生じます。
- テスト範囲の限定 ペネトレーションテストは通常、外部からアクセス可能な範囲に限定されます。しかし実際の被害は、社内システムのアクセス権限の悪用、外注先の不正アクセス、クラウドストレージの誤った公開設定など、テスト範囲外の領域から発生することが多いです。GA4を見ているだけでは全体のアクセスパターンが見えないのと同じ問題です。
- 運用プロセスの欠落 脆弱性は検出されてから修正・確認されるまでの期間に被害が発生します。テスト実施後、修正が完了するまで平均30日要するという現場データもあります。つまり「テスト完了＝安全」ではなく、修正完了まで脆弱性は存在し続けるのです。Slack上での報告で終わっていないか、修正予定が曖昧になっていないか、チェックが必要です。
- 人的操作への対応がない 脆弱性の大半は技術的な穴ですが、被害のきっかけは人的操作の誤りが占めます。強力なパスワードを使っているはずなのに、メモ書きされていたり、退職者のアカウントが削除されていなかったり、MFA（多要素認証）が導入されていなかったり。ペネトレーションテストではこうした運用プロセスまでは評価されません。
- 検出後の対応速度が設計されていない 新しい脆弱性は毎日検出されます。その脆弱性情報が組織に到達してから、実際に対応が始まるまでの期間が長いほど、被害リスクは高まります。Search Consoleで問題が報告されてから確認するまでに1週間かかっているなら、セキュリティ情報でも同じペースになっていないでしょうか。
CVR優先順位理論をセキュリティに適用する考え方
福岡ECサイトで提唱している「CVR優先順位理論」は、実はセキュリティ評価にも応用できます。この理論では改善順序を「導線→商品→信頼→集客」と定めますが、セキュリティでも同じロジックが成立します。
セキュリティの優先順位は「組織レベルの基本構造→データ保護の仕組み→検出と対応体制→攻撃情報の取得」の順で対応すべきです。多くの企業は順番を無視して、最新の攻撃対策ツール（集客に相当）を導入しているため、基本構造が整わないまま施策だけが増え、複雑化と疲弊が生じています。ここ、意外と見落としがちですが重要なポイントです。
| 従来のセキュリティ評価 | CVR優先順位で判断するセキュリティ評価 |
|---|---|
| 脆弱性の深刻度スコアで優先順位を決める | 組織に与えるビジネス影響度で優先順位を決める |
| 見つかった脆弱性から対応を開始する | 対応できる体制が整ってから検査スコープを拡大する |
| セキュリティツールの導入を増やす | 検出→報告→対応→確認の運用プロセスを整える |
| IT部門の責任として扱う | 経営判断が必要な領域として経営層を巻き込む |
つまり、ペネトレーションテストの前に「本当に対応できる体制があるのか」「修正後の確認プロセスはあるのか」を確認すべきです。受け口がない状態で脆弱性情報を集めれば、それは対応負荷を増やすだけになります。
セキュリティ評価の構造は3つの層で成立する
効果的なセキュリティ評価は、3つの層に分けて考える必要があります。ペネトレーションテストはこのうち1つの層にすぎず、その他の層がなければ被害は防げません。
- 予防層：脆弱性が入り込まない仕組み 開発段階でのセキュアコーディング、アーキテクチャの設計、アクセス権限の最小化。ここが弱いと、テストを何度やってもイタチごっこになります。
- 検出層：脆弱性と異常なアクセスを見つける仕組み ペネトレーションテスト、ログ監視、異常検知システムがここに該当します。ただしテストだけでは不十分で、日常的な監視体制が必要です。
- 対応層：見つかった脆弱性に迅速に対応する仕組み 責任者の明確化、修正期限の設定、修正完了の確認、再検証。ここが一番手薄になりやすい領域です。
多くの企業は「検出層」にお金をかけます。 最新のペネトレーションテスト、高度な監視ツール。 ただ実際の被害を防ぐには「予防層」と「対応層」が8割を占めます。 対応体制がない状態で、より多くの脆弱性を検出すれば、それは混乱と後手対応を招くだけです。これ、実際の現場でよくある状況なんですが、避けるべき判断ミスですね。
福岡ECサイト株式会社が支援した事例：ペネトレーションテスト後の体制構築
BtoBオンラインサイトの運営企業は、セキュリティ診断で「高リスク脆弱性なし」という結果を得ていました。しかし3ヶ月後、不正アクセスによるデータ流出が発生しました。原因を調査すると、テスト後の修正プロセスが組織に存在していなかったのです。
検出された脆弱性は報告されたものの、誰が修正するのか、期限はいつなのか、修正後どう確認するのかが決まっていない。結果として、緊急度の低い脆弱性から修正が進み、中程度のリスクは後回しになり、放置されていました。
対応としては以下の構造を設計しました。
- セキュリティ情報の受信から報告までを24時間以内に完了する
- 脆弱性を「即座対応（24時間以内）」「1週間以内」「30日以内」に分類し、対応予定を事前に決める
- 修正完了後の確認テストをセキュリティ担当者が実施（IT部門だけではなく）
- 月1回の経営層へのセキュリティレポートで進捗を可視化する
この体制整備によって、脆弱性の平均対応期間は90日から14日に短縮されました。重要なのはここです。
