YY/T 1843-2022 PDF in English
YY/T 1843-2022 (YY/T1843-2022, YYT 1843-2022, YYT1843-2022)
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Name of Chinese Standard | Status |
| YY/T 1843-2022 | English | 380 |
Add to Cart
|
0-9 seconds. Auto-delivery.
|
Basic requirements of cybersecurity for medical electrical equipment
| Valid |
Standards related to: YY/T 1843-2022
PDF Preview
YY/T 1843-2022: PDF in English (YYT 1843-2022) YY/T 1843-2022
YY
PHARMACEUTICAL INDUSTRY STANDARD
OF THE PEOPLE’S REPUBLIC OF CHINA
ICS 11.040.01
CCS C 30
Basic requirements of cybersecurity for medical electrical
equipment
ISSUED ON: MAY 18, 2022
IMPLEMENTED ON: JUNE 01, 2023
Issued by: National Medical Products Administration
Table of Contents
Foreword ... 3
Introduction ... 4
1 Scope ... 5
2 Normative references ... 5
3 Terms and definitions ... 5
4 General requirements ... 10
5 Test methods ... 22
Appendix A (Normative) Requirements for the security capability testing process ... 23
Appendix B (Informative) Relevance between this document and other documents . 27
Appendix C (Informative) Guidance and rationale for specific clauses ... 28
Appendix D (Informative) Considerations regarding personal sensitive data in this
document ... 36
References ... 38
Basic requirements of cyber security for medical electrical
equipment
1 Scope
This document specifies the basic requirements for cyber security of medical
electrical equipment, medical electrical system and medical device software.
This document applies to medical electrical equipment, medical electrical system
and medical device software with functions of user access, electronic data exchange
or remote control.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
The following terms and definitions are applicable to this document.
3.1 Safety
Do not pose an unacceptable risk to persons, property or the environment.
[Source: ISO/IEC GUIDE 51:2014, 3.14, modified]
3.2 Confidentiality
The characteristic that information is not available or disclosed to unauthorized
persons, entities or processes.
[Source: GB/T 29246-2017, 2.12]
3.3 Malware
Software designed to maliciously disrupt normal functionality, collect sensitive data,
and/or access other connected systems.
3.4 Firewall
A network security product that analyzes the passing data stream and realizes access
control and security protection functions.
3.5 Risk
The combination of the probability of occurrence of an injury and the severity of that
injury.
[Source: YY/T 0316-2016, 2.16]
3.6 Risk analysis
The process of systematically using available information to identify hazard (sources)
and estimate risks.
[Source: YY/T 0316-2016, 2.17]
3.7 Risk control
The process of making decisions and implementing measures to reduce risk or
maintain risk at a specified level.
[Source: YY/T 0316-2016, 2.19]
3.8 Risk management
The systematic application of management policies, procedures and practices for risk
analysis, evaluation, control and monitoring.
[Source: YY/T 0316-2016, 2.22]
3.9 Personal sensitive data
Personal information which, once leaked, illegally provided or misused, may
endanger personal information and property safety, and may easily lead to damage or
discriminatory treatment to personal reputation, physical and mental health.
Note 1: Personal sensitive data may include ID number, personal bioinformation,
bank account number, communication records and content, property
information, credit information, whereabouts, accommodation information,
health and physiological information, transaction information, and personal
information of children under or of the age of 14.
Note 2: In GB/T 35273-2020, it is called personal sensitive information. Since this
document mainly regulates data, it is rewritten as data in this document.
Note 3: For the determination method and type of personal sensitive data, refer to
Appendix B in GB/T 35273-2020.
[Source: GB/T 35273-2020, 3.2, modified]
3.10 Emergency access
Through the technical processing of personal sensitive data, the subject of personal
sensitive data cannot be identified or associated, and the processed information
cannot be restored.
[Source: GB/T 35273-2020, 3.14, modified]
3.17 De-identification
Through the technical processing of personal sensitive data, the subject of personal
sensitive data cannot be identified or associated without additional information.
Note: De-identification is based on individuals, retaining the individual granularity,
and using technical means such as pseudonyms, encryption, and hash
functions to replace the identification of personal sensitive data.
[Source: GB/T 35273-2020, 3.15, modified]
3.18 Equipment data
Data describing the operating status of the equipment, which is used to monitor and
control the operation of the equipment or for the maintenance of the equipment, and
does not involve personal sensitive data itself.
3.19 Audit logging
Data about information security events, which is collected for review and analysis,
as well as ongoing monitoring.
[Source: GB/T 25068.1-2020, 3.4]
3.20 Security capability
Technical measures – based on risk management – enabling product data and/or
functions to have acceptable levels of confidentiality, integrity, availability and other
cyber security features.
Note: In this document, in order to distinguish the Chinese characters of security and
safety, security is called cyber security, and safety is called safety.
[Source: IEC/TR 80001-2-2:2012, 3.27, modified]
3.21 Security capability description
The document – clarifying the security capability of the product – whose main
purpose is to serve as a basis for the tester to test the product.
Note: The form of security capability description – which is not specified in this
document – can be a document, a set of documents, or a part of a document.
3.22 Integrity
The attribute that data shall not be altered in an unauthorized manner since it is
created, transmitted or stored.
[Source: ISO/IEC 29167-19:2016, 3.40]
3.23 IT-network
One or more systems consisting of communication nodes and transmission links, to
provide a physical link or wireless transmission between two or more designated
communication nodes.
[Source: IEC/TR 80001-2-2:2012, 3.10]
3.24 Medical device software
A developed software system included in a medical device, or a software system
developed for use as a medical device itself.
[Source: YY/T 0664-2020, 3.11]
3.25 Medical electrical equipment
ME equipment
Electrical equipment that has an applied part or transmits or obtains energy to the
patient or detects the transmitted or obtained energy. Such electrical equipment:
a) has no more than one connection to a specified power supply mains; and
b) its manufacturer intends to use it for:
1) diagnosis, treatment or monitoring of patients; or
2) eliminating or reducing disease, damage or disability.
[Source: GB 9706.1-2020, 3.63]
3.26 Medical electrical system
ME system
A combination of several devices that are functionally connected or connected to
each other by a multi-position socket under the manufacturer’s regulations. At least
one of the combination is an ME equipment.
[Source: GB 9706.1-2020, 3.64]
3.27 Medical IT-network
4.1.1.3 The security capability description shall clarify the security capability
according to the application of the product, in accordance with the requirements of
4.1.4 ~ 4.1.20.
4.1.1.4 The cyber security characteristics stated in the security capability description
shall be testable or verifiable.
4.1.2 *Classification
4.1.2.1 According to the type of expected access network, it can be divided into
products expected to access private network and public network.
4.1.2.2 According to the domain expected to be connected to the network, it can be
divided into products expected to be connected to personal area networks, local area
networks, and wide area networks.
4.1.2.3 According to the type of connection, it can be divided into products expected
to be independently wired and wirelessly connected with other information
equipment.
Note: The wired connection may include: USB, RS232, etc., and the wireless
connection may include Wi-Fi communication, Bluetooth communication,
wireless communication of a private protocol in a private frequency band,
etc.
4.1.2.4 According to the data transmission direction in the data exchange process, it
can be divided into one-way transmission and two-way transmission.
4.1.2.5 According to usage scenario, it can be divided into medical scenario and
non-medical scenario.
Note: Medical scenario may include treatment, diagnosis or monitoring scenario,
and non-medical scenarios may include maintenance scenario, etc.
4.1.3 Product feature description
4.1.3.1 The security capability description shall classify products according to 4.1.2.
4.1.3.2 The security capability description shall specify the intended use of the
product.
4.1.3.3 The security capability description shall provide a list of all electronic
interfaces of the product in its intended configuration, including:
a) all remote interfaces;
b) all local interfaces, product local internal interfaces;
Note: The internal interface refers to the interface between the various components
in the ME system.
c) all wireless interfaces;
d) input interface for all external files;
e) all communication protocols supported by each interface and their usage.
4.1.3.4 *The security capability description shall list the software name and version
number of the product, including all third-party and open-source software included
in the product.
4.1.3.5 The security capability description shall indicate the different configurations
used in the product or the supported configurations.
Note 1: The configuration here refers to software and hardware configuration, such
as:
-- operating system, system software or other supporting software;
-- processor and its size, main memory and its size, input and output
devices;
-- network environment.
Note 2: Different configurations can be specified for different requirements.
However, manufacturers need to recognize the cyber security risks posed
by different operating systems.
4.1.4 Storage confidentiality
The security capability description shall include a statement about the confidentiality
of storage of sensitive data.
4.1.5 Transmission confidentiality
The security capability description shall include a statement about the confidentiality
of transmission, especially considerations for sensitive data.
Note 1: Special consideration should be given to the confidentiality policy of
sensitive data during the network data transmission process of the device on
the public network.
Note 2: For more information on transmission confidentiality in wireless networks,
refer to IEC/TR 80001-2-3:2012.
4.1.6 Identity information in health data
4.1.12 Node authentication
When applicable, the security capability statement shall contain a statement of node
certification.
If the device is deployed in an HDO, the authentication policy shall be flexibly
adapted to the security policy of the local HDO IT-network.
If the product contains multiple nodes, and the nodes may be accessed by other
nodes outside the product, node authentication in this case shall be considered.
Note: Node authentication methods generally include white list, user name/password,
certificate, etc.
4.1.13 Malware detection and protection
The security capability description shall include a statement of whether the product
supports malware detection and protection, which shall include how the security
product is configured, and how malware is handled and repaired when it is detected.
Note: Security products generally include antivirus software, auxiliary security
software, and firewalls.
4.1.14 *System and application software hardening
Manufacturers shall take into account product system and application software
hardening. If hardening is required, the security capability description shall include a
statement of system and application software hardening measures. Such measures
are used to ensure that only those resources and services relevant to the intended use
are provided and that maintenance activities are kept to a minimum.
Note: Examples of such measures:
-- closing/disabling access ports unrelated to the product’s intended use;
-- closing/disabling services unrelated to the product’s intended use;
-- closing/disabling software applications unrelated to the product’s intended
use;
-- restricting/controlling access to the resource layer;
-- restricting/controlling access to the task layer.
4.1.15 Physical protection
The security capability description shall include a statement about the physical
protection of the data exchange ports on the product.
If the product is deployed in an HDO, the security capability description shall
include a statement about the physical protection of the product.
Note: Even if the asset of the physical equipment does not belong to the
manufacturer, if there is an associated risk, it needs to be stated.
4.1.16 Non-repudiation
The security capability description shall include a statement about non-repudiation
of the product.
4.1.17 Integrity and authenticity of health data
The security capability description shall include a statement about ensuring the
integrity and authenticity of health data.
4.1.18 Accountability
The security capability description shall include a statement about the product’s
accountability content and its means.
Note: Examples for such content:
-- successful or failed login attempts;
-- access, modification and deletion of health data;
-- import and export of health data;
-- changes in security configuration (e.g., changing credentials for user
authentication, changing the list of valid user accounts);
-- remote access (which may be used for product maintenance or intended
use);
-- emergency access.
4.1.19 Data backup and disaster recovery
The security capability description shall include a statement about the product’s data
backup and disaster recovery strategy.
Note: The objective is to ensure the continuity of medical operations. Utilization of
third-party and operating system functions for data backup is permitted in
this document. This includes the consideration of system disaster recovery. In
particular, products that need to archive health data need to consider
strategies to provide disaster recovery.
4.1.20 Maintainability
If the product is deployed in an HDO, the user documentation set shall clarify the
user’s administrative functions, especially the responsibilities of IT administrators.
Note 1: Considering the independence of the IT administrator’s functions, it is
recommended to publish a separate administrator manual so that it can only
be kept and viewed by the administrator.
Note 2: Regarding “functions”, when necessary, clearly point out what tasks the
administrator needs to complete, such as managing, customizing and
monitoring system information (such as access control lists, audit logging),
and require the administrator to clearly understand the security-related
functions.
Note 3: Even if the IT administrator is dispatched by the supplier/manufacturer, such
responsibilities shall be clarified.
4.2.3 Identity information in health data
The user documentation set shall provide the necessary guidance on how to
de-identify health data as stated in the security capability description.
4.2.4 User access control
The user documentation set shall contain guidance on the functions of user access
control.
4.2.5 User authorization
The user documentation set shall state all existing roles and their access rights.
4.2.6 Automatic logoff
The user documentation set shall provide reference information on automatic logoff
as stated in the security capability description.
4.2.7 Emergency access
The user documentation set shall state the directions for accessing necessary product
functions or health data under the state of emergency.
4.2.8 Security product
If the security product can be installed by the user, the user documentation set shall
state the security products compatible with the product, and shall provide
configuration guidance for the security product.
4.2.9 Physical protection
The user documentation set shall provide reference information on physical
protection as stated in the security capability description.
4.2.10 Accountability
The user documentation set shall provide guidance on how to view internet security
incident records as stated in the security capability statement.
4.2.11 Data backup and disaster recovery
The user documentation set shall provide necessary guidance for product data
backup and disaster recovery according to the statements of the security capability
description.
4.2.12 Maintainability
The user documentation set shall include guidance on the maintainability-related
content stated in the security capability description.
The user documentation set shall state the maintenance services related to the
product maintenance plan and cyber security.
The user documentation set shall include guidance on ensuring that sensitive data is
inaccessible when the storage device is decommissioned.
Note: Decommissioning may include discarding, reusing, reselling or recycling, etc.
4.3 Security capability requirements
4.3.1 Confidentiality
4.3.1.1 The product shall be implemented in accordance with the confidentiality
features stated in the security capability description.
4.3.1.2 The product shall be provided with confidential means for all sensitive data
generated, stored, used or transmitted by the product.
4.3.2 Identity information in health data
If the product can export personal sensitive data, the product shall provide the means
to make it impossible to identify the necessary information of the patient.
Note 1: Such means may include anonymization, de-identification, etc.
Note 2: It is also acceptable to use third-party tools specified by the manufacturer to
accomplish the above goals.
4.3.3 *User access control
......
Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.
|