2026年7月15日 星期三

製造商與產品的網路韌性要求 第一部分:一般要求(六之六)

BSI技術指引 TR-03183-1

適合一般產品及資訊安全產業界,具備基礎教育背景的亞洲讀者。

此文僅供個人參考與資訊喚回,尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊,經由整合篩選與文字調整。後續修訂請查閱歐盟與德國的BSI官方網站、洽詢各家驗證公司、諮詢顧問等。
CC BY-SA 4。0。


(見前篇)


5.12.2 可能性準則
為了估算事件發生的可能性,將使用以下量表:

可能性尺度:
1 - 風險情境極不可能發生;
2 - 風險情境不太可能發生;
3 - 風險情境較有可能發生;
4 - 風險情境極有可能發生;;
5 - 風險情境幾乎必然發生

一般而言,可能性高度依賴於具體風險,應以產業專屬知識與威脅情報來支持。

該指引將使用「環境」指標,根據預期的作業環境保護,根據PwDE或其組成部分所提供的保護,來評估事故發生的可能性,從而降低事故發生的可能性。此方法可獨立於特定可能性的攻擊者剖繪面使用,因為這些資訊已包含在衝擊中,衝擊越高,攻擊動機與能力越高。

注意:環境指標可依特定使用情境調整,包括更複雜的方法。最初定義的指標未包含攻擊鏈或細緻防禦深度策略的考量,因為這需要假設潛在的環境失效或資產衝擊的環境敏感變化。

Indicators

指標

佐證說明

界面限制

介面限制降低攻擊的可能性。此指標顯示 PwDE 最大假設可達性。

存取限制

存取限制會衝擊潛在攻擊者的數量及可能的攻擊時段,降低成功攻擊的可能性。

使用者能力

缺乏技能的使用者更容易錯誤操作產品,或更容易受到社交工程面向的攻擊。此指示器僅在風險的處理方式依賴使用者之應對作為

 界面限制

指標

佐證說明

實體

PwDE 內部通訊,並可透過物理操作存取。對於軟體產品而言,這涉及對軟體內部通訊/處理的操作。攻擊者需要直接存取 PwDE 並在內部進行操控

局部

PwDE 透過本地介面進行短距離通訊,例如嵌入式使用者介面、NFC 或短距離有線連接。軟體方面,這也包括在同一裝置上與其他軟體 PwDE 之間的進程間通訊。攻擊者需要PwDE直接本地存取權限

搭配既定網路

PwDE 與使用者已知且信任的相鄰網路通訊,無需預期連接外部網路。該網路專門用於特定使用情境,因此預期僅有限數量的 PwDE,僅用於該專用場景,例如本地家庭匯流排系統、點對點無線區域網路(WLAN)或藍牙連結。攻擊者必須靠近 PwDE 才能透過網路存取,外部網路的存取並非設計

已知網路

PwDE 與使用者已知且信任的相鄰多功能網路通訊,該網路與其他 PwDE 共享,用於多種使用情境,例如家庭或辦公室網路。攻擊者必須靠近 PwDE 才能透過網路存取,外部網路的存取並非原本預期方式

外部網路

PwDE 與非使用者或其組織控制的網路通訊,例如行動網路、WAN 或未知的 WLAN。攻擊者可能從任何地方存取 PwDE,因為外部網路的拓撲結構未

 存取限制

指標

佐證說明

限制

進入PwDE的權限是有限的,只有一群已知的人能使用PwDE

公眾限制

預期提供公眾進入或不可避免,但PwDE通常由已獲得授權人員監督。攻擊的窗口通常係受到

移動式

預期提供公眾進入或不可避免,但PwDE通常由已獲得授權的人員監督。PwDE是移動的,攻擊者可以將之移除。攻擊的窗口通常係受到,但可以透過移動目標來擴大窗口。

無限制

沒有特定的存取限制,也沒有潛在攻擊者和攻擊窗的限制。如果本地存取受到限制,攻擊仍可能在沒有本地存取的情況下得以執行。

 使用者容量

