認可された用途のみ: このスキルは、認可されたセキュリティ評価、防御的検証、または管理された教育環境でのみ使用してください。

Pentest チェックリスト

目的

ペネトレーションテストの計画、実行、およびフォローアップのための包括的なチェックリストを提供します。徹底的な準備、適切なスコープ設定、および発見された脆弱性の効果的な修復を確保します。

入力/前提条件

• テストの明確なビジネス目標
• ターゲット環境情報
• 予算とタイムラインの制約
• ステークホルダーの連絡先と認可
• 法的合意とスコープドキュメント

出力/成果物

• 定義されたペネストのスコープと目標
• 準備されたテスト環境
• セキュリティ監視データ
• 脆弱性の調査結果報告書
• 修復計画と検証

コアワークフロー

フェーズ 1: スコープ定義

目標を定義する

• テストの目的を明確にする - 目標を決定する (脆弱性の検出、コンプライアンス、顧客保証)
• ペネテストの必要性を検証する - ペネトレーションテストが適切なソリューションであることを確認する
• 成果を目標と調整する - 成功基準を定義する

参照質問:

• このペネテストをなぜ実施するのか?
• 具体的にどのような成果を期待するのか?
• これらの調査結果をどう活用するのか?

テスト種別を理解する

種別	目的	スコープ
外部ペネテスト	外部攻撃面を評価	公開向けシステム
内部ペネテスト	インサイダー脅威リスクを評価	内部ネットワーク
Web アプリケーション	アプリケーション脆弱性を検出	特定アプリケーション
ソーシャルエンジニアリング	人的セキュリティをテスト	従業員、プロセス
レッドチーム	完全な敵対者シミュレーション	組織全体

起こり得る脅威を列挙する

• 高リスク領域を識別する - どこで被害が発生する可能性があるか?
• データの機密性を評価する - どのデータが危険にさらされる可能性があるか?
• レガシーシステムを確認する - 古いシステムには脆弱性があることが多い
• 重要資産をマップする - テスト対象の優先順位を付ける

スコープを定義する

• スコープ内システムをリストする - IP、ドメイン、アプリケーション
• スコープ外項目を定義する - 回避すべきシステム
• テスト境界を設定する - どのようなテクニックが許可されるか?
• 除外を文書化する - サードパーティシステム、本番データ

予算計画

要因	検討事項
資産価値	より高い価値 = より高い投資
複雑性	より多くのシステム = より多くの時間
必要な深さ	徹底的なテストはより多くのコストがかかる
評判価値	ブランド名の企業はより高いコストがかかる

予算の現実チェック:

• 廉価なペネテストはしばしば貧弱な結果をもたらす
• 予算を資産の重要性に合わせる
• 継続的テストと一回限りのテストを検討する

フェーズ 2: 環境準備

テスト環境を準備する

• 本番環境対ステージング環境の決定 - テスト場所を決定する
• テスト制限を設定する - 本番環境への DoS なし
• テストウィンドウをスケジュールする - ビジネス影響を最小化する
• テストアカウントを作成する - 適切なアクセスレベルを提供する

環境オプション:

本番環境  - 現実的だがリスキー
ステージング環境 - より安全だが本番環境と異なる可能性あり
クローン     - 理想的だがリソース集約的

予備スキャンを実行する

• 脆弱性スキャナーを実行する - 既知の問題を最初に検出する
• 明らかな脆弱性を修正する - ペネテスト時間を無駄にしない
• 既存の問題を文書化する - テスターと共有する

一般的な事前スキャンツール:

# ネットワーク脆弱性スキャン
nmap -sV --script vuln TARGET

# Web 脆弱性スキャン
nikto -h http://TARGET

セキュリティポリシーを確認する

• コンプライアンス要件を確認する - GDPR, PCI-DSS, HIPAA
• データ処理ルールを文書化する - 機密データ処理手順
• 法的認可を確認する - 書面による許可を取得する

ホスティングプロバイダーに通知する

• プロバイダーポリシーを確認する - どのようなテストが許可されるか?
• 認可リクエストを提出する - AWS, Azure, GCP の要件
• 承認を文書化する - 記録を保管する

クラウドプロバイダーのポリシー:

• AWS: https://aws.amazon.com/security/penetration-testing/
• Azure: https://docs.microsoft.com/security/pentest
• GCP: https://cloud.google.com/security/overview

開発を凍結する

• テスト中のデプロイを停止する - 一貫した環境を維持する
• 現在のバージョンを文書化する - システム状態を記録する
• 重大なパッチを避ける - セキュリティ緊急時以外

フェーズ 3: 専門知識の選定

有資格のペネテスターを探す

• 推奨を求める - 信頼できる情報源に相談する
• 認資格を検証する - OSCP, GPEN, CEH, CREST
• 参考資料を確認する - 以前のクライアントと話す
• 専門知識をスコープに合わせる - Web、ネットワーク、モバイル専門家

評価基準:

要因	質問
経験	業界での年数、類似プロジェクト
方法論	OWASP, PTES, カスタムアプローチ
レポート	サンプルレポート、詳細レベル
コミュニケーション	可用性、更新頻度

方法論を定義する

• テスト標準を選択する - PTES, OWASP, NIST
• アクセスレベルを決定する - ブラックボックス、グレーボックス、ホワイトボックス
• テクニックに合意する - 手動テスト対自動テスト
• コミュニケーション スケジュールを設定する - 更新とエスカレーション

