# CYBERSEC 2025 台灣資安大會 - 4月17日 演講心得分享

## 目錄
- [上午場](#toc-17-morning)
- [議程：關鍵基礎設施場域資安實現：應對工控場域資安挑戰的全面驗證與評估方案](#toc-17-ot)
- [議程：以資料保護設計為預設的系統實踐思維](#toc-17-dpbd)
- [議程：透過深度神經網路(DNN)攻擊來學習 OWASP](#toc-17-dnn)
- [議程：矛盾大對決：開源後門程式對開源防禦平台剖析](#toc-17-backdoor)
- [下午場](#toc-17-afternoon)
- [議程：生成式 AI 合規技術與挑戰](#toc-17-genai-compliance)
- [議程：神經級逆向技藝：從人機翻譯到全自動符號語義推理模型，打造仿生逆向聖杯](#toc-17-nmt-re)
- [議程：大型語言模型驗測革命：LLM-as-a-Judge 的實踐與挑戰](#toc-17-llm-judge)
- [議程：從 HR 的觀點看資安證照的潛力與價值](#toc-17-hr-cert)
- [議程：當 GenAI 從雲端降落到車載，深入淺出軟韌體、硬體架構與風險](#toc-17-genai-auto)

## 議程理解與整體脈絡

4 月 17 日作為大會的最後一天，議程聚焦於特定領域的深度探討與新興議題。上午場涵蓋了關鍵基礎設施 (OT/ICS) 的資安驗證標準、系統開發中的資料保護設計 (DPbD) 思維、AI/ML 自身的安全風險 (OWASP ML Top 10)，以及開源攻防工具的對決分析。下午場則持續關注 AI 議題，探討生成式 AI 的合規挑戰、利用 AI 進行更深層次的逆向工程、創新的 LLM 驗測方法 (LLM-as-a-Judge)，並從人才角度探討資安證照的價值，最後以車用 GenAI 的安全風險作為壓軸，展現了從工業控制、軟體開發、AI 安全、人才發展到前瞻應用安全的多元面向。

---

<a id="toc-17-morning"></a>
## 上午場

<a id="toc-17-ot"></a>
### **議程：關鍵基礎設施場域資安實現：應對工控場域資安挑戰的全面驗證與評估方案**

#### 1. 基本資訊
* **議程標題：** 關鍵基礎設施場域資安實現：應對工控場域資安挑戰的全面驗證與評估方案
* **講者：** 林上智 (SZ Lin)（國際自動化協會 臺灣分會 會長 / IEC 62443 國家標準委員）
* **時間與地點：** 09:30-10:00 | 7F 701H
* **關鍵字：** `OT Security`, `ICS/SCADA Security`, `Cyber-Physical System Security`, `ISA/IEC 62443`, `ISASecure`, `Certification`, `Risk Assessment`, `Site Assessment`

#### 2. 內容摘要
* **核心訊息：** 面對日益增長的工控 (OT) 場域資安攻擊，僅有產品或系統層級的驗證已不足夠。國際標準 ISA/IEC 62443 已成為 OT 資安的關鍵依據，而 ISASecure 推出的「場域評估 (Site Assessment)」驗證方案 (ACSSA)，旨在將標準落地，評估實際場域中資產擁有者、服務提供商的管理系統與流程是否到位，以應對「有技術卻未落實」的挑戰，確保 OT 環境的整體安全。
* **關鍵論點：**
* **OT 攻擊現況嚴峻：** 引用歐盟數據，針對關鍵基礎設施與工控系統的攻擊頻繁 (日均 3-6 起已知攻擊)。
* **國際共識與標準：** 美歐多國安全機構聯合發布白皮書，建議 OT 擁有者採購符合 Secure by Design 及 **ISA/IEC 62443** 標準的產品與系統。IEC 網站亦明確將 62443 定位為 OT 領域的水平標準 (如同 IT 的 27001)。
* **ISA/IEC 62443 框架：**
* 源於 ISA，後與 IEC 合作，涵蓋一般流程、系統、產品及特定行業 Profile。
* 適用範圍廣泛：電力、石油、製造、交通、樓宇、半導體等。
* 成為歐盟 CRA、RED 等法規的基礎。
* *(提及標準可能更名為 ACS 或 OT 以擴大適用性)*
* **ISASecure 驗證方案演進：**
* **目標：** 將標準文字轉化為可實作、可溝通、一致性的驗證方法。
* **現有方案：**
* SDLA (4-1): 安全產品開發生命週期。
* SSA (3-3): 系統安全功能要求。
* CSA (4-2): 元件 (產品) 安全功能要求。
* ICSA (IIoT): 工業物聯網設備特定要求。
* **場域驗證 (Site Assessment - ACSSA) 的必要性：**
* **問題根源：** 即使產品/系統通過驗證，場域仍頻繁出事。
> **講者引用/強調：** "為什麼我們有現場的開發的過程，為什麼我們系統跟產品有安全功能通過驗證...還是有所謂的資安事件?"
* **三大實務痛點：**
1. **有技術，沒政策：** 人員不知如何正確使用或配置安全功能。
2. **有政策/技術，沒啟用/落實：** 人為疏失或認知不足導致安全功能未開啟。
3. **有技術/政策/啟用，但服務商(SI)不知：** 委外廠商缺乏對應知識或流程，導致事件處理延遲或不當。
* **核心理念：** 場域驗證**不是驗狀態，而是驗管理系統與流程**是否到位。
* **ACSSA 場域驗證方案：**
* **整合標準：** 融合 2-1 (資產擁有者安全計畫)、2-4 (服務提供商要求)、3-2 (風險評估)、3-3 (系統安全要求) 等多項 62443 標準。*(註：2-3 補丁管理待其成為國際標準後納入)*
* **評估核心：**
1. 檢視風險評估結果 (確定安全等級 SL-T)。
2. 評估資產擁有者的安全流程 (2-1)。
3. 評估場域系統的管理與啟用狀態 (3-3，著重管理面而非功能有無)。
4. 評估服務提供商 (整合商/維護商) 的流程與能力 (2-4)。
* **兩種模式：**
* **檢驗 (Inspection - 17020):** 一次性評估，可接受較低成熟度 (SL1)，無證書，作為改善參考。
* **驗證 (Certification - 17065):** 需達成熟度三 (SL3，流程文件化、已實施、已認知)，有證書，需年度監督與三年重評。
* **客製化與彈性：** 可依場域特性調整評估範圍，可選擇是否公開證書 (避免成攻擊目標)。
* **共同方法：** 無論檢驗或驗證，技術評估方法一致。
* **未來挑戰與發展：**
* 多場域驗證的簡化方法 (抽樣、中央政策評估)。
* 評估員 (Assessor) 的專業能力培訓 (需懂 62443 且能與現場人員溝通)。
* 針對不同產業制定更細緻的場域驗證 Profile。

#### 3. 技術(或政策)與實務區塊
* **主要技術/政策要點：**
* **OT/ICS 安全標準：** **ISA/IEC 62443** 系列標準的結構與核心內容 (尤其 2-1, 2-4, 3-2, 3-3, 4-1, 4-2)。
* **OT 資安驗證方案：** **ISASecure** (SDLA, SSA, CSA, ICSA) 以及最新的 **ACSSA (場域評估)**。
* **風險評估與安全等級 (Risk Assessment & Security Levels - SL):** 在 OT 場域的應用 (識別 SL-T)。
* **管理系統稽核：** 場域驗證的核心是評估管理流程與機制，而非僅技術功能。
* **成熟度模型 (Maturity Levels):** 驗證模式與成熟度要求 (SL1 vs SL3)。
* **供應鏈安全 (Supply Chain Security):** 涵蓋服務提供商 (SI) 的安全要求 (2-4)。
* **實務應用方法：**
* **資產擁有者：**
* 理解 62443 標準對自身 (2-1) 與委外廠商 (2-4) 的要求。
* 進行場域風險評估 (3-2)，定義目標安全等級 (SL-T)。
* 要求供應商提供符合 62443 的產品/系統 (4-1, 4-2, 3-3)。
* 考慮進行 ISASecure ACSSA 檢驗或驗證，評估自身管理流程成熟度。
* **系統整合商/服務提供商：**
* 遵循 62443-2-4 要求，建立對應的安全服務流程。
* 確保交付的系統符合資產擁有者要求的 SL 等級 (3-3)。
* **產品製造商：**
* 導入安全開發流程 (4-1)，取得 SDLA 驗證。
* 確保產品符合對應的安全等級功能要求 (4-2)，取得 CSA 驗證。
* **產業趨勢/發展方向：**
* ISA/IEC 62443 成為全球 OT/ICS 資安的共通語言與要求基準。
* 資安驗證從產品/系統層級延伸至**實際運行場域的管理流程**。
* 對 OT 環境中「人」與「流程」的重視程度提升。
* 供應鏈安全 (含服務提供商) 成為 OT 資安不可或缺的一環。

#### 4. 價值評估
* **獨特價值與亮點：**
* **權威性與前瞻性：** 由標準制定參與者介紹最新的國際 OT 場域驗證方案 (ISASecure ACSSA) 的背景、內容與目標。
* **解決實務痛點：** 直接回應業界「有標準、有產品，為何仍出事」的困境，提出從管理系統與流程入手的解方。
* **框架整合視角：** 清晰說明場域驗證如何整合 62443 系列中針對不同角色 (擁有者、服務商、系統) 的標準要求。
* **理念傳達：** 強調驗證的核心是「管理系統與流程」而非「當下狀態」，更具持續性價值。
* **對資安產業的意義：**
* **推動標準落地：** ACSSA 方案有助於將 62443 標準從紙本要求轉化為可在實際場域驗證的實踐。
* **提升 OT 安全水位：** 透過關注管理流程，有望系統性地降低因人為或流程因素導致的資安事件。
* **建立共通評估基準：** 為 OT 場域的資安成熟度提供更客觀、一致的評估方法。
* **促進供應鏈協同：** 強調資產擁有者、服務商、製造商在 OT 安全上的共同責任。
* **實際工作應用潛力：**
* **CI/OT 營運者：** 可將 ACSSA 作為內部稽核或委外評估的框架，檢視自身管理流程的成熟度。
* **資安顧問/稽核單位：** 可依循 ACSSA 的方法論，為客戶提供 OT 場域的風險評估與改善建議。
* **政府監管機構：** 可參考此國際驗證方案，制定國內 CI/OT 場域的查核標準。
* **SI/服務提供商：** 需了解 2-4 要求並建立對應流程，以滿足客戶未來可能提出的驗證需求。

---

<a id="toc-17-dpbd"></a>
### **議程：以資料保護設計為預設的系統實踐思維**

#### 1. 基本資訊
* **議程標題：** 以資料保護設計為預設的系統實踐思維 (Practical Thinking on Systems with Data Protection by Design as Default)
* **講者：** 林逸塵（個人資料保護委員會籌備處 隱私科技組 組長）
* **時間與地點：** 10:15-10:45 | 7F 702
* **關鍵字：** `Data Protection`, `Data Security`, `Software Security`, `Privacy by Design`, `DPbD`, `Compliance`, `System Development`, `GDPR`, `SDLC`, `FIPPS`

#### 2. 內容摘要
* **核心訊息：** 資料保護設計 (Data Protection by Design and by Default, DPbD²) 不應僅是法規遵循的要求，更應內化為系統開發與組織營運的核心思維。本演講追溯其源頭 (FIPPS, Privacy by Design)，闡述其七大原則，並說明如何在系統開發生命週期 (SDLC) 的各階段融入 DPbD² 考量，以預防性、系統性地降低個資風險，實現保護與應用雙贏。
* **關鍵論點：**
* **DPbD² 的概念演進：**
* **源頭：** 美國 FIPPS (Fair Information Practice Principles, 1973) 強調透通、目的限制、當事人參與、最小化、安全、品質、當責等原則。
* **發展：** 加拿大 Ann Cavoukian 博士提出 Privacy by Design (PbD) 七大原則 (90年代)，強調主動預防、預設保護、內嵌設計、正和(功能與隱私雙贏)、端到端生命週期安全、透明可見、使用者中心。PbD 範圍被認為超越 FIPPS。
* **標準化：** Global Privacy Standard (GPS) 進一步對應 PbD 原則與具體要求。
* **最終呈現 (本演講焦點):** Data Protection by Design and by Default (DPbD²)，強調在系統設計之初就將資料保護作為預設考量。
* **DPbD² 的核心理念：**
* **哲學層面：** 將個資保護視為理所當然，如同安全帶或紅綠燈，應自然融入系統與流程。
> **講者引用/強調：** "當這個哲學深入你的心，你會覺得說個資保護那個很自然，不是本來就應該這樣做嗎？"
* **應用範圍：** 涵蓋技術、業務、營運、物理架構、管理、基礎設施等整個資訊生態系治理。
* **目標：** 實現隱私保護與系統功能性的「正和雙贏 (Positive-sum)」，而非零和取捨。
* **DPbD² 的組成要素：** 組織面 (政策、風險管理) + 技術面 (ICT Controls - 如 NIST SP 800-53)。
* **DPbD² 的七大原則 (源自 PbD)：**
1. **主動而非被動 (Proactive not Reactive):** 事前預防，而非事後補救。
2. **預設隱私保護 (Privacy as the Default):** 最高保護設定為預設值，無需使用者自行調整。
3. **內嵌於設計 (Privacy Embedded into Design):** 保護措施應整合於系統核心架構，而非外加。
4. **全功能正和 (Full Functionality - Positive-Sum):** 兼顧保護與功能，避免為了保護而犧牲可用性。
5. **端到端生命週期安全 (End-to-End Security):** 從資料收集到銷毀的全程保護。
6. **可見性與透明度 (Visibility and Transparency):** 讓使用者與監管者清楚了解資料處理方式。
7. **尊重使用者隱私 (Respect for User Privacy):** 以使用者為中心設計。
* **DPbD² 在 SDLC 的實踐：**
* **表格：DPbD² 於 SDLC 各階段的考量**
| SDLC 階段 | DPbD² 實踐要點 | 相關技術/原則 |
| :--------------- | :------------------------------------------------------------------------------------------------------------ | :---------------------------------------------- |
| **需求 (Req.)** | **資料保護影響評估 (DPIA)**, 界定目的, 資料最小化評估, 風險緩解規劃 | FIPPS, PbD 原則, 風險評估 |
| **設計 (Design)** | **資料最小化設計**, 識別個資欄位, **去識別化/匿名化** 評估, 設計告知同意機制 (分層通知), 規劃存取控制 (MAC, RBAC) | Data Minimization, Pseudonymization, Consent Mgmt |
| **開發 (Dev.)** | **安全編碼實踐 (Secure Coding)**, 避免 Test Free 欄位風險, 設計加密/遮罩機制, **安全程式碼審查 (Code Review)** | OWASP Secure Coding, Input Validation, Encryption |
| **測試 (Test)** | **使用者驗收測試 (UAT)** (從隱私角度), 驗證存取控制, 檢查 SQL Joins 風險, **滲透測試/弱點掃描** | UAT, Pentest, Vulnerability Scanning |
| **部署 (Deploy)**| **安全組態設定**, 預設啟用隱私保護功能, 提供**使用者自我管理介面** (查閱、更正、刪除) | Secure Configuration, User Control Interface |
| **維運 (Maintain)**| **設備管理 (MDM)**, **資料加密 (儲存/傳輸)**, **匿名化/假名化**, **日誌記錄與監控**, **過期資料管理**, 資料更新 | MDM, Encryption (At-rest, In-transit), Logging |
* **實踐挑戰與好處：**
* 挑戰：需要組織文化轉變，開發人員需具備 DPbD² 意識，可能涉及額外成本。
* 好處：預防勝於治療，早期融入設計可**降低後期修改成本與延遲**，提升使用者信任，符合法規要求，建立競爭優勢 (如 Apple 強調隱私)。
* **重要案例/數據：** FIPPS 九宮格原則、PbD 七大原則、GDPR 十大原則與 PbD 對照、DPIA 範例 (差勤系統)、Metadata 風險 (數位照片 EXIF)、告知同意分層通知、Apple 隱私報告、Google 廣告沙盒案例。

#### 3. 技術(或政策)與實務區塊
* **主要技術/政策要點：**
* **資料保護原則：** **FIPPS**, **Privacy by Design (PbD) 七大原則**。
* **法規遵循 (Compliance):** 隱含 GDPR 等法規對 DPbD² 的要求。
* **風險評估方法：** **資料保護影響評估 (DPIA)**。
* **隱私強化技術 (PETs - Privacy Enhancing Technologies):** **資料最小化 (Data Minimization)**, **假名化 (Pseudonymization)**, **匿名化 (Anonymization)**, **加密 (Encryption)**。
* **安全開發生命週期 (Secure SDLC):** 將 DPbD² 融入 SDLC 各階段。
* **存取控制模型 (Access Control):** DAC, MAC, RBAC。
* **使用者控制 (User Control):** 提供使用者查閱、更正、刪除個資的機制。
* **實務應用方法：**
* **組織文化導入：** 將 DPbD² 思維納入開發人員、PM、DPO 的培訓與要求。
* **流程整合：** 在 SDLC 流程中明確加入 DPIA、隱私設計審查、UAT (隱私角度) 等環節。
* **工具應用：** 利用 PETs 技術降低個資暴露風險。
* **政策制定：** 建立清晰的個資收集、處理、儲存、銷毀政策。
* **告知同意設計：** 採用分層、易懂的方式向使用者說明個資處理方式並取得同意。
* **預設值設定：** 新系統或功能上線時，將最高隱私保護設為預設選項。
* **產業趨勢/發展方向：**
* 隨著個資法規日益嚴格 (如 GDPR, CCPA)，DPbD² 從「nice-to-have」變為「must-have」。
* 隱私工程 (Privacy Engineering) 成為新興專業領域。
* PETs 技術持續發展，應用場景擴大。
* 使用者對個資掌控權的要求提高。

#### 4. 價值評估
* **獨特價值與亮點：**
* **概念溯源與釐清：** 清晰梳理了 DPbD² 概念的歷史演進 (FIPPS -> PbD -> DPbD²)，並闡述其核心原則。
* **SDLC 整合框架：** 提供了將抽象的 DPbD² 原則具體落實到 SDLC 各階段的實用框架與考量點。
* **在地視角：** 由個資保護主管機關籌備處代表分享，觀點具官方參考價值。
* **理念倡導：** 強調 DPbD² 不僅是技術或法規問題，更是組織文化與設計哲學。
* **對資安產業(及軟體開發領域)的意義：**
* **提升隱私意識：** 強調在系統開發早期就需考慮資料保護，有助於產業整體提升隱私保護水平。
* **提供實踐方法：** 為開發團隊、PM、法遵人員提供了如何在實務中導入 DPbD² 的具體指引。
* **促進跨領域合作：** 凸顯了資料保護需要 IT、開發、法務、業務等多方協作。
* **實際工作應用潛力：**
* **開發團隊/PM：** 可直接將 SDLC 整合框架應用於新專案的規劃與執行。
* **法遵/DPO：** 可利用此框架檢視公司現有系統與流程是否符合 DPbD² 要求。
* **內部培訓：** 可作為對開發人員進行資料保護設計培訓的教材。
* **供應商管理：** 在委外開發或採購系統時，可將 DPbD² 作為評估要求之一。

---

<a id="toc-17-dnn"></a>
### **議程：透過深度神經網路(DNN)攻擊來學習 OWASP**

#### 1. 基本資訊
* **議程標題：** 透過深度神經網路(DNN)攻擊來學習 OWASP Machine Learning Security Top 10
* **講者：** 徐育正（合作金庫商業銀行 資安部 二等專員）
* **時間與地點：** 11:00-11:30 | 1F 展區會議室 1B
* **關鍵字：** `AI`, `AI Safety`, `AI Security`, `Machine Learning Security`, `OWASP ML Top 10`, `Adversarial Attacks`, `Data Poisoning`, `Model Inversion`, `Membership Inference`, `Model Stealing`, `Backdoor Attack`

#### 2. 內容摘要
* **核心訊息：** 本演講旨在透過實際攻擊深度神經網路 (DNN) 的手法，對應並解釋 OWASP Machine Learning Security Top 10 中的安全風險。講者從機器學習基礎概念入手，介紹 DNN 的結構與訓練原理，並以 MNIST 手寫辨識模型為攻擊標靶，演示了包括對抗式樣本攻擊、資料中毒、模型反演、模型後門等多種攻擊的原理與效果，藉此提升聽眾對 ML/AI 安全風險的具體認知。
* **關鍵論點：**
* **機器學習基礎：**
* 定義：讓電腦從資料中自動學習規律，並利用規律預測未知資料。
* 類比人類學習：模型 ~ 大腦，訓練資料 ~ 書籍/答案，訓練階段 ~ 學習/內化，部署階段 ~ 解決問題。
* 生命週期：訓練階段 (模型+資料->訓練->部署模型) vs. 部署階段 (使用者請求->推論->回應)。
* 四大元件：硬體、軟體、模型 (結構+參數)、資料 (訓練+請求/回應)。攻擊者可針對不同階段、不同元件下手。
* **深度神經網路 (DNN) 基礎：**
* 簡介神經元運算 (線性組合 + 激勵函數)。激勵函數用於引入非線性。*(提及激勵函數與 DoS 攻擊關聯)*
* 基本結構：輸入層、隱藏層 (0 或多層)、輸出層。
* 學習原理 (三步驟)：
1. **前向傳播 (Forward Propagation):** 輸入資料，模型產生預測結果。
2. **計算損失 (Loss Function):** 比較預測結果與真實標籤 (Ground Truth) 的差異 (如均方差 MSE、交叉熵 Cross-Entropy)。目標是最小化損失。
3. **反向傳播 (Backward Propagation):** 計算損失函數對模型參數的梯度 (偏微分)，利用梯度下降法 (Gradient Descent) 更新參數 (W_new = W_old - learning_rate * gradient)，使損失變小。重複此過程直到收斂。
* **攻擊目標：MNIST 手寫辨識模型** (輸入 28x28 圖像 -> 784 維向量 -> 隱藏層 128 維 -> 輸出層 10 維機率分佈)。
* **OWASP ML Top 10 攻擊演示與原理 (選講)：**
* **ML01: 輸入操控攻擊 (Input Manipulation / Adversarial Attack - 白箱):**
* 概念：對輸入資料添加人眼難以察覺的微小擾動 (雜訊)，導致模型輸出錯誤的預測結果。
* 攻擊算法 (FGSM - Fast Gradient Sign Method): 計算損失函數對**輸入圖片**的梯度，沿**梯度方向** (而非反方向) 更新圖片，使損失**最大化**。
* 演示：原始為 "3" 的圖片，加入微小擾動後，肉眼仍看似 "3"，但模型誤判為 "8"。
* **ML02: 資料中毒/污染 (Data Poisoning / ML08: 不安全的訓練資料):**
* 概念：攻擊者操控訓練資料，植入惡意樣本或錯誤標籤，破壞模型性能或植入後門。
* **標籤翻轉 (Label Flipping):** 將訓練資料打上錯誤標籤 (e.g., 貓標為狗)，模型學到錯誤知識。
* **目標式中毒 (Targeted Poisoning):** (更隱蔽) 製作一個看起來像 "7" (基底) 但特徵空間接近 "9" (目標) 的中毒樣本。訓練時，人類標註者會標為 "7"，但模型會學到將接近 "9" 特徵的樣本判斷為 "7"，導致模型在預測真實 "9" 時出錯 (邊界偏移)。
* **ML03: 模型反演攻擊 (Model Inversion):**
* 概念：攻擊者僅能接觸到模型的輸出 (黑箱或灰箱)，試圖反推出部分或全部訓練資料的資訊。
* 攻擊方法 (基於 Autoencoder 概念)：
1. 訓練一個攻擊模型 (Decoder)，輸入為目標模型的輸出 (機率分佈)，輸出為原始輸入圖像。
2. 將目標模型與攻擊模型串聯。
3. 凍結目標模型參數，僅訓練攻擊模型，目標是讓串聯後的輸出盡可能接近原始輸入 (這邊講者似乎將目標設為還原特定類別的代表性圖像)。
4. 訓練完成後，給定一個代表 "7" 的輸出向量 (index 7 為 1)，輸入攻擊模型，即可生成一張具有 "7" 特徵的圖像 (雖然可能模糊)。
* **ML04: 成員推斷 / ML07: 模型竊取 (Membership Inference / Model Stealing):**
* **成員推斷：** 判斷某筆資料是否曾被用於訓練模型 (洩漏隱私)。
* **模型竊取 (遷移學習攻擊)：** 利用目標模型的輸出訓練一個替代模型 (Shadow Model)，其行為與目標模型相似，然後再利用替代模型進行其他攻擊 (如成員推斷)。
* 攻擊流程：準備相似資料 -> 用目標模型輸出訓練 Shadow Model -> 用 Shadow Model 訓練 Attack Model -> 用 Attack Model 攻擊 Target Model。
* **ML05: 模型檔案竊取 (Model Stealing - Physical Access):** 模型結構、算法、參數是商業機密，被竊取會造成損失，並降低後續攻擊門檻 (黑箱變白箱)。
* **ML06: 供應鏈攻擊 (Supply Chain Attack):**
* 攻擊 ML 生命週期的元件 (硬體、軟體、模型、資料)。
* **模型檔案植入惡意代碼:** (重點演示)
* PyTorch (`.pth`/`.pt`) 使用 Pickle 格式，反序列化時可執行任意程式碼 (透過 `__reduce__` 魔術方法)。
* TensorFlow/Keras (`.h5`) 使用 HDF5 格式，可嵌入 Lambda 層執行惡意程式碼。
* 演示：利用工具修改 `.pkl` 或 `.h5` 模型檔，植入打開計算機的指令，使用者載入模型時觸發 RCE。
* **ML09: 不安全的模型輸出 (Output Integrity):** 操控模型輸出，使其產生錯誤或有害結果 (與 ML01/ML02 相關，但更側重輸出結果的影響)。(舉例：修改 Loss Function 使模型傾向輸出特定結果)。
* **ML10: 模型阻斷服務 (Model Denial of Service - MoDoS / AI DoS):** 操控模型結構或參數，使其運作異常或性能下降。
* **模型後門 (Backdoor Attack):** (重點演示)
* 概念：在模型中植入隱藏觸發器 (Trigger)，平時表現正常，遇到觸發器時輸出錯誤結果。
* 結構型後門：增加一個判斷 Trigger 的分支，影響最終輸出。
* 參數型後門 (更隱蔽)：修改模型權重，使得遇到 Trigger 時的激活路徑導向錯誤結果。
* 演示：設計一個判斷白色倒三角 Trigger 的網絡，將其輸出與原模型輸出結合，透過特殊設計的權重矩陣，在 Trigger 出現時強制輸出 "9"，否則輸出原模型結果 ("7")。
* **與大型語言模型 (LLM) 的差異：** LLM 架構更複雜 (Transformer, Self-Attention)，參數更多 (數十億至兆)，開發流程更長，攻擊面更廣 (Prompt Injection, Agent/Plugin 風險)。
* **結語：** AI 安全是新興且重要的議題，需持續關注其風險與防禦方法。

#### 3. 技術(或政策)與實務區塊
* **主要技術/政策要點：**
* **機器學習基礎：** 監督式/非監督式學習, 訓練/部署階段, 四大元件。
* **深度神經網路：** 神經元, 激勵函數, 前向/反向傳播, 損失函數, 梯度下降。
* **OWASP ML Top 10 風險:**
* **對抗式攻擊 (Adversarial Attack):** FGSM 算法原理。
* **資料中毒 (Data Poisoning):** 標籤翻轉, 目標式中毒。
* **模型反演 (Model Inversion):** Autoencoder 概念應用。
* **成員推斷/模型竊取 (Membership Inference/Model Stealing):** Shadow Model 訓練。
* **模型檔案攻擊：** Pickle/HDF5 格式漏洞, RCE。
* **模型後門 (Backdoor Attack):** 結構型/參數型後門原理與實現。
* **ML 安全生命週期：** 在訓練與部署階段都需要考慮安全。
* **實務應用方法：**
* **風險意識：** 開發或使用 ML/AI 系統時，需認知到 OWASP ML Top 10 所揭示的風險。
* **安全測試：** 將對抗式攻擊、資料中毒防禦、模型健壯性測試納入 AI 模型的驗證流程。
* **供應鏈安全：** 審慎檢查來源不明的模型檔案，使用安全的反序列化方法或進行掃描。
* **訓練資料管理：** 確保訓練資料的品質與安全，防止被污染。
* **模型監控：** 部署後持續監控模型的輸入、輸出與行為，偵測異常。
* **安全開發實踐：** 將安全設計原則融入 ML 模型的開發過程。
* **產業趨勢/發展方向：**
* AI/ML 安全成為獨立且重要的研究領域。
* 針對 AI/ML 的攻擊手法不斷演進，防禦技術也需跟上。
* 需要更標準化、自動化的 AI 安全測試與驗證工具。
* 將安全考量融入 MLOps (AI 開發運維) 流程成為趨勢。

#### 4. 價值評估
* **獨特價值與亮點：**
* **攻擊實踐導向：** 以實際攻擊演示對應 OWASP ML Top 10 風險，使抽象概念具象化，易於理解。
* **技術深度：** 深入淺出地解釋了多種 ML 攻擊的核心原理與實現步驟 (FGSM, Targeted Poisoning, Model Inversion, Backdoor 等)。
* **結構化知識：** 將複雜的 ML 安全風險系統性地對應到 OWASP 框架，便於學習與記憶。
* **案例清晰：** 使用 MNIST 模型作為統一的攻擊目標，方便比較不同攻擊手法的效果。
* **對資安產業(及AI應用領域)的意義：**
* **提升 ML 安全意識：** 有效地向開發者、資安人員普及了機器學習系統面臨的獨特安全風險。
* **提供攻擊視角：** 讓防禦者了解攻擊者的思路與可能採用的手法，有助於設計更有效的防禦策略。
* **推廣 OWASP 標準：** 透過實例演示，提高了 OWASP ML Top 10 的能見度與應用價值。
* **實際工作應用潛力：**
* **AI 開發人員：** 可藉此了解自身開發的模型可能面臨的攻擊，在設計與訓練階段加入防禦考量。
* **資安測試人員 (紅隊)：** 提供了多種可實際操作的 ML 模型攻擊思路與技術細節。
* **資安防禦人員 (藍隊)：** 理解攻擊原理有助於設計更有效的監控與偵測規則。
* **資安教育訓練：** 可作為 ML/AI 安全培訓的絕佳入門教材與實作參考。

---

<a id="toc-17-backdoor"></a>
### **議程：矛盾大對決：開源後門程式對開源防禦平台剖析**

#### 1. 基本資訊
* **議程標題：** 矛盾大對決：開源後門程式對開源防禦平台剖析
* **講者：** 高于凱（勤業眾信聯合會計師事務所 數位轉型服務 資深經理）
* **時間與地點：** 11:45-12:15 | 7F 703
* **關鍵字：** `Blue Team`, `Red Team`, `Open Source Security`, `Backdoor`, `C2`, `SIEM`, `EDR`, `Detection Engineering`, `Wazuh`, `Suricata`, `Sysmon`, `Adversary Simulation`

#### 2. 內容摘要
* **核心訊息：** 透過實驗模擬，測試三款常見的開源 C2 (命令與控制) 框架 (Sliver, Merlin, PoshC2) 在預設配置下，能否被開源的防禦平台 (以 Wazuh 作為 SIEM/端點可視性代表，Suricata 作為 NIDS/網路可視性代表) 所偵測。實驗結果顯示，在僅建立 C2 連線 (HTTPS) 而無後續惡意行為的基礎情境下，大部分情況下難以觸發預設告警，凸顯了縱深防禦、日誌完整性、客製化規則以及對端點行為深入監控的重要性。
* **關鍵論點：**
* **攻防對抗本質：** 資安是持續的攻防競賽，防禦方部署新措施，攻擊方尋求繞過。
* **選擇開源工具的原因：** 透明性、貼近真實環境 (紅藍隊常用)、降低成本、避免商業置入。
* **藍隊可視性三角 (Gartner SOC Visibility Triad):** SIEM (日誌)、EDR (端點)、NDR (網路) 三者互補，提供完整可視性。本實驗選用 Wazuh (涵蓋 SIEM/HIDS) 和 Suricata (NIDS/IPS) 作為代表。
* **Wazuh:** 功能豐富的 SIEM + HIDS/EDR (檔案完整性監控, Rootkit 檢測, 安全組態評估, Cisco 監控, 主動回應等)。
* **Suricata:** 知名的 NIDS/IPS，用於網路流量監控與威脅偵測 (本次僅偵測模式)。
* **C2 (命令與控制) 介紹：** 攻擊者用於遠端管理已入侵主機的核心系統，常見於 APT 與紅隊演練。
* **基本架構：** Agent (植入受害者主機) <-> Listener (C2 Server) <-> Operator (攻擊者)。
* **通訊協定：** HTTPS, HTTP, MTLS, DNS, SMB 等。*(MTLS 可繞過中間人解密)*
* **本次選用 C2:**
* **Sliver:** 功能強大，支援多協定，使用合法憑證。
* **Merlin:** 支援多協定，Agent 有混淆/反偵測機制 (Jitter, GA3 Hash)。
* **PoshC2:** 基於 PowerShell，內建多種 Payload 與繞過技術。
* **實驗環境與設定：**
* 攻擊者 (Kali) <--(HTTPS)--> 受害者 (Win10 + Wazuh Agent + Suricata Sensor) --> Wazuh Server。
* 基本條件：網路通暢，停用 Windows Defender，C2 使用 HTTPS，IPv4 連線，防禦工具採**預設安裝與設定**。
* **謹慎操作：** 強調需確實終止 Agent 進程，避免殘留影響後續測試。
* **實驗結果 (第一輪 - 基礎連線)：**
* **結果：** 三款 C2 (Sliver, Merlin, PoshC2) 均成功建立 HTTPS 連線，Wazuh 和 Suricata 在**預設配置下均未產生任何告警**。
> **講者引用/強調：** "都沒有偵測到。我當時看了那個 Wazuh 的 dashboard 一片空白的時候，腦袋也是一片空白。"
* **可能原因分析：**
* **Wazuh (SIEM):** 日誌不足 (未收集 C2 相關日誌)、規則不存在/不匹配。
* **Wazuh (Endpoint):** 主要功能 (檔案/註冊表監控, Rootkit 檢測) 未被觸發，其設計目標與 EDR 著重進程關聯分析不同 (User Space vs. Kernel Mode)。
* **Suricata (NIDS):** 預設規則可能未涵蓋所用 C2 的特定網路模式，或被 HTTPS 加密流量繞過。
* **實驗限制：** 僅測試 C2 連線建立，未包含前期偵察或後期惡意活動，這些活動才可能觸發其他規則。*(講者補充：若執行後續惡意操作，Wazuh/Suricata 可觸發)*
* **實驗結果 (第二輪 - 強化監控)：**
* **變更：** 在 Wazuh 端整合 Sysmon 日誌，並將 C2 Server 移至外網。
* **結果：**
* **Wazuh (含 Sysmon):** **PoshC2 被偵測到** (因其執行方式為 Base64 編碼的 PowerShell 指令，觸發 Wazuh 內建的可疑 PowerShell 命令規則)，Sliver 和 Merlin 仍未偵測到。Sysmon 本身記錄到進程創建/網路連線事件，但未提升至 Wazuh 告警層級。
* **Suricata:** 仍未偵測到 HTTPS 連線。*(講者發現預設規則主要針對 HTTP，而非 HTTPS 的 C2 流量)*
* **結論與建議：**
* 單一防禦方案有其局限性，需縱深防禦。
* 確保日誌收集的完整性與正確性。
* 強化端點監控能力 (Sysmon 有幫助但需配合規則)。
* 理解各防護技術的功能與限制 (e.g., Wazuh Endpoint vs. EDR)。
* 定期進行測試模擬 (如本次實驗)，驗證防禦有效性。

#### 3. 技術(或政策)與實務區塊
* **主要技術/政策要點：**
* **開源安全工具：** **Wazuh** (SIEM/HIDS), **Suricata** (NIDS/IPS), **Sysmon** (端點日誌)。
* **開源 C2 框架：** **Sliver**, **Merlin**, **PoshC2** 的基本運作方式與特性。
* **偵測工程 (Detection Engineering):** 理解為何預設規則無法偵測，需客製化規則或增強日誌源。
* **網路流量分析 (NTA):** Suricata 的角色，以及 HTTPS 加密帶來的挑戰。
* **端點可視性 (Endpoint Visibility):** Wazuh Agent 與 Sysmon 的能力與限制。
* **攻防演練 (Adversary Simulation):** 透過模擬攻擊驗證防禦部署。
* **實務應用方法：**
* **工具評估與部署：** 在選擇或部署開源防禦工具時，理解其預設能力與限制，進行必要客製化。
* **日誌策略：** 規劃全面的日誌收集策略，確保涵蓋端點 (如 Sysmon)、網路、應用等關鍵日誌源。
* **規則調校：** 不能依賴預設規則，需根據自身環境與威脅情資，開發或調整偵測規則 (如針對特定 C2 的網路行為或端點活動)。
* **縱深防禦設計：** 結合 SIEM, EDR, NDR 等不同層面的工具，互相彌補盲點。
* **定期驗證：** 定期使用 C2 或其他攻擊模擬工具，測試防禦體系是否能有效偵測。
* **產業趨勢/發展方向：**
* 開源安全工具在企業中的應用越來越廣泛。
* 偵測工程與規則開發能力成為藍隊的核心技能。
* 對加密流量的可視性與分析需求增加。
* 持續的攻擊模擬與防禦驗證 (BAS/CTEM 概念) 受到重視。

#### 4. 價值評估
* **獨特價值與亮點：**
* **實證性強：** 透過搭建真實環境進行開源工具的攻防對決實驗，結果直觀。
* **貼近實務：** 選用的工具 (Wazuh, Suricata, Sliver 等) 在業界有實際應用，實驗結果具參考價值。
* **問題導向：** 從「為何沒偵測到」出發，深入分析各工具的限制與偵測盲點。
* **教育意義：** 為聽眾提供了對常用開源 C2 和防禦工具的基本認識。
* **對資安產業的意義：**
* **破除迷思：** 提醒使用者不能迷信單一工具或預設配置，需客製化與整合。
* **推動開源安全：** 展示了開源工具的能力與限制，有助於社群改進與使用者正確評估。
* **強調基礎建設：** 再次證明了日誌收集、規則調校等基礎工作的不可或缺。
* **實際工作應用潛力：**
* **藍隊/SOC 團隊：** 可直接參考實驗結果，評估自身使用的開源工具配置是否足夠，是否需要補充 Sysmon 或調整 Suricata 規則。
* **紅隊/滲透測試人員：** 了解常用開源 C2 在預設情況下的隱匿性，以及可能觸發偵測的行為 (如 PoshC2 的執行方式)。
* **安全架構師：** 在設計防禦體系時，考慮如何結合不同工具彌補單點偵測的不足。
* **資安教育/研究：** 可作為開源工具攻防分析的入門案例。

---

<a id="toc-17-afternoon"></a>
## 下午場

<a id="toc-17-genai-compliance"></a>
### **議程：生成式 AI 合規技術與挑戰**

#### 1. 基本資訊
* **議程標題：** 生成式 AI 合規技術與挑戰
* **講者：** 曲華榮（中華電信研究院 雲端所 高級研究員）
* **時間與地點：** 12:40-13:10 | 4F 展區會議室 4B
* **關鍵字：** `AI Safety`, `AI Security`, `Compliance`, `Generative AI`, `LLM Guard`, `Responsible AI`, `Risk Management`, `Prompt Injection`, `Policy Violation`

#### 2. 內容摘要
* **核心訊息：** 僅依賴模型供應商的安全對齊 (Alignment) 無法完全排除生成式 AI (GenAI) 的安全與合規風險 (如 Prompt Attack, Policy Violation)。企業落地 GenAI 需建立額外的防護機制 (Guardrails)，例如利用如 Llama Guard 等安全檢測模型，並設計支持客製化規則、兼顧使用者體驗的合規架構，才能在不同應用場景下確保 AI 的安全、可靠與合規運行。
* **關鍵論點：**
* **GenAI 風險普遍存在：**
* 類比經典 AI 失控電影 (天網、HAL 9000)，指出 GenAI 風險核心在於「系統失控，違反意圖」。
* **Prompt Attack (提示攻擊):**
* **Injection:** 攻擊者在輸入中植入惡意指令，操控模型行為 (如比價平台被供應商植入指令優先推薦自家產品)。
* **Jailbreak:** 繞過模型內建的安全護欄，使其輸出不當內容 (如虛構情境、Token Smuggling 繞過關鍵字過濾)。
* **問題根源：** 模型訓練目標是滿足人類需求，安全限制是後加的，且不能過強以免影響可用性。模型本身難以完美防禦所有攻擊變種。
* **Policy Violation (策略違反):** 模型輸出內容違反特定場域的規範、道德或法律要求。
* **情境依賴性：** 同樣的輸出在不同場景下合規性不同 (如醫療場景不能建議自殘，但犯罪預防研究可能需要相關資訊)。
* **挑戰：** 無法單靠通用模型滿足所有場域的合規要求。
* **模型對齊 (Alignment) 的局限：**
* 主流模型供應商雖已進行安全對齊訓練，但無法涵蓋所有攻擊手法與特定場域的合規需求。
* 攻擊手法不斷翻新，模型對齊永遠落後於攻擊。
> **講者引用/強調：** (為何公開的攻擊手法多已失效) "...這些市面上你可以用到的模型，他都已經針對這種不適當的行為，他都已經被訓練過，他已經認識過這些行為，那這叫做 Model Alignment。" (但這不代表沒有新手法)
* **需要外部防護機制 (Guardrails)：**
* **概念：** 在核心 LLM 之外，增加一層或多層安全檢測與過濾機制。
* **工具示例：Llama Guard**
* Meta 開發的專用安全分類模型，用於檢測輸入/輸出是否違反特定策略 (如仇恨言論、犯罪資訊等)。
* **優點：** 專門訓練，效果較好；開源，可本地部署。
* **測試結果 (中華電信研究院)：**
* 能區分是使用者輸入違規還是模型輸出違規。
* 具備一定的多模態 (文字+圖像) 理解能力 (判斷投資建議 vs. 手機推薦)。
* 對中文有一定支援能力 (雖官方未宣稱)。
* **客製化能力有限：** 對於**未經訓練**的新增規則類別，Zero-shot/Few-shot 調整效果不佳，仍需 Fine-tuning。但可調整現有規則的敏感度或移除規則。
* **誤判調整：** 可透過提取模型輸出的**機率值**，設定自訂閾值來調整誤判率。
* **AI 合規閘道器架構設計：**
* **目標：** 在不大幅修改現有 AI 應用程式的前提下，導入合規檢測能力。
* **架構：** 在 AI 應用與 LLM 之間插入一個「AI 合規閘道器 (AI Compliance Gateway)」。
* **功能：** 攔截應用與模型間的請求/回應 -> 調用安全檢測模型 (如 Llama Guard) -> 根據檢測結果決定放行、阻擋或修改內容。
* **挑戰與考量：**
* **使用者體驗 vs. 安全性：** LLM 的流式輸出 (Streaming) 體驗較好，但合規檢測常需完整上下文。需設計緩衝或分段檢測機制來平衡。 (舉例偽造護照教學的逐步檢測)
* **成本效益：** 安全檢測本身也消耗 Token 與運算資源。
* **場景適應性：** 不同應用場景 (如威脅檢測 vs. 政令宣導) 需要不同的合規規則集。
* **技術中立與風險管理：**
* **類比：** 日本壓縮機 vs. 中國壓縮機，重點不在於來源地，而在於是否有完善的安全設計、安規標準與風險控制機制。
* **觀點：** 不應因噎廢食，禁止使用特定模型 (如 DeepSeek)，而應思考如何在技術上確保其合規使用。
> **講者引用/強調：** "...這個東西要不要禁止是政策上的問題，我們在技術上或者是整個商業目標上，其實是會需要一個整體的考慮... 我們是可以透過一些技術的手段去讓他去合規。"
* **重要案例/數據：** 比價平台 Injection 案例、Jailbreak 騙取 System Prompt、虛構情境/Token Smuggling 繞過、論壇機器人身份洩露、偷車教學 Jailbreak、Llama Guard 功能與測試結果、偽造護照流式檢測案例、DeepSeek 合規性討論。

#### 3. 技術(或政策)與實務區塊
* **主要技術/政策要點：**
* **生成式 AI 安全風險：** **Prompt Attack (Injection, Jailbreak)**, **Policy Violation**。
* **模型安全對齊 (Model Alignment):** LLM 供應商內建的安全訓練。
* **外部防護機制 (Guardrails):** 獨立於核心 LLM 的安全檢測層。
* **安全檢測模型：** **Llama Guard** 的原理、能力與限制。
* **AI 合規架構 (AI Compliance Architecture):** **AI 合規閘道器**的設計理念與實現考量 (如流式輸出處理)。
* **客製化規則 (Customizable Policies):** 根據特定應用場景調整安全與合規規則。
* **實務應用方法：**
* **風險評估：** 導入 GenAI 前，需評估 Prompt Attack 和 Policy Violation 的風險。
* **多層防禦：** 不能僅依賴模型供應商的安全承諾，應考慮部署外部 Guardrail 機制。
* **工具選型：** 評估 Llama Guard 等開源或商業安全檢測工具，並進行 PoC 驗證其在自身場景下的有效性與客製化能力。
* **架構設計：** 考慮採用閘道器模式，降低對現有應用的侵入性。
* **規則制定：** 根據應用場景和法規要求，定義清晰的 AI 使用策略與禁止輸出的內容。
* **持續監控與調整：** 監控 Guardrail 的攔截情況與誤判率，動態調整規則與閾值。
* **產業趨勢/發展方向：**
* GenAI 的安全與合規成為企業落地應用的核心關切。
* 獨立的 AI Guardrail/安全檢測方案成為新興市場。
* 開源安全模型 (如 Llama Guard) 提供更多彈性與可控性。
* 如何在保障安全的同時維持良好的使用者體驗 (如流式輸出) 是重要的技術挑戰。
* 針對特定行業的合規要求將推動更細緻的 AI 治理方案。

#### 4. 價值評估
* **獨特價值與亮點：**
* **實務導向：** 從企業落地 GenAI 的角度出發，聚焦於實際面臨的合規挑戰與技術解方。
* **技術深入：** 詳細介紹並評測了 Llama Guard 這類具體的安全檢測模型。
* **架構創新：** 提出了 AI 合規閘道器的架構設計，具備較高的實施參考價值。
* **觀點平衡：** 討論了如何在安全、合規、成本、使用者體驗之間取得平衡，並對技術封鎖提出反思。
* **對資安產業(及AI應用領域)的意義：**
* **補充模型自身不足：** 強調了外部 Guardrail 在彌補 LLM 內在安全限制方面的重要性。
* **提供落地指引：** 為企業如何建構 GenAI 的安全合規防護提供了具體的技術架構與工具參考。
* **推動開源安全：** 展示了 Llama Guard 等開源工具在 AI 安全領域的潛力。
* **實際工作應用潛力：**
* **AI 應用開發團隊：** 在設計 GenAI 應用時，可參考合規閘道器架構，預先規劃安全機制。
* **資安/合規團隊：** 可將 Llama Guard 等工具納入技術評估，用於強化 GenAI 應用的安全與合規性。
* **技術決策者：** 在評估不同 GenAI 方案時，需將其安全防護機制與客製化能力納入考量。

---

<a id="toc-17-nmt-re"></a>
### **議程：神經級逆向技藝：從人機翻譯到全自動符號語義推理模型，打造仿生逆向聖杯**

#### 1. 基本資訊
* **議程標題：** 神經級逆向技藝：從人機翻譯到全自動符號語義推理模型，打造仿生逆向聖杯
* **講者：** 黃智威（TXOne Networks 資深資安威脅研究員）
* **時間與地點：** 14:00-14:30 | 1F 展區會議室 1B
* **關鍵字：** `Machine Learning`, `Reverse Engineering`, `Security Operation`, `AI Agent`, `NMT (Neural Machine Translation)`, `Symbolic Execution`, `Endpoint Security`, `Automation`, `Code Understanding`, `Type Inference`

#### 2. 內容摘要
* **核心訊息：** 傳統逆向工程高度依賴分析師經驗與時間投入，本演講探討如何借鑒自然語言處理中的翻譯模型 (尤其是基於 Attention 的 Transformer 架構)，將其應用於逆向工程任務。透過學習程式碼的語法結構與上下文語意 (如控制流、資料流)，AI 模型不僅能還原函數名稱，更能進一步推論變數型別與開發者原始命名，大幅降低人工分析負擔，為實現更自動化、更深層次的惡意程式分析與漏洞挖掘帶來可能。
* **關鍵論點：**
* **翻譯的本質與逆向工程的類比：**
* **自然語言翻譯：** 從早期基於詞頻統計 (Co-occurrence Matrix, Word2Vec) 到考慮句法結構 (Chomsky)，再到基於上下文語意的 Sequence-to-Sequence 模型 (Encoder-Decoder) 與 Attention 機制 (解決長句問題，關注相關詞彙)，最終發展出 Transformer 架構。
* **程式語言作為一種「語言」：** 程式碼具有比自然語言更嚴謹的語法與語意結構，可以將單行指令視為句子，函數視為文章。因此，翻譯模型的思路有望應用於理解程式碼。
* **逆向分析師的工作流程與 AI 輔助點：**
* **人類分析師：** 依賴經驗，關注控制流 (Control Flow) 與資料流 (Data Flow) 來理解函數語意。
> **講者引用/強調：** (引述 UseNext 2020 論文觀點) "...逆向分析師其實非常對於 Control Flow 和 Data Flow 有著非常強烈的需求... 假如我們可以從 Data 之間的參考和函數之間的交互...那我們就可以得到一個函數或者一個整個 binary 的潛在語意。"
* **AI 輔助點 1 - 函數名稱還原 (Function Name Recovery):**
* **動機：** 靜態連結 (Static Linking) 或符號剝離 (Stripping) 會導致失去原始函數名稱。
* **方法 (UseNext 2020 論文)：**
1. **污點分析 (Taint Analysis):** 追蹤 API 參數來源與流向。
2. **構建參數呼叫圖 (Argument Call Graph):** 包含 API 名稱 (Symbol) 和參數內容 (Value/Tokenized Reference)。
3. **模型訓練 (LSTM, Transformer, GNN):** 輸入 Argument Call Graph，輸出函數名稱標籤。GNN 對圖結構理解更好，準確率達 68%。
* **類比 IDA 功能：** 類似 IDA 的 FLIRT/Lumina，但 AI 方法無需人工維護簽章庫。
* **AI 輔助點 2 - 變數型別推論 (Variable Type Inference):**
* **動機：** 還原函數名稱不足以完全理解邏輯 (特別是漏洞挖掘或惡意行為分析)，需要知道變數的型別 (尤其是結構體 Structure)。編譯器優化 (Padding) 和缺乏原始結構定義是主要障礙。
* **人類經驗：** 分析師可從上下文 (如特定常數比較 - PE/NT Header，API 參數用法 - `NtQueryInformationProcess` 返回 `PROCESS_BASIC_INFORMATION`) 推斷變數型別。
* **方法 (UseNext 2022 論文)：**
1. **學習 C++ 開源專案：** 讓模型學習程式碼結構、變數用法與對應的 Structure/Type 關係。
2. **雙編碼器架構 (Dual Encoder):**
* **Code Encoder:** 輸入與變數相關的程式碼片段 (上下文)。
* **Data Layout Encoder:** 輸入 IDA 分析出的變數資訊 (位置 - Global/Stack, 大小 - Size, 被存取的偏移量 - Offset)。Offset 資訊有助於推斷 Structure 內部成員。
3. **推論 (Decoder):** 結合 Code 和 Data Layout 特徵，推論出最可能的變數型別 (Data Type) 和原始變數名稱 (Developer Name)。
* **效果：** 顯著提升反編譯程式碼的可讀性 (舉例 `GetModuleFileNameEx` 和 `Reflective Loader` 分析)。準確率：型別 68%，名稱 75%。
* **未來展望：**
* **整合應用：** 將函數名稱還原與變數型別推論結合，可提供更完整的反編譯結果，輔助 LLM (如 ChatGPT 類工具) 進行更高層次的自動化逆向分析。
* **惡意程式檢測：** 推論出的函數行為/語意可直接用於靜態惡意函數檢測。
* **重要案例/數據：** 翻譯模型演進 (Word2Vec, Seq2Seq, Attention, Transformer)；UseNext 2020 函數名稱還原準確率 (LSTM 40%, Transformer 41%, GNN 68%)；UseNext 2022 變數型別/名稱推論準確率 (型別 68%, 名稱 75%)；IDA FLIRT/Lumina 功能對比；`GetModuleFileNameEx`, `Reflective Loader`, Lockbit (COM Object 提權) 的逆向分析案例。

#### 3. 技術(或政策)與實務區塊
* **主要技術/政策要點：**
* **逆向工程基礎：** 反彙編 (Disassembly), 反編譯 (Decompilation), 控制流圖 (CFG), 資料流分析 (DFA)。
* **程式語言理解 (Code Understanding):** 靜態連結, 符號剝離, 編譯器優化, 數據結構 (Structure)。
* **自然語言處理 (NLP) 應用於程式碼：**
* **翻譯模型架構：** **Sequence-to-Sequence**, **Attention Mechanism**, **Transformer**。
* **圖神經網路 (GNN):** 用於處理圖結構數據 (Argument Call Graph)。
* **AI 輔助逆向技術：** **函數名稱還原**, **變數型別推論**, **變數名稱推論**。
* **污點分析 (Taint Analysis):** 追蹤數據流動。
* **實務應用方法：**
* **分析師提效：** 將 AI 推論出的函數名稱、變數型別/名稱整合到 IDA Pro 等逆向工具中，作為輔助信息，加速人工分析過程。
* **自動化工具開發：** 基於這些技術開發更智能化的反編譯器或靜態分析工具。
* **惡意程式檢測：** 利用 AI 推斷出的函數語意或行為模式，開發新的靜態檢測規則。
* **漏洞挖掘：** 更準確的變數型別有助於發現潛在的記憶體錯誤或其他漏洞。
* **產業趨勢/發展方向：**
* 利用 AI/ML 提升逆向工程的自動化程度與分析深度。
* 將 NLP 技術應用於理解程式碼語意成為重要研究方向。
* 圖神經網路在分析程式結構化數據方面展現潛力。
* 需要更強大的 AI 模型來應對程式碼混淆、加殼等反逆向技術。
* AI 輔助逆向將成為未來安全研究與分析的重要工具。

#### 4. 價值評估
* **獨特價值與亮點：**
* **跨領域類比：** 巧妙地將自然語言翻譯的原理與逆向工程任務相類比，提供了理解 AI 應用的新穎視角。
* **技術前沿：** 介紹了學術界在利用 AI 進行函數名稱還原和變數型別推論方面的最新研究成果 (UseNext 論文)。
* **原理深入：** 詳細解釋了相關 AI 模型 (Transformer, GNN) 和分析技術 (Argument Call Graph, 污點分析, 雙編碼器) 的核心思想。
* **痛點解決：** 直接針對逆向工程中耗時、依賴經驗、難以理解複雜程式碼等痛點提出 AI 解決方案。
* **對資安產業的意義：**
* **提升逆向能力：** 為產業提供了提升惡意程式分析和漏洞挖掘效率的潛在技術路徑。
* **推動 AI 落地：** 展示了 AI 在核心資安技術 (逆向工程) 領域的深度整合潛力。
* **啟發新工具開發：** 可能催生整合了 AI 推理能力的新一代逆向分析工具。
* **實際工作應用潛力：**
* **逆向工程師/惡意程式分析師：** 雖然目前可能尚未有成熟產品，但理解這些技術有助於未來利用相關工具提升工作效率。
* **安全研究人員：** 可基於這些研究方向進行更深入的探索或開發原型工具。
* **資安產品開發商：** 可考慮將類似的 AI 推理能力整合到 EDR、靜態分析平台或反編譯器中。

---

<a id="toc-17-llm-judge"></a>
### **議程：大型語言模型驗測革命：LLM-as-a-Judge 的實踐與挑戰**

#### 1. 基本資訊
* **議程標題：** 大型語言模型驗測革命：LLM-as-a-Judge 的實踐與挑戰
* **講者：** Stanley Chou（Coupang Director of Security Engineering）
* **時間與地點：** 14:45-15:15 | 1F 展區會議室 1B
* **關鍵字：** `LLM`, `AI Safety`, `Responsible AI`, `LLM Evaluation`, `AI Testing`, `LLM-as-a-Judge`, `Risk Assessment`, `Automation`, `Benchmarking`

#### 2. 內容摘要
* **核心訊息：** 傳統評估大型語言模型 (LLM) 輸出品質的方法 (如人工評估、基於指標的自動評估) 面臨成本高、難以擴展、主觀性強、無法捕捉細微差異等挑戰。LLM-as-a-Judge (讓 LLM 評估 LLM) 作為一種新興的自動化評估範式，展現出巨大潛力，但也存在自身偏見、評分標準對齊困難等問題。本演講旨在探討 LLM-as-a-Judge 的實踐方法、關鍵成功因素與挑戰，以期更有效地驗測和強化 AI 系統的安全與可信度。
* **關鍵論點：**
* **LLM 評估的困境：**
* **傳統方法挑戰：**
* **人工評估：** 成本高昂、耗時、主觀性強、難以標準化和規模化。
* **基於指標的自動評估 (e.g., BLEU, ROUGE):** 主要適用於特定任務 (如翻譯、摘要)，難以評估開放式生成任務的品質、一致性、安全性、創造力等複雜維度。
* **驗測需求複雜：** 需要評估的面向多元，包括準確性、流暢性、連貫性、安全性 (無害性、無偏見)、遵循指令能力、特定領域知識等。
* **不可復現性：** LLM 輸出具有隨機性，難以進行穩定的回歸測試。
* **缺乏 Ground Truth:** 對於許多生成任務，沒有唯一的標準答案。
* **LLM-as-a-Judge 的興起：**
* **概念：** 利用一個 (或多個) 強大的 LLM (通常是 GPT-4 等級) 作為評審 (Judge)，來評估另一個 (或同一) LLM (被評估者) 的輸出品質。
* **動機：** 解決人工評估的成本與規模問題，並期望利用 LLM 的理解能力評估更複雜的品質維度。
* **LLM-as-a-Judge 的實踐方法：**
* **評分模式 (Scoring Patterns):**
* **點對點比較 (Pairwise Comparison):** 給定兩個模型的輸出，讓 Judge LLM 判斷哪個更好 (或平手)。常用於模型選擇或 A/B 測試。
* **單一答案評分 (Single-Answer Grading):** 給定一個模型的輸出和評分標準，讓 Judge LLM 直接給出分數 (如 1-10 分)。
* **參考答案比對 (Reference-based Grading):** 給定模型輸出、參考答案 (若有) 和評分標準，讓 Judge LLM 評估模型輸出與參考答案的接近程度或優劣。
* **Prompt 設計是關鍵：** 需要精心設計 Prompt，清晰定義評分維度、標準、輸出格式，以引導 Judge LLM 做出一致、可靠的評估。
* **關鍵成功因素：**
* **強大的 Judge LLM：** 通常需要 GPT-4 或同等級的模型才能較好地理解細微差異和複雜指令。
* **清晰的評分標準與 Prompt：** 這是確保評估一致性和有效性的核心。
* **多樣化的測試案例：** 涵蓋不同難度、主題、風格的輸入，以全面評估模型能力。
* **多輪評估與多數決：** 類似人工評估，讓多個 Judge LLM (或同一個 Judge 多次) 評估，取多數決或平均值，以提高穩定性。
* **人工校準與驗證：** 定期抽取部分 LLM-as-a-Judge 的評估結果，與人工評估進行比對，校準 Prompt 或 Judge 模型。
* **LLM-as-a-Judge 的挑戰：**
* **自身偏見 (Inherent Biases):** Judge LLM 本身也可能存在偏見 (如位置偏見 - 偏好第一個答案，冗長偏見 - 認為答案越長越好，自我偏見 - 偏好自己生成風格的答案)。
* **評分標準對齊困難：** 讓 Judge LLM 完全理解並嚴格遵循複雜的評分標準仍有困難。
* **成本問題：** 使用 GPT-4 等強大模型作為 Judge 的 API 調用成本仍然不低。
* **幻覺風險：** Judge LLM 在評估時也可能產生幻覺，給出錯誤的評價理由。
* **未來方向：** 結合不同評估方法 (人工、指標、LLM-as-a-Judge)，開發更魯棒、更高效的 LLM 驗測框架；研究如何減輕 Judge LLM 的偏見；探索使用更小、更專用的模型作為 Judge 的可行性。
* **(影片內容推測):** 影片《Atlas》中，主角透過觀察 AI 機器人自我反思 (Self-Correction/Reflection) 時的內部狀態 (類似 LLM 推理過程)，找到了突破口。這隱喻了未來可能需要更深入地理解模型內部運作機制來進行驗測或攻擊。

#### 3. 技術(或政策)與實務區塊
* **主要技術/政策要點：**
* **大型語言模型評估 (LLM Evaluation):** 人工評估, 指標評估 (BLEU, ROUGE), **LLM-as-a-Judge**。
* **評估範式：** **點對點比較**, **單一答案評分**, **參考答案比對**。
* **提示工程 (Prompt Engineering for Evaluation):** 設計用於引導 Judge LLM 進行評估的 Prompt。
* **模型偏見 (Model Bias):** 位置偏見, 冗長偏見, 自我偏見等影響評估結果的因素。
* **自動化測試 (Automated Testing):** 利用 LLM-as-a-Judge 實現大規模、自動化的 LLM 輸出品質評估。
* **基準測試 (Benchmarking):** 利用 LLM-as-a-Judge 對不同模型進行橫向比較。
* **實務應用方法：**
* **模型選型/迭代：** 使用 LLM-as-a-Judge (特別是點對點比較) 快速評估不同模型或同一模型不同版本在特定任務上的表現。
* **線上品質監控：** 抽取線上服務的 LLM 輸出，定期使用 LLM-as-a-Judge 進行自動化品質抽檢。
* **紅隊測試/安全驗證：** 設計 Prompt 讓 Judge LLM 評估目標 LLM 的輸出是否存在安全風險 (如洩漏敏感資訊、生成有害內容、被 Prompt Injection)。
* **輔助人工評估：** 利用 LLM-as-a-Judge 進行初步篩選或提供評價理由，輔助人工評估者提高效率和一致性。
* **Prompt 優化：** 透過 Judge LLM 的反饋，迭代優化用於生成任務的 Prompt。
* **產業趨勢/發展方向：**
* LLM-as-a-Judge 成為 LLM 評估領域的研究熱點與重要實踐方向。
* 對 Judge LLM 自身偏見的識別與緩解技術將持續發展。
* 開發更專門化、更輕量級的 Judge 模型以降低成本。
* 建立更標準化、更可靠的 LLM 評估基準與流程。
* 將 LLM-as-a-Judge 整合到 MLOps 流程中，實現持續的自動化驗測。

#### 4. 價值評估
* **獨特價值與亮點：**
* **聚焦前沿方法：** 深入探討了 LLM-as-a-Judge 這一新興且極具潛力的 LLM 驗測範式。
* **實踐導向：** 詳細介紹了 LLM-as-a-Judge 的不同實踐模式與關鍵成功因素。
* **挑戰坦誠：** 客觀分析了 LLM-as-a-Judge 目前面臨的偏見、成本等挑戰。
* **結合安全視角：** 強調了 LLM-as-a-Judge 在驗測 AI 系統安全性與可信度方面的應用潛力。
* **對資安產業(及AI應用領域)的意義：**
* **解決評估瓶頸：** 為解決傳統 LLM 評估方法的成本與效率瓶頸提供了可行的自動化方案。
* **提升 AI 可信度：** 有助於更全面、更規模化地驗測 LLM 輸出，提升 AI 系統的整體安全性和可靠性。
* **推動評估標準化：** LLM-as-a-Judge 的研究與應用有助於建立更客觀、更一致的 LLM 評估標準。
* **實際工作應用潛力：**
* **AI/ML 團隊：** 可將 LLM-as-a-Judge 納入其模型開發與迭代的評估流程中。
* **QA/測試團隊：** 可利用此方法設計針對 LLM 應用的自動化測試方案。
* **資安/風控團隊：** 可應用 LLM-as-a-Judge 進行 AI 系統的安全風險驗測與合規性檢查。
* **研究人員：** 可在此基礎上進一步研究如何優化 Judge Prompt、減輕偏見、降低成本。

---

<a id="toc-17-hr-cert"></a>
### **議程：從 HR 的觀點看資安證照的潛力與價值**

#### 1. 基本資訊
* **議程標題：** 從 HR 的觀點看資安證照的潛力與價值
* **講者：** 鄭惠如 (RURU)（Integrated Solutions Technology, Inc. 人資暨財務主管 / ISC² Taipei Chapter 理事）
* **時間與地點：** 15:45-16:15 | 4F Cyber Talent 專區
* **關鍵字：** `Career Path`, `Certification`, `Cyber Hunting`, `Talent Acquisition`, `Human Resources`, `ISC2 CC`, `Skills Gap`, `Internal Controls`, `Data Protection`

#### 2. 內容摘要
* **核心訊息：** 資安不再僅是 IT 部門的職責，具備資安知識與相關證照，即使對於非技術背景的 HR 專業人士，也能在人才招募、內部流程風險管理、員工關係處理、甚至參與公司治理（如資安專責單位）等方面帶來獨特的價值與職涯發展潛力。資安意識與實踐應融入企業營運的各個環節。
* **關鍵論點：**
* **資安重要性提升：** 政府推動 (資安即國安)、法規要求 (證交所對上市櫃公司設資安專責單位)、實際損失慘重 (PWC 報告：事件增長 37%，單次損失可達百萬美元，修復期長達 283 天)，顯示資安已是企業永續經營的關鍵。
* **資安事件無所不在 (HR 視角案例)：**
* **訪客管理疏失：** 警衛請面試者將內含公司機敏資訊 (銀行信件) 的文件帶上樓，暴露風險。
* **AI 工具使用風險：** 員工將公司會議記錄、程式碼上傳至公有 AI 平台，可能導致機密外洩或被競爭對手利用。
* **離職員工帳號管理不當：** 離職兩年的員工仍可登入昂貴的外部資料庫系統，顯示帳號盤點與權限回收流程存在漏洞。
> **講者引用/強調：** (談離職員工帳號) "他已經離職兩年了，卻還在使用公司的帳號密碼登入這個資料庫... 盤點帳號的那個留存是沒有做到落實的。"
* **資安政策落實困難：** 政策制定容易，但實際執行是企業最大痛點。
* **HR 結合資安知識的價值：**
* **優化內部流程風險：**
* **離職流程：** 不僅是面談、收回物品，更要確保即時停用所有帳號權限、變更相關密碼，防止惡意破壞或資料竊取。需提醒 IT 與部門主管落實。
* **特權帳號管理：** HR 需了解除了 IT 管理的帳號外，財務、行政等部門可能持有高權限帳號 (網路銀行、工商憑證)，需納入離職盤點。
* **員工行為觀察 (員工關懷角度)：** 透過日常互動，可能發現潛在內部風險 (如員工將密碼貼在螢幕上、使用他人電腦傳輸資料)。
* **保護員工個資與公司機密：**
* **健檢報告處理：** 意識到其為特種個資，應由專人 (醫護) 保管或同仁自行提交，避免 HR 直接收受整批報告。
* **Offer Letter 加密：** 為保護薪資隱私，寄送錄取通知時應加密，密碼使用接收者已知資訊 (如身分證號、生日)，避免誤寄導致外洩。
* **新進報到權限設定：** 門禁、系統權限需謹慎設定，如使用人臉辨識應取得明確授權同意書 (告知用途、調閱單位、刪除機制)。
* **資安知識對 HR 職涯的加分：**
* **提升招募精準度：** 了解不同資安職位所需的技能與證照 (舉例 PM/產品經理看 CC/CISSP，雲端看 CCSP)，能更有效地篩選人才。
* **跨領域發展機會：**
> **講者引用/強調：** (分享自身經驗) "因為你懂我們的作業流程...然後呢你有資安證照...所以他就希望 Lulu 加入團隊，一起來幫忙公司導 ISO..." (HR 背景因懂資安而被邀請參與 ISO 導入)
* 具備跨領域知識 (如 HR+資安) 的人才，在晉升管理職或轉換跑道時更具優勢 (引用 PMI 數據：跨領域任管理職比例 59% vs. 單一專長 30.9%)。
* 薪資潛力提升 (估計增加 8K-10K)。
* **協助產品/服務增值：** 懂資安的產品經理能將安全作為產品亮點，提升客戶信任度。
* **重要案例/數據：** PWC 資安事件損失數據、HR 經手個資 (身分證、健檢報告) 的風險、健檢中心誤寄全公司報告、離職員工仍可登入系統、警衛請訪客遞送內部文件、資深員工將密碼貼螢幕、HR 發 Offer Letter 加密實務、HR 因懂資安參與 ISO 導入、PMI 跨領域人才晉升數據。

#### 3. 技術(或政策)與實務區塊
* **主要技術/政策要點：**
* **人力資源安全 (Human Resource Security):** 將資安考量融入 HR 流程 (招募、報到、離職、績效、員工關係)。
* **內部威脅管理 (Insider Threat Management):** 識別與預防因員工疏忽或惡意行為導致的風險。
* **個資保護法規遵循 (Data Protection Compliance):** 特種個資處理、告知同意、權限管理、資料生命週期。
* **帳號與權限管理 (Account & Access Management):** 離職帳號即時停用、特權帳號盤點與監控。
* **資安意識培訓 (Security Awareness Training):** 持續教育員工識別風險 (社交工程、AI 工具誤用)。
* **資安證照價值 (Value of Certification):** 作為衡量人才技能與知識的參考指標 (如 ISC² CC, CISSP, CCSP)。
* **實務應用方法：**
* **HR 流程檢視：** HR 部門應檢視招募、報到、離職等流程，識別個資處理與帳號管理的風險點，並導入控制措施 (如 Offer 加密、離職 checklist 強化)。
* **跨部門協作：** HR 需與 IT、法務、部門主管緊密合作，確保離職流程中帳號權限的完整回收。
* **員工關懷結合風險意識：** 在執行員工關懷時，留意可能的異常行為或風險跡象。
* **內部培訓設計：** 將真實案例 (如密碼張貼、AI 誤用) 融入資安意識培訓。
* **人才招募策略：** 在招募特定職位 (如 PM、開發人員) 時，將相關資安知識或證照列為加分項。
* **個人職涯規劃：** 非 IT 背景人員可考慮考取入門級資安證照 (如 ISC² CC)，拓展跨領域能力。
* **產業趨勢/發展方向：**
* 資安不再只是 IT 的事，而是所有部門 (尤其 HR、財務等接觸敏感資訊的部門) 的共同責任。
* 內部威脅與人為疏失持續是企業資安的主要風險來源。
* 跨領域整合能力 (如 HR+資安, 財會+資安) 的人才價值提升。
* 資安證照在人才市場上的能見度與參考價值增加。

#### 4. 價值評估
* **獨特價值與亮點：**
* **獨特視角：** 以非技術背景的 HR 專業人士角度切入，探討資安的價值與實踐，具新鮮感與說服力。
* **案例貼切：** 使用大量 HR 日常工作中可能遇到的真實案例 (健檢報告、離職、Offer、特權帳號)，讓聽眾感同身受。
* **跨領域價值彰顯：** 清晰論證了資安知識如何賦能 HR 工作，並帶來職涯發展機會。
* **行動導向：** 鼓勵非 IT 人員學習資安，並提供了證照作為入門路徑。
* **對資安產業的意義：**
* **擴大資安影響力：** 有助於將資安意識與實踐推廣到 HR 等非傳統 IT 部門。
* **促進內部控制：** 強調 HR 在落實內部控制 (尤其帳號管理、個資保護) 中的關鍵角色。
* **多元人才引導：** 鼓勵更多不同背景的人才投入或關注資安領域。
* **實際工作應用潛力：**
* **HR 人員：** 可直接應用演講中提到的方法，檢視並改善內部流程的資安風險。
* **資安推廣者/講師：** 可借鑒其案例與視角，向非技術人員說明資安的重要性。
* **求職者/在職者：** 可將考取資安證照作為提升自身跨領域競爭力與職涯發展的選項。
* **企業管理者：** 應意識到資安需全員參與，並支持 HR 等部門在資安治理中扮演更積極的角色。

---

<a id="toc-17-genai-auto"></a>
### **議程：當 GenAI 從雲端降落到車載，深入淺出軟韌體、硬體架構與風險**

#### 1. 基本資訊
* **議程標題：** 當 GenAI 從雲端降落到車載，深入淺出軟韌體、硬體架構與風險
* **講者：** Shin li（VicOne Staff Researcher, CyberThreat Research Lab）
* **時間與地點：** 16:15-17:00 | 1F 展區會議室 1A
* **關鍵字：** `AI`, `Supply Chain Security`, `Automotive Security`, `Generative AI`, `Edge AI`, `Firmware Security`, `Hardware Security`, `Connected Vehicles`, `SoC`, `NPU`, `Side Channel Attack`, `Prompt Injection`

#### 2. 內容摘要
* **核心訊息：** 將生成式 AI (GenAI) 從雲端部署到車載端 (Edge AI) 具有提升使用者體驗、降低延遲、保護隱私等優勢，但也帶來了獨特的軟硬體架構挑戰與安全風險。理解車用 SoC (System on Chip) 的複雜異構架構 (CPU, GPU, NPU, DSP 等共享記憶體與匯流排)、硬體加速器的歷史演進與潛在漏洞 (如共享資源導致的側信道攻擊)、以及針對嵌入式環境的 Prompt Injection 手法，對於設計安全可靠的車載 AI 系統至關重要。
* **關鍵論點：**
* **車載 GenAI 的動機：**
* **提升使用者體驗：** 改善語音助理的辨識度與互動自然度 (對比早期真人客服或蹩腳的 Siri)。
* **降低延遲：** 本地處理反應更快。
* **數據隱私/合規：** 避免敏感數據 (語音、影像、行車軌跡) 傳至雲端，符合 GDPR 等法規。
* **離線韌性：** 在無網路環境下維持功能一致性。
* **產品競爭力：** 市場內捲下的功能需求。
* **硬體架構的演變與挑戰 - 從 PC 到 SoC：**
* **歷史類比：** AI 加速器 (NPU) 如同早期的數學協同處理器 (8087) 或圖形加速器 (GPU)，是為特定任務設計的專用硬體，從外掛走向整合。
* **SoC 異構計算：** 車用/行動平台為成本、功耗考量，將 CPU, GPU, NPU, ISP, DSP 等多種處理單元高度整合到單一晶片，常**共享記憶體控制器與內部匯流排**。
* **NPU 特性：** 專為稀疏矩陣運算 (Transformer 模型) 優化，但也面臨**記憶體頻寬瓶頸** (資料搬運耗電佔比高達 9 成)。
* **硬體抽象層 (HAL) 與 SDK 風險：** 為簡化開發，廠商提供 SDK/HAL，但也隱藏了底層硬體細節，可能引入漏洞或限制效能認知。
> **講者引用/強調：** (引用高通文件精神) "如果你沒有照著我們的資料結構以及硬體加速器設計，效能掉到 20% 以下，是你的問題，不是我(晶片)跑不穿。" (說明遵循硬體設計重要性)
* **硬體架構衍生的安全風險 - 側信道攻擊 (Side Channel)：**
* **根源：** 異構單元**共享資源** (匯流排、快取、記憶體、甚至亂數產生器的 Buffer)。
* **案例 (非車用但原理相通)：**
* **Intel CPU ID 洩漏亂數：** CPU ID 指令與亂數產生器共用 Buffer，在高負載下讀取 CPU ID 可能取到部分亂數內容。
* **高通 Hexagon DSP 漏洞 (FastRPC)：** Host OS (Android/Linux) 與 DSP 上的 RTOS 透過共享記憶體 (Mailbox) 通訊。若 Host OS 的 FastRPC 驅動或 DSP 上的程式存在漏洞 (UAF, OOB Read/Write)，攻擊者可利用此通道進行權限提升，甚至從 Non-secure World 攻擊 Secure World (TrustZone)。(此類漏洞已被用於實際攻擊)
* **啟示：** 抽象化帶來方便，但也隱藏風險；複雜系統易產生未預期的交互作用 (生鏽效應)；需了解底層硬體特性。
* **NVIDIA 方案的風險 - Container 逃逸：**
* NVIDIA 為解決驅動/函式庫版本依賴問題，常用 Container (NVIDIA Container Toolkit) 封裝運行環境。
* **漏洞案例 (CVE-2024-xxxx, CVE-2025-xxxx)：** Container Toolkit 在處理 Host 與 Container 間檔案映射 (特別是 Softlink) 時存在漏洞，允許 Container 內應用程式透過特殊路徑要求，讀取到 Host 上的敏感檔案 (如 Docker Socket)，進而實現**容器逃逸 (Container Escape)**。且此漏洞在修復後短期內又被發現可透過大量嵌套目錄繞過。
* **車載環境下的 Prompt Injection：**
* **主要手法：Invisible Unicode Injection**
* 利用 Unicode 中控制字元 (如反轉 `RLO`, `LRO`, `PDF`) 或隱藏字元 (如零寬空格) 構造看似正常但實際執行惡意指令的輸入。
* **Demo (Rick Astley):** 展示如何在正常句子中插入 Unicode 反轉字元，讓 AI 讀取並執行隱藏的 `Never gonna give you up` 播放指令。
* **車載應用風險：** 可用於欺騙語音助理執行非預期操作 (如開啟車門、導航至錯誤地點)，或在簡訊/通知中隱藏惡意指令，使用者介面 (HUD Pop-up) 可能無法完全顯示而忽略風險。
* **海豚音攻擊 (Dolphin Attack - 物理層攻擊)：**
* 利用麥克風及類比電路的非線性失真特性，將人耳聽不到或聽不清的高頻/特殊調製聲音，轉換為可被語音助理識別的指令 (如 "OK Google", "Hey Siri")。
* **風險：** 可遠距離 (數米至數十米) 無接觸觸發語音助理。
* **脆弱性：** 麥克風越小越容易受影響；實驗證明 Audi Q3 等車款也受影響。
* **車載 GenAI 的整體風險：**
* **硬體限制與漏洞：** SoC 架構複雜性、共享資源側信道、供應鏈風險。
* **模型本身：** 量化 (Quantization) 導致精度下降、穩定性問題 (Drifting)。
* **資源競爭：** AI 推論與其他關鍵車載功能 (ADAS, 儀表板) 競爭 CPU/記憶體/匯流排資源，可能導致延遲或功能異常 (舉例 AI 計算圓周率導致 ADAS 卡頓)。
* **軟體/韌體/SDK 漏洞：** 如前述高通、NVIDIA 案例。
* **緩解措施 (Mitigation)：** 硬體安全設計、最小權限原則、模型安全管理、供應鏈安全審查、持續監控與更新、**深入理解所用硬體與 SDK**。

#### 3. 技術(或政策)與實務區塊
* **主要技術/政策要點：**
* **車用 SoC 架構：** 異構計算 (CPU, GPU, NPU, ISP, DSP), 共享記憶體/匯流排。
* **AI 加速器 (NPU):** 基本原理, TOPS/功耗指標的局限, 記憶體頻寬瓶頸。
* **硬體安全漏洞：** **側信道攻擊 (Side Channel Attack)** 原理 (共享資源), **容器逃逸 (Container Escape)**。
* **嵌入式 AI 安全：** **Prompt Injection (Unicode)**, **物理層攻擊 (Dolphin Attack)**。
* **模型量化 (Model Quantization):** 將模型縮小以部署於邊緣設備的技術及其潛在影響。
* **資源競爭與即時性 (Resource Contention & Real-time):** 在嵌入式系統中平衡 AI 運算與其他關鍵任務的需求。
* **供應鏈安全 (Supply Chain Security):** SDK, HAL, 硬體元件的安全性。
* **實務應用方法：**
* **架構設計：** 在設計車載 AI 系統時，需充分考慮 SoC 的硬體限制、資源共享帶來的潛在干擾與側信道風險。
* **供應商評估：** 深入了解晶片/IP/SDK 供應商提供的硬體架構細節與安全機制。
* **安全測試：** 針對車載環境，測試 Unicode Prompt Injection, 物理層語音注入等特定攻擊手法的防禦能力。
* **資源隔離與調度：** 設計有效的資源隔離機制 (如 Container 安全強化) 與任務調度策略，避免 AI 運算影響關鍵行車功能。
* **模型選擇與部署：** 謹慎評估模型量化對安全性和穩定性的影響。
* **縱深防禦：** 結合硬體安全、韌體安全、軟體安全、輸入驗證等多層次防禦。
* **產業趨勢/發展方向：**
* GenAI 加速向邊緣端 (包括汽車) 遷移。
* 車載 AI 的安全與可靠性成為核心挑戰。
* 對 SoC 等嵌入式硬體架構安全的關注度提升。
* 針對嵌入式 AI 的特定攻擊手法 (物理層、資源競爭) 成為新的研究方向。
* 車用供應鏈安全標準與法規 (如 UN R155) 將更趨嚴格。

#### 4. 價值評估
* **獨特價值與亮點：**
* **獨特應用場景：** 聚焦於 GenAI 在車載端這一新興且高風險的應用場景。
* **軟硬整合視角：** 深入探討了底層硬體架構 (SoC, NPU, 共享資源) 對上層 AI 應用安全的直接影響，視角獨特。
* **風險剖析深入：** 結合側信道、容器逃逸、Unicode Injection、物理層攻擊等多種技術，全面剖析車載 AI 的潛在風險。
* **歷史與現實結合：** 透過回顧硬體加速器歷史，類比當前 AI 晶片發展，提供更易理解的脈絡。
* **對資安產業的意義：**
* **拓展安全邊界：** 將 AI 安全的討論從雲端延伸至硬體、韌體、物理層交互的複雜嵌入式環境。
* **提升硬體安全意識：** 強調理解底層硬體對於評估真實世界 AI 系統安全的重要性。
* **聚焦車用安全：** 呼應了汽車智慧化、網聯化帶來的巨大資安挑戰。
* **促進跨領域研究：** 鼓勵資安研究人員關注硬體架構、物理特性與軟體安全的交叉影響。
* **實際工作應用潛力：**
* **車廠/供應商：** 在設計、開發、測試車載 AI 功能時，可參考報告中提及的架構風險與攻擊手法，加強安全設計與驗證。
* **安全研究人員：** 可作為深入研究嵌入式 AI 安全、側信道攻擊、物理層攻擊的起點。
* **晶片設計/韌體開發人員：** 應將安全作為設計考量，減少資源共享帶來的風險，並提供更安全的 SDK/HAL。
* **產品安全團隊：** 在進行產品安全評估時，需將硬體架構與供應鏈因素納入考量。