分層設計：L0–L9 十層與三個橫切面

11.1 本層要解決的問題

治理層回答三個問題：誰有權決策？誰負責執行？如何向外證明？

在 ODM 情境下，治理層有兩個一般企業沒有的額外任務：

1. 對外證明——客戶稽核、公司治理評鑑、年報揭露都是治理層的產出
2. 多法域政策協調——同一份政策在 Z1 與 Z2 的落實方式不同，但基線必須一致

11.2 政策架構：三層式

11.3 CSF 2.0 GOVERN function 的對應

CSF 2.0 的 GOVERN function 是 2.0 版新增，官方定義為「The organization's cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored」已證實。

其中 GV.SC（Cybersecurity Supply Chain Risk Management） 對 ODM 特別重要——它把供應鏈治理定位為治理職能而非技術控制，這與 §2.1.2 的 61% 第三方涉入數字互相呼應，也是資安長向董事會提出供應鏈治理預算的框架依據。

11.4 董事會報告：頻率與內容

法規與評鑑要求

• ESG 評鑑指標 S-12（原 2.24）要件 1 要求「定期向董事會報告」已證實
• 同業實務：廣達揭露「至少每年一次」（最近一次 2024-12-27）；緯創「資安執行委員會每季召開，每年向董事會報告」廠商主張・公司自行揭露

董事會報告的建議內容架構（每次 6–8 頁）

11.5 組織與 RACI（詳見第 24 章）

治理層必須產出一份明確的 RACI 矩陣，涵蓋：

• 集團總部 vs 各廠區的責任劃分
• 資安 vs IT vs 業務單位的責任劃分
• 五個信任分區各自的負責人

本手冊建議的功能切分（依 C2M2 v2.1 的 10 個 domain 為權威依據，這是本次查證找到最權威可引用的資安功能切分框架）已證實：

外加 ODM 特有的兩項（C2M2 未涵蓋）：產品安全 / PSIRT、OT 資安。

11.6 法遵管理：以控制項為中心而非以法規為中心

正確做法：建立單一控制項庫（unified control set），每個控制項標註其滿足的所有外部要求。範例：

這張表的價值：一次稽核可以用同一份證據回應多個框架；新增法規時只需增加一欄，而非重建一套清單。附錄 D 提供本手冊建議的完整控制項庫。

11.7 常見失敗模式

↑ 回本部目錄

12.1 本層要解決的問題

身分是 ODM 資安架構的第一優先層，理由有三：

12.2 必備控制清單

12.2.1　人類身分

12.2.2　非人身分（NHI）——本手冊認為最被低估的區塊

OWASP Non-Human Identities Top 10 (2025) 已證實 — 清單，發布日期未載明：

必備控制：

12.2.3　ODM 特有：ABAC 與國籍屬性

依原則七，身分屬性須包含：

12.3 分區差異

12.4 市場與選型

必須先知道的市場結構事實 已證實：

選型的三個 ODM 特有考量：

1. 中國區可用性：Entra ID、Okta 在中國境內的連線穩定性與合規性須實測；Azure China 是獨立雲端，Entra ID 全球租戶與 Azure China 的整合有限制
2. ABAC 能力：多數 IAM 產品的 ABAC 支援深度不同，須實測「以專案屬性動態授權 PLM 資料夾」的可行性
3. OT 相容性：PAM 對舊版協定（VNC、RDP over legacy、專有 HMI 協定）的支援

12.5 常見失敗模式

↑ 回本部目錄

13.1 本層要解決的問題

網路層在零信任架構下的角色已經改變：它不再是信任邊界，而是可視性與強制點（enforcement point）。

對 ODM 而言，本層最關鍵的兩件事：

1. 對外邊界裝置的管理（原則三：假設已被入侵）
2. 跨分區的 conduit 控制（第 10 章）

13.2 必備控制清單

13.3 分區差異

13.4 市場與選型

必須先知道的市場結構事實：

廠商已知限制（Gartner Cautions 摘要）第三方評論

13.5 常見失敗模式

↑ 回本部目錄

14.1 本層要解決的問題

端點層在 ODM 有三類差異極大的資產：

14.2 必備控制清單

14.3 設備入網管制：從 TSMC 2018 學到的流程

台積電 2018 事件的根因是新機台軟體安裝過程操作失誤，機台連上內網後病毒擴散 已證實。

