はじめに
「脆弱性診断（Vulnerability Assessment）」「ペネトレーションテスト（Penetration Test）」「レッドチーム（Red Team Engagement）」は、全部“セキュリティ評価”に見えますが、目的がまったく違うため、成果物も、進め方も、成功条件も変わります。
ひと言でまとめるなら：
- 脆弱性診断：穴を広く見つける（守りの優先順位づけ）
- ペネトレ：穴が本当に使えるか・どこまで行けるか（技術的影響評価）
- レッドチーム：侵入を前提に、検知・対応が機能するか（組織的レジリエンス評価）
1. 脆弱性診断（Vulnerability Assessment）
1.1 目的
脆弱性診断の目的は、ネットワーク上のできる限り多くのホスト・サービスに対して、既知の脆弱性や設定不備を網羅的に発見し、修正の優先順位を付けることです。
- 「どこが弱いか」を地図化する
- 「何から直すべきか」を決める
1.2 特徴
- 自動化ツール中心（スキャナ、設定診断、CVE照合など）
- ホストを「個体」として評価し、ネットワーク全体の“攻撃の連鎖”は深掘りしないことが多い
- “効率優先”のため、診断中にスキャナが止められないように、評価環境では一部の制御を緩めることもあり得る（例：診断端末の通信を許可する、例外ルールなど）
1.3 成果物（例）
- 脆弱性一覧（CVE / 影響度 / 露出面）
- リスク評価（CVSS、資産価値、悪用可能性）
- 修正提案（パッチ、設定、運用改善）
- 再診断計画
1.4 向いている状況
- まず現状を把握したい
- 多拠点・大量端末で、脆弱性の棚卸しが必要
- 「標準化」された改善を進めたい（パッチ運用、設定基準）
2. ペネトレーションテスト（Penetration Test）
2.1 目的
ペネトレは、診断で見つかった脆弱性（または探索で見つけた弱点）が、実際に攻撃者の視点で悪用可能か、悪用した場合にどんな影響が起きるかを明確にするものです。
- 脆弱性は「存在する」だけではなく、“使えるか”が重要
- ネットワークは“相互作用するシステム”なので、連鎖で被害が拡大する
2.2 特徴
- 脆弱性の**実証（Exploit）**を行う（ただしルールの範囲で）
- 侵入後に、追加情報の取得・横展開（Post-Exploitation）を通して影響評価を行う
- スコープは比較的広めになりがち（多ホスト・多サービスを短期間で確認）
- 時間制約が強く、ステルス（検知回避）を徹底しない場合が多い
→ “うるさくても、短期間で結果を出す”のが現実的なプロジェクト設計になりやすい
2.3 成果物（例）
- 再現手順（どの条件で成立するか）
- 影響範囲（権限、到達可能な資産、情報流出の可能性）
- 攻撃の経路（初期侵入→権限昇格→横展開→目的達成までのストーリー）
- 対策（技術・運用・検知）
2.4 向いている状況
- “本当に危険か”を経営層に説明したい
- 対策コストの判断材料が欲しい
- 監査・顧客要件で「実証」が求められる
3. なぜ「通常のペネトレ」だけでは足りないのか（APTの観点）
3.1 現実の攻撃者（APT）の特徴
APT（Advanced Persistent Threat） は、国家支援や組織犯罪などの高度な攻撃者像を指し、特徴は以下です：
- Persistent（持続的）：数ヶ月〜数年、潜伏して目的を達成する
- Stealth（ステルス）：ログやEDRに引っかからないよう行動を最適化する
- 非技術ベクトルも使う：フィッシング、なりすまし、物理侵入、サプライチェーンなど
- 場合によっては未知の手法（ゼロデイ等）を利用し得る
3.2 通常のペネトレの限界
ペネトレは価値が大きい一方で、現実の攻撃と一致しない部分が出ます。
-
ペネトレは LOUD（うるさい）
多数の探索・試行を短期間で実施するため、実攻撃よりアラートが出やすい。
→ つまり、Blue Team側が「検知できた」ように見えても、現実のAPTはもっと静かに来る可能性がある。 -
非技術ベクトルが範囲外になりがち
人・物理・運用プロセスはスコープ外になることが多い。 -
セキュリティ機構を緩めることがある
WAF/IPS/EDRの例外設定など、効率のために“本番と違う条件”が混ざると、実戦耐性の評価が歪む。
3.3 ここで出てくる問い
- 数ヶ月潜伏されたら検知できる？
- インシデント対応の連携は機能する？
- 初期侵入が「経理のJohnの添付ファイル」だったら止められる？
- 侵入後の横展開・権限取得を追跡できる？
この問いに答えるのが、レッドチームです。
4. レッドチーム演習（Red Team Engagement）
4.1 目的
レッドチームは、従来の「脆弱性を見つける」「侵入できるか」を超えて、防御側（Blue Team）の検知・対応能力を測るための演習です。
- Prevent（防ぐ）より、Detect/Respond（気づいて対処する）
- “侵入される前提”の現実的な設計
レッドチームのゴールは「Blueに勝つ」ことではなく、
現実の脅威を模して、Blueが改善できる材料を作ること。
4.2 特徴
- 目標（Crown Jewels / Flags）を明確化して、その最短経路を狙う
- ネットワーク全体を叩き回さない（派手なスキャンを避ける）
- 防御機構（FW/AV/EDR/IPS/WAF等）を“現実同様に”相手にする
- Blueに事前通知しないことが多い（バイアスを避ける）
4.3 取り扱う攻撃面（3つ）
- 技術（Technical）：インフラ/アプリ/ADなど（ただしステルス重視）
- 人（Social Engineering）：フィッシング、電話、SNSなど
- 物理（Physical）：入館、RFID、鍵、設備など
4.4 Tactics, Techniques and Procedures（TTPs）
TTPs は、実在する攻撃者の行動を構造化して表現する概念です。
| 要素 | 意味 | 例 |
|---|---|---|
| Tactics | 攻撃の目的・フェーズ | Initial Access, Lateral Movement |
| Techniques | 目的達成のための手法 | Phishing, Credential Dumping |
| Procedures | 実際の具体的実装 | メール文面、実行順、ツール運用 |
「なぜ・何を・どうやってやるか」 をセットで捉える考え方。
5. エンゲージメントの形（3パターン）
5.1 Full Engagement
初期侵入〜目的達成までを一気通貫で模擬。
- 本番に近い
- 時間もコストも大きい
- Blueの運用成熟度が見えやすい
5.2 Assumed Breach
「すでに侵入されている」前提で開始。
- 例：あるユーザーの認証情報が漏れている、端末1台が乗っ取られている想定
- 初期侵入フェーズを省略でき、内部移動と検知・対応に集中できる
- 現実的でコスパが良いことも多い
5.3 Table-top Exercise
机上演習。シナリオを提示し、対応を議論。
- ライブ侵入が難しい環境でも実施可能
- IR手順や意思決定、コミュニケーションの弱点が見える
- ただし技術的検証は弱い（“理想論”になりやすい）
6. チーム構成（Red / Blue / White）
6.1 3つのセル
- Red Cell：攻撃側。実施者。
- Blue Cell：防御側。SOC/CSIRT/運用/管理職などを含み得る。
- White Cell：審判・調整。ルール順守、影響制御、評価、調整を担当。
Whiteがいるのが重要で、これが無いと「ただの殴り合い」になって失敗します。
7. キルチェーンで見る“行動の全体像”
レッド/ブルー双方が共通言語として使えるのが サイバー・キルチェーンです。代表例（Lockheed Martin Cyber Kill Chain）は以下：
- Recon（偵察）
- Weaponization（武器化）
- Delivery（配送）
- Exploitation（悪用）
- Installation（設置）
- C2（遠隔操作）
- Actions on Objectives（目的達成）
7.1 実務での使いどころ
- Red：TTPの設計・演習計画を整理する
- Blue：どの段階で検知・遮断できたかを振り返る
- White：演習の観測点（ログ/アラート/通報）を定義する
8. どう使い分けるべきか（実務の判断軸）
| 手法 | 目的 | 成功条件 | 向いている組織 |
|---|---|---|---|
| 脆弱性診断 | 脆弱性の網羅的発見 | “一覧化と優先度”ができる | まず現状把握したい |
| ペネトレ | 悪用可能性と影響の実証 | “再現＋影響説明”ができる | 対策投資判断をしたい |
| レッドチーム | 検知・対応能力の評価 | “検知・対応の改善点”が出る | SOC/CSIRT成熟度を上げたい |
9. ありがちな失敗パターン（超重要）
9.1 目標が曖昧
「何でもいいから攻撃して」だと、評価が散ります。
レッドチームは必ず **Crown Jewels（守るべき資産）**を決めるべきです。
9.2 ルール（ROE）が弱い
- どこまでやって良いか
- どの時間帯にやるか
- 影響が出たらどう止めるか
- 禁止事項（例：本番データ破壊、業務停止につながる操作）
ここが曖昧だと事故ります。
9.3 “勝ち負け”に寄る
レッドが勝っても、Blueが学べないなら失敗。
改善（Detection Engineering / IR手順） に繋げる設計が必要です。
まとめ
- 脆弱性診断は「弱点を棚卸しする」
- ペネトレは「弱点の影響を実証する」
- レッドチームは「侵入を前提に、検知・対応が回るかを評価する」
APT時代に重要なのは、穴がゼロであることよりも、
侵入後に“気づけるか / 止められるか / 復旧できるか” です。