設計：框架選擇與總體架構

7.1 為什麼不能只用一個框架

任何單一框架都無法覆蓋 ODM 的需求。原因在於各框架的設計目的不同：

7.2 本手冊建議的四層框架堆疊

7.3 各框架的 2026 年現況（必須用對版本）

7.3.1　NIST CSF 2.0

CSF 2.0 快速指南（全部一手確認）已證實

對 ODM 最貼合的官方 Profile —— 但都還是草案已證實

7.3.2　ISO/IEC 27001:2022 與 27002:2022

其他 ISO 標準的重大改版（多數中文資料尚未更新）已證實

7.3.3　CIS Controls v8.1

7.3.4　IEC 62443 系列

IEC 已發行部件已證實（IEC Webstore）

IEC 62443-2-1:2024 Ed.2 的重大結構變更——這是本手冊 OT 章節的核心論述依據已證實（IEC 官方預覽本）。Ed. 2.0「與前版有重大技術變更」：重構要求結構、消除與 ISMS（ISO 27001）之重複、新增成熟度模型（Maturity Model）供評鑑使用。要求改以 8 個 Security Program Elements（SPE） 組織：

ANSI/ISA 版本與 IEC 版本編號不同步——引用時的易錯點已證實

引用時必須註明是 IEC 版或 ISA 版，並附年份。

SL 1–4 與 Zones/Conduits 的查證狀態

7.3.5　零信任：NIST SP 800-207 系列與 SP 1800-35

CISA vs DoD 的支柱數差異——常見的誤解

7.3.6　供應鏈與軟體供應鏈

ESF 安全軟體供應鏈系列（NSA、ODNI、CISA 共同發行）已證實：Part 1 Developers（2022-08）、Part 2 Suppliers（2022-09）、Part 3 Customers（2022-11）。系列源起為回應 Executive Order 14028（因 SolarWinds、Log4j 而生）；Part 3 明確引用 NIST SP 800-218 與 SLSA Framework 作為技術依據。

7.3.7　MITRE 系列

7.4 一項關鍵的負面發現：不存在官方的 CSF 2.0 ↔ IEC 62443 對映

已證實（負面確認）

NIST 官方 CSF 2.0 Informative References（OLIR）清單未包含 IEC 62443 或 ISA/IEC 62443。已對映至 CSF 2.0 的標準為：ISO/IEC 27001:2022、CIS Controls 8.1、NIST SP 800-53 Rev.5、NIST SP 800-171 Rev.3、NIST SP 800-81 Rev.3、PCI DSS 4.0.1、Cloud Controls Matrix v4.0、Secure Controls Framework、OWASP LLM Top 10 v2.0、NICE Framework v2.0.0。

亦即：目前不存在 NIST 官方發行、經 OLIR 驗證的「CSF 2.0 ↔ IEC 62443」對映表。

官方確實存在的對映途徑已證實

↑ 回本部目錄

原則一：以「出貨」為最高可用性目標，而非以「系統」

主張：所有 RTO/RPO 的定義單位必須是「一條產線從投料到出貨的完整資訊鏈」，而非個別系統。

依據

• Dragos 2025：25% 案例導致 OT 場域完全停擺廠商主張
• Kojima → Toyota：供應商 IT 系統離線導致 Toyota 日本 14 廠停產已證實
• Asahi：IT 訂單系統癱瘓導致日本 6 廠停止營運已證實

落地要求

• 繪製「出貨資訊鏈圖」，標出從投料到客戶收貨之間所有必要系統與介接
• 對每一條鏈定義 RTO/RPO，而非對每一個系統
• 建立「降級作業手冊」——IT 全斷時以人工維持出貨的正式程序

原則二：客戶信任是交付物，資安投資的商業論證來自訂單

主張：資安預算的主要商業論證不是「避免損失」，而是「維持與取得訂單」。

依據

• JLR 事件：損失絕大部分在 5,000 家下游供應商，ODM 正處於這個位置已證實
• MKS → Applied Materials：供應商事件出現在下游客戶的財測中已證實
• Microsoft SSPA：未完成 SSPA 前不得開始工作已證實
• ESG 評鑑指標 S-12（原 2.24）要件 4：ISO 27001 驗證加分已證實

