30 天的攻防演練凝縮成一張矩陣——每個攻擊都有對應的偵測和防禦。

學習目標

完成本日實作後，你將能夠：

• 將 ATT&CK 攻擊技術對應到 D3FEND 防禦措施
• 使用安全成熟度模型評估 KOAD 部署的防禦覆蓋率
• 執行驗證指令確認各層防禦的實際狀態
• 識別目前部署中的防禦缺口並規劃改善路徑
• 設計四層防禦架構（Cloud → Cluster → Container → Code）

閱讀前置條件

本篇是 30 天攻防的完整對照矩陣。建議的最低閱讀量：

快速路徑：如果時間有限，至少讀完 Day 1 → 24 → 本篇，即可掌握全局攻防視圖。

MITRE ATT&CK × D3FEND 對照框架

ATT&CK 描述攻擊者「做了什麼」，D3FEND 描述防禦者「該怎麼回應」。兩者結合，才是完整的攻防視圖。

ATT&CK Containers Matrix 回顧

MITRE ATT&CK for Containers 是專門針對容器環境的攻擊知識庫。KOAD 覆蓋了全部 10 個戰術、28 個技術：

D3FEND 防禦框架

D3FEND 是 MITRE 的防禦知識庫，定義了七大防禦戰術：

D3FEND 技術對應

每個 D3FEND 戰術下有具體的防禦技術。KOAD 使用的 D3FEND 技術：

D3FEND 技術深度解析

每一項 D3FEND 技術都能對應到具體的合規標準和 KOAD 實作。以下逐一拆解：

D3-ACL — Access Control List（存取控制清單）

• 合規對應：NIST SP 800-53 AC-3（Access Enforcement）、ISO 27001 A.9.4.1
• K8s 實作：Calico NetworkPolicy 定義 Pod 間可通訊的白名單，搭配 default-deny-all 作為基線
• KOAD 場景覆蓋：S01（阻擋 SSRF 到 Metadata）、S28（限制掃描範圍）、S30（隔離跨 NS 通訊）、S34（防禦網路 DoS）

# D3-ACL 實作範例：阻擋 Metadata API
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-metadata
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except: [169.254.169.254/32]

D3-MAC — Mandatory Access Control（強制存取控制）

• 合規對應：NIST SP 800-53 AC-3(3)、ISO 27001 A.9.4.1、CIS Benchmark 5.7.2
• K8s 實作：AppArmor profile 限制容器可執行的系統呼叫和檔案存取路徑
• KOAD 場景覆蓋：S13–S19（所有逃逸場景的防禦層）

D3-SCA — System Call Analysis（系統呼叫分析）

• 合規對應：NIST SP 800-53 SI-4（Information System Monitoring）、ISO 27001 A.12.4.1
• K8s 實作：Falco 使用 eBPF 攔截 syscall，比對自訂規則後產生告警；Tetragon 可直接在 kernel 層阻擋
• KOAD 場景覆蓋：幾乎全部 35 場景的 Detect 層——Falco 是 KOAD 偵測覆蓋率最高的工具

D3-FE — File Encryption（檔案加密）

• 合規對應：NIST SP 800-53 SC-28（Protection of Information at Rest）、PCI-DSS 3.4
• K8s 實作：etcd EncryptionConfiguration 加密 Secrets 資源，避免明文儲存在 etcd
• KOAD 場景覆蓋：S26（明文憑證防禦）

# D3-FE 實作範例：etcd 加密配置
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:

- resources: [secrets]
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: <base64-encoded-key>
  - identity: {}

D3-BA — Behavioral Analysis（行為分析）

• 合規對應：NIST SP 800-53 SI-4(2)（Automated Tools and Mechanisms）、ISO 27001 A.12.4.1
• K8s 實作：Falco 規則不只比對單一事件，而是分析行為模式（如短時間內大量 API 呼叫、異常 binary 執行）
• KOAD 場景覆蓋：S24（暴力破解偵測）、S35（挖礦行為偵測）

D3-SPP — System Call Filtering（系統呼叫過濾）

