事件通報¶
本作業手冊說明 Weblate 團隊如何處理產品安全性通報,以及影響由 Weblate 營運之服務的安全性事件。通報政策和期限請參閱 漏洞與事件處理。服務封鎖和復原請使用 Weblate 事件回應計畫。
由一人負責處理事件,並安排一位可支援的隊友擔任備援。視需要由同一批人調查、通報及溝通。聯絡人指派、存取資訊和已完成的事件記錄都應存放在團隊的私有紀錄中。
接手事件¶
任何人看到可信的主動利用通報或嚴重安全性事件通報時,都應透過 Signal 通知隊友。由一位有空的隊友接手負責並指定備援人員,不必等待管理階層核准即可回應。如果事件負責人無法處理,備援人員就接手。請在事件記錄中記下交接情形,讓期限和已承諾的更新都清楚可見。
立即建立一份私有事件記錄。請使用含時區的時間戳記記下團隊得知相關事實的時間,最好採用 UTC。請區分收到初始通報的時間,以及得知正在遭利用或發生嚴重事件的時間,並記錄各項依據。不要等到修正程式碼、正式宣告或完成調查後才開始準備通報。
評估通報內容¶
主動利用是指有可靠證據顯示惡意行為者未經系統所有者許可便利用弱點。理論上的弱點、概念驗證,或只有未經許可這項事實,都不足以證明發生惡意利用。請儘速調查疑似遭利用的情形,並記錄已知和不確定的事項。請參閱 CRA 第 3(42) 條。
若產品安全性事件已損害或可能損害重要或敏感資料、功能的保護,或已導致或可能導致惡意程式碼被植入或在產品或使用者系統上執行,請將其評估為嚴重事件。這包括執行已存在的惡意程式碼。請參閱 CRA 第 14(5) 條。請考量可用性、真實性、完整性及機密性。僅憑營運中斷的嚴重程度,不足以決定此分類。
請檢查受影響的版本、發行成品和隨附的相依套件,也要查看自架系統營運者回報的事件。由營運者負責本機封鎖;此處評估的是產品通報。執行階段的發現結果如何依 Weblate 威脅模型 處理,本身並不能決定是否需要通報事件。
如果主動利用也造成嚴重事件,請同時評估兩種通報流程。適當時,分別記錄得知事件的時間,並追蹤兩種最終報告期限。
請及早檢查是否發生個人資料外洩,包括資料遭意外或不法銷毀、遺失或變更,以及遭未經授權揭露或存取。即使沒有資料遭揭露,也要評估 隱私權通知。如有需要,請尋求外部意見,同時繼續調查和準備通報。
請記錄此事件是否必須通報或屬自願通報,以及判斷原因。有不確定之處時應儘速諮詢,不可因此停止準備工作或延誤適用期限。此政策基準不會判定 Weblate 承擔的法規角色;請參閱 產品與聯絡資訊。請分別評估受影響的託管服務和可下載發行版本,不要假設兩者適用相同的法規範圍。
建立一份私有事件記錄¶
請將以下欄位複製到團隊的私有事件記錄:
案件 ID、摘要、負責人、備援人員及交接紀錄。
產品、受影響的版本或成品摘要值、部署環境,以及已知的受影響產品提供地所在成員國;並註明資訊來源和限制。若已知且相關,也請另外記錄事件影響地點。
得知事件的時間戳記、支持證據、未知事項及分類理由,包括是否必須或自願通報的決定。
通報期限、提醒,以及個別的隱私權通知待辦事項。
調查時間軸、影響、緩解措施,以及每項修正或緩解措施何時開始提供。
已提交報告的副本、提交時間戳記、平台參考編號、收據、失敗記錄,以及要求補交的報告。
使用者警告、收件者或公開公告連結、已承諾的更新,以及任何延後技術細節揭露的理由和檢視日期。
尚待處理的事項,以及簡短團隊檢討的結果。
敏感證據和附件應與私有記錄一同保管,並限制只有處理事件的人員可以存取。認證資訊應存放在團隊的認證資訊儲存區。Signal 僅供協調使用;請將決策和相關時間戳記複製到可長期留存的記錄中。不要將這些資料放在公開問題追蹤區。
提交及追蹤¶
請使用最新的 ENISA 單一通報平台指南,確認協調 CSIRT、存取方式,以及必須或自願提交的管道。國家級事件通報入口網站不一定是 CRA 指定的通報端點。若不確定要使用哪個管道,請洽詢協調機關。
由事件負責人提交報告,必要時由備援人員接手。可行時請隊友協助檢查,但不要為了等待審查而錯過期限。請依照 主管機關通報 的期限和目前的平台表單提交。準時提交已有的資訊,註明未知事項,並隨調查進展補充內容。
在任一類型的早期警告中,請指出事件,以及已知時受影響產品提供地所在的成員國。這是產品散布資訊,不是個別使用者所在位置,也不只是觀察到遭利用的地點。嚴重事件的警告還須指出是否懷疑涉及不法或惡意行為。兩種流程都依據 CRA 第 14(2)(a) 和 (4)(a) 條 要求提供產品散布所在的成員國。
在遭利用弱點的主要通報中,請指出受影響的產品,並概述漏洞及利用方式的性質。依 CRA 第 14(2)(b) 條規定,請列出已採取的修正或緩解措施、使用者可採取的措施,以及適用時資訊的敏感程度。
在嚴重事件的主要通報中,請描述事件性質並提供初步評估,包括已知影響。依 CRA 第 14(4)(b) 條規定,請列出已採取的修正或緩解措施、使用者可採取的措施,以及適用時資訊的敏感程度。
在遭利用弱點的最終報告中,請描述弱點及其嚴重程度和影響。依 CRA 第 14(2)(c) 條規定,請提供已取得的惡意行為者資訊(包括曾利用或正在利用該弱點的人),以及為修正問題而提供的安全性更新或其他修正措施詳情。緩解措施一旦提供,即可能開始計算此期限,即使最終修補程式尚未完成也一樣。
在嚴重事件的最終報告中,請詳細說明事件,包括嚴重程度和影響、可能引發事件的威脅類型或根本原因,以及已採取和持續進行的緩解措施,依 CRA 第 14(4)(c) 條規定辦理。如果沒有持續進行的緩解措施,請明確說明。
散布資訊請使用現有的客戶或散布紀錄,例如已知付費客戶所在國家。請說明這些紀錄的限制:可能不知道其他使用者所在位置。不要因為產品在歐盟普遍提供,就推定產品已在所有成員國散布。本程序不要求追蹤個別使用者的位置或蒐集新的位置資料。請據實回報已知資訊,不要為了查明其他地點而延遲提交,並視需要更新資訊。請參閱 ENISA SRP 詞彙表 中的產品提供地欄位。
請儲存收據和報告參考編號。追蹤中期報告要求,並在事實變更時更新先前提交的資料。如果同一事件觸發兩種通報流程,請連結兩筆記錄並確保兩套通報要求都已涵蓋;不得默默以一份最終報告取代另一份。
若平台無法使用,請記錄失敗嘗試和時間戳記,透過已公開的備援管道聯絡協調機關,並依其指示辦理。平台重新可用後,請完成平台提交程序。以其他方式聯絡,不會自動證明已履行法定通報義務。
警告使用者並追蹤後續事項¶
請透過 漏洞與事件處理 所列的電子郵件和公開公告管道提供防護建議,不必等到修補程式或完整技術揭露完成。請說明受影響版本、已知影響、可採取的措施及仍不確定之處。記錄已傳達的內容,並履行承諾的後續更新。
主管機關通報、使用者警告及詳細技術揭露可視需要分別進行。若延後技術細節,請記錄安全理由,並在記錄的檢視日期重新評估決定。
復原後,請檢查剩餘的通報期限、要求提供的更新及揭露決定。召開簡短團隊檢討、記下改善事項,並在待辦事項完成後,或已明確交接給負責人且訂出期限後,結束事件記錄。
準備檢查清單¶
這些是準備工作,應先完成並私下記錄。發布本作業手冊,不代表存取權或演練已經就緒。
選擇一般通報聯絡人和備援人員,並約定其中一人無法聯絡時,隊友要如何通知彼此。
使用 ENISA 單一通報平台指南,確認通報存取權、復原安排、協調 CSIRT 及已公開的備援聯絡方式。帳號資料請保密。
請選擇負責人和備援人員都能存取的私有位置,存放事件記錄,並使用現有的團隊工具設定期限提醒和交接事宜。
確認能否存取客戶聯絡清單和 GitHub 安全性公告。
進行簡短的離線情境演練,涵蓋週五晚間收到弱點遭利用通報、發生嚴重事件但不確定弱點、收到自架部署或隨附相依套件的通報,以及同時觸發兩種通報流程的事件。也請模擬負責人無法聯絡、平台中斷、資訊不完整,以及最終修補程式完成前已提供緩解措施的情況。檢查按小時計算的期限和按日曆月計算的期限如何跨越二月。記下缺口和後續行動,不要將演練報告送給真實收件者。