落地要求

• 資安預算提案必須包含「因資安不足而可能失去或無法承接的訂單」估算
• 建立「客戶資安要求資料庫」，可依客戶查詢其技術要求、稽核頻率、通知時限
• 每次通過客戶稽核應記錄為可量化的資安成果

原則三：假設邊界裝置已被入侵

主張：對外邊界裝置（防火牆、VPN、SD-WAN 管理平面）的處置策略必須假設一旦遭利用即無法信任其韌體完整性。

依據

• CISA ED 25-03 明載攻擊者「可竄改唯讀記憶體（ROM）以在重開機與系統升級後持續存在」，且至少早自 2024 年即具備此能力已證實
• 2026 年新增 201 筆 KEV 中，Cisco 14、Fortinet 6、Ivanti 5，多筆標記 known ransomware use已證實
• CrowdStrike 2026：中國關聯行為者 40% 鎖定對外邊界裝置廠商主張

落地要求

• KEV 收錄且標記 known ransomware use 的邊界裝置漏洞：24 小時內完成修補或隔離
• 邊界裝置遭利用的事件處置不是「打補丁」，而是更換或完整重刷 ＋ 該裝置經手的所有憑證輪換
• 已終止支援（EOL）的邊界裝置必須有明確的下線期限，不得無限期展延

原則四：身分是新的邊界，非人身分是最大的盲區

主張：存取控制的主體必須從「網路位置」轉為「經驗證的身分 ＋ 裝置狀態 ＋ 情境」；且非人身分（NHI）的數量與風險已超過人類身分。

依據

• NIST SP 800-207（2020-08-11）：零信任的核心原則已證實
• NIST SP 1800-35 Final（2025-06-10）：24 家夥伴、19 套範例實作已證實
• Silk Typhoon：濫用竊得的 API 金鑰與憑證存取下游租戶廠商主張（Microsoft 一手）
• Gartner 2025 PAM MQ 將「PAM for machines」升格為評分要件第三方評論
• OWASP Non-Human Identities Top 10 (2025) 之 NHI7 Long-Lived Secrets、NHI1 Improper Offboarding已證實（清單）

落地要求

• 所有特權存取（人與機器）收斂至 PAM
• 禁止長期有效的 API 金鑰；一律改用短期憑證或 workload identity federation
• 建立 NHI 清冊：服務帳號、API 金鑰、憑證、機器人帳號的擁有者、用途、輪換週期、下線程序

原則五：偵測與應變的設計目標是 29 分鐘

主張：SOC 的流程設計必須以「攻擊者 29 分鐘內完成橫向移動」為前提，這代表自動化圍堵必須先於自動化調查。

依據

• CrowdStrike 2026：eCrime 平均突破時間 29 分鐘，最快 27 秒，某案例入侵後 4 分鐘即開始外傳資料廠商主張
• M-Trends 2026：初始存取至交手的中位時間 22 秒（2022 年為逾 8 小時）第三方評論轉述

落地要求

• 對高信心告警（如已知勒索軟體家族、CrowdStrike/Defender 高信心偵測）啟用自動隔離主機，不等待人工確認
• 人工確認留給「解除隔離」而非「執行隔離」——誤判的代價（一台機器暫時離線）遠低於漏判
• 定義「自動化圍堵白名單」：哪些主機（產線控制電腦、核心伺服器）不可自動隔離，改為自動通知 ＋ 人工 15 分鐘內回應

原則六：日誌保存期是偵測能力的硬上限

主張：日誌保存期不是成本問題，是能力邊界問題。

依據

• Volt Typhoon 在受害者環境維持存取「至少五年」，且使用 living-off-the-land 不投放惡意程式已證實
• M-Trends 2026：間諜型入侵中位停留時間 122 天第三方評論轉述；全球停留時間中位數 14 天（2024 年為 11 天）

落地要求