• 合規對應：NIST SP 800-53 CM-7(5)（Authorized Software）、CIS Benchmark 5.7.1
• K8s 實作：seccomp profile 以白名單方式限制容器可用的 syscall，RuntimeDefault 已阻擋大部分危險操作
• KOAD 場景覆蓋：S13–S19（逃逸防禦）、S17（阻擋 ptrace）

D3-OSM — Operating System Monitoring（作業系統監控）

• 合規對應：NIST SP 800-53 AU-2（Audit Events）、ISO 27001 A.12.4.1、SOC2 CC7.2
• K8s 實作：Kubernetes Audit Log 記錄所有 API Server 請求，包含 who/what/when/where
• KOAD 場景覆蓋：S09–S11（Persistence 偵測）、S22（偽裝 Pod 偵測）、S29（RBAC 探測偵測）

D3-NI — Network Isolation（網路隔離）

• 合規對應：NIST SP 800-53 SC-7（Boundary Protection）、ISO 27001 A.13.1.3、PCI-DSS 1.3
• K8s 實作：Calico NetworkPolicy 實作 Namespace 間和 Pod 間的網路隔離，支援 L3/L4 規則
• KOAD 場景覆蓋：與 D3-ACL 重疊，但更強調隔離（S19 gVisor 核心隔離、S34 DoS 防禦）

完整攻防矩陣

TA0001 Initial Access

TA0002 Execution

TA0003 Persistence

TA0004 Privilege Escalation

TA0005 Stealth

TA0112 Defense Impairment

TA0006 Credential Access

TA0007 Discovery

TA0008 Lateral Movement

TA0040 Impact

分層防禦總結

Cloud → Cluster → Container → Code

Build → Deploy → Runtime → Operate

覆蓋率分析

ATT&CK 覆蓋率

D3FEND 覆蓋率

觀察：Harden 和 Detect 是主力，佔了防禦措施的 80%+。這符合業界實務——大部分安全投資應該放在「強化」和「偵測」。

防禦空缺分析

防禦投資 ROI 分析

不是所有防禦措施的投報率都一樣。以下從「部署成本」和「覆蓋場景數」兩個維度分析，幫你決定先投資什麼：

高 ROI 防禦（低成本 × 高覆蓋）

中 ROI 防禦（中成本 × 中覆蓋）

低 ROI 防禦（高成本 × 低覆蓋但不可或缺）

建議部署順序

Phase 1（第 1 天）：NetworkPolicy + RBAC + PSS
  ↓ 覆蓋 16 場景，阻擋 80% 攻擊鏈
Phase 2（第 1 週）：Falco + Audit Log + etcd 加密
  ↓ 新增偵測能力，覆蓋 25 場景
Phase 3（第 2 週）：Kyverno + Cosign + Trivy
  ↓ Admission 控制 + 供應鏈安全
Phase 4（第 1 月）：Tetragon + gVisor + Talon + Velero
  ↓ 進階防禦 + 自動回應 + 備份恢復

CKS 六大領域完整覆蓋

如何使用這張矩陣

1. 風險評估

用這張矩陣做風險評估時，檢查你的環境：

對於每個 KOAD 場景：
  □ 這個攻擊在我的環境中可行嗎？
  □ 對應的 Harden 措施是否已部署？
  □ 對應的 Detect 措施是否已設定？
  □ 如果偵測到，回應 SOP 是否準備好？

2. 防禦優先級

不是所有場景都需要同等投入。根據風險和影響排序：

3. 合規對照

將矩陣與合規框架交叉比對：

攻擊鏈路徑分析

最短路徑：3 步到 Impact

SSRF (S01) → kubectl (S05) → Cryptominer (S35)
   │              │                │
   TA0001         TA0002           TA0040
   Initial        Execution        Impact
   Access

這是 KOAD 攻擊鏈中最短的路徑——只需要 3 步。前提是 Pod 的 SA 已有足夠權限。

典型路徑：7 步完整攻擊鏈

各層防禦的阻斷點

關鍵觀察：越早阻斷，成本越低、損害越小。NetworkPolicy 在步驟 1 就能終結整條鏈，是投資報酬率最高的防禦措施。

防禦成熟度模型

根據 KOAD 的實戰經驗，定義四個防禦成熟度等級：

Level 1：基礎（最低安全要求）

