Pentestチェックリスト

目的

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

入力/前提条件

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

出力/成果物

• 定義されたpentestのスコープと目標
• 準備されたテスト環境
• セキュリティモニタリングデータ
• 脆弱性検出レポート
• 改善計画と検証

コアワークフロー

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

目標の定義

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

参照質問:

• なぜこのpentestを実施しますか？
• どのような具体的な成果を期待していますか？
• 検出結果をどうしますか？

テストタイプを理解する

タイプ	目的	スコープ
外部Pentest	外部攻撃面を評価	公開されているシステム
内部Pentest	インサイダー脅威リスクを評価	内部ネットワーク
Webアプリケーション	アプリケーション脆弱性を発見	特定のアプリケーション
ソーシャルエンジニアリング	人的セキュリティをテスト	従業員、プロセス
Red Team	完全な敵対者シミュレーション	組織全体

潜在的な脅威を列挙

• 高リスク領域を特定 - どこで被害が発生する可能性がありますか？
• データ機密性を評価 - どのデータが侵害される可能性がありますか？
• レガシーシステムをレビュー - 古いシステムは脆弱性を持つことが多い
• 重要資産をマッピング - テスト対象に優先順位を付ける

スコープを定義

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

予算計画

要因	考慮事項
資産価値	より高い価値 = より高い投資
複雑さ	より多くのシステム = より多くの時間
必要な深さ	徹底的なテストはより多くのコストがかかる
評判価値	有名企業はより高い費用がかかる

予算の現実性確認:

• 安価なpentestはしばしば低品質の結果をもたらす
• 予算を資産の重要性に合わせる
• 継続的対 一回限りのテストを検討

フェーズ2: 環境準備

テスト環境を準備

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

環境オプション:

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

予備スキャンを実行

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

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

# ネットワーク脆弱性スキャン
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: 専門知識の選択

認定されたPentesterを見つける

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

評価基準:

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

方法論を定義

• テスト標準を選択 - PTES, OWASP, NIST
• アクセスレベルを決定 - Black box, gray box, white box
• テクニックに合意 - 手動対自動テスト
• コミュニケーションスケジュールを設定 - 更新とエスカレーション

テストアプローチ:

タイプ	アクセスレベル	シミュレート
Black Box	情報なし	外部攻撃者
Gray Box	部分的アクセス	アクセス権限の限られたインサイダー
White Box	完全なアクセス	インサイダー/詳細監査

レポート形式を定義

• サンプルレポートをレビュー - 品質がニーズを満たしていることを確認
• 必要なセクションを指定 - 経営層向けサマリー、技術詳細
• 機械可読出力をリクエスト - 追跡用の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

ロギングを構成

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

監視すべき主要ログ:

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

例外ツールを監視

• エラー率を追跡 - 異常なスパイクはテストを示す
• 運用チームに通知 - テストと攻撃を区別
• ベースラインを文書化 - 通常対pentestアクティビティ

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

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

フェーズ5: 改善

バックアップを確認

• バックアップの整合性を検証 - 復元をテスト
• 復旧手順を文書化 - 復元方法を理解
• バックアップアクセスを分離 - テストから保護

改善時間を予約

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

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

• 一般的にパッチを回避 - 一貫した環境を維持
• 重大な問題の例外 - セキュリティ緊急時のみ
• 変更を伝える - pentesterに変更を通知

クリーンアップ手順

• テスト成果物を削除 - バックドア、スクリプト、ファイル
• テストアカウントを削除 - pentesterアクセスを削除
• 設定を復元 - 元の状態に戻す
• クリーンアップを完了確認 - すべての変更を監査

次のPentestをスケジュール

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

テスト頻度の要因:

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

クイックリファレンス

Pentest前チェックリスト

□ スコープが定義され文書化されている
□ 認可が取得されている
□ 環境が準備されている
□ ホスティングプロバイダーに通知されている
□ チームがブリーフィングされている
□ モニタリングが有効化されている
□ バックアップが検証されている

Pentest後チェックリスト

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

制約

• 本番環境でのテストは固有のリスクを伴う
• 予算制限は徹底性に影響する
• 時間制約は対象範囲を制限する可能性がある
• Testerの専門知識は大きく異なる
• 検出結果は急速に古くなる

例

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

**ターゲット:** 企業Webアプリケーション（app.company.com）
**タイプ:** Gray boxウェブアプリケーションpentest
**期間:** 5営業日
**除外:** DoSテスト、本番データベースアクセス
**アクセス:** 標準ユーザーアカウント提供

例2: モニタリング設定

# 包括的なロギングを有効化
sudo systemctl restart rsyslog
sudo systemctl restart auditd

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

トラブルシューティング

問題	ソリューション
スコープの拡大	変更承認の文書化と要求
テストが本番環境に影響	営業時間外のスケジュール、ステージング使用
検出結果が異議を唱えられる	詳細な証拠を提供、再テスト
改善が遅延	リスク別に優先順位付け、期限を設定
予算超過	スコープを明確に定義、固定価格契約