ペネトレーションテストと脆弱性スキャンの違い

購買担当者は「ペネトレーションテスト」と「脆弱性スキャン」を同じ意味の言葉として耳にすることがよくあります。しかし、両者は異なります。脆弱性スキャンは、既知の弱点のデータベースとシステムを照合する自動チェックです。ペネトレーションテストは、スコープを定めた人手主導の作業であり、テスト担当者が合意した対象に対して弱点を実際に悪用できるかを検証し、その証跡を記録します。どちらも有用です。適切な選択は、答えを得たい問い、環境の成熟度、そして結果を誰が読むかによって決まります。

何であるのか

脆弱性スキャンは、ホスト、Webサイト、アプリケーションに対してツールを実行し、認識できる問題を報告します。たとえば、未適用のパッチ、古いソフトウェアバージョン、公開されたサービス、脆弱なTLS設定、一般的な設定ミスなどです。スキャンは高速で繰り返し実行できるため、定期的な衛生管理に適しています。その限界もよく知られています。スキャナーは誤検知を生み、ビジネスロジックに依存する問題を見逃し、低評価の指摘事項が他の指摘事項と組み合わさることで深刻化するかどうかを判断できません。ペネトレーションテストは、書面のスコープと実施ルール（Rules of Engagement）から始まります。テスト担当者はスキャナーを含むツールを使用しますが、その後は手作業で進めます。指摘事項の検証、認証と認可のテスト、ロールやテナントの分離状況の確認、攻撃者が試みうる現実的な経路の追跡などです。成果物は、ツール出力の生の一覧ではなく、証跡、深刻度、是正のガイダンスを含む報告書です。要するに、スキャンは「問題がありそうな箇所」を示し、ペネトレーションテストは合意したスコープ内で「実際に問題があると示せる箇所」とその重要性を示します。

誰のために

この比較は、次のようなチームに役立ちます。

顧客、パートナー、保険会社から「セキュリティテスト」を求められ、実際に何を求められているのかを理解する必要がある
すでに定期的なスキャンを実施しており、手動テストが有意義な知見を加えるかを知りたい
新しいWebアプリケーション、API、モバイルアプリをリリースする予定で、リリース前テストをどこまで深く行うかを決める必要がある
「テスト」の見積もり2件で作業量と成果物が大きく異なる理由を経営陣に説明する必要がある

明確にするのに役立つこと

両者を並べて読むことで、次の点が明確になります。

問いが既知の問題の衛生管理（スキャン）なのか、特定システムにおける悪用可能なリスク（ペネトレーションテスト）なのか
既存のスキャン報告書のうち、どの指摘事項がノイズである可能性が高く、どれが手動での検証に値するか
ビジネスロジック、アクセス制御、多段階の攻撃経路が、自動ツールで通常検出できる範囲の外にあること
関係者が最終報告書でどのような証跡を期待するか

含まれる内容

スキャンのチェックリスト：対象資産の一覧を定義し、定期的にスキャンを予定し、結果のトリアージ担当者を割り当て、是正状況を継続的に追跡する
ペネトレーションテストのチェックリスト：作業開始前に、対象、環境、テスト期間、アクセス方法、指名連絡先、停止条件を書面で合意する
システム所有者、およびスコープ内のシステムを運用するホスティング事業者やサプライヤーから書面による許可を得る
アクセス制御の問題を検証できるよう、認証付きテスト（ロールごとのテストアカウント）が必要かを判断する
指摘事項の評価方法と、指名連絡先との間で証跡を安全に共有する方法を合意する
是正後に修正済みの指摘事項を確認できるよう、再テストの期間を計画する

含まれていないもの

スキャンだけでアプリケーションの安全性が示せるという主張
ペネトレーションテストがあらゆる弱点を発見するという主張（合意した時間内で合意したスコープを検証するものです）
悪用手順の提供、または所有していない、もしくはテストの許可がないシステムのテスト
認証、コンプライアンス上の承認、正式な監査意見

それを選ぶべきとき

多数の資産を定期的かつ広範に把握する必要があり、報告結果をトリアージして修正するプロセスがある場合は、スキャンを選択してください。特定のシステムが事業にとって重要な場合、顧客やパートナーから手動テストの証跡を求められた場合、大規模なリリースの前、あるいは認証、決済、データ処理に大きな変更を加えた後には、ペネトレーションテストを選択してください。多くの組織は両方を活用しています。定期的なスキャンで衛生状態を安定させ、定期的なペネトレーションテストで最もリスクの高いシステムを検証します。資産や担当者をまだ一覧化できていない場合は、どちらよりも先に、より広範なベースラインレビューを行う方が有用な第一歩となる場合があります。

私たちのアプローチ

まず、下すべき判断から始めます。顧客の質問票が年1回のペネトレーションテストを求めている場合、スキャン報告書では通常それを満たせません。インターネットに公開されたサーバーにパッチが適用されているかを知りたいだけであれば、本格的な手動テストは必要以上かもしれません。次に、スコープを確定します。どのアプリケーション、API、環境、ユーザーロールを含め、どれを明示的に除外するかです。テスト期間と、作業を一時停止できる担当者を合意します。当社のPenetration Testing サービスはこの流れに沿っています。スコープ設定、書面による許可、合意した実施ルールの範囲内でのテスト、優先順位付きの是正ガイダンスを含む指摘事項報告書、報告会、そして含まれている場合は合意した指摘事項の再テストです。どの事業者を利用する場合でも、契約前にサンプル報告書の提示を求め、検証済みの指摘事項と参考情報としての所見が区別されているかを確認してください。最後に、是正のための時間を確保してください。誰も修正する時間がない指摘事項を生むだけのテストはほとんど価値を生まないため、テスト日程をチームが結果に対応できる体制に合わせて設定してください。

Penetration Testing サービス

Penetration Testingのサービスページを見る