はじめに

「脆弱性診断（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時代に重要なのは、穴がゼロであることよりも、
侵入後に“気づけるか / 止められるか / 復旧できるか” です。