iT邦幫忙

2026 iThome 鐵人賽

DAY 5
2
Security

時鐘從「知悉」開始:從零打造 PSIRT,三十天走完歐盟 CRA 的通報與 SBOM系列 第 5

Day 05|24 小時、72 小時、14 天:三份不同的報告,不是同一份寫三次

  • 分享至 

  • xImage
  •  

昨天講兩個鬧鐘。今天把短鬧鐘拆開看。

CRA 第 14 條要求製造商在發現產品有正在被利用的弱點時,分三次通報。很多人第一次看到會以為是「同一份報告寫三遍,愈寫愈詳細」。

不是。三個時限要的是三種不同的東西。

這套設計跟空難調查是同一個邏輯

民航事故調查有一套分階段報告的慣例:初步報告先講發生了什麼、有沒有人受傷;事實資料報告補上調查發現;最終報告才給原因與建議。

為什麼分三段?因為**「知道發生什麼」跟「知道為什麼發生」的時間尺度差很多**。堅持等原因查清楚才通報,第一時間需要知情的人會全部錯過。

CRA 第 14 條的三個時限是同一套邏輯。
https://ithelp.ithome.com.tw/upload/images/20260905/20169113EzZFp3Q7G7.jpg
24 小時那份不需要你查清楚根因。它甚至不需要你知道是哪個元件。它只需要你說:我們有一個產品,有一個弱點,它正在被利用,我們目前做了這些。

多數團隊卡住的原因就是想等到查清楚才送。等到查清楚,24 小時早就過了。

時鐘從「知悉」起算,不是從「確認」起算

這是最容易被忽略、也最容易出事的一句。

時鐘不是從你的工程師確認完弱點才開始跑,是從公司知悉那一刻。

「知悉」的認定比想像中寬。研究人員寄信到你的對外信箱,那封信被收到的時間點很可能就是起算點,不是誰打開它的時間,也不是誰轉給資安的時間。

而且這個時鐘不會因為週末暫停,不會因為時區暫停,也不會因為你們內部還在確認「這應該歸誰管」而暫停。

它是一個從外部視角開始計算的時間,跟你內部的流程狀態無關。
這對台灣公司特別不友善。台北比中歐快六到七小時,週五下午五點收到的通報,等你週一進辦公室,24 小時早就燒完,72 小時也快了。

重大事件是另一條線,而且最終報告是一個月

還有一個容易搞混的地方:第 14 條管兩種東西,時限不完全一樣。

遭利用的弱點:24 小時早期預警、72 小時漏洞通報、修補或緩解措施可用之後 14 天內最終報告。

嚴重事件(資安事件影響到可用性、真實性、完整性或機密性,或導致惡意程式碼被植入或執行):24 小時、72 小時一樣,但最終報告是漏洞通報後一個月。

實務上的意義:**你不能只準備一份 runbook。**弱點跟事件的判定條件不同、後續動作不同、最終報告的時間也不同。

那個「actively exploited」到底怎麼判

觸發整套流程的關鍵詞是「正在被利用」。這四個字決定你有沒有那 24 小時。

難處在於你通常不會有完整證據,手上可能只有客戶回報的異常、一則社群貼文、一個 PoC 影片,或情資廠商的一句話。
我的判斷原則是這樣:證據的門檻應該低於「法庭等級」,高於「有人在推特上說」。

具體來說,只要出現下面任一項,就啟動 24 小時流程(先啟動,之後可以撤回):

你自己的紀錄裡看到符合該弱點的利用軌跡
可信來源(CERT、情資廠商、客戶的鑑識報告)指出在野利用
公開的可運作 PoC,且產品暴露在網路上
弱點被列入已知遭利用的目錄

**寧可先啟動再撤回,不要等到確定才啟動。**啟動的成本是幾個人跑一次流程,不啟動的成本是超時。

這一條 Day 18 會講得更細,因為它牽涉到合規時鐘怎麼跟案件狀態脫鉤。

交付物:通報時鐘牆卡

這張印出來貼在牆上,或設成群組的置頂訊息。
┌─────────────────────────────────────────────┐
│ CRA 第 14 條 · 通報時鐘 │
│ │
│ 起算點:公司「知悉」的那一刻 │
│ (不是確認完,不是轉到資安手上) │
│ 不因假日、時區、內部釐清權責而暫停 │
│ │
│ ─── 遭利用的弱點 ─────────────── │
│ +24h 早期預警 │
│ 受影響會員國 / 弱點性質 / 已做的緩解 │
│ +72h 漏洞通報 │
│ 產品資訊 / 遭利用性質 / 矯正措施 │
│ +14d 最終報告(自措施可用起算) │
│ 完整描述 / 根因 / 已釋出的修補 │
│ │
│ ─── 嚴重事件 ───────────────── │
│ +24h 早期預警 │
│ +72h 事件通報 │
│ +1個月 最終報告(自漏洞通報起算) │
│ │
│ 啟動門檻(任一成立即啟動,可事後撤回) │
│ □ 自有紀錄看到利用軌跡 │
│ □ 可信來源指出在野利用 │
│ □ 公開可運作 PoC + 產品暴露在網路 │
│ □ 已列入已知遭利用目錄 │
│ │
│ 決策人:__________ 代理人:__________ │
│ 最後更新:__________ │
└─────────────────────────────────────────────┘
最後那兩格是重點。沒有名字的時鐘卡只是壁紙。

明天 Day 06:沒有落日條款,已經賣出去的也算

第 69(3) 條。這一條決定你要盤點多少產品,而多數人第一次讀都會誤解。順帶講 Annex III 的重要產品分類,以及它怎麼決定你要不要找驗證機構。

順便問一句。假設現在有人寄信到你們的對外信箱,說某個產品有弱點而且已經被利用:

這封信會在多久之內傳到能做決定的人手上?

(a)一小時內 (b)當天 (c)看是不是上班時間 (d)不確定,沒測過

留個字母就好,不用打長篇。我猜(d)跟(c)加起來會超過一半,包括我自己。

這系列每天更新,覺得有用的話幫忙訂閱一下。

參考:Regulation (EU) 2024/2847 第 14 條;通報義務生效日 2026/09/11。啟動門檻為個人判斷,非法規明文。


上一篇
Day 04|家裡失火,跟房子要抗震補強,不是同一種工程
下一篇
Day 06|沒有落日條款:已經賣出去的也算
系列文
時鐘從「知悉」開始:從零打造 PSIRT,三十天走完歐盟 CRA 的通報與 SBOM11
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

1
hunterlin
iT邦新手 5 級 ‧ 2026-09-08 14:52:32

寧可先啟動再撤回,不要等到確定才啟動 --> 推
我選(c)看是不是上班時間

24小時早期預警,這點是不是公司如果沒有系統或是人掌握狀況,遇到周末就有可能gg?

resorce iT邦新手 4 級 ‧ 2026-09-08 15:04:22 檢舉

24小時早期預警,這點是不是公司如果沒有系統或是人掌握狀況,遇到周末就有可能gg?<--專業耶~ 有什麼好建議嗎? 因為時鐘不會因為周末而為我們停留阿

hunterlin iT邦新手 5 級 ‧ 2026-09-09 11:05:21 檢舉

感覺假日只能透過AI的方式自動蒐集或是有監控系統之類的,才能避免人工的方式XD

resorce iT邦新手 4 級 ‧ 2026-09-09 13:51:10 檢舉

AI確實是可能的解決方案, 但是回到資安管理的架構 Human-in-Loop是必要的 所以人工可能減少但是逃不掉

我要留言

立即登入留言