TARA 練習題

1. Asset Identification 資產識別
2. Threat Scenario Identification 威脅情境識別
3. Impact Rating 衝擊評等
4. Attack Path Analysis 攻擊路徑分析
5. Attack Feasibility Rating 攻擊可行性評等
6. Risk Value Determination 風險值判定
7. Risk Treatment Decision 風險處置決策
8. (持續監控與更新)

記憶：「找資產 → 想威脅 → 看後果 → 畫路徑 → 算難度 → 算風險 → 決定處置」

參考 12-TARA-Methods/01-TARA-Overview

B。Safety / Financial / Operational / Privacy
是 ISO 21434 衝擊評等的四個面向，每面獨立評估，取最高為 Overall。
參考 12-TARA-Methods/04-Impact-Rating

D. Very Low。

對應表：

Total Score	Attack Feasibility
0–13	High
14–19	Medium
20–24	Low
≥ 25	Very Low

分數越高 = 攻擊越困難 = Feasibility 越低。
30 分屬於 ≥ 25 區間，所以 Very Low。

這是 ISO 21434 最容易考錯的點——很多人直覺覺得 30 分高 = High Feasibility，錯！

參考 12-TARA-Methods/06-Attack-Feasibility-Rating、00-Dashboard/Exam-Traps#Trap 3

1. Attack Potential-based（業界最常用，源自 Common Criteria）
2. CVSS-based（適用已知 CVE）
3. Attack Vector-based（簡化方法）

三選一，但全公司一致使用。
參考 12-TARA-Methods/06-Attack-Feasibility-Rating

impact_rating:
  safety: Severe # 高速失控可致命
  financial: Major # 召回 + 賠償 + 品牌
  operational: Severe # 車輛無法安全駕駛
  privacy: Negligible # 不涉及 PII

  overall: Severe # max

注意：

• Safety 為 Severe 是主要驅動
• Operational 也為 Severe（功能完全失效）
• Privacy 可被忽略
• Financial 嚴重但不到 Severe（除非全車隊）

Overall = Severe（任一面 Severe 即 Severe）

參考 12-TARA-Methods/04-Impact-Rating

B。

比較	CAL	ASIL
標準	ISO 21434 (Annex E)	ISO 26262
領域	資安	功能安全
等級	1-4	QM, A-D
推導	Impact + Attack Vector	S × E × C
強制性	非強制	通常為標準要求

CAL 是 informative（Annex E）。
不可將兩者畫等號或混用。

參考 12-TARA-Methods/08-Risk-Treatment、13-Annexes-Tools/01-CAL-Cybersecurity-Assurance-Level、00-Dashboard/Exam-Traps#Trap 2

Avoid（避免） / Reduce（降低） / Share or Transfer（轉移） / Retain（保留 / 接受）

選項	適用
Avoid	移除功能/設計變更
Reduce	加入資安控制（最常見）
Share/Transfer	給供應商/保險（需驗證對方）
Retain	接受作為殘餘風險（需文件化 + 適當層級簽核）

參考 12-TARA-Methods/08-Risk-Treatment

錯誤——Risk Value 5 通常不可直接 Retain。

問題：

1. 組織政策通常禁止 Retain Very High Risk
2. 「修補成本過高」不是充分理由
3. 即使要 Retain，需 VP/CTO 層級接受（不是開發團隊）
4. Cybersecurity Assessment 會拒絕
5. 不可 Release 至 Post-Development

正確做法：

1. 嘗試 Reduce：加入資安控制降低 feasibility 或 impact
2. 若 Reduce 不可行，考慮 Avoid：移除功能
3. 若仍要 Retain（極少數情況）：
   • 詳細風險評估
   • 補償措施（如監控、限制使用情境）
   • 高層級書面接受（CTO 或更高）
   • 完整文件化於 CS Case
   • 持續監控觸發升級條件

不可：

• 為趕進度 Retain
• 由 Project Manager 私自接受

參考 12-TARA-Methods/08-Risk-Treatment、03-Project-Dependent/07-Release-for-Post-Development

C。

Damage Scenario：「車輛在高速公路失控撞擊」（後果）
         ↑
         │ 由以下手段達成
         │
Threat Scenario：「攻擊者透過 OBD 注入偽煞車 CAN 訊息」（過程）

參考 12-TARA-Methods/03-Threat-Scenario、00-Dashboard/Exam-Traps#Trap 12

總分 = 0 + 3 + 3 + 1 + 4 = 11

對應 Feasibility：

• 0-13 → High (容易)

結論：Attack Feasibility = High

此情境可能是「使用商業 CAN tool 從 OBD 注入偽 CAN 訊息」——熟手在數小時內就能完成。

參考 12-TARA-Methods/06-Attack-Feasibility-Rating

對照矩陣：

               Very Low  Low    Medium   High
Severe         2         3      4        5
Major          1         2      3        4
Moderate       1         1      2        3
Negligible     1         1      1        2

Major × Medium = 3

Risk Value = 3 (Medium)

此風險通常需評估後決定處置（不一定要 Reduce，但需文件化）。

