《網路韌性法》的 24 小時通報時限一啟動，差距就在於團隊能否在時限內，從一個受影響的元件追出產品、版本與影響範圍。本文提出 Time-to-Know，量出從告警到足以決策所花的時間。
文／游政卿‧校訂╱CIO 編輯室
產品弱點通報進來後，團隊還要多久才能決定下一步？
在一場產品安全演練中，情境設定為：外部研究人員通報，某款產品的韌體疑似有可從遠端觸發的弱點。產品安全事件應變團隊（PSIRT）收到通報後，依照既定流程處理：
‧ 09:12：收到外部通報，威脅情資平台也同時發出告警。
‧ 09:40：完成初步驗證，確認這是一起產品安全事件。
‧ 11:40：確認哪些產品、韌體版本及開放原始碼元件受到影響，並核對軟體物料清單（SBOM）的記載。
‧ 13:05：管理階層掌握足夠資訊，可以評估安全公告要涵蓋哪些產品、如何降低風險，以及何時通報。
從收到通報，到有足夠資訊做決定，總共花了 3 小時 53 分鐘。其中有 2 小時用來核對 SBOM 與產品實際燒入的版本，並確認上游元件資訊。
我在演練現場的感受是，團隊已經掌握一些資訊，也開始處理了，但還沒弄清楚影響範圍，決策就卡在這裡。我把從收到通報或告警，到掌握足以支持下一個決定的資訊所花的時間，稱為得知時間（Time-to-Know）。
MTTD、MTTR 之外，為何還要量決策時間
過去，我們習慣用平均偵測時間（MTTD）和平均恢復時間（MTTR）衡量應變。MTTR 有多種用法，本文採用從系統故障到恢復正常運作的平均時間。這些指標依然重要，我也建議增加 Time-to-Know，看看發現異常後，團隊還要花多久才能做出下一個決定。
資訊還在確認時，團隊就可以先隔離設備、關閉功能或發出內部通知。後續要決定安全公告涵蓋哪些產品、如何降低風險，以及通報內容，則需要對應的證據。每個決定所需的資訊，應在事前講清楚。
這段空窗，正好被法規拿來檢驗。歐盟《網路韌性法》（CRA，Regulation (EU) 2024／2847）把通報期限訂得很清楚。自 2026 年 9 月 11 日起，適用 CRA 的製造商須依下列期限儘速通報：
‧ 製造商得知產品弱點已遭主動利用後，最遲須在 24 小時內提交早期預警、72 小時內提交弱點通報，並在修正或緩解措施可用後 14 天內提交最終報告。
‧ 製造商得知影響產品安全的嚴重事件後，同樣須在 24 小時內提交早期預警、72 小時內提交事件通報，並在提交事件通報後 1 個月內提交最終報告。
兩類通報共通的重點在於，24 小時起算點可能早於內部判定。前述演練設定的是疑似弱點，是否觸發 CRA 的強制通報，還要確認弱點是否已遭主動利用，或事件是否符合影響產品安全的嚴重事件條件。事件已符合通報條件，調查尚未結束，製造商仍須依期限先提交早期預警，再依各階段的期限，根據已掌握的資訊提交後續通報與報告。
24 小時是從企業得知產品弱點已遭主動利用時開始算，這個時間可能比工單被標記為產品安全事件還早。研究人員的第一封信、情資平台的告警，或供應商的通知，都可能是起算點，要看當時收到的內容，是否已足以讓企業知道弱點已遭主動利用。
如果收到通知時就已經知悉，團隊卻在一小時後才完成事件判定，但通報期限仍要從收到通知時算起，能用的時間就少了一小時。因此，程序要寫清楚如何判斷知悉時間，也要留下當時的資訊與判斷依據，事後才能向主管機關說明為什麼從那一刻起算。
我常跟團隊說，我們看得到異常，卻還說不清楚發生了什麼事。工具雖然多，出了事還是得靠人登入各個平台，把資料一筆一筆對起來，才能弄清楚影響範圍，判斷下一步怎麼處理。
用 T0 到 T3 量出 Time-to-Know 與可決策
我建議團隊先說清楚本次要決定的是安全公告範圍、緩解措施，還是後續通報內容，再用工單和系統留下的時間紀錄，追蹤以下四個時間點：
比較不同事件時，也要選擇性質相近的事件與決定，讓數字有可比性。
‧ T0：第一次收到通報或告警。記錄企業第一次收到外部通報或監控告警的時間。
‧ T1：確認是產品安全事件。記錄 PSIRT 將工單標記為產品安全事件的時間。
‧ T2：確認受影響的範圍。記錄團隊在 SBOM 與版本庫中，標記哪些產品、版本和開放原始碼元件受到影響的時間。
‧ T3：資訊足夠，可以決定下一步。工單要載明本次準備做的決定，並記錄六項資訊：受影響的產品與版本、元件類型、對營運的影響、攻擊是否仍在持續、可能涉及的法規，以及證據的可信程度。由事先指定的決策人確認現有資訊足以支持該項決定，再將工單轉為可決策（Decision Ready），並留下確認時間。
[ 加入 CIO Taiwan 官方 LINE 、 Facebook 與 LinkedIn，與全球CIO同步獲取精華見解 ]
尚未確認的事項，要記錄目前掌握的內容、負責人，以及對該項決定的影響。團隊也應在工單註明資料來源與查核結果，讓決策人知道哪些資訊已確認、哪些仍待查明，再判斷現有證據是否足以支持這次要採取的行動。Time-to-Know 就是 T3 減去 T0，也就是從第一次收到通報或告警，到資訊足以支持該項決定，總共花了多久。
分段看，還能追查時間花在哪裡：T0 到 T1 是驗證與確認事件的時間；T1 到 T2 可以檢查 SBOM、版本資料與日誌是否容易比對；T2 到 T3 則可以檢查資訊是否備齊，以及誰負責判斷、誰有權拍板，是否事先講清楚。
[ 推薦閱讀：24 小時考驗判斷力：CRA 要問的是多快釐清受影響產品 ]
在我看過的資料裡，較容易缺的是證據有多可信，以及可能涉及哪些法規。少了前一項，主管就難以分辨哪些內容已經確認、哪些還只是推測；少了後一項，該不該通報就容易拖到期限快到了才討論。分工上，研發與產品團隊可協助確認產品、版本和元件，資安團隊研判攻擊狀態與證據可信度，法務協助判斷通報義務。各項資訊由誰提供、誰複核，應依組織的實際職責事先說好。
本文以產品安全事件為例，所以要有工單、SBOM 和版本紀錄，而且資料得能互相核對。用在企業內部系統時，則可依資產清單、部署與版本紀錄追查。資料或工具還沒備齊的團隊，可以先量 T0 到 T1，用簡單紀錄留下收到告警與完成事件判定的時間，先知道這一段花了多久。
AI 代理幾秒完成操作，團隊追查要幾小時
量法有了，但新技術可能讓中間耗時更長。假設 PSIRT 接獲產品管理介面疑似遭不當使用的通報，追查後發現，AI 代理（AI Agent）用有效的 API 金鑰進入介面，讀取設定、匯出組態，再使用雲端備份工具。分別查看各個系統的紀錄，這些操作都符合各自的要求：認證系統顯示憑證有效，API 閘道顯示呼叫符合規格，雲端稽核紀錄也顯示操作在授權範圍內。團隊仍要查明這些操作是否符合原本的授權目的，以及涉及哪些產品、版本與資料。
我看這類案子時，通常先問三件事：這個 AI 代理是替誰做事、有哪些權限、實際做了什麼。最難查清楚的是最後一件。它讀過哪些產品和版本資料，又用了哪些管理介面與雲端工具，都得查。偏偏紀錄分散在產品日誌、雲端稽核紀錄和身分系統裡，PSIRT 得把各處的資料對起來，才知道它做了哪些事。
AI 代理可以在幾秒內完成一連串符合權限的操作，團隊卻得逐筆追查它們之間的關係。如果這些紀錄無法串起來，就會拖長確認影響範圍的時間，也就是 T1 到 T2。
要縮短追查時間，就得事先約定共用的識別碼，把 AI 代理的身分、授權來源和每次呼叫的紀錄連起來。如果三套系統各記各的，事後就得靠發生時間逐筆比對，猜哪些紀錄屬於同一串操作。有了共用的識別碼，才有機會用一次查詢找出相關紀錄，省下人工比對的時間。
供應鏈回覆與 RACI 決定 T2 到 T3 快慢
比對工具之外，供應鏈回覆與分工同樣影響時程。我們把維護 SBOM 和弱點揭露納入日常工作後，比對版本、對外溝通都有了固定做法。前述演練仍有 2 小時用來核對 SBOM 與實際燒入的版本，並確認上游元件資訊，顯示資料比對仍是需要改善的環節。
供應鏈提供元件資訊的速度，會影響 T1 到 T2 的版本核對。影響範圍確認後，誰負責評估公告、通報與緩解措施，則會影響 T2 到 T3。這兩段要分開追蹤，才能知道時間花在等資料，還是等判斷與核准。
事前沒說清楚誰負責、誰能拍板，出了事就容易卡在等人核准。分工可以事先約定，例如由產品與法務共同判斷是否發布安全公告，由法務與財務評估揭露範圍與時程；SBOM 範圍由研發確認，上游元件資訊由供應鏈團隊追蹤。各組織仍要依產品、業務與通報責任，決定實際參與的人員。
這些分工可以事先用責任分配矩陣（RACI）寫清楚：誰負責執行、誰負最終責任、要找誰提供意見，以及要讓誰知道。否則，到了演練現場，各方就容易互相等對方做決定。
報表只列完成數，看不見還沒確認的黃燈
還在確認的問題，報表上就該亮黃燈。如果只列出收了多少文件、完成多少查核，主管容易以為工作做得多，風險就管得好，反而看不到哪些問題還沒查清楚。
我更想在報表上看到三件事：
‧ 高風險產品所需的證據，有多少仍然有效、能用來做判斷。
‧ 依事件類型與要做的決定分類後，Time-to-Know 的中位數是多少，其中 T1 到 T2、T2 到 T3 各占多少時間。
‧ 資訊還在確認時，哪些作業可以繼續，是否已事先說清楚。
Time-to-Know 一旦列入每月報表，團隊就可能為了讓數字好看，提早把工單改成可決策。六個欄位雖然都填了，背後的證據卻還沒核對清楚。因此，還得安排獨立抽查，核對工單、版本紀錄與決策人的確認紀錄，檢查判定可決策的當時，資訊是否足以支持這次要採取的行動。
把 Time-to-Know 從 4 小時壓到 1 小時
資安長可以先把幾件事講清楚：事件發生後，各階段的主管需要掌握哪些資訊、誰有權拍板，以及證據查到什麼程度，就足以決定下一步。還有哪些事項待確認、繼續作業會承擔什麼風險，也要一併記錄。
[ 閱讀所有 游政卿 的文章 ]
以前述演練為基準，可以把下一次演練的目標設為：將 Time-to-Know 從將近 4 小時縮短到 1 小時以內。能否做到，要再用演練紀錄驗證，也要確認縮短時間後，做決定所需的證據仍然足夠。
攻擊越來越快，AI 代理也能用合法身分，在短時間內完成一連串自動化操作。如果主管還得等人把資料整理好，才能做決定，工具再多，也可能錯過及時處理的機會。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
