pentest-checklist

ペンテストチェックリスト

目的

ペネトレーションテストの計画、実施、フォローアップのための包括的なチェックリストを提供します。十分な準備、適切なスコープ設定、発見された脆弱性の効果的な修正を確実に行うことを目的とします。

入力/前提条件

• テストのための明確なビジネス目標
• 対象環境の情報
• 予算とスケジュールの制約
• ステークホルダーの連絡先と承認
• 法的合意およびスコープ文書

出力/成果物

• 定義されたペンテストのスコープと目標
• 準備されたテスト環境
• セキュリティ監視データ
• 脆弱性検出レポート
• 修正計画と検証

コアワークフロー

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

目標の定義

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

参考質問:

• なぜこのペンテストを実施するのですか？
• どのような具体的な成果を期待していますか？
• 検出結果をどのように活用しますか？

テストタイプを理解する

タイプ	目的	スコープ
外部ペンテスト	外部からの攻撃対象領域を評価する	公開システム
内部ペンテスト	内部脅威のリスクを評価する	社内ネットワーク
Webアプリケーション	アプリケーションの脆弱性を発見する	特定のアプリケーション
ソーシャルエンジニアリング	人的セキュリティをテストする	従業員、プロセス
レッドチーム	攻撃者の完全なシミュレーション	組織全体

想定される脅威を洗い出す

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

スコープを定義する

• 対象システムを列挙する - IP、ドメイン、アプリケーション
• 対象外の項目を定義する - 避けるべきシステム
• テストの境界を設定する - どの手法を許可するか？
• 除外項目を文書化する - サードパーティシステム、本番データ

予算計画

要素	考慮事項
資産価値	価値が高いほど投資も高くなる
複雑さ	システムが多いほど時間がかかる
必要な深度	徹底したテストほどコストがかかる
ブランド価値	有名企業ほど費用が高い

予算の現実チェック:

• 安価なペンテストは、往々にして結果が不十分になる
• 予算を資産の重要度に合わせる
• 継続的なテストと単発のテストのどちらが適切かを検討する

フェーズ 2: 環境準備

テスト環境を準備する

• 本番環境とステージング環境の決定 - どこでテストするかを決める
• テストの制限を設定する - 本番環境ではDoSを行わない
• テストの時間枠をスケジュールする - 業務への影響を最小限にする
• テスト用アカウントを作成する - 適切なアクセスレベルを付与する

環境の選択肢:

Production  - Realistic but risky
Staging     - Safer but may differ from production
Clone       - Ideal but resource-intensive

事前スキャンを実行する

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

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

# Network vulnerability scan
nmap -sV --script vuln TARGET

# Web vulnerability scan
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

開発を凍結する

• テスト中のデプロイを停止する - 環境の一貫性を保つ
• 現在のバージョンを文書化する - システムの状態を記録する
• 重要なパッチの適用を避ける - セキュリティ上の緊急事態を除く

Phase 3: 専門家の選定

適格なペンテスターを見つける

• 推薦を求める - 信頼できる情報源に問い合わせる
• 資格を確認する - OSCP、GPEN、CEH、CREST
• 実績を確認する - 過去のクライアントに話を聞く
• スコープに合った専門性を選ぶ - Web、ネットワーク、モバイルの専門家

評価基準:

要素	確認事項
経験	業界での年数、類似プロジェクト
方法論	OWASP、PTES、独自のアプローチ
レポート	サンプルレポート、詳細さのレベル
コミュニケーション	対応可能性、更新の頻度

方法論を定義する

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

テストのアプローチ:

種類	アクセスレベル	想定する攻撃者
ブラックボックス	情報なし	外部の攻撃者
グレーボックス	一部のアクセス	限定的なアクセス権を持つ内部の人間
ホワイトボックス	完全なアクセス	内部の人間／詳細な監査

レポート形式を定義する

• サンプルレポートを確認する - 品質がニーズを満たすか確かめる
• 必須セクションを指定する - エグゼクティブサマリー、技術的詳細
• 機械可読な出力を要求する - 追跡用のCSV、XML
• リスク評価について合意する - CVSS、独自のスケール

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