本手冊建議的設備入網 SOP：

14.4 市場與選型

必須先知道的事實：

ATT&CK Evaluations 的獨立批評 —— 選型時必讀 第三方評論

產品比較

14.5 多 EDR 並存的現實問題

許多 ODM 集團因併購與歷史因素，同時存在多套 EDR/XDR（例如 Microsoft Defender for Endpoint、SentinelOne、Bitdefender、CrowdStrike、TrendMicro 五家並存）。這造成：

本手冊建議的處理順序（不建議一次收斂）：

14.6 常見失敗模式

↑ 回本部目錄

15.1 本層要解決的問題

15.2 雲端安全（CNAPP 與雲端態勢）

15.2.1　必須先破除的錯誤

15.2.2　CNAPP Market Guide 2025-08-05 的關鍵預測 第三方評論

• 至 2029 年，成功在 CSP 環境實施 Zero Trust 的企業中，40% 將依賴 CNAPP 的進階可視性與控制能力
• CNAPP 與應用安全（AppSec）產品正在收斂
• 至 2029 年，50% 企業應用將以容器運行

15.2.3　必備控制

15.2.4　分區差異

15.3 自建應用的安全（SSDF 為骨幹）

15.3.1　框架依據

NIST SP 800-218 SSDF v1.1（2022-02-03）仍為現行正式版；v1.2（Rev. 1）為草案，引用時須標示草案。已證實

SSDF 提供「a core set of high-level secure software development practices that can be integrated into each SDLC implementation」，同時為採購方建立 secure software development 的共同詞彙。

四大實務群組（業界通用引用，本次未自 PDF 逐字取證）第三方評論：

NIST SP 800-218A（2024-07-26）已證實：Secure Software Development Practices for Generative AI and Dual-Use Foundation Models——一份 SSDF Community Profile，若集團自建 AI 應用則須納入。

15.3.2　必備控制

15.3.3　開源與 CI/CD 供應鏈：三個必須做的動作

依 §3.4 的實證（tj-actions、Shai-Hulud 兩波、XZ Utils）：

15.4 SaaS 治理：分析師覆蓋的空白區

必備控制（不依賴特定產品）：

15.5 API 與對外服務

市場事實 已證實：Gartner 沒有現行的「Magic Quadrant for API Protection」。WAAP MQ 最後版本為 2022 年，現由 Market Guide for Cloud Web Application and API Protection 承接。存在的是 Gartner Peer Insights「API Protection」Customers' Choice（2026）——屬客戶評分。

必備控制：

15.6 常見失敗模式

↑ 回本部目錄

16.1 本層要解決的問題

對 ODM 而言，資料層是最終要保護的東西。前面所有層都是為了讓資料不被拿走、不被竄改、不被停用。

X-Force 2026：製造業 40% 事件涉及竊取金融資產或智慧財產（IP） 廠商主張。DBIR 2026：製造業間諜動機 15% 廠商主張。這兩個數字說明資料層在 ODM 的相對重要性高於一般產業。

16.2 資料分類：ODM 的四維模型

依原則七，ODM 的資料分類不能是單一維度的「機密／內部／公開」。本手冊建議四維標籤：

為什麼要四維：

• 一份 JDM 專案的機構設計圖可能是「機密 + JDM 共有 + 無特殊法域 + 專案 X 進行中」
• 一份美國國防客戶的技術資料可能是「極機密 + 客戶所有 + ITAR 管制 + 專案 Y 進行中」
• 兩者的敏感度標籤相同，但可存取的人完全不同（後者僅限美籍或永久居民）

16.3 必備控制清單

16.4 分區差異

16.5 市場與選型

Gartner 對 DSPM 導入的已知痛點（2026 Buyer's Guide 明列）第三方評論：告警疲勞（alert fatigue）、掃描效能盲區（scan performance blind spots）、廠商架構風險（vendor architecture risks）。

EDRM/IRM 與資料庫活動監控（DAM）：本次未能確認 2025/2026 年任何專屬的 Gartner MQ 或 Forrester Wave 尚未證實。選型須自行 PoC 驗證。

16.6 DSPM 導入的實務順序建議

DSPM 最常見的失敗是「掃出 500 萬個發現，然後沒人處理」。本手冊建議的順序：

16.7 常見失敗模式