□ RBAC 已配置（非 default SA cluster-admin）
□ NetworkPolicy default-deny 已部署
□ kubelet anonymous-auth=false
□ etcd 加密已啟用

覆蓋場景：S01–S03, S05, S26

驗證指令：

# 主機終端 — Level 1 驗證
# 檢查是否有 cluster-admin 綁定到 default SA
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") |
      .subjects[] | select(.name=="default")'

# 檢查 NetworkPolicy 是否存在
kubectl get networkpolicy -A | grep -c "deny"

# 檢查 kubelet 認證設定
ssh <node> "cat /var/lib/kubelet/config.yaml | grep anonymous -A1"

# 檢查 etcd 加密
kubectl get apiserver -o=jsonpath='{.items[0].spec.encryption}'
# 或直接驗證 Secret 在 etcd 中是否加密
ETCDCTL_API=3 etcdctl get /registry/secrets/default/test-secret | hexdump -C | head

Level 2：標準（建議的安全基線）

□ Level 1 全部完成
□ Kyverno 7 條策略（至少 Audit 模式）
□ PSS Restricted 已設定
□ Falco 已部署（基本規則集）
□ Audit Log 已啟用
□ CIS Benchmark 掃描 FAIL < 5 項

覆蓋場景：+ S04–S19, S23

驗證指令：

# 主機終端 — Level 2 驗證
# 檢查 Kyverno 策略狀態
kubectl get cpol -o custom-columns=\
  NAME:.metadata.name,\
  MODE:.spec.validationFailureAction,\
  READY:.status.conditions[0].status

# 檢查 PSS 標籤
kubectl get ns --show-labels | grep "pod-security.kubernetes.io"

# 檢查 Falco 是否運行
kubectl get pods -n falco -l app.kubernetes.io/name=falco -o wide
kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=5

# 檢查 Audit Log 配置
kubectl get pods -n kube-system kube-apiserver-* -o yaml | \
  grep -A2 "audit-policy-file"

# CIS Benchmark 掃描
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench | grep -c "\[FAIL\]"

Level 3：進階（主動防禦）

□ Level 2 全部完成
□ Kyverno 切到 Enforce 模式
□ Falco 自訂規則覆蓋全部 KOAD 場景
□ Falco Talon 自動回應已配置
□ Tetragon TracingPolicy 已部署
□ 供應鏈安全（Cosign + Trivy）
□ IR SOP 已建立

覆蓋場景：+ S20–S35

驗證指令：

# 主機終端 — Level 3 驗證
# 確認 Kyverno 已切 Enforce
kubectl get cpol -o json | jq '.items[] |
  select(.spec.validationFailureAction != "Enforce") | .metadata.name'
# 預期：空輸出代表全部 Enforce

# 列出自訂 Falco 規則數量
kubectl get configmap -n falco -l app.kubernetes.io/name=falco \
  -o jsonpath='{.items[*].data}' | grep -c "rule:"

# 確認 Falco Talon 運行中
kubectl get pods -n falco -l app.kubernetes.io/name=falco-talon

# 確認 Tetragon TracingPolicy
kubectl get tracingpolicies -o name | wc -l

# 驗證 Cosign 簽章
cosign verify --key cosign.pub <your-image>:latest

# Trivy 掃描通過
trivy image --exit-code 1 --severity HIGH,CRITICAL <your-image>:latest

Level 4：卓越（持續改善）

□ Level 3 全部完成
□ 季度 IR 演練
□ 攻擊模擬（紅隊/紫隊）
□ SIEM 整合 + 告警關聯
□ 自動化合規報告
□ Chaos Engineering 驗證防禦韌性

驗證指令：

# 主機終端 — Level 4 驗證
# 檢查 IR 演練記錄（假設用 ConfigMap 追蹤）
kubectl get configmap ir-drill-log -n security -o yaml

# 驗證 SIEM 整合（Falco → Elasticsearch/Splunk）
kubectl logs -n falco -l app.kubernetes.io/name=falco-sidekick --tail=5

# Chaos Mesh 已部署
kubectl get pods -n chaos-mesh

# 合規報告 CronJob
kubectl get cronjob -n security compliance-report

紅藍對抗演練指南

這張矩陣最大的價值不只是看，而是用來演練。以下是完整的 Purple Team 演練 SOP：

