BSI技術指引 TR-03183-1
| 適合一般產品及資訊安全產業界，具備基礎教育背景的亞洲讀者。 此文僅供個人參考與資訊喚回，尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱歐盟與德國的BSI官方網站、洽詢各家驗證公司、諮詢顧問等。 CC BY-SA 4。0。 |
（見前篇）
5.9 RH_RT.1 - 風險處理
未被接受的風險必須被處理。處理並不代表完全消除風險，因為這通常不可能。此種處理手段的目標是根據附錄一第一部分的基本網路與資訊安全要求，實施適當的安全措施，將風險的衝擊或可能性降至可接受的水準。附錄一的第一項基本資安要求第一部分（1）規定：「帶有數位元素的產品應設計、開發及生產，以確保根據風險達到適當的資安水準。」這表示產品設計必須根據風險進行適當的風險處理。若產品設計能妥善實施，將帶來安全的開發與生產過程及成果。
風險處理由製造商負責，並依其製程及使用標準進行。該指引將定義後續選擇需求與適當控制的策略，並可與現有標準與流程結合。
5.9.1 RH_RT.1.1 - 選擇適當的控制項（活動）
5.9.1.1 一般
製造商必須根據網路與資訊安全風險評鑑，符合附錄一第一部分（2）的適用要求。這需要根據要處理的風險，初步選擇相應的需求。如果製造商無法有效處理風險，則可採用風險分擔。
一般而言，風險處理可先獨立於附錄一第一部分（2）所列基本網路與資訊安全要求，因為產品必須根據附錄一第一部分第1部分的風險，確保適當的網路與資訊安全水準。然而，PwDE仍須符合符合CRA規定的基本要求。
該指引中選擇適當控制的具體方法將在第六章討論。
5.9.1.2 輸入
• 評估風險清單，需處理的項目
• 附錄一第一部分的基本資安要求
5.9.1.3 控制
製造商必須選擇附錄一第一部分中適用的必要網路與資訊安全要求，且適當的控制措施以處理評估出來的風險並將其降低至可接受水準，並包括產品設計中選定控制事項。
5.9.1.4 輸出
• 產品設計中將納入的選定控制事項及相關風險清單
5.9.1.5 參考CRA
• CRA附錄一 第一部分（1）
• CRA附錄一 第一部分（2）
5.9.2 RH_RT.1.2 - 風險分擔
5.9.2.1.1 一般
如果製造商無法自行有效降低風險，則可以利用《風險分擔risk sharing》將風險降低到可接受的水準。《風險轉移risk transfer》一詞可同義使用，但通常避免使用，因為通常無法完全將風險轉讓給第三方，製造商仍需依據CRA第13條第5款在整合元件時執行盡職調查。
一般來說，有幾種方式可以與供應商分擔風險：
- 透過合規以分擔風險（與 CRA 合作）：若第三方元件受 CRA 約束，製造商可在預期用途、可預見使用及相關處理風險足以整合 PwDE 時分擔風險。其他關於網路與資訊安全的法規，也可能適合用於風險分擔。
- 透過合約以分擔風險：若無法規確保他方能共同分擔風險，製造商可透過與第三方製造商簽訂合約，以符合CRA的要求，強制執行適當的風險處理。此方法可與現有合約架構結合，如服務水準協議、基礎合約或資料處理協議。
注意：在整合自由開源軟體（FOSS）時，風險分擔並不常見，因為該等軟體專案通常缺乏容量、資源及法律義務來符合CRA的要求。若製造商無法妥善處理與FOSS元件相關的風險，他可能會依賴第三方作為開源軟體管理者，提供該元件的支援。這將有助於自由開源軟體的發展，並成為讓自由開源軟體在商業應用中可行的一種方式。
5.9.2.1.2 輸入
可分擔的部分風險清單
5.9.2.1.3 控制
若與第三方供應商分擔風險，製造商必須執行盡職調查，確保整合元件的製造商在法律上、合約要求或其他方面有義務並願意相應地處理風險。
5.9.2.1.4 輸出
• 分擔風險清單，包括製造商為盡職調查所採取的措施。
5.9.2.1.5 參考 CRA
• CRA附錄一 第一部分（1）
5.9.2.2 RH_RT.1.2.2 - 與使用者（活動）的風險分擔
透過提供足夠的設定與維護指引，也能與使用者分擔風險。此時製造商必須考量使用者的能力及其基礎設施。只有當分擔的風險符合使用者可預見的預期狀況時，才算是可以做到，因為使用者在法律或合約上都沒有義務共同分擔風險。最終消費者的常見期待是 PwDE 預設是安全的，且 PwDE 的安全配置與操作只需極少使用者互動。在其他情況下，假設是專業整合商或資訊管理者，若符合使用者預期，風險可能會予以轉移。這也包括提供 多件PwDE 以整合於其他各型 PwDE 中。
5.9.2.2.2 輸入
• 選擇分享風險清單；
5.9.2.2.3 控制
若與使用者分擔風險，製造商必須確保共享風險符合用戶可預見的預期範圍，並提供充分指引，記錄風險及使用者根據第8條預期的緩解措施。
5.9.2.2.4 輸出
• 共同風險清單，包括製造商為記錄共同風險所採取的行動；
5.9.2.2.5 參考CRA
• CRA附錄一 第一部分（1）；
5.9.3 RH_RT.1.3 - 實作與查證（活動）
5.9.3.1 一般
納入產品設計的選定控制措施必須相應實施，才能達到有效效果。這包括依據產品設計進行開發與生產所需的所有措施，以及查證設計對評鑑出來之風險的有效性，以及依規格正確實施的必要措施。查證是CRA符合性評鑑的一部分，並取決於所使用的模組及所實施的控制風險。有效性的查證至少應在概念層面進行，並以開發流程支持，證明製造商依設計正確開發與生產PwDE。一般而言，較高風險可能需要額外或深入的查證。
5.9.3.2 輸入
• 選定控制組清單及相關風險，將之納入PwDE設計；
5.9.3.3 控制
製造商必須實施所選定的控制措施，並根據相關風險查證其有效性與正確性。
5.9.3.4 輸出
• 已實施的控制措施清單及已進行的查證；
5.9.3.5 參考CRA
• CRA附錄一 第一部分（1）；
5.10 RH_DOC.1 - 風險評鑑文件（活動）
5.10.1 一般
依據第13條第3款及第4款，網路與資訊安全風險評鑑應做成記錄並納入第31條及附錄VII所要求的技術文件中。此外，風險評鑑的文件符合製造商利益，因為結構完善且完整的文件可作為風險評鑑更新的基礎。建議使用工具或模板來記錄風險評鑑。
5.10.2 輸入
• 風險前後環節；
• 評估出來的風險；
• 分擔的風險；
• 實施控制措施；
• 適用的基本網路與資訊安全要求；
5.10.3 控制
製造商必須以完整的方式記錄風險評鑑結果。這包括風險背景、評估出來的風險（包括相應實施的控制措施與分擔的風險），以及適用的基本網路與資訊安全要求。
5.10.4 輸出
• 風險評鑑的文件化；
5.10.5 參考CRA
• CRA第13條第3款及第4款；
5.11 RH_UPD.1 - 更新風險評鑑（活動）
5.11.1 一般網路與資訊安全風險評鑑必須依據第13條第3款在指定支援期間內適當更新。每當現有風險評鑑因威脅情境中的外部或內部變化而顯得過時，適當的更新是必要的。至少在以下事件中應做到：
• 產品更新並帶來資訊安全後續影響；
• 發現了新漏洞；
• 發現了新威脅，例如可能衝擊產品的新攻擊方法；
此外，由於並非所有相關事件都能在所有情況下監控，通常建議定期更新風險評鑑。
5.11.2 輸入
• 風險評鑑；
• 可選：影響風險前後環節的事件；
5.11.3 控制
當 PwDE 的風險前後環節改變時，製造商必須更新風險評鑑，並相應處理新的不可接受風險。
5.11.4 輸出
• 更新風險評鑑；
圖七：網路韌性、威脅與衝擊（示意圖）
5.12 決策準則
該指引將根據資產分類及PwDE的作業環境來制定決策準則。決策準則是簡化風險分析與評估的工具，應在產業界、組織性或產品層級上給出定義。決策準則濃縮現有知識，使風險分析能進行可重現且一致的風險評鑑。
風險評鑑可在未給出設詳細決策準則的情況下進行，因為此法能提供更多風險評鑑的自由度，但可能需要付出更多努力才能完成可供理解且前後一致的風險評鑑。
5.12.1衝擊標準
事件的衝擊主要取決於受影響的資產。為了估算事件的潛在衝擊，將使用以下量表：
衝擊：
• 1 - 微乎其微後果；
• 2 - 次要後果；
• 3 - 中度後果；
• 4 - 重大後果；
• 5 - 災難性後果；
衝擊是根據受影響資產及損失類型的機密性(C, confidentiality)、完整性（I, integrity）和可獲得性（A, availability），從下表衝擊準則中選擇基礎影響來估算。標準可依需調整。
基礎衝擊可能無法根據受影響資產的數量，尤其是長期衝擊或多種其他因素。若在該指引架構中使用放大率考量，尚須另外提供前後環節或使用情境的佐證理由說明。
Impact 衝擊= 基本衝擊 * 放大率
此指引區分了需要保護的資產與保護資產所需要的安全資產。
安全資產的衝擊等於對其所保護資產的衝擊，這由X'衝擊推論，其中X等於受保護資產的C、I、A。
資料資產Data Assets
|
資產 |
機密性C |
整合I |
可獲得A |
佐證說明 |
|
個人識別資訊（PII） 技術必要性 |
2 |
1 |
1 |
技術型必要個人識別資訊（PII）是指與個人相關的網路通訊與認證所必需的資料，對機密性衝擊輕微，且無法在不失去功能的情況下被保護。這包括 IP 位址及其他技術識別碼 |
|
PII通用型 |
3 |
2 |
2 |
一般性PII伴有中度 對保密性的衝擊，例如姓名、地址、照片或其他 |
|
PII 重要 |
4 |
3 |
3 |
個人身份資訊（PII）對相關人士在資訊揭露時有重大衝擊。包括財務和健康資料。注意：並不包含混雜在一般的個人身份資訊（PII）內的資料，因其未能識別是否重要。 |
|
其他通訊傳送 |
1 |
1 |
1 |
若遙遠方式傳遞的資料不含個人識別資訊（PII）及安全相關資料，則無相關衝擊 |
|
其他構成項目 |
1 |
1 |
1 |
構成項目無個人識別資訊（PII）亦不涉及安全資料； 若喪失完整性，資料可能會干擾 PwDE 的功能 |
功能資產Functional Assets
|
資產 |
機密性C |
整合I |
可獲得A |
佐證說明 |
|
基本功能 |
|
|
3 |
產品功能為其預期目的及可預見使用所必需的事項，且其可用性對使用者有中等衝擊 |
|
非基本功能 |
|
|
1 |
產品功能中可能屬於預期目的及可預見用途，但其可用性對使用者衝擊微乎其微，例如廣告、影片串流的額外資訊、AI 生成的提示或其他事項 |
|
功能安全 |
|
|
5 |
產品功能相關到安全性，其可用性對使用者有重大衝擊 |
|
網路通訊功能 |
|
3 |
|
產品功能關聯到網路可能會被竄改，並用來影響通常擁有超過兩個網路對等端的相鄰網路。 基底衝擊估計為中等，但如有需要可予以放大。 |
|
局部通訊功能 |
|
2 |
|
產品功能與鄰近節點的連線關係，通常只包含一個節點。基礎衝擊估計為低。 |
資訊安全資產Security Assets
|
資產 |
機密性C |
整合I |
可獲得A |
佐證說明 |
|
資安保密 |
C/I |
C/I |
A |
使用的保密工具（api 金鑰、密碼或其他）以確保受保護資產的機密性或完整性。機密的保密性與完整性衝擊，等同於根據安全機制對受保護資產的保密性或完整性的衝擊。此點同樣適用於可用性，因為沒有保密，無法執行功能或資產存取。 |
|
資安保密、網路工作項目能力 |
3/4 |
A |
A |
使用時的保密（api 金鑰、密碼或其他）由
PwDE 用於網路或網路資源的認證。一般而言，機密性喪失的衝擊等同於未經授權使用揭露秘密存取受影響網路或網路資源的衝擊。對於衝擊完整網路認證的保密，假設衝擊
4，對於單一網路資源，衝擊 3可以當作基準線，且可根據特定使用情境調整。 |
|
資安在大眾性構成項目 |
1 |
I/C |
A |
資訊安全相關構成項目，其機密性喪失對受保護資產無衝擊，仍需根據受保護資產的機密性或完整性，在完整性與可用性方面受到保護。這包括例如伺服器憑證或用於密碼協商的密碼套件。 |
|
資安登錄 |
C |
I |
2 |
資訊安全相關登載日誌包含可能在事件發生時揭露安全相關資料，或控以隱藏事件的資訊。短期的可用性損失是次要問題。若長期無法取得與安全相關的登載日誌資料是主要問題，則可配合使用放大率。 |
|
資安機制 |
|
I/C |
A |
與資訊安全相關的功能，需根據受保護資產的機密性、完整性及可用性，確保完整性與可用性。 |
（未完，見次篇）
沒有留言:
張貼留言