↑ 回本部目錄

17.1 本層要解決的問題

依原則五：設計目標是 29 分鐘（CrowdStrike 2026 eCrime 平均突破時間）廠商主張。

這意味著 SOC 的成功指標不是「發現了多少事件」，而是「從入侵發生到攻擊者被阻斷的時間」。

17.2 遙測策略：優先序而非全收

全收所有日誌是最常見的預算陷阱。本手冊建議的優先序（以 ODM 情境調整）：

17.3 遙測管線（Telemetry Pipeline）

市場事實 已證實：Gartner Market Guide for Telemetry Pipelines，2025-09-02，分析師 Andre Bridges。預測「2027 年 40% 日誌遙測經由 pipeline 產品處理」（2024 年 <20%）。

Market Guide 不做排名，無 Leader 概念——不可宣稱「Cribl 是 Leader」。Representative Vendors 包含 Cribl（Stream/Edge/Lake/Search）、Bindplane、DataBahn、Onum 等。

遙測管線在 ODM 的四個具體價值：

但必須驗證的風險（若導入管線，PoC 必測）：

1. 偵測完整性：縮減後偵測規則是否仍能命中？必須以已知的攻擊模擬驗證
2. 計費量差異：實際降低多少 SIEM 授權量
3. Rehydration 可行性：從物件儲存回灌重放的實際時間與成本
4. 管線本身的可用性：管線故障即全部遙測中斷，需 HA 與緩衝重送機制

17.4 SIEM

市場事實 已證實：

2024 版 MQ 揭露的廠商 Cautions（2025 版 Cautions 未取得）第三方評論：

SIEM 選型的 ODM 特有考量（若集團正在進行 SIEM 選型）：

17.5 SOAR 與自動化

SOAR 的實務定位：對 2–3 人的 SOC 團隊，SOAR 的價值不在於「複雜的自動化劇本」，而在於三件具體的事：

17.6 MDR：外包的判斷

市場事實 已證實：Gartner 明確無 MDR Magic Quadrant（eSentire 引 Gartner 原話：「at this moment, Gartner does not publish an MDR Magic Quadrant」）。只有 Market Guide for MDR，2025-10-01，分析師 Pete Shoard, Andrew Davies, Angel Berrios。

ODM 是否該用 MDR：

MDR 合約必須明訂的五件事：

1. 回應時間 SLA（區分告警確認 vs 圍堵動作）
2. 圍堵權限：MDR 能否直接隔離主機？白名單為何？
3. 資料存放位置與保存期
4. 退場時的資料交還（原始日誌、偵測規則、案件紀錄）
5. MDR 自身遭入侵時的通知義務（Silk Typhoon 的教訓）

17.7 AI SOC：證據空白區

這是本手冊要求最謹慎處理的一節。

Gartner Hype Cycle for Security Operations, 2026（2026-06-05） 第三方評論：

Sample Vendors（10 家，Gartner 明示非背書）：7AI、Arcanna.ai、Conifers.ai、Crogl、Dropzone AI、Exaforce、Intezer、Qevlar AI、Prophet Security、Simbian。

17.8 事件應變：單一通報決策樹

依第 5 章 §5.9.2，台灣總部適用的最嚴通報時限是 TWSE 的 2 小時（回應媒體報導）；中國廠另須注意《國家網絡安全事件報告管理辦法》的 4 小時（CII 為 1 小時）。

第一階段（事件確認後 0–120 分鐘）

召開單一判定會議，出席：資安（主持）、法務、IT、投資人關係／公關、業務代表。使用單一判定表單，同時判斷六條路徑：

第二階段（技術應變，與通報並行）

事件分級（建議五級）

本集團若已有既有的分級標準，應維持既有分級並僅補入通報決策樹；分級標準的一致性比完美更重要。

17.9 常見失敗模式

↑ 回本部目錄

18.1 本層要解決的問題

本層回答兩個問題：我們的破口在哪？防護真的有效嗎？

第二個問題尤其重要——資安投資最大的浪費是「買了但沒生效」。原則十要求所有宣稱可回溯至證據，本層提供的就是「控制有效」的證據。

18.2 CTEM 框架

Gartner 於 2022 年提出 CTEM 一詞，2023 年列為年度資安趨勢之一 第三方評論；原始 Gartner 報告標題與作者未能查證。

五階段：