• 経営層向けのエグゼクティブサマリー
• 証拠を伴う技術的な発見事項
• リスク評価と優先順位付け
• 是正に関する推奨事項
• 再テストに関するガイダンス

Phase 4: モニタリング

セキュリティモニタリングを実装する

• IDS/IPSを導入する - 侵入検知システム
• ロギングを有効にする - 包括的な監査証跡
• SIEMを構成する - ログの集中分析
• アラートを設定する - リアルタイム通知

モニタリングツール:

# Check security logs
tail -f /var/log/auth.log
tail -f /var/log/apache2/access.log

# Monitor network
tcpdump -i eth0 -w capture.pcap

ロギングを構成する

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

監視すべき主要なログ:

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

例外的なツールを監視する

• エラー率を追跡する - 異常な急増はテストの兆候
• 運用チームに周知する - テストと攻撃を区別できるようにする
• ベースラインを文書化する - 通常の活動とペンテストの活動を区別する

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

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

Phase 5: 是正

バックアップを確保する

• バックアップの完全性を検証する - リストアをテストする
• 復旧手順を文書化する - リストア方法を把握しておく
• バックアップへのアクセスを分離する - テストから保護する

是正のための時間を確保する

• チームの対応可能時間を確保する - ペンテスト後の分析
• 修正の実施をスケジュールする - 発見事項への対応
• 検証テストを計画する - 修正が機能することを確認する

テスト期間中のパッチ適用ポリシー

• 原則としてパッチ適用を避ける - 環境の一貫性を維持する
• 重大な問題への例外 - セキュリティ上の緊急事態に限る
• 変更を周知する - 変更があればペンテスターに知らせる

クリーンアップ手順

• テスト用の成果物を削除する - バックドア、スクリプト、ファイル
• テスト用アカウントを削除する - ペンテスターのアクセス権を除去する
• 構成を復元する - 元の状態に戻す
• クリーンアップの完了を検証する - すべての変更を監査する

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

• 頻度を決定する - 年次、四半期ごと、変更後
• 継続的なテストを検討する - バグバウンティ、継続的なアセスメント
• 将来のテストの予算を確保する - 先を見越して計画する

テスト頻度の判断要素:

• リリースの頻度
• 規制上の要件
• リスク許容度
• 過去の発見事項の深刻度

クイックリファレンス

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

□ Scope defined and documented
□ Authorization obtained
□ Environment prepared
□ Hosting provider notified
□ Team briefed
□ Monitoring enabled
□ Backups verified

ペンテスト後のチェックリスト

□ Report received and reviewed
□ Findings prioritized
□ Remediation assigned
□ Fixes implemented
□ Verification testing scheduled
□ Environment cleaned up
□ Next test scheduled

制約事項

• 本番環境でのテストには本質的なリスクが伴います
• 予算の制約により、網羅性が影響を受けることがあります
• 時間の制約により、対象範囲が限定されることがあります
• テスターの専門性には大きなばらつきがあります
• 検出事項は速やかに陳腐化します

例

例 1: スコープの簡易定義

**Target:** Corporate web application (app.company.com)
**Type:** Gray box web application pentest
**Duration:** 5 business days
**Excluded:** DoS testing, production database access
**Access:** Standard user account provided

例 2: モニタリングの設定

# Enable comprehensive logging
sudo systemctl restart rsyslog
sudo systemctl restart auditd

# Start packet capture
tcpdump -i eth0 -w /tmp/pentest_capture.pcap &

トラブルシューティング

問題	解決策
スコープの拡大	文書化し、変更の承認を必須とする
テストが本番環境に影響する	業務時間外にスケジュールし、ステージング環境を使用する
検出事項への異議	詳細な証拠を提示し、再テストを行う
修正対応の遅延	リスクに基づいて優先順位を付け、期限を設定する
予算超過	明確なスコープを定義し、固定価格契約を利用する