The National Medical Products Administration (NMPA) Medical Device Technical Review Center issued the 'Guiding Principles for the Registration and Review of Medical Device Network Security (2022 Revised Edition)' in March 2022. The U.S. Food and Drug Administration (FDA) published the draft 'Guidance for Industry: Quality System Considerations and Premarket Notification for Medical Device Networks' in April 2022. The global attention to the network security of medical devices is increasing, involving more and more medical device products related to network security, and the regulations are becoming more and more perfect. This article interprets the requirements of the 'Guiding Principles for the Registration and Review of Medical Device Network Security (2022 Revised Edition)' (hereinafter referred to as the 'Guiding Principles').
I. General Requirements
1. Scope of Application:
Including the second and third category independent software with one or more of the following functions: electronic data interchange, remote access and control, and user access, as well as medical devices containing software components (including in vitro diagnostic medical devices); applicable to self-developed software and ready-made software.
Interpretation: Some partners may ask if one of the three conditions is met, it is within the scope of application. Does that mean that many simple devices also need to consider network security? The answer is yes, but for medical devices with higher risk levels, the申报 materials need to be more comprehensive and detailed, while for places that are not applicable, a description is sufficient.
2. Main Concepts
Cybersecurity for medical devices:
It refers to the state of protecting the medical device product and related data from unauthorized activities, with the related risks of characteristics such as confidentiality (Confidentiality), integrity (Integrity), availability (Availability), authenticity (Authenticity), non-repudiation (Non-Repudiation), accountability (Accountability), and reliability (Reliability) at an acceptable level throughout the product lifecycle.
Cybersecurity capabilities for medical devices:
Considering the limitations of intended use and usage scenarios, medical devices should have the necessary identification, protection capabilities, and appropriate detection, response, and recovery capabilities for cybersecurity threats.
The guiding principles provide 22 cybersecurity capabilities for medical devices:
Automatic de-registration, review, authorization, node identification, personnel identification, connectivity, physical protection, system strengthening, data de-identification and anonymization, data integrity and authenticity, data backup and disaster recovery, data storage confidentiality and integrity, data transmission confidentiality, data transmission integrity, cybersecurity patch upgrade, ready-made software list, ready-made software maintenance, cybersecurity usage guidelines, cybersecurity feature configuration, emergency access, remote access and control, malicious software detection and protection.
The registrant should analyze the applicability of the above cybersecurity capabilities based on the product characteristics of the medical device.
Cybersecurity verification and validation:
Quality control work should be conducted under the framework of software verification and validation, combining product cybersecurity characteristics, such as source code security audit, threat modeling, vulnerability scanning, penetration testing, and fuzz testing, etc.
Cybersecurity traceability analysis:
Track the relationships between cybersecurity needs, cybersecurity design, source code, cybersecurity testing, and cybersecurity risk management, and analyze the correctness, consistency, integrity, and accuracy of the identified relationships.
Cybersecurity incident emergency response:
A cybersecurity incident emergency response mechanism should be established based on relevant standards and technical reports to ensure the safety and effectiveness of medical devices and protect patient privacy.
Cybersecurity updates for medical devices:
（1）Major cybersecurity updates: Cybersecurity updates that affect the safety or effectiveness of medical devices, i.e., major cybersecurity feature updates, should apply for a change in registration. （2）Minor cybersecurity updates: Cybersecurity updates that do not affect the safety and effectiveness of medical devices do not require an application for a change in registration, and the corresponding registration application materials should be submitted during the next change in registration.
3. Basic Principles
Cybersecurity positioning:
Cybersecurity for medical devices is an important part of the safety and effectiveness of medical devices. It is also an important part of the national cyber strategy.
Risk-oriented:
Cybersecurity risks are an important part of software risks. The cybersecurity risks of medical devices are also comprehensively evaluated in combination with the intended use, usage scenarios, and core functions of medical devices.
Network security risk management:
Identify assets, threats, and vulnerabilities; assess the impact of threats and vulnerabilities on medical devices and patients as well as the possibility of exploitation, determine the risk level, and take sufficient, effective, and appropriate risk control measures.
Lifecycle quality control:
To do a good job of quality control at all stages before and after listing, carry out network security quality control work in combination with the requirements of the quality management system and the characteristics of medical device products before listing, and carry out update request assessment, verification and confirmation, risk management, user notification, and other activities after listing according to the update of network security, regularly carry out risk assessment of medical device network security vulnerabilities, and inform users of necessary network security related information and countermeasures.
The IEC 27000 series standards can be used to规范 information security management system (ISMS) certification requirements to improve the quality control of medical device network security to ensure the safety and effectiveness of medical devices.
4. Technical considerations
Ready-made software: Establish a network security update process for ready-made software according to the requirements of the quality management system, and carry out corresponding network security quality control work according to the relationship type between ready-made software and medical device software.
Outbound medical data: Important data, personal information, and human genetic resource information collected and generated within China should be stored within China in principle, and the transfer to overseas needs to go through the safety evaluation of relevant national departments.
Remote maintenance and upgrade: The registrant needs to clearly specify the implementation methods of remote maintenance and upgrade, the electronic interfaces used, the content of the device data, the isolation methods of device data and medical data, and the technical characteristics of cybersecurity guarantee measures, and provide corresponding research materials and risk management materials.
Legacy equipment: Network security quality control work should be carried out according to the 'Guiding Principles for Quality Management System of Independent Software Production and On-site Inspection'.
Part Two: Verification and Confirmation
Guiding principles require:
As an important part of software verification and confirmation, network security verification and confirmation need to carry out relevant quality control work under the framework of software verification and confirmation, combining product network security characteristics.
It can be seen that the verification and confirmation of network security are not independently existing, but are an extension of software verification and confirmation. Similarly, in the description of Cybersecurity Testing (network security testing) in FDA: Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions: Just like other fields in product development, testing is used to demonstrate the effectiveness of design controls. Although software development and cybersecurity are closely related disciplines, cybersecurity controls require tests beyond standard software verification and confirmation activities to prove the effectiveness of controls in an appropriate security environment, thereby proving that the device has reasonable security and effectiveness guarantees.
Interpretation: After reviewing documents such as UL 2900 and FDA on medical device network security, we divide network security verification and confirmation into software verification and confirmation (specifically referring to the verification of network security capabilities at the software level in this article) and network security testing.
Threat modeling is an important part of risk management and is recommended to be carried out in advance, during the software development process, and the threat modeling phase can refer to Microsoft's Security Development Lifecycle (SDL).
1. Software verification and confirmation
Execution standards:
Throughout the entire lifecycle of software design and development, we need to implement according to the standard of 'YY/T 0664 Medical Device Software Software Verification and Confirmation Process'. Throughout the entire lifecycle, software risk management is required, and the risk management of medical device software can refer to 'YY/T 0316 Application of Medical Device Risk Management to Medical Devices'.
Software development process:
It includes activities such as software development planning, software requirement analysis, software design, software coding, software verification, software confirmation, and software release.
Software development planning needs to clarify how to manage risks during the software development process, and a risk management plan needs to be formulated to evaluate risk severity and the probability of risk occurrence.
Software requirement analysis includes functional and performance requirements, various requirements such as software system inputs and outputs, and information security requirements. For example, to ensure the security and integrity of patients' health data during transmission, it is necessary to design functions such as data anonymization and transmission encryption. According to the guidelines, medical devices should have necessary identification, protection capabilities, and appropriate detection, response, and recovery capabilities against network security threats, and lists 22 specific network security capabilities. The registrant shall analyze the applicability of the above 22 network security capabilities based on the product characteristics of the medical device. If applicable, these capability requirements should be written into the requirements, specifying the implementation methods. If not applicable, the reasons should be elaborated and documented.
Software testing, software verification, and software confirmation: Provide objective evidence to determine that the software meets user requirements and intended use. Validate and confirm the requirements and capabilities related to network security.
Example 1: After requirement analysis, it was confirmed that the network security capability of data transmission confidentiality (TXCF) and the product's ability to ensure data transmission confidentiality are required.
Verification method: Capture packets during data transmission, detect whether sensitive data is encrypted, and identify it in an encrypted manner.
Example 2: After requirement analysis, it was confirmed that the network security capability of malicious software detection and protection (MLDP) and the product's ability to ensure data transmission confidentiality are required.
Verification methods: send malicious code, conduct DDoS, deception attacks, etc., to detect whether the product has the ability to identify and block.
2. Network security testing
According to the guidelines and FAD, UL 2900 and other medical device network security standards, network security testing is summarized as source code security audit, vulnerability scanning, penetration testing, and fuzz testing.
Source code security audit:
Requirements of the U.S. FDA: software composition analysis of binary executable files, static and dynamic code analysis; Requirements of UL 2900: software weakness analysis, static source code analysis, static binary and bytecode analysis
Software security is the basic defense line of network security, and the underlying software is composed of a large number of codes. A significant reason for the occurrence of vulnerabilities is problems in code writing, so it is necessary to conduct source code security auditing. Through testing, it can better discover problems in the code, and the vulnerabilities in the code itself can also be effectively controlled.
Testing methods:Source code auditing. Source code auditing is a comprehensive security check of the security and reliability of the system's source code and software architecture by security service personnel with rich coding experience and a deep understanding of security coding principles and application security. It can also be assisted by code auditing tools in conjunction with testing.
Vulnerabilities found in source code review
Vulnerability scanning:
Requirements of the U.S. FDA: vulnerability chain, closed-box testing of known vulnerability scanning; Requirements of UL 2900: known vulnerability testing, malicious software testing
A vulnerability refers to weaknesses or defects in the hardware, software (including firmware), and protocols on the system, which exist in the security policy. These defects, errors, or unreasonable aspects may be exploited intentionally or unintentionally, affecting the confidentiality, integrity, and availability of system and asset properties, causing leakage, destruction, tampering, and control, etc.
The causes of vulnerabilities are very extensive, and there is no absolutely secure system or software. Vulnerabilities are constantly being discovered, exploited, disclosed, and repaired, forming a cycle. According to the development level of information security, the current stage is to first detect whether there are publicly disclosed vulnerabilities.
Vulnerability classification:
By application scope: operating systems, applications, WEB applications, databases, network devices, intelligent devices (IoT terminal devices), blockchain-related vulnerabilities, Internet of Vehicles, industrial control systems, etc.
By vulnerability principle: buffer overflow, DOS attack, injection, file inclusion, file reading, file upload, file download, directory traversal, sensitive information leakage, weak password, command execution, brute force, unauthorized access, logical vulnerability, misconfiguration, phishing, privilege escalation, network deception, browser hijacking, XSS, CSRF, SSRF, insecure deserialization, etc.
Testing methods:Using vulnerability scanning devices or tools, discover, identify, and evaluate known vulnerabilities. Mainly for evaluating known vulnerabilities in CVE, CNVD, CNNVD vulnerability databases and issuing vulnerability assessment reports.
1. Networked devices, using a device with Linux system
Illustration of vulnerability scanning 1
2. Non-networked embedded devices (including software components or firmware)
Security assessment of vulnerability scanning for software and firmware
Component vulnerabilities found in the security assessment of software binary files
Penetration testing:
Requirements in the US FDA: Penetration testing
Requirements in UL 2900: Structured penetration testing
Penetration testing simulates the methods and techniques of hacker attacks to launch attacks on the target, obtain information and permissions, etc. Through the penetration testing report, it can be more intuitively reflected that the system is facing risks, and it can be clearly seen how information is leaked, how vulnerabilities are exploited, and how the system is controlled, etc.
General process of penetration testing:
Example of penetration testing:
Test engineers crack account passwords
Crack passwords and system administrator privileges
Fuzz testing:
Requirements in the US FDA: Robustness testing, fuzz testing
Requirements in UL 2900: Malformed input testing
Fuzz testing is an automated software testing technology, usually used to identify potential vulnerabilities in programs. Fuzz testing is a method of providing random inputs to the program and recording the test methods that cause the program to crash or fail abnormally. Random inputs are much more extensive than the coverage range of human thinking logic.
Chapter 3: Declaration document for network security registration
The declaration document for network security registration is specifically described in Chapter 6 of the guidance principles on medical device network security research materials, divided into self-developed software and ready-made software, referring to the figure in the guidance principles:
The self-developed software network security research report is a basic report of the above reports, and the other reports can be adjusted accordingly based on this report. Below, we will explain with the self-developed software network security research report.
1. Basic information
(1) Software information
Clearly define the name, model and specifications, release version, and software security level of the declared medical device software.
Software name:
Model and specifications:
Release version:
Software security level: Clearly define the software security level (Level A, B, C), and elaborate on the reasons for determination.
(2) Data architecture
Provide the network environment and data flow diagram for each usage scenario (including remote maintenance and upgrade, etc.) of the declared medical device, and describe the basic situation of the related data and electronic interfaces of the medical device according to the diagram.
Example: Network environment and data flow diagram, some descriptions are omitted, detailed requirements are in the guidance principles.
Data: Wearable devices collect health data, send it to the mobile device management APP via Bluetooth, and then the data is transmitted to the cloud database of the equipment manufacturer. Doctors can view health data by connecting to the cloud server of the equipment through their accounts on computers.
Electronic interface: Bluetooth (Bluetooth)
(3) Network security capability
Analyze item by item the applicability of declared medical device to 22 network security capabilities, elaborate on the implementation methods of applicable network security capabilities and the reasons for inapplicability. If applicable, provide explanations of the applicability of other network security capabilities.
Example 1: Personnel Authentication (PAUT), adopts username and password verification method, the password strength for administrators requires a combination of numbers, uppercase and lowercase letters, and special characters, not less than 8 digits, and locks for 24 hours after 3 consecutive failures. The password strength for ordinary users requires a combination of numbers and letters, not less than 6 digits, and locks for 0.5 hours after 5 consecutive failures.
Example 2: Data Transmission Confidentiality (TXCF), adopts RSA asymmetric encryption algorithm, encrypting the transmitted sensitive medical information. RSA encryption is powerful and reliable, and requires a large amount of time and effort to crack.
(4) Cybersecurity Patches
Provide a list of cybersecurity patches for申报medical devices (including necessary software, external software environment), clearly indicating the name, complete version, and release date of cybersecurity patches. It is also possible to attach files.
Example
Patch Name: PTR 9.1.5 Complete Version: XX2020-R2-Stable Release Date: 2022-05-25 Description: This patch adds new support for administrator account verification method XXXX.
(5) Security Software
Describe the name, model and specification, complete version, supplier, operating environment, and protection rule configuration requirements of the security software (such as antivirus software, firewall, etc.) used or compatible with申报medical devices.
Example
Antivirus Software: Huorong Security Software Model and Specification: Windows-Personal Edition 5.0 Complete Version: 5.0.68.2 Supplier: Beijing Huorong Network Technology Co., Ltd. Operating Environment: Windows 11, Windows 10, Windows 8, Windows 7, Windows XP, and other operating systems Protection Rule Configuration Requirements: Default installation, upgrade and update virus library irregularly.
2. Implementation Process
(1) Risk Management: Provide a risk analysis report and risk management report for the cybersecurity of申报medical devices, and attach the original files formed during cybersecurity development. It is also possible to provide risk management documents for medical device software, but it must indicate the cybersecurity status.
(2) Verification and Confirmation: Provide a cybersecurity test plan and report for申报medical devices, and attach the original files formed during cybersecurity development. It is also possible to provide a system test plan and report for medical device software, but it must indicate the cybersecurity status.
Interpretation: The submitted content includes the original files of the verification and testing carried out in Chapter 2 of this article.
(3) Traceability Analysis:
Provide a cybersecurity traceability analysis report for申报medical devices, summarizing and listing the correspondence between cybersecurity requirement specifications, cybersecurity design specifications, source code (clearly indicating the name of the software unit), cybersecurity test reports, and cybersecurity risk analysis reports. It is also possible to provide a traceability report for medical device software, but it must indicate the cybersecurity status.
(4) Maintenance Plan: Provide flowcharts and other documentation to explain the level of cybersecurity updates for medical device network.
3. Vulnerability Assessment
Assess the discovered vulnerabilities based on the results of the cybersecurity testing. Use the vulnerability level defined by the Common Vulnerability Scoring System (CVSS). Different requirements are used for minor level, medium level, and severe level, with the goal of ensuring that the comprehensive remaining risk of the product is acceptable. See the guidance principles for details.
Example: The vulnerability shown in the figure below was found in the vulnerability scanning process.
The CVSS score of the vulnerability in the figure is 9.8 points, which is a critical vulnerability, and it can be repaired by upgrading. A cybersecurity vulnerability assessment report issued by a cybersecurity assessment organization is required, clearly defining the maintenance plan for the known remaining vulnerabilities.
4. Conclusion
Overview of the standardization of the cybersecurity implementation process of the declared medical device and the results of cybersecurity vulnerability assessment, determine whether the cybersecurity of the declared medical device meets the requirements, and whether the benefits are greater than the risks.
Framework for the cybersecurity research report of self-developed software can be found in the guidance document
5. Supplementary Explanation
(1) Product Registration
Software research materials: A cybersecurity research report for self-developed software should be submitted separately in the software research materials.
Instructions: The instructions provide cybersecurity instructions and usage guidance, and clearly define user access control
Requirements such as mechanisms, electronic interfaces (including network interfaces, electronic data interchange interfaces) and their data types and technical characteristics, configuration of cybersecurity features, data backup and disaster recovery, operating environment (including hardware configuration, external software environment, network environment, if applicable), list of security software compatibility (if applicable), external software environment and security software updates (if applicable), and existing software list (SBOM, if applicable), etc.
(2) Change Registration
Software research materials: When registering changes to medical devices, the research materials on the impact of the changes on product safety and effectiveness should be submitted according to the update of cybersecurity, as well as the change comparison table about the content of cybersecurity in the instructions.
(3) Continuing Registration
Continuing registration usually does not require the submission of research materials related to cybersecurity. Specific requirements are in the guidance
4. References
[1] Guiding Principles for the Registration Review of Medical Device Cybersecurity (2022 Revised Edition) (2022 No. 7)
[2] Guiding Principles for the Registration Review of Medical Device Software (2022 Revised Edition)
[3] FDA: Cybersecurity in Medical Devices: Quality System Considerations and
Content of Premarket Submissions (Draft)
[4] MITRE: Playbook-for-Threat-Modeling-Medical-Devices
[5] YY/T 0316 Application of Medical Device Risk Management to Medical Devices
[6] YY/T 0664 Medical Device Software Software Verification and Validation Process
评论已关闭