指標

佐證說明

與使用者無關

使用者能力衝擊事件發生的可能性

有經驗者

熟練使用者,例如資訊專業人員,不太可能因操作與設定不當而曝露產品,並能利用自身專業知識提升 PwDE 資訊安全性

指示後使用

練的使用者,例如熟悉技巧或懂 IT 資訊安全、閱讀手冊的使用者,不太可能因操作與構成項目不當而曝露產品

無經驗者

技術不夠熟練的使用者,可能會因操作與構成項目不足而不必要地曝露產品

 

5.12.3 接受準則

風險可以根據其可能性與潛在衝擊進行分類與評估。該指引將採用以下風險接受準則:
  • 若存取限制無法阻止具備低複雜度攻擊能力的潛在惡意行為者取得本地存取,則無法接受本地攻擊造成中等或更高衝擊性的風險。
  • 若存取限制無法阻止本地存取已知但潛在惡意且具高複雜度攻擊能力的行為者,則無法接受本地攻擊帶來高或更高衝擊的風險。
  • 若網路限制無法阻止一群具低複雜度攻擊能力的潛在惡意者存取,則中度或更高程度衝擊的風險是不可接受的。
  • 若網路限制無法阻止已知有限群體(具備高複雜度攻擊能力的惡意行為者)存取,則無法接受高或更高網路攻擊衝擊的風險。
  • 若使用者為外行人,因初始配置錯誤而產生中度或更高衝擊的風險是不可接受的。
  • 若使用者是受訓技工但非熟練專家,因初始構成項目錯誤而產生高度或非常高程度的衝擊風險是不可接受的。
風險的接受度也可透過評分方案與風險矩陣加以評估,如附錄B(參見原指引內容)所示。此方法高度實驗性,該指引不會直接採用。

5.13 實務風險處理

風險處理需要經驗,且取決於產品及相關人員,因此很難以既詳細又通用的方式描述風險處理,既能幫助你,又足夠通用以適用於所有產品。

該指引附錄A(參見原指引內容)中包含一個簡單的示例,作為製造商在無風險處理階段時的初步指引。

6 採用可調整型基於風險的控制措施 (ARC, Adaptable Risk-based controls)

該技術指引將採用一種稱為「可調整型基於風險的控制」(ARC)方法,根據相關風險選擇適當的控制措施。因此,ARCs總是會伴隨一個或多個風險情境。

6.1 風險情境 risk scenarios

風險情境包含以下資訊:
風險情境:描述風險前後環節的情境;
資產:受影響的資產及其衝擊情形;
環境:環境參數(存取限制、介面限制、使用者能力);

若某件PwDE帶有風險,可依以下步驟評估之:

1. 依前述之風險處理方式進行風險評鑑。
2. 根據衝擊準則及環境,對所識別的資產進行分類,係依負責處理的資產化PwDE組成部分做出分類。這將帶來資產與基線之間的衝擊映射,涵蓋機密性、完整性與可用性及相應環境。
3. 將PwDE分隔成不同的環境。依照可能性準則,個中環境由存取限制、使用者能力及介面限制組成的元件構成。請著意描述環境的元組件。此可從元組件基礎開始,之後再以介面與功能為基礎予以細化。對於由其負責的 RDPS,製造商可選擇願意提供何種環境來運作 RDPS。
4. 根據控制風險前後環節中給定的資產、衝擊及環境參數選擇控制措施。若 PwDE 或其部分元組件面臨風險
– PwDE 或其部分的處理方式、或以其他方式影響所列出的資產;
– PwDE 或其部分預期環境中列出的存取與通訊限制,以及使用者能力。

示例:PwDE 處理消費者市場及室內使用的通用型個人識別資料(PII)的資訊,並由製造商操作的 RDPS。而RDPS 儲存大量個人識別資料集。

環境

一個與一般消費者共用的元組件,限制室內存取並連接到遠端網路,導致(普通使用者、受到限制、聯結到外部網路)環境。
一個具備專業 IT 操作的 RDPS 元件,位於受到限制的資料中心並連接遠端網路,形成(熟練、受到限制、聯結到外部網路)環境。