演練準備 Checklist

事前準備（D-7）：
  □ 確認 KOAD 環境可用（minikube status）
  □ 確認 Falco / Kyverno / Tetragon 正常運行
  □ 建立演練專用 Namespace（kubectl create ns drill-<date>）
  □ 準備演練記錄模板（Google Sheet / Confluence）
  □ 指定紅隊（1-2 人）和藍隊（1-2 人）角色
  □ 設定演練時間窗口（建議 2-4 小時）

演練當天（D-Day）：
  □ 藍隊先確認監控基線（Falco 無 alert）
  □ 紅隊按攻擊鏈順序執行（S01 → S05 → S09 → ...）
  □ 藍隊即時監控 + 回應
  □ 每個場景記錄：偵測？幾秒？誰回應？

演練執行流程

Round 1：單步驟演練（初階）

逐一執行單一場景，驗證偵測能力：

# 紅隊：執行 S01 SSRF 攻擊
kubectl exec -n drill attacker -- \
  curl -s http://169.254.169.254/latest/meta-data/

# 藍隊：檢查 NetworkPolicy 是否阻擋
kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=10 | \
  grep -i "metadata"

# 記錄表格
# | 場景 | 攻擊成功？ | 偵測到？ | 偵測延遲 | 回應動作 | 結果 |
# | S01  | 否(被NP阻擋)| N/A     | N/A      | N/A     | PASS |

Round 2：攻擊鏈演練（中階）

執行完整攻擊鏈，測試縱深防禦：

演練攻擊鏈路徑：
  Step 1：S01 SSRF → 預期被 NetworkPolicy 擋住
  Step 2：（繞過）直接 S05 kubectl → 預期被 RBAC 擋住
  Step 3：（繞過）直接 S09 RBAC 竄改 → 預期被 Audit Log 偵測
  Step 4：（繞過）直接 S13 特權逃逸 → 預期被 PSS 擋住
  Step 5：（繞過）直接 S35 挖礦 → 預期被 Falco 偵測
  
每個步驟記錄：
  - 阻擋層是否生效？
  - 如果繞過，下一層是否接住？
  - 最終落到哪一層才被擋住？

Round 3：假設淪陷演練（高階）

假設某些防禦已被繞過，測試深層防禦：

演練後複盤模板

演練報告：KOAD Purple Team Drill #<N>
日期：YYYY-MM-DD
參與人員：紅隊 / 藍隊

1. 總覽
   - 演練場景數：__ / 35
   - 成功阻擋率：__% 
   - 平均偵測時間：__ 秒

2. 發現的防禦空缺
   | 場景 | 預期防禦 | 實際結果 | 根因 | 修復方案 | 負責人 | 期限 |

3. 改善行動項
   - [ ] 修復項 1 — 預計完成日期
   - [ ] 修復項 2 — 預計完成日期

4. 下次演練重點
   - 聚焦本次失敗的場景
   - 新增哪些攻擊手法

快速驗證演練：10 分鐘攻防矩陣實測

理論再完整，不如動手驗證一次。以下是一個濃縮版演練——從攻擊矩陣中各挑一個代表場景，逐層驗證防禦。

Step 1: 確認環境就緒

# 主機終端 — 快速檢查 KOAD 三大防禦元件
echo "=== Kyverno ==="
kubectl get cpol --no-headers 2>/dev/null | wc -l
echo "=== Falco ==="
kubectl get pods -n falco -l app.kubernetes.io/name=falco --no-headers 2>/dev/null | grep -c Running
echo "=== NetworkPolicy ==="
kubectl get networkpolicy -n koad --no-headers 2>/dev/null | wc -l

預期結果：

=== Kyverno ===
7
=== Falco ===
1
=== NetworkPolicy ===
3

Step 2: Harden 層驗證 — PSS 阻擋特權 Pod（TA0004 代表）

# 主機終端 — 嘗試在已啟用 PSS Restricted 的 namespace 建立特權 Pod
kubectl label namespace koad \
  pod-security.kubernetes.io/enforce=restricted --overwrite 2>/dev/null

kubectl run matrix-test-privileged --image=busybox -n koad \
  --overrides='{"spec":{"containers":[{"name":"test","image":"busybox",
  "securityContext":{"privileged":true}}]}}' 2>&1

