pentest-checklist

⚠️ 許可された使用のみ このスキルは、教育目的または許可されたセキュリティ評価のみを対象としています。 このツールを使用する前に、システム所有者から明示的な書面による許可を得る必要があります。 このツールの悪用は違法であり、固く禁じられています。

必須の確認ゲート ターゲットに対して調査、悪用、変更、永続化、データ抽出、または資格情報へのアクセスを試みるコマンドを実行する前に:

1. ユーザーに正確なターゲット URL、IP、アカウント、またはリソースを述べるよう求めます。
2. ユーザーに書面による許可と許可された範囲を確認するよう求めます。
3. 正確なコマンドを示し、その予想される効果を説明します。
4. 現在の会話で明示的な確認を待ちます。

その確認がない場合は、読み取り専用のままにし、防御的なガイダンスのみを提供してください。サンドボックス、使い捨ての VM、または制御されたラボを優先してください。

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

ペネトレーションテストチェックリスト

目的

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

入力/前提条件

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

出力/成果物

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

コアワークフロー

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

目的の定義

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

参考質問:

• なぜこのペネトレーションテストを行うのですか?
• どのような具体的な成果を期待していますか?
• 発見事項をどう活用しますか?

テストの種類を知る

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

想定される脅威の列挙

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

スコープの定義

• 対象範囲内のシステムのリスト - IP、ドメイン、アプリケーション
• 対象範囲外の項目の定義 - 回避すべきシステム
• テスト境界の設定 - どのような手法が許可されていますか?
• 除外項目の文書化 - サードパーティのシステム、本番データ

予算計画

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

予算の現実チェック:

• 安価なペネトレーションテストはしばしば不十分な結果を生みます
• 予算を資産の重要度に合わせます
• 継続的テストと単発テストを検討します

フェーズ 2: 環境の準備

テスト環境の準備

• 本番 vs. ステージングの決定 - どこでテストするかを判断します
• テスト制限の設定 - 本番環境での 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

開発の凍結

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

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

適格なペネトレーションテスターを探す

• 推薦を依頼する - 信頼できる情報源に相談します
• 資格を確認する - OSCP、GPEN、CEH、CREST
• 推薦先を確認する - 過去の顧客に話を聞きます
• 専門知識をスコープに合わせる - Web、ネットワーク、モバイルの専門家

評価基準：

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

方法論の定義

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

テストのアプローチ：

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

レポート形式の定義

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

レポートに含める内容：

• 経営陣向けのエグゼクティブサマリー
• 証拠を含む技術的な調査結果
• リスク評価と優先順位
• 修正の推奨事項
• 再テストのガイダンス

フェーズ 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 ログを監視する - ブロックされた試行を追跡します
• エンドポイント保護を確認する - ウイルス対策ソフトの検出状況を確認します

フェーズ 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 &

トラブルシューティング

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

使用するタイミング

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