ペネトレーションテストはどこまでやればいい？

こんにちは。ペネトレーションテストサービスの実査を担当している戸谷と、ペネトレーションテスト部門のマネージャーとしてセキュリティコンサルタント兼テクニカルコミュニケーターをしている川島です。

2020年11月に「脆弱性診断とペネトレーションテストの使い分け」についての情報発信を行ってから、約4年が経ちました。当時の「脆弱性診断とペネトレーションテストの違いがよくわからない」状況から、2025年現在の脆弱性診断やペネトレーションテストを取り巻く環境は少し変化している印象を受けます。具体的には、各種のセキュリティ基準や会社のルールなどで「脆弱性診断だけではなく、ペネトレーションテストを実施すること」というルールが定められているケースを多く目にするようになり、脆弱性診断とは異なるセキュリティテスト（以下、テスト）としてペネトレーションテストの実施を要求するケースが増加していることを感じます。

このような状況の中で、「何をどこまでやればペネトレーションテストを実施したことになるのか？」という質問をお客様からいただくことが増えてきました。本記事では、ペネトレーションテストを検討する際に知っておきたいギャップや、自組織にとって必要なテストが完了したと言える段階を詳しく解説します。

ペネトレーションテストの定義とは

結論からいうと、この質問に対する正解は存在しません。それはペネトレーションテストの具体的な定義や内容に関する統一的な基準や見解のようなものが、現時点で確立されていないためです。この曖昧さの結果、「ペネトレーションテスト」というキーワードから想起されるテスト内容は人によって異なります。そのため、実務におけるギャップが生じることもしばしばあります。

私たちはこれらを整理し、ペネトレーションテストの調査内容に応じて7つのレベルに分類しました。

レベル	内容	アプローチ
1	脆弱性スキャンツールによるテスト	ツールによるシグネチャベースの調査
2	脆弱性スキャンツールおよび手動の調査を併用するテスト	ツールで難しい領域を手動で調査
3	検出した脆弱性が実際に悪用可能かどうかをテスト	脆弱性を悪用し、対象システムへの「侵入」を試みる
4	検出した脆弱性を実際に悪用して何をどこまでできるのかのテスト	「侵入」後に何をどこまでできるか調査する
5	機密情報の窃取といった目的を定め、目的を満たせるか否かのテスト	攻撃者の目的を達成できるか調査する
6	機密情報の窃取といった目的を定め、目的を達成する原因となり得る問題点を洗い出すテスト	攻撃者の目的を達成する方法を可能な限り洗い出す
7	疑似攻撃に対するシステムの検知・対応能力のテスト ※ 脅威ベースのペネトレーションテスト（TLPT）を含む	インシデント対応など「レジリエンス※」の評価 ※ サイバー攻撃を受けた際に、被害を最小化する能力

上記の調査内容およびアプローチについて、ラックでは以下の表に示すような脆弱性診断およびペネトレーションテストを提供しています。

ラックをはじめ、さまざまなサービス事業者が脆弱性診断やペネトレーションテストに関するサービスを提供しています。しかし、「何をどこまでやればペネトレーションテストを実施したことになるのか？」という問いに答えるためには、まずはそれぞれのテストで何をどこまで実施するのか、それを実施することでどのような結果が得られるのかを知ることが必要です。以降でそれぞれのテストのアプローチについて解説します。

脆弱性診断でできること

レベル1：脆弱性スキャンツールによるテスト

脆弱性診断とペネトレーションテストの実施内容の違いを明確にするため、まずレベル1にあたる「脆弱性スキャンツールによるテスト」から解説します。脆弱性診断はその名の通り、ソフトウェアやアプリケーションの脆弱性を検出することを目的とした診断で、Webアプリケーションやミドルウェアを含むサーバなどのプラットフォームに対して実施します。

レベル1のテストでは、脆弱性スキャンツールを用いてシグネチャベースの調査を行い、既知の脆弱性を効率的に検出します。このような脆弱性には、対象のサーバへの侵入に悪用可能な脆弱性も含まれます。また、ミドルウェアを含むサーバなどを対象とするプラットフォーム診断では、脆弱性に加えてソフトウェアやアプリケーションの設定不備を検出することも可能です。

レベル2：脆弱性スキャンツールおよび手動の調査を併用するテスト

ツールのみで診断をする場合は、脆弱性があると誤って判定されるケースや、逆に脆弱性が見逃されるケースがときに発生します。