# 還原
kubectl label namespace koad pod-security.kubernetes.io/enforce- 2>/dev/null

預期結果：

Error from server (Forbidden): pods "matrix-test-privileged" is forbidden: 
violates PodSecurity "restricted:latest"

Harden 層生效：PSS 在 Admission 階段阻擋了 S13–S18 所有需要特權的逃逸。

Step 3: Detect 層驗證 — Falco 偵測異常行為（TA0002 代表）

# 主機終端 — 在攻擊者 Pod 中觸發 Falco 規則
# 執行一個會觸發 Falco 的指令（讀取 SA Token）
kubectl exec -n koad $(kubectl get pods -n koad -l app=attacker -o name | head -1) -- \
  cat /var/run/secrets/kubernetes.io/serviceaccount/token > /dev/null 2>&1 || true

# 等待 2 秒讓 Falco 處理
sleep 2

# 檢查 Falco 告警
kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=5 2>/dev/null | \
  grep -i "token\|sensitive" | tail -2

預期結果（類似）：

{"output":"Warning Sensitive file opened for reading by non-trusted program ...
  (file=/var/run/secrets/kubernetes.io/serviceaccount/token ...)"}

Detect 層生效：Falco 即時偵測到 SA Token 讀取行為，對應 S25/S26 憑證竊取。

Step 4: Isolate 層驗證 — NetworkPolicy 阻擋跨 Namespace（TA0008 代表）

# 主機終端 — 驗證 NetworkPolicy 隔離效果
# 從 koad namespace 嘗試存取 kube-system 的服務
kubectl exec -n koad $(kubectl get pods -n koad -o name | head -1) -- \
  timeout 3 wget -q -O- http://kube-dns.kube-system.svc:53 2>&1 || true

預期結果：

wget: download timed out

Isolate 層生效：NetworkPolicy 阻擋了跨 Namespace 通訊，S30 橫向移動被封鎖。

Step 5: 綜合結果

# 主機終端 — 一鍵防禦狀態總覽
echo "╔════════════════════════════════════════════════════╗"
echo "║        KOAD 攻防矩陣 — 防禦驗證結果              ║"
echo "╠════════════════════════════════════════════════════╣"
echo "║  Harden (PSS)      : $(kubectl run pss-check --image=busybox -n koad --overrides='{"spec":{"containers":[{"name":"t","image":"busybox","securityContext":{"privileged":true}}]}}' 2>&1 | grep -q Forbidden && echo 'PASS' || echo 'FAIL')"
echo "║  Detect (Falco)    : $(kubectl get pods -n falco -l app.kubernetes.io/name=falco --no-headers 2>/dev/null | grep -q Running && echo 'PASS' || echo 'FAIL')"
echo "║  Isolate (NetPol)  : $(kubectl get networkpolicy -n koad --no-headers 2>/dev/null | grep -q . && echo 'PASS' || echo 'FAIL')"
echo "║  Kyverno           : $(kubectl get cpol --no-headers 2>/dev/null | grep -q . && echo 'PASS' || echo 'FAIL')"
echo "╚════════════════════════════════════════════════════╝"

這個快速演練驗證了矩陣中四個 D3FEND 戰術（Harden / Detect / Isolate + Kyverno Admission）。完整演練請參考上方「紅藍對抗演練指南」的 Round 1–3 流程。

常見問題 FAQ

Q1：ATT&CK Containers Matrix 和一般 Enterprise Matrix 有什麼差別？

Enterprise Matrix 涵蓋所有平台（Windows、Linux、macOS、Cloud），有 14 個戰術和 200+ 個技術。Containers Matrix 是子集，專注於容器和 Kubernetes 環境，只保留 10 個戰術、28 個技術。差異在於 Containers Matrix 移除了不適用的技術（如 Registry Run Keys、DLL Injection），新增了容器特有的技術（如 T1611 Container Escape、T1610 Deploy Container）。KOAD 選擇 Containers Matrix 是因為它精確覆蓋了 K8s 的攻擊面，不多不少。

Q2：D3FEND 和 NIST CSF 有什麼關係？可以互相對照嗎？

D3FEND 和 NIST CSF（Cybersecurity Framework）都是防禦框架，但抽象層級不同。NIST CSF 定義五大功能（Identify / Protect / Detect / Respond / Recover），更偏管理層面；D3FEND 定義七大戰術，更偏技術層面。兩者可以對照：

Q3：35 個場景太多了，生產環境應該優先部署哪些防禦？

按 Phase 1-4 順序（見「防禦投資 ROI 分析」）。如果只能做三件事：(1) NetworkPolicy default-deny — 一條 YAML 阻擋大部分橫向移動和 SSRF；(2) RBAC 最小權限 — 移除 default SA 不必要的權限；(3) PSS Restricted — 一個 label 阻擋全部容器逃逸。這三步幾乎零成本，卻覆蓋 16+ 個場景。

Q4：Falco 規則太多會不會影響效能？

Falco 使用 eBPF 在 kernel 層攔截 syscall，規則數量對效能的影響遠小於你想像的。KOAD 的 26 條自訂規則在 4 核 / 8GB 的 Minikube 上只增加約 2-3% CPU 使用率。真正影響效能的是輸出量——如果規則太寬鬆（例如監控所有 open syscall），產生的 alert 量會壓垮 Falco Sidekick。建議：先用 priority: WARNING 以上的規則，穩定後再逐步加入 NOTICE 級別。詳見 Day 25 的規則設計原則。

Q5：這張矩陣可以直接用來做合規報告嗎？

可以，但需要加工。矩陣本身是技術對照表，合規報告還需要：(1) 證據截圖（kubectl 輸出、Falco alert 記錄）；(2) 控制措施的有效性測試記錄；(3) 管理層級的風險評估。建議流程：用矩陣的合規對照表找到覆蓋範圍 → 用 kube-bench 產生 CIS 合規報告 → 用 Falco alert 作為偵測控制的證據 → 用演練記錄作為回應能力的證據。Day 27 的 CIS Benchmark 章節有完整的報告產出範例。

Q6：KOAD 矩陣沒有覆蓋 D3FEND Deceive 戰術，有影響嗎？

沒有直接影響，但長期而言是一個值得填補的空缺。Deceive（欺騙）的核心工具是蜜罐（honeypot），在 K8s 中可以用 kubetrap 或自建 honeypot Pod 來誘捕攻擊者。蜜罐的價值在於零誤報——正常使用者不會碰到蜜罐，所以任何觸發都是真實攻擊。部署方式：

# 蜜罐 Pod 範例（故意暴露高權限 SA）
apiVersion: v1
kind: Pod
metadata:
  name: honeypot-db
  namespace: production
  labels:
    app: mysql-backup
spec:
  serviceAccountName: honeypot-sa
  containers:
  - name: trap
    image: alpine:latest
    command: ["sleep", "infinity"]

搭配 Falco 規則，任何 exec 到這個 Pod 的行為立刻觸發 CRITICAL 告警。這是 KOAD v2 的規劃方向之一。

CKS 考點對照

本日小結

完成度自我檢查

• [ ] 能將至少 5 個 ATT&CK 技術對應到 D3FEND 防禦措施
• [ ] 使用 Level 1 驗證指令確認基礎防禦已就位
• [ ] 使用 Level 2 驗證指令確認 Kyverno / Falco / PSS 狀態
• [ ] 識別目前部署中至少 2 個防禦缺口
• [ ] 能說明四層防禦架構（Cloud → Cluster → Container → Code）的覆蓋範圍

今日重點回顧

• 35 個攻擊場景覆蓋 ATT&CK Containers Matrix 全部 10 戰術、28 技術
• 每個攻擊都有對應的 D3FEND 防禦：Harden / Detect / Isolate / Evict / Restore
• 四層防禦架構：Cloud → Cluster → Container → Code
• 防禦投資 ROI：NetworkPolicy + RBAC + PSS 三步即覆蓋 80% 攻擊面
• 安全成熟度模型：Level 1（基礎）→ Level 4（卓越）的漸進式路線圖

這張矩陣是 KOAD 的核心產出——不只是一張表格，而是一個可操作的防禦框架。

明天 Day 29 進入 Incident Response——當 Falco 告警響起的 SOP。