ペネトレーションテスト報告書の内容と読み方

何であるのか

ペネトレーションテスト報告書は、何を、どのように、どのような条件でテストし、何が見つかったかを記録した文書です。報告書は2種類の読者が読めるものであるべきです。技術者ではない関係者には、全体的なリスク、最も重要な問題、推奨される優先順位を短くまとめた概要が必要です。技術チームには、各指摘事項を理解し、安全な環境で再現し、修正できるだけの詳細が必要です。優れた報告書は、自らの限界も記録します。スコープ外だったもの、テストできなかったもの、そしてテストアカウントが利用できなかった、テスト期間が短縮されたなど、網羅性に影響した条件です。こうした限界が示されていないと、読者は報告書が実際以上の範囲をカバーしていると思い込むおそれがあります。

誰のために

本ガイドは次のような方に役立ちます。

• 提案書を比較しており、実際にどのような成果物を受け取るのかを知りたい購買担当者
• 指摘事項を受け取り、是正を計画する必要があるエンジニアリングリーダー
• 結果を誇張することなく、顧客、パートナー、監査人、取締役会に概要を共有しなければならないマネージャー
• 以前に受け取った報告書が対応につなげにくかったチーム

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

想定される構成を知っておくと、次の点を確認できます。

• 報告書に記載されたスコープと実施ルールが合意内容と一致しているか
• 各指摘事項に証跡、明確な深刻度評価、実践的な是正ガイダンスがあるか
• どの問題に直ちに対応が必要で、どの問題を通常の開発サイクルに組み込めるか
• どの記述なら外部と安全に共有でき、どの記述は技術スタッフ内にとどめるべきか

含まれる内容

• エグゼクティブサマリー：全体像、最も重要な指摘事項、推奨される優先順位を平易な言葉で記載
• スコープと実施ルール：対象、環境、ユーザーロール、日付、テスト期間、除外事項
• 手法の概要：採用したアプローチと参照したフレームワーク（Webアプリケーション向けのOWASPガイダンスなど）
• 指摘事項一覧：各問題のタイトル、深刻度、影響を受ける資産、説明、証跡の参照、ビジネスへの影響
• 技術的詳細：チームが問題を理解し、安全に再現するための手順
• 是正ガイダンス：実践的な修正方法と、必要に応じた短期的な緩和策
• 制約事項：テストできなかったこととその理由
• 再テストの項：再テストが含まれる場合、チームが修正した後の合意済み指摘事項の状況

含まれていないもの

• テスト後にシステムが安全である、または脆弱性が残っていないという記述
• 合意したスコープ外の指摘事項を、テストしたかのように示すこと
• 認証、コンプライアンス上の承認、正式な監査意見
• 別途合意がない限り、修正の実装

それを選ぶべきとき

テストの提案書に署名する前に本ガイドをお読みください。サンプル報告書を求め、構成を確認できます。報告書が届いたときにも役立ちます。上記の各項目をチェックリストとして使い、欠けているものがないかを確認してください。関係者から「ペンテスト報告書を送ってほしい」と求められた場合は、相手に必要なのが技術文書の全文なのか、エグゼクティブサマリーと是正状況のレターなのかを事前に判断してください。技術的な詳細を広く共有すると、自社システムの弱点を説明することになるため、リスクが高まります。

私たちのアプローチ

テスト開始前に、深刻度の基準を明確にするよう求めてください。多くの事業者は発生可能性と影響に基づく尺度を使い、CVSSを参照することもあります。重要なのは、それが一貫しており、説明されていることです。証跡の保管・共有方法と、指名連絡先を誰にするかを合意してください。報告書が届いたら報告会を設定し、文脈が新しいうちに開発者が質問できるようにします。指摘事項一覧を、担当者と目標日を設定したチケットに落とし込み、深刻度の最も高い問題から修正してください。そのうえで合意済み指摘事項の再テストを依頼し、解決した内容を報告書に記録できるようにします。当社のPenetration Testing サービスでは、エグゼクティブサマリー、スコープと実施ルールの概要、証跡の参照付きで深刻度別に整理した指摘事項一覧、各指摘事項の技術的詳細、優先順位付きの是正ロードマップ、そして再テストが含まれる場合はその結果をお届けします。どの事業者を選ぶ場合でも、報告書の各版を保管し、修正せずにリスクとして受容した指摘事項とその判断者を記録してください。次に誰かから自社のセキュリティ状況を尋ねられたとき、その記録はテストそのものと同じくらい価値を持つことがよくあります。

Penetration Testing サービス

よくある質問

関連記事