18.3 弱點優先排序：EPSS 的實務價值

EPSS v4 於 2025-03-16 發布（Empirical Security / FIRST EPSS SIG）已證實。2026-09-29 更新：官方每日分數檔自 2026-06-15 起改標 model_version:v2026.06.15，即已改用新模型 已證實；FIRST 研究頁稱現行為 Version 5，但正式版本名稱與發布公告 尚未證實。以下為 v4 相對 v3 的改進：

• 資料擷取與監控大幅改善
• 新增惡意程式活動與端點偵測訊號（每月追蹤約 12K 漏洞）
• 新增 RSS/網路提及、Shodan 掃描、HackerOne 報告
• 以 cve.org 作為 NVD 備援
• CWE 收斂為 22 類
• REJECTED CVE 不再給分

EPSS 的效益數據（v3／v4 時期數據）第三方評論：

即修補工作量約降至 1/8。

本手冊建議的弱點優先序公式（優先於 CVSS）：

P1（24 小時）  = 在 CISA KEV 中 且 標記 known ransomware use 且 對外可達
P2（7 天）     = 在 CISA KEV 中，或 EPSS ≥ 0.7 且對外可達
P3（30 天）    = EPSS ≥ 0.1 且對外可達，或 CVSS ≥9.0 且內部關鍵系統
P4（90 天）    = 其餘 CVSS ≥7.0
P5（例行週期） = 其餘

外加 ODM 特有的調整項：

• 位於 Z4 產品開發區或影響已出貨產品元件者，優先序提高一級（因涉及 CRA 通報義務）
• 位於 Z5 廠務 OT 且無法修補者，直接轉為「網路隔離補償控制」而非留在待辦中

18.4 EASM 與資產發現

市場事實 尚未證實：Gartner 目前無 EASM 專屬 MQ；僅有 Gartner Peer Insights Voice of the Customer for EASM（2025）——客戶評分。

EASM 的 ODM 特有價值：

EASM 的實務要求：每季比對 EASM 發現與 CMDB，差異就是治理缺口。差異數量本身是一個有意義的指標（見第 27 章）。

18.5 對抗式暴露驗證（AEV）

市場事實 已證實：

2026 版預測：至 2029 年 60% 組織將把結構化暴露驗證納入 CTEM。

AEV 在 ODM 的四個高價值使用場景：

18.6 暴露評估平台（EAP）

市場事實 已證實：Gartner Magic Quadrant for Exposure Assessment Platforms（首屆），2025-11-10，分析師 Mitchell Schneider, Dhivya Poole, Jonathan Nunez。

市場定義：「將持續資產發現、風險導向優先排序與修補收斂為單一統一框架的解決方案」，並將暴露對應至攻擊路徑與業務風險脈絡。

完整象限與各家 Cautions 未取得 尚未證實。

18.7 紅隊與滲透測試

ODM 應納入紅隊範圍的五個特殊場景：

1. 服務台 vishing（Clorox 案的直接對策）
2. HR 履歷投遞（UNK_FistBump 的求職主題釣魚）
3. 供應商冒充（假冒設備廠商要求遠端維運存取）
4. 實體 + 社交工程組合（訪客進入、USB 投放、拍攝螢幕）
5. 產線降級測試：不攻擊 OT，而是模擬 IT 全斷，測試「降級作業手冊」是否可行

18.8 常見失敗模式

↑ 回本部目錄

19.1 本層的策略前提：先做邊界，後做深度

依 §4.7 的實證：勒索集團無需取得控制系統存取即可中斷工業生產。四個已證實案例（Asahi、Kojima→Toyota、JLR、Foxconn 北美）全部是「攻擊 IT、停掉產線」的模式。

19.2 IEC 62443 的正確用法

19.2.1　2-1 Ed.2 的關鍵價值：不必另建一套管理系統

IEC 62443-2-1:2024 Ed. 2.0（2024-08-07） 明確「重構要求結構、消除與 ISMS（ISO 27001）之重複、新增成熟度模型」已證實・IEC 官方預覽本。

要求以 8 個 Security Program Elements（SPE） 組織：ORG、CM、NET、COMP、DATA、USER、EVENT、AVAIL。

19.2.2　分區（Zones & Conduits）

由 IEC 62443-3-2:2020 定義並要求執行 已證實其為 system design 之安全風險評鑑。