衝擊分類

在(普通使用者、受到限制、聯結到外部網路)環境中放置的元組件負責處理個人識別資料(PII)。具有通用型之機密性:3、完整性:2、可獲得性:2。
RDPS 元組件在(普通使用者、受到限制、聯結到外部網路)環境中負責處理個人識別資訊(PII)。具有通用型之機密性:3、完整性:2、可獲得性:2。。由於可能影響的資料集數量甚多,會使用放大率「1」,從而獲得機密性:4、完整性:3、可獲得性:3。

控制事項的選擇

假設控制事項如下:
自動更新機制(機制);
風險情境:PwDE處理衝擊為中等或較高的資產,若產品完整性喪失,則無法受到保護。使用者只是個普通使用者,沒有定期安裝更新,導致 PwDE 容易受到外部網路攻擊。

資產:
• 機密性C(3);
• 完整性I(3);
• 可獲得性A(3);

環境:
• 存取限制:(視實際情況而定);
• 介面限制:外部網路;
• 使用者能力:普通使用者;

控制:

PwDE 的更新機制必須包含能自動檢查新更新的自動更新機制。

根據前述參數,可選擇控制點以適應不同環境:

「自動更新機制」確實適用於在沒有熟練使用者的情況下,處理衝擊至少為《3》 的外部網路資產的 PwDE。因此,此方式通常適用於典型的 PwDE,處理一般個人識別資料(PII)並使用遠端網路存取。

由於控制系統也預期一般使用者,因此僅適用於由普通使用者管理的 PwDE 元組件,而非 RDPS 元件,因為 RDPS 元組件是在專業環境中操作的。這適用於許多預設的安全控制系統。

6.2 ARC 的佐證說明

ARC是一種針對PwDE使用情境,選擇適用於網路與資訊安全的控制措施的方法。

影響資安適宜性有兩個面向:
必須保護哪些內容
這是由資產識別中識別出來的資產及其潛在衝擊所定義。在第二步所述的衝擊分類後,可以推導出保密性、完整性及可獲得性保護程度的指標。

必須防範哪些因素
這取決於威脅分析中識別出來的威脅及其發生的可能性。將資產分類為不同衝擊類型時,也會產生三種通用威脅,即失去保密性、完整性喪失及可獲得性喪失。這也包括這些威脅發生的可能性,因為其衝擊直接關聯於惡意行為者的動機及潛在能力。

如果對產品一無所知,可假設是最壞情況,即存在三種威脅,且相對可能存在潛在衝擊。通常情況並非如此,因為基於環境,PwDE已具備一定程度的保護,因此基於現有的存取限制、通訊限制或其他安全控制措施,事件發生的可能性降低。一個特殊的環境因素是使用者能力,因為高使用者能力表示環境已具備成熟的管理控制機制,並預期具備設定特定限制或其他技術/物理控制的能力。雖然不惡意,但不熟練的使用者仍需額外支援以保障 PwDE 的安全操作。

環境可用於 PwDE 元件的組合。PwDE 的某個元組件係在製造商預期會提供該等環境以整合元組件。製造商必須完整提供預期的環境,或是將此種預期環境交給供應鏈中的下一個使用者。若是如此,製造商必須協助下一位使用者達成期望的環境。此點至少包含對委外期望的透明化敘述,以及達成期望的方法,例如若預期有額外配置事項,則需提供設定介面。



圖八:環境構成示意圖

關於此技術指引的評鑑,複合特性可用於自上而下的方法,若評估者假設某項控制對 PwDE 的某一部分(例如介面、應用程式或功能)不必要甚至有害,評估者可將所使用的環境與資產具體範圍至該部分 PwDE 並重新評估控制內容。

7 網路與資訊安全控制

該指引定義了一套產品安全與漏洞處理的初步控管措施,這些措施通常用於確保PwDE的網路與資訊安全。