參考 12-TARA-Methods/07-Risk-Determination

理由：保守原則 + 攻擊者選擇權

1. 攻擊者選擇權：
   • 攻擊者不會選最難的路
   • 一定會選成本最低、最快、最容易的路
   • 評估「最容易」反映真實攻擊情境
2. 保守原則：
   • 低估容易度 → 低估風險 → 防護不足
   • 高估容易度 → 過度防護（成本高但不致命）
   • 兩權相害取其輕：寧可過度防護
3. 多路徑時：
   • 識別所有路徑
   • 評估每條的 feasibility
   • 取 max(feasibility) = 最容易那條
4. 防禦含意：
   • 想降低風險 → 必須降低「最容易那條」的 feasibility
   • 若多條都同樣容易 → 需多管齊下
5. 與 Risk Treatment 連動：
   • 處置後若該路徑被堵住，第二容易的路徑成為新的「最容易」
   • 需重評

參考 12-TARA-Methods/05-Attack-Path-Analysis、12-TARA-Methods/06-Attack-Feasibility-Rating

Step 3：Impact Rating (SFOP)

Safety: Negligible (不直接影響行車安全)
Financial: Moderate (品牌損害、客戶流失)
Operational: Negligible (功能仍可用)
Privacy: Major (位置追蹤、跟監風險)
→ Overall: Major

Step 4：Attack Path Analysis

路徑 A：Rogue base station + 沒有 TLS
  - 不適用（已有 TLS 1.3）
路徑 B：TLS Cert validation bypass
  - 需找 CA 或實作弱點
路徑 C：Hijack DNS + cert pinning bypass
  - 需 device 無 cert pinning
路徑 D：Compromise OEM CA
  - 極困難

Step 5：Feasibility (路徑 B 為例)

Time: 4 (< 1 month)
Expertise: 6 (Expert)
Knowledge: 3 (Restricted)
Window: 4 (Moderate)
Equipment: 4 (Specialized)
Total: 21 → Low Feasibility

Step 6：Risk Determination

Impact: Major × Feasibility: Low
Risk Value: 2 (Low)

Step 7：Risk Treatment

Risk Value 2 通常可 Retain，但 Privacy Major 需謹慎：

決策：Reduce (額外控制)
  • 已實作：TLS 1.3 + Cert pinning + Per-device cert (mTLS)
  • 補強：Perfect Forward Secrecy、 連線異常通報
  • Privacy 額外：位置資料加密 at rest、最小化收集、匿名化

接受者：CS Manager + Privacy Officer
殘餘風險：1 (Very Low) — 接受
持續監控：TLS 弱點 CVE 追蹤、加密演算法演進

對應 CS Goal：

• CG-XXX：車輛位置資料的機密性應被保護免於蜂巢通訊中的中間人攻擊。

參考所有 12-TARA-Methods/02-Asset-Identification 至 12-TARA-Methods/08-Risk-Treatment

B。
CAL（Annex E）由 Impact 與 Attack Vector 推導。
注意：是 Attack Vector（網路/實體等向量），不是 Attack Feasibility。

參考 13-Annexes-Tools/01-CAL-Cybersecurity-Assurance-Level

TARA Step 1-2: Assets + Threats
   ↓
   → 識別需保護的 Asset/Property

TARA Step 3: Impact
   ↓
   → 決定 SFOP 衝擊
   → 影響 CAL 推導
   → 影響後續 Validation 嚴格度

TARA Step 4-5: Attack Path + Feasibility
   ↓
   → 識別攻擊面
   → 影響架構設計（Trust Boundary）
   → 影響 Pen Test 範圍

TARA Step 6: Risk Value
   ↓
   → 排序處置優先級
   → 影響資源分配

TARA Step 7: Treatment Decision
   ↓
   → 產生 Cybersecurity Goals（Reduce / Avoid 情境）
   → 產生 Cybersecurity Claims（Transfer / Out-of-scope 情境）
   → 接受的 Retain → 殘餘風險紀錄

Cybersecurity Goals
   ↓
   → Cybersecurity Concept（如何達成）
   → Cybersecurity Requirements（可實作）
   → Architecture Design
   → Implementation
   → Verification（驗證 Requirements）
   → Validation（驗證 Goals 在車輛級達成）
   → Cybersecurity Case（論證 Goals 達成）
   → Assessment（評估 Case 是否成立）
   → Release for Post-Development

Post-Development：
   → Production Controls
   → Operations + Incident Response
   → Updates + Vulnerability Management
   → EoS + Decommissioning

同時 Clause 8 Continual Monitoring：
   → 觸發 TARA 重新評估（閉環）

核心啟示：TARA 是「車輛資安整體生命週期」的引擎。錯誤的 TARA → 後續所有活動都受影響。

因此 TARA 必須：

• 完整（不遺漏 Asset / Threat）
• 準確（評等正確）
• 持續更新（隨情境變化）
• 文件化（可追溯）

參考 12-TARA-Methods/01-TARA-Overview、01-Foundations/04-Lifecycle-Overview