• 熱資料（可直接查詢）≥90 天
• 總保存（含冷儲存）≥12 個月，身分與網路連線日誌（DC/AD、DNS、VPN、Proxy、EDR 遙測）≥24 個月
• 保存期政策必須經法遵確認（各法域個資保存限制與資安需求的平衡）

原則七：資料分類必須以「專案 × 客戶」為正交維度

主張：ODM 的存取控制不能只用組織階層建模，必須引入專案與客戶兩個正交維度（ABAC 而非純 RBAC）。

依據

• ODM/JDM 商業模式中自有 IP 與客戶 IP 並存，JDM 之 IP 雙方共有、無單一所有權人
• ITAR/EAR deemed export：向外國籍員工釋出受管制技術視同出口，需依國籍的存取控制
• 客戶合約常要求「特定國籍員工不得存取本專案資料」
• 台積電 2nm 案：超出職務需要的資料庫存取權限是三個技術失效點之一已證實

落地要求

• 身分屬性須包含：部門、職級、專案代號清單、可服務客戶清單、國籍（僅限出口管制場景，須有 DPIA）
• PLM／檔案系統的存取策略以屬性組合判定，而非群組成員
• 專案結案後的存取自動撤銷（專案生命週期驅動的權限回收）

原則八：供應鏈治理是主要曝險，不是合規項目

主張：第三方風險應以「該供應商停擺時我方多久出不了貨」與「該供應商被入侵時我方受多大影響」排序，而非以採購金額排序。

依據

• DBIR 2026 製造業第三方涉入 61%（全產業 48%）廠商主張
• Silk Typhoon 策略轉向入侵 IT 供應商以取得下游存取廠商主張
• TSMC／Kinmax：供應商的測試環境是外洩來源已證實
• CSF 2.0 新增 GV.SC category，將供應鏈治理升格為治理功能已證實

落地要求

• 供應商分級以「單點失效（SPOF）分析」與「資料存取深度」為主軸
• 關鍵供應商必須有事件通知條款（24–48 小時）與第二來源
• 供應商資安問卷必須涵蓋非生產環境（測試、開發、Demo）
• 第三方遠端存取全部收斂至受監控的 PAM／ZTNA 通道

原則九：多法域的隔離是架構決策，可稽核性不等於可存取原始資料

主張：中國區隔離不是法律強制，是風險對沖與合約要求的架構決策；集團治理的可視性應以指標與境內稽核達成，而非原始資料回傳。

依據

• CAC 三路徑機制容許受管控跨境傳輸；2025-03 核准率 325/509第三方評論
• DSL 第 36 條／PIPL 第 41 條：未經批准不得向境外司法或執法機關提供境內資料——與 eDiscovery、CMMC 稽核、客戶稽核存在無法以技術化解的法律衝突
• 金管會 2024-03-05 明文要求強化子公司資訊安全監督已證實

落地要求：見 第 6 章 §6.6 的「治理層可視性與技術層隔離分離設計」框架。

原則十：所有對外的資安宣稱都必須可回溯至證據

主張：任何寫入 RFP、客戶回覆、年報、對外簡報的資安宣稱，都必須能指向具體證據（政策文件、稽核報告、系統設定截圖、第三方證書）。

依據

• ESG 評鑑指標 S-12（原 2.24）要件 3 明文要求量化揭露資安人力數、保險金額、會議頻率已證實
• Gartner 2026 Hype Cycle 四度警告 "AI washing"／"agent washing"，並建議買方「demand independent benchmarks」第三方評論
• RBA VAP 官方範圍不含資安——若以「通過 VAP」回應客戶資安問卷，構成不實陳述風險已證實

落地要求

• 建立「資安宣稱證據庫」：每一項對外宣稱對應一份可提供的證據文件
• 年報揭露的資安人力數與投入資源，必須與實際編制與預算一致
• 對外文件中的分析師定位必須註明「報告正式名稱 ＋ 發布日期 ＋ 分析師姓名」

↑ 回本部目錄

9.1 三維設計模型

一般資安架構圖是一維的（由外而內的層）。ODM 需要三維：

9.2 九層架構總覽

外加一個特殊層：

9.3 三個橫切主題