這些控制措施為通用型設計,適用於多種產品,因此屬於較高階設置,製造商會根據使用情境及特定 PwDE 類型進行進一步規範。

該技術指引的網路與資訊安全控制以機器可讀格式OSCAL定義,以利於
• 提供根據使用情境篩選適當控制的能力
• 簡化現有控制的再予使用及自訂控制目錄的定義
• 建立結構化格式,用於記錄與評鑑已實施控制的措施

OSCAL 控制功能可透過 Github 倉庫提供: https://github.com/tr-03183/tr-03183-1

若有申請, tr-03183@bsi.bund.de將提供有關資料庫及OSCAL使用情況的額外資訊

8 使用者文件

使用者文件對於PwDE使用者能安全地設置、維護及除役至關重要。使用者文件讓製造商能向使用者傳達對安全使用產品的期望,從而降低因使用者錯誤而產生的濫用與漏洞風險。同時也提供使用者必要資訊,以便向製造商回報漏洞與安全事件。

本節概述CRA附錄II中規定的PwDE最低程度須在使用者文件呈現事項。

8.1 UD - 使用者文件

8.1.1 UD.1.1 - 製造商識別(文件)

8.1.1.1 控制
與 PwDE 相關的使用者文件必須包含製造商的名稱、註冊品牌或註冊商標,以及郵遞地址、電子郵件或其他數位聯絡方式,以及(如有)提供聯絡製造商的網站。

8.1.2 UD.1.2 - PwDE產品識別(文件)

8.1.2.1 控制
與 PwDE 相關的使用者文件必須包含PwDE名稱、類型及任何能將之唯一識別的額外資訊。

8.1.3 UD.1.3 - 支援期間(文件)

8.1.3.1 控制

與 PwDE 相關的使用者文件必須包含製造商提供的技術安全支援類型,以及使用者可預期處理漏洞並獲得安全更新的支援期限。

8.1.4 UD.1.4 - 安全設定(文件)

8.1.4.1 控制

與 PwDE 相關的使用者文件必須包含關於 PwDE 初期調試期間及整個生命週期所需措施的詳細資訊,以確保其安全使用。

8.1.5 UD.1.5 - 修改的後果(文件)

8.1.5.1 控制

與 PwDE 相關的使用者文件必須包含詳細說明修改 PwDE 如何影響資料安全。

8.1.6 UD.1.6 - 更新安裝(文件)

8.1.6.1 控制

與 PwDE 相關的使用者文件必須包含如何安裝安全相關更新的詳細資訊。

8.1.7 UD.1.7 - 安全除役(文件)

8.1.7.1 控制

與 PwDE 相關的使用者文件必須包含關於產品安全除役的詳細資訊,並包含數位元素,包括如何安全移除使用者資料的說明。

8.1.8 UD.1.8 - 自動更新預期安裝事項(文件)

8.1.8.1 控制

與 PwDE 相關的使用者文件必須包含詳細說明如何關閉自動安裝安全更新的預置設定。

8.1.9 UD.1.9 - 安全整合(文件)

8.1.9.1 控制

與 PwDE 相關的使用者文件必須包含詳細說明 PwDE 用於整合至其他數位元件產品的位置,以及整合者符合基本要求所需的資訊。

參考文獻:參見原指引。
附錄A:參見原指引內容。
附錄B:參見原指引內容。

(全篇竟)




2026年7月14日 星期二

製造商與產品的網路韌性要求 第一部分:一般要求(六之五)

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 RH_RT.1.2.1 - 與供應商的風險分擔(活動)

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 - 與使用者(活動)的風險分擔

5.9.2.2.1 一般
透過提供足夠的設定與維護指引,也能與使用者分擔風險。此時製造商必須考量使用者的能力及其基礎設施。只有當分擔的風險符合使用者可預見的預期狀況時,才算是可以做到,因為使用者在法律或合約上都沒有義務共同分擔風險。最終消費者的常見期待是 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

資訊安全相關的功能,需根據受保護資產的機密性、完整性及可用性,確保完整性與可用性。



(未完,見次篇)