驗證方法

方法概覽

┌─────────────────────────────────────────┐
│       Vehicle-level Validation          │
├─────────────────────────────────────────┤
│  • Penetration Testing  (★ 必要)         │
│  • Fuzzing                              │
│  • Vehicle-level functional test        │
│  • Red Team Exercise                    │
│  • Side-channel analysis (selected)     │
│  • Environmental testing (含 EMC)        │
│  • Long-term Operational Test           │
└─────────────────────────────────────────┘

1. Penetration Testing (Pen Test)

Pen Test 流程（PTES / OWASP）

1. Pre-engagement Interactions
   ├── Scope 定義（含 out-of-scope）
   ├── Rules of Engagement
   ├── Authorization（含法律授權）
   └── 緊急聯絡

2. Intelligence Gathering
   ├── 公開資訊蒐集
   ├── 文件研讀（依 CIA）
   └── 攻擊面 mapping

3. Threat Modeling
   ├── 與 TARA 對齊
   ├── 選擇優先攻擊路徑
   └── 攻擊樹更新

4. Vulnerability Analysis
   ├── 工具掃描
   ├── 手動測試
   └── 弱點分類

5. Exploitation
   ├── 嘗試 PoC
   ├── 取得初始存取
   └── 紀錄成功攻擊

6. Post-Exploitation
   ├── 提權 / Pivoting
   ├── 影響範圍（橫向移動）
   └── 持久化測試

7. Reporting
   ├── Executive Summary
   ├── 技術細節
   ├── 風險評估
   └── Remediation 建議

8. Re-testing
   └── 修補後驗證

Pen Test 範圍（汽車情境）

External Pen Test (整車外部)：
├── Cellular interface
├── Wi-Fi / Bluetooth
├── V2X (DSRC / C-V2X)
├── GNSS spoofing/jamming
├── RKE / PKE (key fob)
└── Backend (in scope per CIA)

Internal Pen Test (整車內部)：
├── OBD-II
├── CAN buses
├── Ethernet
├── USB ports
├── Charging interface (CCS, ChAdeMO)
└── Service interfaces

Hardware Pen Test：
├── JTAG / SWD
├── UART debug
├── Glitching (voltage/clock)
├── Side-channel (SPA/DPA)
└── Memory chip-off

2. Fuzzing

針對輸入處理元件：

fuzz_test_plan:
  targets:
    - "CAN message parser"
    - "Ethernet protocol stack"
    - "OTA payload parser"
    - "Diagnostic message handler"
    - "JSON/Protobuf parsers"
    - "TLS handshake (TCP/UDP)"

  tools:
    - AFL++ (Coverage-guided)
    - libFuzzer
    - Defensics (commercial)
    - Custom (for proprietary protocols)

  metrics:
    - "Code coverage achieved"
    - "Time to first crash"
    - "Unique crashes found"
    - "Hang/timeout incidents"

3. Red Team Exercise

Red Team 攻擊鏈範例（汽車）：
1. 偵察 OEM 雲端
2. 釣魚攻擊 OEM 員工
3. 取得內網存取
4. 入侵簽章伺服器
5. 簽署惡意韌體
6. 觸發 OTA 部署
7. 控制車隊

Validation 觀點：
完整鏈條的任何一環失敗 → 整體攻擊失敗

4. Vehicle-level Functional Test (with Security View)

Normal functional tests + 加入安全角度：

例：OTA 更新測試
├── 正常 OTA 過程：功能 OK + 簽章驗證 OK
├── 中斷情境：power loss、network loss
│   ↓ 攻擊者可否利用？
├── 異常封包：malformed、超長、replay
│   ↓ 是否被拒絕？
└── 故意失敗：tampered image
    ↓ 必須拒絕 + 紀錄

5. Side-Channel Analysis

針對加密實作：

DPA (Differential Power Analysis)
SPA (Simple Power Analysis)
EM Analysis
Timing Attack
Fault Injection (glitching)

對象：
├── HSM
├── 簽章運算（boot 階段）
└── TLS 握手

通常由外部專業實驗室執行（如 Riscure、Brightsight）。

6. Long-term Operational Test

針對「時間相關的弱點」：

測試項目：
├── 隨機數熵源衰退
├── 監控 log 滿溢
├── 憑證即將過期的行為
├── 軟體在長時間運行後的狀態
└── 對抗持續性攻擊（如低頻 fuzzing）

通常與功能可靠度測試合併。

Validation 與 TARA 的閉環

TARA 識別威脅情境
        ↓
Validation 嘗試實現這些情境
        ↓
   ┌────┴────┐
   ↓         ↓
成功阻擋    成功攻擊
   ↓         ↓
紀錄為      重新評估
證據         ↓
   ↓     更新 TARA
CS Case   更新處置

Validation 失敗的後果

Validation Pass → 進入 Assessment
Validation Fail → 修正 + 重測

可能後果：
├── 延後 Release
├── 修補設計（Clause 10 回流）
├── 重新 TARA
├── 修改 CS Goals / Concept
├── 殘餘風險接受（限低嚴重度）
└── 取消專案（極端情況）

Validation 報告分發

Validation Report 接收者：
├── Project CS Manager
├── Cybersecurity Assessor
├── Top Management (Release 決策者)
├── Safety Manager (可能交互影響)
├── 客戶（依 CIA）
└── 監管機構（如 UN R155 認證需要）

證照考點

Related Notes

• 08-Cybersecurity-Validation/01-Validation-Objectives
• 07-Product-Development/02-Integration-Verification
• 12-TARA-Methods/05-Attack-Path-Analysis
• 00-Dashboard/Exam-Traps#Trap 11

Practice

• 08-Cybersecurity-Validation/Practice-Validation