Zone 依「後果嚴重度」而非 Purdue 層級分組，各指派目標 Security Level（SL-T）。同一 Purdue 層級的兩條產線，若一條停線影響單一客戶、另一條影響全廠出貨，應屬不同 zone。

Conduit 為區域間受控通道，每條通訊鏈路須被識別、正當化與治理——這正是第 10 章 §10.2 conduit 清冊的來源。

19.2.3　成熟度等級（ML）的正確理解 —— 一個常見誤用

ML 出自 IIC/ISAGCA 的 Security Maturity Model 對照文件，不是 IEC 62443 本體定義的等級。已證實

ISAGCA/IIC SMM 的四個 Comprehensiveness Level：

Security Level 與 Security Maturity 的區別（必須釐清） 已證實：

• Security Level =「a measure of the strength of a security measure（例如更強的密碼學）」
• Security Maturity =「the degree of confidence that the current security state meets all organizational security needs」，強調「the appropriateness in addressing the goals, rather than their objective strength」
• 原文警語：「higher comprehensiveness levels do not mean more maturity」（若超出組織需求）

19.3 Purdue 模型：疊加而非取代

見第 10 章 §10.3。此處補充五個現代失效點 第三方評論：

1. 雲端連線使 OT 資料橫向外流而非逐層上行
2. 邊緣運算／Unified Namespace 繞過逐層鏈路
3. 遠端維運無對應層級
4. IIoT 感測器直連雲端
5. 虛擬化／SDN 使實體層難以界定

核心問題：「連線已多維化，資料往上、往下、橫向、往第三方流動」。

IEC PAS 62443-1-6:2025（2025-12-19） 專門處理 IIoT 在 62443 系列中的應用 已證實，是處理第 1、4 兩個失效點的官方參考（注意：PAS 依 ISO/IEC Directives 於 4 年後自動撤銷）。

19.4 必備控制清單

19.5 市場與選型

市場事實 已證實：

2026 年 4 家 Leaders 中已個別證實者：Claroty、Armis（連 2 年）、Nozomi Networks（並宣稱在四項 Critical Capabilities 使用案例全部拿到最高分、且 Execution 與 Vision 雙軸最高）。第 4 家未能確認 尚未證實。

Critical Capabilities 四項使用案例 廠商主張：① Discover and Map CPS Assets ② Threat and Vulnerability Management ③ Prioritize CPS Security Issues and Remediation ④ Monitor CPS Security; Align to Enterprise Efforts。

19.6 分區內的 OT 差異

19.7 常見失敗模式

↑ 回本部目錄

20.1 為什麼 ODM 必須有這一層

1. EU CRA Art. 14 已於 2026-09-11 適用，全面義務 2027-12-11 已證實
2. AI 伺服器 L10/L11 使 ODM 直接接觸 BMC、BIOS、韌體整合（§1.3）
3. 客戶（尤其車用、工控、醫療客戶）已在合約中要求 IEC 62443-4-1 或等效的 SDL

20.2 PSIRT：組織與流程

20.2.1　標準依據

FIRST PSIRT Services Framework v1.1 的服務領域：

20.2.2　ODM 的 PSIRT 特殊挑戰

20.3 SBOM

20.3.1　格式：兩個必須知道的更正

以上兩項 已證實。

雙格式對照：

20.3.2　SBOM 的最低要求（CRA 對應）

CRA Annex I Part II 第 1 點：「a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies」第三方評論・第三方轉錄；正式出版前建議以 EUR-Lex PDF 覆核官方文字。

注意「至少頂層相依性」——CRA 的最低要求不是完整遞迴的相依樹。但客戶要求通常更嚴，且完整相依樹才能有效回答「Log4j 影響我們哪些產品」這類問題。本手冊建議產出完整遞迴 SBOM，而非只做到 CRA 最低線。

20.3.3　VEX：讓 SBOM 可用的關鍵

SBOM 告訴你「產品裡有什麼」，VEX 告訴你「這個漏洞是否真的影響本產品」。沒有 VEX，一份 SBOM 會產生數百個不影響產品的 CVE 告警，導致客戶與內部都無法使用。

VEX 的四種狀態：not affected / affected / fixed / under investigation。ODM 的 PSIRT 必須能為每個高關注 CVE 產出 VEX 聲明並提供給客戶。