このような場合では、実際に人の目で診断結果を確認することが求められます。この人の目での確認作業を手動診断と呼ぶケースがあります。一方で、ツールはあくまでも補助的に使用し、手動での調査を中心に行う方法を手動診断と呼ぶこともあります。一概に「手動での脆弱性診断」といっても、サービス事業者によって手動で行っている作業の範囲が異なることが想定されるため、具体的にどのような作業を行っているかを確認することが重要です。

後者の手動での調査を中心に行う方法では、ツールでは検出が難しいアプリケーションの仕様に基づく脆弱性を検出する場合があります。例えば、ユーザAのアカウントでログインした後、ユーザBのアカウント情報を閲覧できる脆弱性のようなものが当てはまります。一般的なツールでの診断の場合、このような脆弱性の検出は困難です。なぜなら、「あるユーザのアカウントで別のユーザのアカウントを閲覧できてはいけない」というのは人間が決めた仕様（ルール）であり、ツールでは発生した動作がルールに沿った正しいものか、そうでないものかという判断は困難です。このような仕様に関する脆弱性の検出においては手動診断が有効であり、かつ診断員の技量も影響します。

レベル3：検出された脆弱性が実際に悪用可能かどうかのテスト

ペネトレーションテストに関するご相談では、「脆弱性診断で脆弱性を検出するだけではなく、検出した脆弱性が実際に悪用可能かどうか試してほしい」という要望をいただくことが多くあります。例えば、サーバなどのプラットフォームに対する診断で、OSコマンドの実行が可能と考えられる脆弱性を発見した場合、実際にOSコマンドを実行し、対象のホストに侵入できるかどうかの調査などが該当します。このような調査について、脆弱性診断の範疇に含まれるのか、ペネトレーションテストとして実施するのかで複数の見解が存在してきました。

近年では、クレジットカード会員情報の保護を目的とした国際統一基準であるPCI DSSの2022年3月にリリースされたv4.0のペネトレーションテストに関する項目にて「脆弱性のスキャンで見つかった脆弱性を利用しようとすることだけに焦点を当てた場合、侵入テストは適切とは言えない」という文言が追加される動きがあり、脆弱性診断の範疇で実施されるケースが多いと考えられます。

脆弱性診断とペネトレーションテストの境界

レベル4：検出された脆弱性を悪用して、何をどこまでできるのかのテスト

ラックでは、ペネトレーションテストを「現実的な攻撃シナリオを用いて攻撃者の目的達成可否を実証するテスト」と位置付けています。それをふまえると、レベル4の「検出された脆弱性を悪用して、何をどこまでできるのかのテスト」はまさに脆弱性診断とペネトレーションテストの境界にあると言えます。「検出された脆弱性を悪用して、何をどこまでできるのかのテスト」を明らかにするには、「何を」や「どこまで」の部分を具体的に考える必要があります。

ラックの「情報システムペネトレーションテスト エクスプレス」では、対象のシステムへの侵入に成功した攻撃者が行うと考えられる侵害行為の可否を調査します。侵害行為の例としては、ネットワーク上の他端末への侵入や権限昇格、特権の奪取などが挙げられます。ペネトレーションテストが「攻撃者の目的達成可否を実証するテスト」であるならば、特権の奪取などは攻撃者の目標となりうるものと考えられます。

また、「何を」に加え「どこまで」というのも重要な要素です。レベル1～3の脆弱性診断では、サーバやアプリケーション単体を対象として調査をします。一方で、「何をどこまでできるのか」を考えるときには、サーバ単体の内部でOSコマンドの実行や情報収集、権限昇格などといった侵害行為がどこまでできるのかという視点もあれば、あるいは他のサーバへの横断的侵害も含める視点もあります。さらに横断的侵害の対象となった他のサーバで、OSコマンドの実行や情報収集、権限昇格などといった行為が可能かを調査するような視点もあるでしょう。ここにも脆弱性診断とペネトレーションテストの境界が存在すると考えます。

ペネトレーションテストは「現実的な攻撃シナリオを用いた調査」として、その目的を達成するために攻撃者が取ると予測される手順を追い、実際の脅威に近づけます。しかし、現実の攻撃者は侵入に成功した最初のサーバに留まらず、目的の達成を目指して他のサーバへ侵害を拡大し、最終的にはシステム全体に対する制御を得ようとします。ペネトレーションテストの視点はサーバ1台1台のような単位ではなく、システム全体を対象とした視点が望ましいと言えます。

このような侵害拡大の視点や、システム全体に対する被害の視点をどれだけ反映させるかによって、ペネトレーションテスト寄りの脆弱性診断や、脆弱性診断寄りのペネトレーションテストにもなり得るのが、レベル4の「検出された脆弱性を悪用して、何をどこまでできるのかのテスト」です。

