（見前篇）
參見標準：ANSI/AAMI SW 96:2023器材製造商的資安風險管理
© All Rights reserved。 版權聲明。CC BY-SA 4。0。
（內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。）
C.4 選擇性的報告章節
此外，若需要時，可選擇性補充到報告內容的以下章節為宜：
l 採用案例：
n 須視專案及資安風險報告的預期用途，而在報告中陳述與資安風險相關的採用案例。具體言之，採用此等案例，係提供威脅建模的細節與生態系統範圍，供評估所需的資安風險，可看做是重要事項。最重要者，採用此等案例須促使理解專案內部潛在的資安風險來源。在識別資安風險嚴重性與衝擊的量化效應時，所採用的案例也很有幫助。
核准矩陣
l 係按照風險增大程度、所需涉及之管理階層、及主題專業知識等，因風險接受程度不同而促成簽署的要求階層。
參考的設計、策略、指導及標準等
l 作為基本參考文件，在風險摘要文件中，列出各種內部及外部文件，供做基礎資安應用。
私密性風險
l 隱私合規雖然是極為重要的議題與風險，但通常不在本附錄的範圍內；然而，資料保護、資料完整性及其他相關安全風險仍應被視為安全風險，且在適當範圍內。根據前述章節中對安全風險的評估及本報告的預期用途，明確將相關安全風險與隱私風險連結的章節，可能必要或不必要。
安全性風險
l 本節將討論被識別出可能對安全造成影響的安全風險，並被轉交至安全風險管理流程進行分流與回應。雖然底層安全漏洞仍保留於此安全風險文件中，但安全風險評估結果則保留在安全風險評估文件中（例如失效模式與影響分析—— FMEA、危害分析等）。
l 相對地，也必須確保可能存在安全風險的安全風險被適當識別並評估其安全風險。任何此類風險都應在本節中記錄並討論。
定義
或許可以新增一個章節，列出報告內容相關的獨特定義及定義的參考來源。
C.5資安漏洞與資安風險管制的屬性
與風險管理報告類似，建議以支持解決方案在整個生命周期中使用與維護的方式，捕捉資安漏洞及資安風險控制/緩解措施。雖然威脅也是資安風險架構中須考慮的重要面向，但假設此等項目會被保存在獨立的威脅建模地點中。為了讓各種漏洞都能全面地檢視與分析，本節將針對每個漏洞列出威脅情境，但威脅模型須為主要的真實來源。為達成此項工作，任何尚未被納入原始威脅建模活動的新識別出來的威脅，須加入威脅模型產物中，以供檢視及分析。從該威脅模型來源，個別威脅會連結到本節中的漏洞與控制措施。
針對每個已識別的漏洞，建議採用以下各項屬性：
漏洞識別號碼：
l 唯一識別碼以引述漏洞。若適當時，可能會使用共通漏洞與曝露（CVE，Common Vulnerability Exposure 係一種公開已知弱點的編號與資料庫）。
註：CVE 是什麼?
l CVE 是一個由 MITRE 管理、各國單位共同維護的公開清單，每一則弱點都有唯一的 CVE-ID（例如 CVE-2024-12345）。
l 它只提供「標準化的弱點描述與基本資訊」，而不直接給你完整技術細節與 exploit code，那些通常在 NVD 或廠商公告裡補充。
l CVE是一個「公開已知弱點的編號與資料庫」，用來標示並追蹤軟體與硬體的已知資安弱點。
在醫療器材網路安全情境下，CVE 是把「技術弱點」轉成「可評估、可溝通的風險項目」的標準語言，便於業者將之納入
EN ISO 14971 / MDCG 2019-16 的風險管理流程裡，採取對應措施以降低或排除風險或潛在威脅。
漏洞描述：
l 提供具體的特定漏洞或情境描述（若出現事件序列）。
漏洞最初出現的日期或版本識別編碼；
l 提供該漏洞首次被發現的日期或版本。
根漏洞或相關共通弱點列舉（CWE Common Weakness Enumeration，係一種編碼方式）：
l 如果可能，請提供 CWE 識別碼，或描述該漏洞的「根漏洞」。例如，「弱式授權碼」可能是一個潛在的根漏洞，係指因為密碼太短造成的漏洞。
註：CWE是什麼?
l CWE 是由 MITRE 維護的分類表，列出數百種常見軟體／硬體漏洞類型，例如硬編碼密碼（CWE-798）、缺少授權檢查、緩衝區溢位等。
l 一個實際的漏洞（CVE）通常可以追溯到一個或多個 CWE 類別，也就是「這個漏洞是因為哪一種設計／實作錯誤造成的」。
l CWE可以理解為「導致資安漏洞的通用設計／實作缺陷清單」，是把「程式或設計錯誤」系統化分類的國際共通語言，業者採用之後可以幫助在設計階段就把未來可能變成 CVE 的漏洞盡量消滅掉。
由漏洞所引發的威脅情境
l 描述一個或多個可能利用該漏洞的威脅情境，或在適當情況下參考已記錄的威脅模型中的威脅。若使用識別號碼以區分不同威脅，宜於使用此等識別碼。
與漏洞相關的系統元件、子系統或資產：
l 表示系統中因為該漏洞而受衝擊的任何資源或資源群組。
l 須識別每個資源或資源集合的版本，以便在漏洞已被解決的版本中提供可追溯性。
既有的安全風險控管/緩解/補償控制：
l 指出既有的安全風險控制或緩解措施，以消除、控制或緩解已識別出來的漏洞。
緩解前的風險量化價值：
l 透過可重現的流程量化漏洞的風險。例如，將
CVSS 與 MITRE 的醫療器材 CVSS 評分準則結合使用，或是開放網路應用安全計畫（OWASP）或國際藥品與醫療器材隱私聯盟的風險評分準則。
新的安全風險控管/緩解/補償控制：
l 為消除、控制或減輕已識別的漏洞而新增的控制措施或緩解措施。若本節之控制/緩解措施以識別號碼標出，則宜使用該識別號碼。在此宜使用標準化的資安風險控制識別碼，如 NIST 800-53 中所記載的識別碼。
l 記錄任何已知的資安風險控制/緩解限制。
l 提供可追溯至任何現有設計輸入需求、及查證與確證輸出的可追溯性。後生產階段時，可能會增加參考緩解或矯正措施計畫，或補充參考。
l 提供文件名稱與版本，以及該控制對應於相關資安標準或架構中的具體事項。參考文件可能包括但不限於FDA網路資安上市前指引、NIST網路資安架構、NIST SP 800-53等。
l 提供資安風險控制的品質型強度，詳見
NIST SP 800-53（修訂版 1，表 D-3）。選項有：非常低、低、中等、高和非常高。
本欄位是對控制事項的註釋，而非受限之控制範圍所引起的任何弱點。
l 請合理化上述事項關於預估攻擊者能力足以繞過資安風險控制的佐證說明。
l 若控制需要後生產階段的監督才能有效果，請提供建置此等監督的相關流程。
l 請提供相關控制措施或緩解措施用於解決此漏洞的日期或版本，或各個版本的對應日期。
新控制措施/緩解措施/補償控制措施後的風險量化值更新：
透過可重現的流程，量化在施加額外控制或緩解措施後，漏洞所帶來的資安風險。可能的做法包括將CVSS與MITRE的醫療器材CVSS評分標準及環境評分（如適用）結合使用，或採用開放網路應用安全計畫（OWASP）或國際藥品與醫療器材隱私聯盟的風險評分準則。若無法進行額外的緩解與控制，須視之為前期的緩解值。
C.6 可選擇採用的安全漏洞屬性
此外，下列屬性也可能對識別出的漏洞有所幫助：
漏洞利用程式碼成熟度；
族群效應；
l 若此漏洞被利用，應識別潛在的病患族群衝擊為單一病患或多病患。
其他可能正面或負面衝擊資安的誘發條件；
l 記錄任何衝擊潛在利用可能性或脆弱性衝擊的相關條件，只要是本節其他段落未充分記錄；
若被利用，衝擊類別；
l 可能的例子包括：治療提供過程的安全相關事項、隱私、營運；
若治療提供受到衝擊，則適用的安全危害亦將會受到的衝擊；
l 列出與該漏洞相關的任何安全相關危害的潛在效應。
附錄D：威脅建模化
D.1 威脅模型為何重要?
威脅建模化有助於判斷系統內需要保護的部分，以及系統中設計的控制措施以實施該等保護。威脅模型之所以重要的原因，是設計控制措施以保護系統免受攻擊。
D.2 何為威脅模型化?
威脅模型詳細描述影響裝置或生態系統的關鍵威脅。威脅包括哪種系統類型的自然風險、相關威脅，以及需要採取的對策類型。基本上，威脅模型會建立特定的威脅情境剖繪，進而引導更明智的設計決策，以及在漏洞評鑑（Vulnerability Assessment）時使用較為相關聯的攻擊策略。
威脅模型也為防禦者提供系統性分析，分析潛在攻擊者的動機與特徵。 這種系統性分析提供了辨識可能攻擊途徑的方法。了解這些攻擊途徑將以最有效的方式強化組織的防禦策略與系統安全風險控管。
系統設計定義了系統結構，包含交換資料的元件、元件間的資料流，以及安全邊界。該模型是系統行為的一種視角，用以識別資料在安全邊界的流動、資料所有權及元件的容納範圍。
威脅模型利用設計的抽象，來引發問題：問題可能發生在哪裡。
D.3 必要時的輸入事項，即：器材生命周期的哪一個階段須開始導入?
在建模威脅情境時，主要有三種情境需要考慮：供應鏈、設計與後生產階段。威脅建模應該貫穿整個生命周期。然而，不同方法學與模型在產品生命周期的特定階段可能提供不同層次的細節。更多資訊請參見D.7作為範例。
D.3.1 供應鏈
在選擇與包含元件（硬體、軟體與服務）時，可以從索取詳細組成分析開始，這樣在開始昂貴的內部設計流程前，就能評估其威脅，並建立其資安特性，並在後續漏洞揭露時提供。
D.3.2 設計
威脅建模愈早在設計生命周期中進行，就越愈早開始影響設計決策。然而，若過早進行，系統相關資訊不足，無法建立穩健的威脅模型。衍生型設計可能涵蓋從其生命周期中累積的大量威脅經驗。
當威脅建模在需求階段進行時，系統的主要使用方式與功能集已獲得充分了解，該等資料提供建立高階威脅模型所需的資料。此階段所建立的威脅模型有助於深刻影響系統設計。此階段可能帶來最大效益的威脅模型是以威脅行為者為導向（Threat Actor Oriented）的視角，因為從威脅行為者的視角評鑑系統是否有有價值的目標（詳見方法學章節）。其他方法如資產導向，在此階段價值有限，因為對系統設計的了解尚不充分。
當威脅建模在早期設計階段進行時，系統知識已成熟，能建立詳細的威脅模型。由於設計已經開始，威脅建模可能導致修正現有設計決策，且對未來的設計決策與實作仍有重大影響。此時可納入供應鏈風險建模，若設計流程允許，設計與採購之間的權衡可在此時開始評估。
在設計後期完成的威脅模型可能導致意想不到的需求更新與設計變更，因為先前未被考慮的威脅會在查證與確證階段彰顯出來（參考 JSP 生命周期概念於啟動階段）。然而，要認識到資安能力所需的設計變更發起若受到耽擱，可能會大幅衝擊工時與成本。
D.3.3 後生產階段
後生產階段是考慮新增功能是否需要增加的階段。若新增重要功能，現有威脅模型可能需要更新，或建立新的威脅模型以涵蓋新功能。
對於尚未被威脅建模的舊系統，設計成熟，供應鏈特性良好，製造商可隨時開始威脅建模。舊有系統通常
可供資安研究社群使用，因此外部研究者的漏洞揭露可能會讓製造商措手不及。製造商須考慮對舊有系統進行威脅建模，以防止意外發生，並提供詳細資料，以可能為基於誤解的漏洞揭露辯護。
當產品有新漏洞被通報，且現有控制措施無法充分保護產品免受該漏洞時，產品威脅模型可能需要更新。這可能需要對產品提出新的要求與控制。新的漏洞可能來自第三方組件。為了判斷該漏洞是否相關或評估現有緩解措施的有效性，威脅模型會描述對資料流的影響。根據威脅模型輸出，可以評估第三方的漏洞及其衝擊。
（未完，見續篇）