9.4 五個信任分區

9.5 分區 × 層的矩陣：架構決策的核心表格

這張表是本手冊主張的架構文件核心產出。每一格都需要明確的決策，而非「全公司一套」。

9.6 架構圖的敘述（文字版）

由外而內、由上而下的資料流與控制點：

[網際網路 / 客戶 / 供應商]
        │
        ├── 對外服務（Web、EDI、客戶入口）
        │      └─ WAF ＋ DDoS ＋ EASM 持續監控（L2/L7）
        │
        ├── 遠端使用者（員工、第三方）
        │      └─ SASE/SSE → ZTNA（非 VPN）→ 裝置狀態檢查（L1/L2/L3）
        │
        └── 對外邊界裝置（防火牆、SD-WAN）
               └─ KEV 24 小時修補 SLA；假設已被入侵（原則三）
                        │
        ┌───────────────┴───────────────┐
        │      Z1 全球區（微分段）        │
        │  ┌──────────┬──────────────┐  │
        │  │ OA/協作  │ 業務系統      │  │
        │  │ M365     │ ERP/PLM/MES   │  │
        │  └────┬─────┴──────┬───────┘  │
        │       │            │           │
        │   L5 資料層：分類 + DSPM + DLP + EDRM
        │       │            │           │
        │   L3 端點：EDR/XDR 全面覆蓋      │
        │       │            │           │
        │   L6：遙測 → 管線 → SIEM → SOC  │
        └───────┬────────────┬───────────┘
                │            │
   ┌────────────┴───┐   ┌────┴──────────────┐
   │  Z2 中國區     │   │  Z5 廠務 OT 區     │
   │  受控閘道      │   │  Level 3.5 DMZ     │
   │  獨立 IdP      │   │  堡壘機 + 單向閘道  │
   │  境內 SIEM     │   │  IEC 62443 zones   │
   └────────────────┘   └───────────────────┘

   ┌────────────────┐   ┌───────────────────┐
   │ Z3 客戶專案區  │   │ Z4 產品開發區      │
   │ ABAC 隔離      │   │ CI/CD + 簽章 HSM   │
   │ 專案生命週期   │   │ SBOM 產出          │
   │ 驅動權限回收   │   │ → L9 PSIRT         │
   └────────────────┘   └───────────────────┘

   橫切 X1 供應鏈：貫穿所有分區的第三方存取與元件來源
   橫切 X2 韌性：不可變備份 + 降級作業手冊 + 演練
   橫切 X3 人員與 AI：意識、服務台驗證、AI 使用治理

↑ 回本部目錄

10.1 分區的判定準則

新的系統或環境要歸入哪一區？依序回答：

1. 是否位於中國境內或處理中國境內產生的資料？ → Z2
2. 是否受特定客戶合約的隔離要求拘束（含 ITAR/EAR 管制技術資料）？ → Z3
3. 是否參與產品韌體／軟體的建置、簽章或 SBOM 產出？ → Z4
4. 是否位於產線網路或直接控制／監測生產設備？ → Z5
5. 以上皆非 → Z1

10.2 conduit（受控通道）的設計原則

分區之間的每一條連線都是 conduit，必須被識別、正當化、治理。這個概念來自 IEC 62443-3-2，但本手冊主張把它從 OT 推廣到整個架構。每一條 conduit 必須有一份紀錄，包含：

10.3 Purdue 模型的處理：不取代，而是疊加

Purdue Enterprise Reference Architecture 在 2026 年已被廣泛批評不足以描述現代 OT 環境。批評的五個失效點第三方評論：

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

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

Zone 的定義依據（IEC 62443-3-2:2020）：Zone 依「後果嚴重度」分組，各指派目標 Security Level（SL-T）；Conduit 為區域間受控通道，每條通訊鏈路須被識別、正當化與治理。

註：SL 1–4 的逐字定義與 zone/conduit 的正式定義文字位於 IEC 付費牆內，本手冊未取得尚未證實。集團應購買 IEC 62443-3-2 與 -3-3 正本以核對。

10.4 分區設計的常見錯誤

↑ 回本部目錄