ペネトレーションテストの目的と使い方

レベル5：機密情報の窃取といった目的を定め、目的を満たせるか否かのテスト

ラックでは「①現実的な攻撃シナリオを用いること」、「②攻撃者の目的達成可否を実証すること」がペネトレーションテストを構成する要素であると考えています。それをふまえると「機密情報の窃取といった目的を定め、目的を満たせるか否かのテスト」はまさにペネトレーションテストであると言えそうです。

ペネトレーションテストについてお客様に説明する際、「目的を達成してしまったら、それで調査は終了なのか？」という質問をいただくことがあります。攻撃者の視点では、目的を達成したらそれでミッション完了です。では、あるべきペネトレーションテストの姿としてはどうでしょうか？

レベル6：機密情報の窃取といった目的を定め、目的を達成する原因となり得る問題点を洗い出すテスト

ラックとしては、ペネトレーションテストを実施する目的の1つに、「実際にサイバー攻撃を受けた際に悪用されると考えられるセキュリティ上の問題点を洗い出し、セキュリティ対策に活用すること」を挙げています。攻撃者の目的を達成した時点でテストを終了してしまうと、テスト自体の目的には不十分となってしまうことに注意が必要です。

攻撃者の目的が達成できたという結果だけが残っても、問題点を洗い出して対策を打たなければ、セキュリティの向上にはつながりません。ラックのペネトレーションテストでは、調査期間中に可能な限り目的達成に至るまでのセキュリティ上の問題点を洗い出しています。実際に、多くのお客様のシステムに対して実施したペネトレーションテストでは、目的達成のための経路を複数検出しています。

「目的達成のための経路」に関連して、脆弱性診断とペネトレーションテストの大きな違いについて説明します。脆弱性診断を実施した場合、アウトプットとして得られるのは検出した脆弱性の一覧です。一方で、ペネトレーションテストでは目的達成可否を含む攻撃の過程がまずアウトプットとして存在し、検出した脆弱性は攻撃の過程を構成する要素にあたります。

レベル7：疑似攻撃に対するシステムの検知・対応能力のテスト

ペネトレーションテストを実施する目的として、「サイバー攻撃を受けた際に、攻撃をどの程度検知・遮断できるかをペネトレーションテストで確認したい」という要望があります。サイバー攻撃の検知・対応能力をペネトレーションテストで調査する場合は、導入しているセキュリティ製品やサービスの単なる性能評価にならないように注意する必要があります。

例えば、端末にEDRを導入しており、このEDRによる検知や遮断を回避して攻撃ができるかを調査するようなケースです。端末でマルウェアを実行する攻撃手法を想定した場合は、攻撃シナリオに沿って調査をするペネトレーションテストよりは、端末でのマルウェア実行について数百種類、数千種類のパターンを試行するBAS（Breach Attack Simulation）のようなツールの方が効果的です。加えて、「検知できなかった」という結果となった場合に、どのように対策を進めればよいのかという問題も浮上します。

このため、検知・対応能力の調査にあたっては、セキュリティ製品やサービス単体ではなく、システムや組織全体で検知・対応できているかという視点が必要です。攻撃シナリオに沿って一連の流れを実行し、攻撃のどの部分が検知・遮断されたのか、またシステムの改善によりどの部分が検知・遮断が可能になるのかを検証することで、より実践的な対策をしやすくなります。

最後に

これらの実施内容の違いをふまえ、「ペネトレーションテスト」といったサービスの名称で判断するのではなく、自組織のシステムにどのようなテストが必要かを見極めることが重要です。冒頭でも触れたように、現時点では「ペネトレーションテスト」の定義に関する共通認識は確立されていません。そのため、いざ「ペネトレーションテスト」を依頼したつもりでも、実際には意図した内容と異なるサービスを受けてしまうことが発生しやすい状況です。特に、業界特有の要件や基準に沿ったテストが求められる場合、その認識のズレが顕著に現れることもあります。

PCI DSSの例のように、業界によっては「ペネトレーションテスト」として成立しているとみなす内容に関して、業界ガイドライン等も整備される動きがあります。こうした内容を把握し、どのようなテストが求められているのかを理解することが重要です。その上で、セキュリティベンダーとコミュニケーションを取り、要望を明確に伝えることが求められます。

本稿が、ペネトレーションテストを検討している皆様にとって、必要なテスト内容を整理する一助となれば幸いです。