BSI技術指引 TR-03183-1
| 適合一般產品及資訊安全產業界，具備基礎教育背景的亞洲讀者。 此文僅供個人參考與資訊喚回，尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱歐盟與德國的BSI官方網站、洽詢各家驗證公司、諮詢顧問等。 CC BY-SA 4。0。 |
（見前篇）
第二部分漏洞處理要求項目
帶有數位元素產品的製造商應：- 識別並記錄帶有數位元素的產品中的漏洞與元件，包括以常用且機器可讀格式繪製軟體材料清單，至少涵蓋產品頂層相依性；
- 針對帶有數位元素的產品所面臨的風險，立即處理並修復漏洞，包括提供安全更新；在技術上可行的情況下，新的安全更新應與功能更新分開提供；
- 對包含數位元素的產品安全性進行有效且定期的測試與檢討；
- 安全更新發布後，分享並公開已修復漏洞的資訊，包括漏洞描述、使用者識別受影響數位元素的產品資訊、漏洞影響、嚴重程度，以及清晰易取得的資訊，幫助使用者修復漏洞；在正當理由的情況下，製造商認為公開的安全風險超過安全效益，可能會延遲公開有關已修復漏洞的資訊，直到使用者獲得適用相關修補程式的機會；
- 制定並執行協調性漏洞揭露政策；
- 採取措施促進其產品潛在漏洞資訊與數位元件及產品內第三方元件的共享，包括提供聯絡地址以通報產品中發現的數位元件漏洞；
- 提供機制以安全分發帶有數位元素產品的更新，以確保漏洞能及時修正或緩解，並在安全更新適用時自動進行；
- 確保若有安全更新可用以解決已識別的安全問題，必須立即發布，原則上皆免費提供，除非製造商與企業用戶另有協議，且針對帶有數位元素的量身訂做產品；發布該項補釘時並附有提供相關資訊的警示資訊，包括可能採取的措施。
圖四：基本資訊安全要求結構與交互作用
只有符合第一部分要求的 PwDE 才能放入歐洲市場，這必須由製造商先予做到而展現之。第二部分要求由製造商自PwDE放入市場之日起，並於產品整個支援期間內達成之。第一部分的要求著重於確保產品設計與預設安全，而第二部分則著重於持續的漏洞處理流程。
然而，上述兩個部分並非彼此獨立，因為第一部分（2）點（a）要求產品必須沒有已知可利用漏洞，因此製造商必須先建立漏洞處理流程，以減輕已知可利用漏洞，然後才將PwDE放入市場。第二部分要求製造商識別、處理並修復漏洞，這可能包括更新 PwDE 的風險評鑑，以及變更第一部分要求的實施方式。
第一部分（1）是CRA的總體要求，要求製造商根據網路與資訊安全風險評鑑，確保PwDE達到適當的網路與資訊安全等級。此處包括識別潛在風險，並在PwDE上實施適當措施以降低這些風險。第一部分（2）以高層級涵括的產品需求支持第一項要求，這些要求必須根據風險評鑑並適用時實施於 PwDE。
3.10 不合規的後果
放入市場的PwDE係受到相應的市場監督主管機關之管制。製造商應根據市場監督機關的合理要求，提供所有必要的資訊與文件，以紙本或電子形式展現產品與數位元素及製造商所建立的符合基本資安要求的流程。製造商必須配合市場監督主管機關，採取任何措施，消除其放入市場的數位元素產品所帶來的網路與資訊安全風險。
違反CRA義務可能導致重大罰款（最高可達1,500萬歐元，或是佔企業全球年營業額的2.5%）、市場限制或產品召回。
3.11 如何準備CRA
簡單來說，以下幾個面向即使沒有具體法規指引，也應考慮以妥善面對CRA的考驗：1. 對必須受到PwDE保護的資產及潛在威脅進行誠實的網路與資訊安全風險評鑑；
2. 根據CRA的基本要求，利用適當的安全控管，將風險降低至可容忍的程度；
3. 將用戶放在心上，並以開放透明的方式溝通，以用戶的最佳利益為依歸；
4. 維護 PwDE 在整個生命週期中的資訊安全性，並與相關單位合作防範漏洞；
5. 採用現有最佳實務，無須重新發明輪子。
遵循上述的各個面向，每一家製造商，尤其是已經熟悉網路與資訊安全的廠商，都應該具備充分的CRA準備妥當情況。
此份技術指引將更詳細說明CRA的潛在待實施考量，特別是針對剛接觸資安主題的製造商。
4 Usage
該技術指引提供製造商或第三方代表製造商進行自我評鑑。執行評鑑時必須考慮以下說明與評鑑程序。4.1 評估員
評鑑由評估人員執行，評估人員可以是製造商自身組織或由第三方為之。選擇評估者時需考慮以下因素：• 評估員需具備足夠的技術知識及評鑑方法，以合格方式執行評鑑；
• 評估員需取得或被提供所有執行評鑑所需的資訊；
• 評估者必須保持公正，不應參與帶有數位元素產品（PwDE）的開發事項，以促進獨立地評鑑。
即使評鑑是由開發團隊執行，也必須以適當的批判心態進行評鑑，並保持客觀。
4.2 評鑑範圍
符合性評鑑針對PwDE的設計或完成的PwDE實例進行。將採用圖五中的通用 PwDE 架構。PwDE由依據（CRA第3（1）條）提供到市場的硬體及/或軟體元件組成。這些「提供到市場的元件」會銷售到各處並受到使用者控制。
提請注意：某個PwDE 可能接觸到多個使用者，例如：安裝 PwDE 的整合者、負責配置與維護 PwDE 的管理者，或實際使用 PwDE 功能的終端使用者。經銷商若原封不動地轉售 PwDE，則不被視為使用者，因為經銷商既不更改 PwDE，也不使用其功能。
若PwDE允許從硬體或軟體面向改造元件，或由製造商（或其他經濟營運者）提供到市場、或受渠等控制的元件，此等元件在評鑑中毋須納入考量。而得能容納該等元件的界面則是 PwDE 的一部分，亦須受到前述的評鑑。此外，風險評鑑還必須考慮可能用到帶有額外元件的效應。
同樣的情況也適用於應與其他PwDE一起使用、由製造商（或其他經濟營運者）提供到市場或由其控制的PwDE。
使用者整合的額外元件不屬於 PwDE，例如額外的應用程式或服務。雖然此等未由製造商整合的元件不屬於 PwDE 的一部分，但若使用者整合第三方元件符合 PwDE 的預期目的或可預見用途，執行風險評鑑時仍須考慮相關風險。
除了市面上的軟體/硬體元件外，PwDE 還包含由製造商設計與開發、或由製造商負責的遠端資料處理解決方案（RDPS, remote data processing solutions），若缺乏該等解決方案，將阻礙帶有數位元件的產品執行其功能（CRA 第 3（2） 條）。
根據CRA第26條，委員會將提供更多關於RDPS的指引文件。在此段等待期間，此份技術指引將假設由製造商設計與開發、提供「已提供到市場的元件」功能的軟體，皆為 PwDE 的「RDPS」。開發亦包括第三方軟體的量身打造及實施 PwDE 使用的新特性。設定第三方軟體的行為並不視為開發。
此處包括由製造商設計與開發、為 PwDE 必要功能所必需的 RDPS，以及對使用者而言不重要的其他 PwDE 功能所必需的 RDPS，如；遠端遙傳或廣告，因為這些非必要功能也可能對 PwDE 構成風險。抑或即使由製造商開發，但若軟體對 PwDE 功能沒有直接衝擊，則並不屬於 PwDE，例如：時程安排程序、後端日誌架構、無商業邏輯的儲存或其他基礎設施服務。
RDPS 元件的基礎架構，即硬體、第三方軟體及運作 RDPS 元件所需的組織措施，並不屬於 PwDE 的一部分。然而，製造商仍負責 RDPS 元件，並必須透過提供必要的基礎設施來確保安全運作。
4.3 評鑑時間點
由於無法避開使用者自行修改 PwDE為不安全狀態，因此只有依照使用者手冊建議初始配置及（可能的）更新至最新版本後的狀態才對評鑑才有參考價值。此狀態可透過執行以下步驟達成：• 取得新產品或將產品重置至原始狀態，例如恢復出廠設定或全新安裝。
• 依照使用手冊建議啟動產品及初步設定。
• 若在初始設定時尚未更新，則執行最新版本軟體。
4.4 情態動詞
該指引中關鍵詞「必須must」、「絕不must not」、「要求required」、「應shall」、「不應shall not」、「須should」、「不須should not」、「建議recommended」及「可選optional」，當且僅以全部大寫字母寫出時，應依BCP 14（RFC 2119， RFC 8174）中所述解釋，如此處所示。1. 「必須must」這個詞，或「要求REQUIRED」或「應SHALL」，表示該定義是絕對必要的規範要求。
2. 「絕不must not」或「不應SHALL NOT」，表示該定義為絕對禁止的規範。
3. 「should」或形容詞「RECOMMENDED」，表示可能存在正當理由或在特定情況下忽略特定項目，但其完整含意必須是理解並謹慎權衡後才得以選擇另一條途徑。
4. 「須should」或形容詞「不建議NOT recommended」，表示在特定情況下會因某種有效的理由，使該行為可以接受甚至甚有用處，但在實施任何以此情態動詞描述的行為前，應充分理解其含義並仔細權衡。
4.5 控制
CRA的要求由該條例自身寫出各項規定。該份技術指引將制定控制措施，旨在降低PwDE的資安風險，並滿足CRA的基本資安要求。每個控制部分包含以下事項：
• 輸入（僅限活動）：製造商活動的預期輸入；
• 風險前後環節（可選）：基於風險的情境，且適用於控制時；
• 控制：必須由PwDE或其部分（如適用時）達成；
• 產出（僅限活動）：製造商活動的預期產出；
• 目標（可選）：由控制所保護的元件或功能類型；
• 評鑑指引（可選）：針對控制評鑑的額外指引。根據相關涉及的風險，可能會提供不同層級的評鑑指導；
• 實作指引（可選）：控制的實作特定資訊，例如特定的密碼演算法、或 PwDE 的特定配置；此事項並非強制性要求，而是由於涉及相關風險，建議以特定方式實施控制措施；
• 補償（可選）：若無法執行此控制，則可作為補償的替代控制；
• 參考到CRA：控制事項須引述所對應的CRA基本要求、或其他由控制措施支持的要求。此處的參考資料可用來識別由PwDE實施的基本要求。
4.6 評鑑程序
該節給出評鑑程序，以評鑑該技術指引中所述的安全控管是否得到遵循。考慮重現性與一致性，每個評鑑步驟都應由評估者記錄並納入第4.8節定義的測試報告中。評鑑透過依照以下規則評估該指引中每項控制措施的適用性與實現性予以執行：
控制：控制由一個帶有 MUST（必須）的規範性陳述組成，若陳述可被評鑑為【通過PASS】，否則控制【未達成（FAIL）】。控制事項可以標記為【不適用（N/A）】，若
• 可以參照到某種補償方式，
• 控制事項的目標機制並不存在於PwDE中，
• 控制語句中的「如果if」條件不適用，
• 或該控制事項與其他法規相抵觸。
一般來說，控制事項的評估範圍須足夠具體，若不夠具體，控制事項將由額外的指引補充，這些指引必須用於評鑑控制事項。控制事項至少必須根據（PwDE）的文件在概念層面進行評鑑。建議根據PwDE或製造商的行為進行功能評鑑，以取得額外保證，但並非強制要求。
基於風險的控制：基於風險的控制包含一個或多個風險前後環節、一個要求事項及可選的評鑑準則。若風險不適用於產品，則風險導向控制可能評鑑為【不適用（N/A）】。若係稱控制事項得由受風險影響的PwDE或其部分達成，則基於風險的控制之評鑑結果為【通過PASS】。
一般而言，CRA的要求只要採取適當的控制措施，即可充分降低網路與資訊安全風險。該指引使用以下類型的控制以方便區分：
活動：活動是行政控制，包含製造商應執行的活動以及預期的輸入與產出。若製造商執行要求中所述活動並產生所要求的產出，則流程控制即係【通過PASS】；否則，控制便是【未達成（FAIL）】。
機制：機制為主動技術控制，若控制依照 PwDE 描述實施，則稱為【通過PASS】，否則控制便是【未達成（FAIL）】。
文件化：文件化是在 PwDE 的運行過程的產出物，但不是直接屬於 PwDE 的部分。若製造商以上述方式提供文件供內部、外部或公眾使用，則文件控制係【通過PASS】。文件評鑑不包括對係稱流程的評鑑。
評鑑最好整合進開發流程及持續型品質保證流程，若可能時，宜採自動化方式為之。
若所有控制點均標示為【通過PASS】或【不適用（N/A）】，則整體判定為【通過PASS】，否則便是【未達成（FAIL）】。
評鑑步驟可能包含以下各項術語，評估者必須對此有所了解及採用之：
• （普遍認可）的【現今技術水準state of the art】是指特定領域內，針對特定使用情境，目前且普遍認可的最佳實務。這裡通常不是要求使用最新技術，而是採用知名且成熟的技術、方法與流程，以符合特定使用情境。如有需要，會提供現今技術水準的示例或準則。
• （普遍認可）【現今技術水準的密碼學State of the art cryptography】遵循常見且知名的密碼學建議，例如 BSI TR-02102、SOG-IS 協議密碼機制或符合 ISO 18033-1 附錄 A 要求的類似標準。若密碼機制適合相應的使用情境，且目前尚無既有技術可行使此事項的攻擊，則可視為現今技術水準。
提供與發佈表示資訊的分配方式。預設情況下，製造商若未另行指定提供或發佈，則無需提供文件或其他紀錄給第三方。【提供】指的是授權特定第三方存取文件，例如PwDE的使用者。【發佈】意味著某件事被記錄下來，並可免費、輕鬆且公開地存取。
• 支援與實施表示某功能是否必須由PwDE直接實施，或僅在整合至其他PwDE的前後環節下支援。
• 預設且總是顯示 PwDE 配置/政策的有效性。「預設」意指若使用者未另行設定，PwDE 會依照描述方式運作。「總是」表示該項行為屬於強制執行，使用者無法更改。
4.7 整體判決的詮釋
整體判決僅作為指標，顯示PwDE是否符合該技術指引的要求，但並非直接聲明符合CRA規定。【未達成（FAIL）】不一定代表PwDE不符合CRA規範，因為該指引中的某些要求可能不適用於所有帶有數位元件的產品。【通過PASS】也不代表PwDE產品符合《網路韌性條例》（CRA），因為PwDE可能帶有該技術指引未涵蓋的風險。
4.8 測試報告
根據CRA第31條，製造商必須在將PwDE放入市場前，先擬具制定技術文件。其中包括：• 產品總體描述，包含數位元素，包括其預期用途、影響符合基本資安要求的軟體版本、附錄II中所列使用者資訊與說明，以及展示外部特徵、標記與硬體內部佈局的照片或插圖。
• 描述產品設計、開發與生產過程，包含數位元素與漏洞處理流程
• PwDE產品的生產與監控流程的必要資訊與規範，包含數位元素，並確證此等流程；
• 評鑑PwDE產品所面臨的資安風險，包括附錄一第一部分適用的基本資安要求；
• 為查證PwDE產品的符合性所進行的測試報告，以及符合附錄一的第一部分及第二部分所列出適用係稱產品的基本資安要求之漏洞處理流程；
利用該份技術指引，可以產生測試報告以記錄對PwDE產品的評鑑。
根據該份技術指引的要求，測試報告至少必須包含以下資訊：
• 評鑑日期
• 識別PwDE產品，至少包括以下資訊：
– PwDE產品的名稱與型號；
– PwDE產品說明及預期目的；
– 硬體與軟體版本；
– 軟體物料清單（SBOM）（如適用時）；
– 針對硬體 PwDE：展示外部特徵的照片或插圖，標記；以及內部佈局與硬體元件，並包含數位元素；
• 風險評鑑
– 已識別的資產與威脅；
– 評估風險；
– 可接受的風險；
• 設計文件化
– PwDE架構，包含硬體與軟體元件及數位化元件，以及網路和實體介面；
– 適用的控制措施，包括風險緩解及相應的必要網路與資訊安全措施要求；
– 選擇控制措施的實施內容說明；
– 選定之控制事項的查證流程；
• 說明漏洞處理活動
• 查證漏洞處理活動
• 提供給使用者的文件。
（未完，見次篇）
沒有留言:
張貼留言