20.4 安全開發生命週期

20.4.1　IEC 62443-4-1:2018 已證實・IEC Webstore

Edition 1.0，2018-01-15 發布，狀態 Active（stability date 2027）。涵蓋：安全需求定義、安全設計、安全實作（含編碼規範）、驗證與確認、缺陷管理、修補管理、產品生命終止。僅適用於產品開發者與維護者，不適用系統整合商與終端用戶。

20.4.2　SSDF 與 SLSA

見第 15 章 §15.3。此處補充對產品的特殊要求：

20.5 漏洞情報基礎設施的變局

20.5.1　CVE 計畫的資金危機與現況 第三方評論

20.5.2　EUVD 已證實

European Vulnerability Database (EUVD) 於 2025-05-13 正式上線（先前為 beta），由 ENISA 營運，法源為 NIS2 指令。彙整來源包含 CSIRTs、廠商、CISA KEV、MITRE CVE、CSA GSD、GitHub Advisories (GHSA)。

20.5.3　CVSS 與 EPSS

見第 18 章 §18.3 的優先序公式。

20.6 CRA 落地的十二個月行動清單

依 §5.2 的時程（Art. 14 於 2026-09-11、全面義務 2027-12-11）：

20.7 常見失敗模式

↑ 回本部目錄

21.1 為什麼這是橫切而非某一層

供應鏈風險同時出現在：L1（第三方帳號）、L2（第三方連線）、L3（第三方軟體與設備）、L4（開源元件與 SaaS）、L9（產品元件），無法歸屬單層。

CSF 2.0 新增 GV.SC 把它定位為治理功能 已證實，這正確反映了它的橫切性質。

21.2 曝險的規模

21.3 供應商分級：以影響而非金額

本手冊建議的雙軸分級：

兩軸的判定準則：

T1 供應商的特別要求：

1. 現場稽核（至少兩年一次）
2. 24 小時事件通知條款
3. 第二來源或替代方案
4. 持續監控（外部資安評分服務、暗網監控、其自身的重大訊息）
5. 退場計畫（若該供應商遭入侵須斷聯，我方如何維持營運）

21.4 供應商資安問卷

市場標準對照 第三方評論：

Shared Assessments 官網於本次查證時被登入頁攔截，題數與版本無法回溯至發行機構一手來源，引用時應標註為二手。

憑證覆蓋率 第三方評論：SOC 2 Type II 可回答 CAIQ 的 60–70%、SIG Core 的 40–50%、VSA 的 70–80%；加上 ISO 27001 後 CAIQ 升至約 75–80%、SIG Core 升至 50–65%。

本手冊建議：不要自製問卷。理由：供應商每年收到數十份不同問卷，自製問卷的回覆品質與速度都差。建議：

• T1/T2 供應商：SIG Lite 或 CAIQ + ODM 特有的補充題（見下）
• T3/T4：接受 ISO 27001:2022 證書 + SOC 2 Type II + 簡短補充題

ODM 特有的補充題（多數標準問卷未涵蓋）：

1. 非生產環境：測試、開發、Demo 環境是否納入你的資安控制範圍？（TSMC/Kinmax 案的直接對策）
2. 我方資料的存放位置：具體到國家與雲端區域
3. 分包（第四方）：你是否將涉及我方資料的作業分包？分包商是誰？
4. 事件通知：你能在多久內通知我方？合約 SLA 為何？
5. 中國營運：你在中國是否有營運、研發或資料處理？（地緣政治審查的第一道門）
6. AI 使用：你是否使用 AI 處理我方資料？是否用於模型訓練？
7. 退場：合約終止時我方資料如何刪除？如何證明？

21.5 一項必須澄清的誤解：RBA VAP 不涵蓋資安

見第 5 章 §5.8.2。RBA VAP 官方範圍不含資訊安全 已證實。

21.6 第三方存取的技術控制

依原則四與 §4.4 的 Silk Typhoon 教訓：

21.7 客戶端稽核的應對

ODM 每年要接受數十次客戶資安稽核。這是重大的人力負擔，也是可以優化的流程。

優化策略：

21.8 常見失敗模式

↑ 回本部目錄

22.1 韌性的定義：以出貨為單位

四個已證實案例的共同教訓：

22.2 備份：3-2-1-1-0 與其標準地位

