導入
本記事は以下記事の続編としてを解説します。
この記事で得られること
- 侵入テスト結果を「経営判断につながるレポート」として整理・提示する実践的な考え方
- 技術的・管理的・運用的観点からの改善策を導出する手法
- 侵入テストにおける適切なコミュニケーションと、テスト完了後に求められる実務対応
⚠️ 注意（必読）
本記事で扱う内容は、悪用した場合、重大な法的リスクを伴います。
許可された演習環境・検証環境でのみ実施してください。
実在組織・個人への攻撃は禁止されています。
はじめに
侵入テストにおいて最終的な成果物はレポートです。
単なる脆弱性の一覧ではなく、経営層・技術者・運用担当者が、次の意思決定へ進むための技術文書として成立していることが求められます。
本記事では、CEH 9章「報告とコミュニケーション」に基づき侵入テストのレポート作成と改善策提示、コミュニケーション、契約後のオペレーションについて解説いたします。
1. レポートが果たす役割と構成（9.1）
■ レポートの前提：誰が読む文書なのか
侵入テストレポートは、 読者層（CISO / CIO / CSIRT / 開発 / インフラ / 運用） により期待される粒度が異なります。
そのため、最上位に「エグゼクティブサマリー」を配置し、経営層向けにリスクと推奨事項のみを簡潔に提示する構成が一般的です。
※自動スキャンツールにもレポート機能は存在しますが、誤検知の含有率が高く、そのまま提出できる品質ではない点には留意が必要です。
■ 一般的な侵入テストレポートの構成
テンプレートを基盤とし、テストスコープや成果物に応じて調整します。
代表的な項目は以下のとおりです。
- エグゼクティブサマリー
- スコープの詳細
- テスト方法
- 調査結果（CVSSベースの評価付）
- 改善策と推奨事項
- 結論
- 附録（ツール出力、PoC、スクリーンショットなど）
レポート例としては以下が参考になります：
https:／／github.com/The-Art-of-Hacking/art-of-hacking/tree/master/pen_testing_reports
■ CVSS評価の整理
CVSSは以下の3グループから構成され、組織におけるリスク優先順位付けに使用されます。
- 基本メトリック：攻撃難易度・権限要件・CIAへの影響
- 時間的メトリック：エクスプロイト成熟度、修正状況、レポート信頼性
- 環境メトリック：組織固有の資産価値や影響度
また、Webアプリケーションでは OWASP Risk Rating Methodology も併用されます。
■ レポートの安全な配布と管理
侵入テストレポートは機密度が極めて高く、取り扱いには厳格な管理が求められます。
● 配布・管理の要点
- 配布数を限定し、コピー番号・受領者IDを付与
- 配布ログ（配布日・配布方法）を保持
- ネットワーク配布時は、文書自体と転送経路の双方を暗号化
- 電子配布はより厳重に扱い、
依頼部門のセキュアサーバーへ1部のみ配置し、配布後はテスター側で全コピーを削除
■ メモ作成とドキュメント整理
テスト中から継続的にメモを取り、**使用ツール → 手順 → 出力 → 証跡（スクリーンショット）**の関係を残します。
大規模テストでは Dradis のような専用プラットフォームが有効です。
https://github.com/dradis/dradis-ce
■ 共通テーマと根本原因の抽出
ツールの出力のみでは、真のリスクは見えないため分析や確認が必要です。
例：
Nessus では FTP（Port21）が最新バージョンのため問題なしとされても、
外部から接続可能な経路が残存し、機密データ転送に利用されていた場合、深刻なビジネスリスクとなります。
このように、環境特有の脅威文脈・誤検知の排除・根本原因分析が不可欠です。
2. 調査結果の分析と改善策提示（9.2）
調査結果は「報告」で終わりではなく、改善可能な具体策に落とし込めるかが品質を左右する。
■ 技術的対策（Technical Controls）
● システム強化（Hardening）
- パッチ適用・不要サービス停止
- 不要ポート閉鎖、暗号化方式の強化
● 入力サニタイズ・パラメータ化
SQLi / XSS / Command Injectionの回避方法を明確に提示します。
参考：OWASP CheatSheet
https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
● 多要素認証（MFA）
パスワード単体の強化よりも効果の高い対策です。
● シークレット管理
- AWS Secrets Manager
-
Google Cloud Secret Manager
などの専用基盤を利用し、環境変数・Git等での漏洩を防止。
● ネットワークセグメンテーション
従来型の境界FW集中モデルではクラウド・ゼロトラスト時代に適応できない。
VM/コンテナ単位での マイクロセグメンテーション が主流。
● その他対策
- パスワードの暗号化
- プロセスの修復
- パッチ管理
- キーローテーション
- 証明書管理
■ 管理的対策（Managerial Controls）
- RBAC：役割単位で権限設計し例外を排除
-
セキュアSDLC：設計段階からのセキュリティ組み込み
(OWASP SAMM / SSDLC) - ポリシーと手順整備：What / Why にフォーカスし、How は運用に委ねる
■ 運用対策（Operational Controls）
- ジョブローテーション
- 勤務時間帯でのアクセス制限
- 強制休暇（不正の長期隠蔽を防止）
- セキュリティトレーニング
■ 物理的対策（Physical Controls）
- マントラップ（アクセス制御玄関ホール）
- 生体認証
- CCTV監視
3. 侵入テストにおけるコミュニケーション（9.3）
テスターとクライアント間のコミュニケーション品質は、レポート品質と同等に重要です。
■ コミュニケーショントリガー
-
重大事項の発見
（事前合意した報告タイミングで共有） -
ステータスレポート
進捗報告の要求に応じて提供 -
侵害の兆候検出
既存攻撃の痕跡を確認した場合、即時報告
■ コミュニケーションの原則
- 重複・誤検知の排除
- 犯罪行為の兆候は即時報告
- 目標変更の際はスコープクリープを防ぐための調整
- レポート後半ではエンジニア向けに PoC、ログ、挙動、再現手順を正確に記述
4. レポート提出後のクリーンアップ（9.4）
侵入テストでは、テスト実施によって環境に一時的な副作用を残す場合があります。
テスト完了後のクリーンアップは必須作業です。
■ クリーンアップ対象の例
- SQLインジェクション検証で生成された不要データの削除
- RCE手法確認でアップロードしたshellファイルの削除
- テスト用のアカウント、権限、ログ設定の復元
- テスト時に生成されたエラーログや検証用ファイルの除去
“何も残さず、元の状態へ戻す” ことは、
クライアントへの信頼維持に不可欠なプロセスです。
まとめ
本章で扱った内容は、侵入テストの最終工程における品質管理の中心領域です。
- レポートは「読まれる文書」として最適化する
- 調査結果を組織の改善行動へ接続する
- コミュニケーションでスコープ・進捗・重大事項を制御
- テスト後は環境を完全に復元する
これらを統合することで、侵入テストは単なる脆弱性検出作業から、
組織のセキュリティ成熟度向上に寄与するプロセスへと昇華 します。
📍 次回予告
次回は10章「ツールとコード分析」の内容を解説します。
長期にわたりましたが、次回で最終回予定です。
次の記事はこちら