• 限制僅有經授權的可信賴使用者才能進行存取使用(Limited Access to Trusted Users Only):
• 、 醫療器材應設計具備身分驗證機制來限制裝置存取，例如用戶帳號與密碼、智慧卡(Smartcard）、生物辨識科技(Biometric Technology)。
• 、  根據使用者角色（例如照護者、系統管理員）或裝置角色實施分級授權模式

(Layered Authorization Model)。

• 、 採用適當身份驗證方式以設定不同權限。（例如透過多重驗證方法為系統管理人員、服務技術人員、維護人員等不同人員設置裝置存取權限）。
• 、 醫療器材應具備防範未經授權使用之相關功能特性，例如使用自動計時方式終止系統使用（視適用情況實施）、強化密碼保護機制並定期更新、採用裝置與通訊埠的實體鎖以降低密碼竄改機會、在同意軟體或韌體更新以前（包括作業系統、應用程式、防惡意軟體的更新），要求身分驗證或其他適當控制程序等。
• 確保可信賴的內容(Ensure Trusted Content):
• 、 醫療器材執行軟體或韌體更新時，應確保為經驗證之程式碼，製造廠應考慮軟體或韌體更新須採用適當的認證機制，例如驗證碼(Authenticated Code)、代碼簽名認證（Code Signature Verification）等方式，並應採用系統化程序，供授權用戶於廠商端下載可識別版本之軟體與韌體。
• 、  針對敏感性資料的儲存及傳輸於可行時進行加密保護機制。

(二)、 偵測、應變、回復(Detect, Respond, Recover)

• 醫療器材應具備相關功能特性，使產品在正常使用下能夠偵測(Detected)、辨識 (Recognized)、記錄(Logged)、時間控制(Timed)、處理(Acted)網路安全功能減損之情形。
• 針對醫療器材之關鍵功能，則應設計實施相關保護措施，即便產品的網路安全已受減損，仍可保護產品不影響其關鍵功能。
• 醫療器材亦應具備系統保存(Retention)及回復(Recovery)功能，可以提供通過驗證之特定授權人員，維持與復原產品組態的方法。
• 應針對最終使用者提供當偵測到資訊安全事件時應採取的適當措施相關資訊。

(三)、 製造廠思考如何完備醫療器材產品網路安全特性時，可參考國際相關評估指標，例如IEC 80001-2-2:2012 標準及HIMSS/NEMA Standard HN 1-2013《醫療器材網路安全特性製造廠聲明表格》 (Manufacturer Disclosure Statement for Medical Device Security form, MDS2 form)，針對自動登出、稽核控管、授權機制、安全特徵組態、網路安全更新、健康資料去識別化、數據備援、緊急使用、醫療數據的完整性與正確性、惡意軟體偵測與防護、網路節點識別、使用者識別、器材硬體鎖、第三方軟體控管、系統與應用程式韌性、安全性指引、資料儲存機密性、資料傳輸機密性、資料傳輸完整性等網路安全防護面向，依產品特性與預期用途進行自我評估，製造廠選擇產品適用之安全防護措施時，應有相關之文件紀錄以說明其合理性。
(四)、 製造廠應針對醫療器材網路安全機制進行適當的確效測試，例如對程式碼進行惡意軟體測試(Malware Testing) 以確保軟體不會潛藏已知的危害風險；透過外部界面輸入資料進行異常輸入測試(Malformed Input Testing)，驗證產品在隨意或意外輸入的情況下，能維持其正確運作；亦可考慮實施結構性滲透測試(Structured Penetration Testing)，嘗試規避風險管控措施和安全維護組態，入侵服務系統、設備等產品相關軟硬體，找出各種潛在的脆弱性，藉以驗證產品的資料與功能是否可被竊取或破壞，評估軟體系統與硬體安全性是否有待加強。
(五)、   醫療器材產品申請上市時，製造廠應提供下列醫療器材網路安全相關資料：

• 產品敘述與說明資料，應包含以下內容:
• 產品所有設計功能、安全維護功能及管理功能的描述；
• 所有外部界面或實體輸入/輸出界面清單，包括遠端界面、本機界面、無線傳輸界面、外部檔案輸入，以及所有支援這些界面的通訊協定；
• 所有可執行程式及函式庫清單、相關軟體建置和安裝整合程序之說明；
• 產品生命週期內如何維持其網路安全的方法，以及如何提供經確效之軟體更新與修補程式之計畫；
• 產品使用說明與產品規格等，包含預期使用環境下建議採用之網路

安全控制方式:如網路安全組態和使用環境需求、能夠確保安全功能

有效性的操作說明、身份識別和授權的方法、防毒軟體及防火牆的使用等。

• 產品設計與驗證資料，應包含因應意圖(Intentional)或非意圖(Unintentional)的網路安全風險之風險分析、風險管控措施、設計考量，以及說明每個風險管控措施如何實施，其中應包括；
• 產品設計過程中考量之網路安全風險清單；
• 產品建立之網路安全風險管控措施清單與理由說明；
• 連結網路安全風險分析及風險管控措施的可追溯矩陣圖；
• 簡要敘述用於確保醫療器材軟體之完整性(如防範惡意軟體)的控制措施；
• 各風險管控措施之確效資料

八、上市後網路安全監管

(一)、 製造廠應制定完善的上市後網路安全風險管理計畫與文件紀錄，包含但不限於申訴處理、品質稽核、矯正與預防措施、軟體確效與風險分析、售後服務等。
(二)、 網路安全管理計畫應包括網路安全資訊來源及第三方軟體元件的監控，以便於器材的總產品生命週期中找出新的脆弱性；針對修正脆弱性的軟體更新與修補制訂相關驗證與確效程序，包括與市售軟體相關的更新與修補；持續了解、評估、偵測網路脆弱性的存在與影響之程序；建立與使用者的溝通管道以收集網路危害訊息；採用風險分析模式，例如威脅模型等，以評估分析如何發展網路安全風險減輕管制措施來維持產品的安全性與效能； 採用共通性的網路安全危害訊息揭露政策與規範；儘早實施可於脆弱性遭利用前改善網路安全風險的危害減輕措施。

九、危害處置與通報原則

(一)、 針對可能導致病患遭受傷害的殘餘風險低至可被接受之可控風險，製造廠即便在殘餘風險為可接受程度時，仍應積極維護及增進安全的網路環境，盡力降低網路安全風險。即便安全風險已受控制，亦鼓勵製造廠可部署其他控制程序，做為「深度防禦(Defense-in-depth)」策略的一環。
(二)、  關於處理與可控風險相關的安全脆弱性事項之例行性網路安全更新與修補，這類變

動被視為一種加強醫療器材安全的措施，不需提出申請，但應將網路安全脆弱性資訊與例行性網路安全更新與修補之詳細資訊，主管機關於必要時將視情況要求製造廠提供相關資料。
(三)、 當風險降低與補償性控制措施不足，可能產生病患遭受傷害的殘餘風險不可被接受之未受控風險。製造廠應盡速處理未受控風險。
由於脆弱性修補方案未必可立即取得或實行，製造廠於發現安全脆弱性之最短時間內(不超過 15 天)應通知給客戶及使用者，告知安全脆弱性、識別並提供臨時的風險補償性控制措施，並制定計畫將殘餘風險降至可接受程度。風險控制措施必須確保不會對器材之安全及有效性造成更大的風險。醫療器材製造廠應將相關資訊文件化並保存，包含矯正計畫的處理時間點及理論依據。製造廠對於顧客及使用者的通知應至少包含下列內容:

• 敘明安全脆弱性相關資訊，包含製造廠依據現有資訊推估可能對使用者造成的影響。
• 說明製造廠為儘速降低病患傷害而進行中的措施。
• 若有，說明補償性控制措施。
• 說明製造廠正致力於修補安全脆弱性或提供深度防禦策略，以降低發生傷害的機率與嚴重性，並且將於未來修補程式可使用時與顧客及使用者聯繫。

製造廠於得知脆弱性後，應盡快修補安全脆弱性，驗證修正處，並將修補程式提供給客戶及使用者，以便將殘餘風險降至可接受程度。在某些情況下，補償性控制措施可以做為一個降低殘餘風險至可接受程度的長期解決方案。補償性控制措施必須確保不會對器材之安全及有效性造成更大的風險。此外，製造廠於必要時應針對最終使用者進行追蹤。
(四)、若未受控風險於國內導致嚴重不良反應，應於得知此類反應情形後，依「嚴重藥物不良反應通報辦法」，於規定之時限內向中央衛生主管機關或其委託機構通報。若製造廠評估未受控風險可能導致嚴重不良反應，則於得知此類風險存在情形後，不論是否已發生嚴重不良反應，參酌前開規定，向中央衛生主管機關或其委託機構通報未受控風險資訊及可能導致的嚴重不良反應。

(五)、 如發生適用個人資料保護法或其他法規規範之安全危害事件，製造廠除應遵循本指引前述醫療器材網路安全危害事件之處置及通報要求，亦應依相關法規規定事項辦理通報及其他必要處置。
(六)、不論例行性/非例行性更新，若涉及規格或效能變更，應依「藥事法」及「醫療器材查驗登記審查準則」相關規定辦理變更登記。

十、參考資料

• US FDA: Guidance for Industry: Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software, 2005.
• US FDA: Guidance for Industry and FDA Staff: Content of Premarket submissions for Management of Cybersecurity in Medical Devices, 2014.
• US FDA: Guidance for Industry and FDA Staff: Postmarket Management of Cybersecurity in Medical Device, 2016.
• US FDA: Guidance for Industry and FDA Staff: Design Considerations and Premarket Submission Recommendations for Interoperable Medical Device, 2017.
• US FDA: Guidance for Industry and FDA Staff: Deciding When to Submit a 510(k) for a Software Change to an Existing Device, 2017.
• US FDA: Guidance for Industry and FDA Staff: Guidance for the Content of Premarket Submission for Software Contained in Medical Devices, 2005.
• ISO 14971:2007, Medical devices - Application of risk management to medical devices
• IEC/TR 80001-2-2:2012, Application of risk management for IT-networks incorporating medical devices -- Part 2-2: Guidance for the communication of medical device security needs, risks and controls.
• ANSI/AAMI TIR57:2016, Principles for medical device security-Risk management
• UL 2900-1:2017, Standard for Software Cybersecurity for Network-Connectable Products, Part 1: General Requirements
• UL 2900-2-1:2017, Software Cybersecurity for Network-Connectable Products, Part