3-2-1-1-0 規則：3 份副本、2 種媒體、1 份異地、1 份離線/氣隙/不可變（immutable）、0 個備份驗證錯誤。

ODM 的備份必備項：

22.3 市場：備份平台

市場事實 第三方評論：Gartner MQ for Backup and Data Protection Platforms（2026 版）於 2026-07-03 發布，受評 11 家；Kaseya Unitrends 被剔除。

22.4 降級作業手冊（Degraded Mode Operations Manual）

這是本手冊最強調的單一產出。它不需要採購任何產品，但直接對應四個已證實案例的教訓。

建議內容：

演練建議：每年至少一次，可利用計畫性停機時段執行。範圍可從一條產線開始，逐年擴大。

22.5 業務衝擊分析（BIA）與 RTO/RPO

以出貨鏈為單位（原則一）：

22.6 已驗證的財務衝擊：可引用的數字

22.7 網路保險

市場事實 尚未證實：本次未確認 2025/2026 年任何一線分析師的網路保險專屬評測。

同業實務 廠商主張・公司自行揭露：

• 廣達：2008 年起投保資安險，增列社交工程與網路中斷附加條款
• 緯創：2021 年起全球投保資安險
• 四家台灣 ODM 均未揭露保費金額

ESG 評鑑指標 S-12（原 2.24）要件 3 明文要求量化揭露「資安保險金額」 已證實——這使網路保險成為可查核的治理項目。

ODM 投保的四個特殊考量：

1. 營業中斷（BI）的定義：是否涵蓋「供應商遭入侵導致我方停產」（contingent BI）？
2. 多法域承保：中國、墨西哥、捷克、泰國的當地承保要求（Controlled Master Program 架構）
3. 客戶求償：若我方事件導致客戶損失，保單是否涵蓋第三方責任？
4. 勒索支付：多數法域對支付贖金有法律限制（如涉及受制裁實體）

22.8 常見失敗模式

↑ 回本部目錄

23.1 人員風險：從意識訓練到人員風險管理

23.1.1　Gartner 的預測與方向

已證實

23.1.2　同業實測數據（可作為基準）

以上均為 廠商主張・公司自行揭露。

23.1.3　意識訓練的策略調整

基於本手冊的威脅數據，意識訓練的邊際報酬率已經下降：

• X-Force 2026：製造業初始入侵 漏洞利用 32% > 有效帳號 16% > 外部遠端服務 11%
• DBIR 2026 製造業：釣魚由 19% 降至 13%
• Sophos 2025：惡意郵件由 29% 降至 23%

但這不代表可以停掉訓練，而是代表訓練的重點應該轉移：

23.2 Arup 案：一個必須正確歸類的案例

全案 已證實。

佐證趨勢：M-Trends 2026 顯示 vishing 已成為第二大初始感染向量（11%），而 email phishing 持續下滑——與 Arup 案的手法轉向一致 第三方評論轉述。

23.3 內部威脅的人員面

依 §4.6 台積電 2nm 案：

23.4 AI 治理：雙重角色

AI 在 ODM 資安架構中有三個角色，必須分開處理：

23.4.1　框架依據

NIST AI 600-1 的 12 項 GenAI 風險類別 已證實：
① CBRN Information or Capabilities ② Confabulation（自信但錯誤的輸出）③ Dangerous, Violent, or Hateful Content ④ Data Privacy ⑤ Environmental Impacts ⑥ Harmful Bias or Homogenization ⑦ Human-AI Configuration ⑧ Information Integrity ⑨ Information Security ⑩ Intellectual Property ⑪ Obscene, Degrading, and/or Abusive Content ⑫ Value Chain and Component Integration

（粗體為對 ODM 最相關者。）

23.4.2　OWASP Top 10 for LLM Applications 2026 —— 必須更新的版本

2026 版清單 第三方評論：

2026 版方法論創新：首次以事故資料驗證社群投票——分析 7,714 起真實 LLM 相關事故 第三方評論。

OWASP Top 10 for Agentic Applications 2026：2025-12-09 發布，逾 100 位專家協作 已證實 — 發布日；完整條目清單本次未取得 尚未證實。

23.4.3　AI 使用治理的必備控制

23.4.4　分區差異

23.4.5　EU AI Act 對 ODM 的具體影響

依 §5.5.3：

23.5 常見失敗模式

↑ 回本部目錄