テストアプローチ:

種別	アクセスレベル	シミュレート対象
ブラックボックス	情報なし	外部攻撃者
グレーボックス	部分的アクセス	アクセスが制限されたインサイダー
ホワイトボックス	完全アクセス	インサイダー/詳細監査

レポート形式を定義する

• サンプルレポートを確認する - 品質がニーズを満たすことを確認する
• 必須セクションを指定する - エグゼクティブサマリー、技術詳細
• 機械可読出力をリクエストする - 追跡用 CSV, XML
• リスク評価に合意する - CVSS、カスタムスケール

レポートに含まれるべき内容:

• 経営陣向けのエグゼクティブサマリー
• エビデンス付きの技術的調査結果
• リスク評価と優先順位付け
• 修復の推奨事項
• 再テストガイダンス

フェーズ 4: 監視

セキュリティ監視を実装する

• IDS/IPS をデプロイする - 侵入検知システム
• ログを有効にする - 包括的な監査証跡
• SIEM を構成する - 一元化されたログ分析
• アラートをセットアップする - リアルタイム通知

監視ツール:

# セキュリティログを確認
tail -f /var/log/auth.log
tail -f /var/log/apache2/access.log

# ネットワークを監視
tcpdump -i eth0 -w capture.pcap

ログを構成する

• ログを一元化する - すべてのシステムから集約する
• 保持期間を設定する - 分析用ログを保管する
• 詳細ログを有効にする - アプリケーションおよびシステムレベル
• ログ収集をテストする - すべてのソースが機能していることを確認する

監視対象の主要ログ:

• 認証イベント
• アプリケーションエラー
• ネットワーク接続
• ファイルアクセス
• システム変更

例外ツールを監視する

• エラー率を追跡する - 異常なスパイクはテストを示す
• オペレーションチームに説明する - テストと攻撃を区別する
• ベースラインを文書化する - 通常対ペネテスト活動

セキュリティツールを監視する

• IDS アラートを確認する - ペネテストと実際の攻撃を分離する
• WAF ログを監視する - ブロックされた試行を追跡する
• エンドポイント保護を確認する - アンチウイルス検出

フェーズ 5: 修復

バックアップを確保する

• バックアップの整合性を確認する - 復元をテストする
• 復旧手順を文書化する - 復元方法を知る
• バックアップアクセスを分離する - テストから保護する

修復時間を予約する

• チームの可用性を割り当てる - ペネテスト後の分析
• 修正実装をスケジュールする - 調査結果に対応する
• 検証テストを計画する - 修正が機能することを確認する

テスト中のパッチポリシー

• 一般的にパッチを回避する - 一貫した環境を維持する
• 重大な問題の例外 - セキュリティ緊急時のみ
• 変更を通信する - 変更があればペネテスターに知らせる

クリーンアップ手順

• テスト成果物を削除する - バックドア、スクリプト、ファイル
• テストアカウントを削除する - ペネテスターのアクセスを削除する
• 構成を復元する - 元の状態に戻す
• クリーンアップが完全であることを確認する - すべての変更を監査する

次のペネテストをスケジュールする

• 頻度を決定する - 年次、四半期ごと、変更後
• 継続的テストを検討する - バグバウンティ、継続的評価
• 将来のテストに予算を確保する - 事前に計画する

テスト頻度の要因:

• リリース頻度
• 規制要件
• リスク許容度
• 過去の調査結果の重大性

クイックリファレンス

ペネテスト前チェックリスト

□ スコープが定義および文書化されている
□ 認可が得られている
□ 環境が準備されている
□ ホスティングプロバイダーに通知済み
□ チームが説明を受けている
□ 監視が有効化されている
□ バックアップが検証されている

ペネテスト後チェックリスト

□ レポートが受け取られ、確認されている
□ 調査結果が優先順位付けされている
□ 修復が割り当てられている
□ 修正が実装されている
□ 検証テストがスケジュールされている
□ 環境がクリーンアップされている
□ 次のテストがスケジュールされている

制約

• 本番環境テストは本質的なリスクを伴う
• 予算の制限は完全性に影響する
• 時間の制約はカバー範囲を制限する可能性がある
• テスターの専門知識は大きく異なる
• 調査結果はすぐに古くなる

例

例 1: クイックスコープ定義

**ターゲット:** 企業 Web アプリケーション (app.company.com)
**種別:** グレーボックス Web アプリケーションペネテスト
**期間:** 5 営業日
**除外:** DoS テスト、本番データベースアクセス
**アクセス:** 標準ユーザーアカウントが提供されている

例 2: 監視セットアップ

# 包括的なログを有効にする
sudo systemctl restart rsyslog
sudo systemctl restart auditd

# パケットキャプチャを開始
tcpdump -i eth0 -w /tmp/pentest_capture.pcap &

トラブルシューティング

問題	解決方法
スコープクリープ	文書化し、変更承認が必要
テストが本番環境に影響	オフピーク時にスケジュール、ステージング使用
調査結果が異議を唱えられる	詳細なエビデンスを提供、再テスト
修復が遅延	リスク別に優先順位、期限を設定
予算超過	明確なスコープを定義、固定価格契約

使用時期

このスキルは、概要で説明されているワークフローまたはアクションを実行するために適用できます。