UL 2900-2-1-2017 pdf download
UL 2900-2-1-2017 pdf download.Software Cybersecurity for Network-Connectable Products, Part 2-1: Particular Requirements for Network Connectable Components of Healthcare and Wellness Systems.
C) A means of demonstrating traceability that links product cybersecurily risk controls to the cybersecurity risks that were considered;
d) A summary describing the plan for providing validated software updates and patches as needed throughout the litecycle of the product to continue to assure its safety and effectiveness:
e) A summary describing cybersecunty risk controls that are in place to assure that the product software will maintain its integrity (e.g. remain free of maiware) from the point of origin to the point at which that product leaves the control of the vendo and
1) Product instructions for e and product specifications related to recommended cybersecurity risk controls appropriate for the intended use environment (e.g. anti-virus software, use of firewall).
12.3.5 The organization shall identify all security-related safety and non-safety security-related requirements for the product in the risk management file or in separate documents referenced by the risk management file (see also 12.4.1.1. 12.4.2.1, and 12.4.3.1).
12.3.6 The security risk controls shall be based on requirements derived from the risk evaluation.
12.3.7 The security risk controls shall be derived from relevant product requirements including requirements not stated by the customer, but necessary for the security and safety of the product during its intended use.
12.4 Coverage of security analysis and testing
12.4.1 Protection of inputs
12.4.1.1 Security measures protecting inputs to the product shall be specified when applicable (e.g. encryption of input data).
12.4.1.2 Any specific inputs to the risk controls derived from the product isputs shall be specified (e.g. threshold values for safety Interlocks).
12.4.1.3 Data security (e.g. authenticated encryption) shall be specified for inputs.
12.4.1.4 Metadata security comparable to that in 12.4.1.3 shall be specified for inputs (e.g. patient identifying information).
12.4.1.5 Security measures to protect confidentiality of the contextual meaning of any exposed input data (e.g. wirelessly transmitted data as opposed to data securely entered locally at an HMI) shall be specified.
NOTE: An example of such a measure would be de-identificahon of patient identifiable data.
12.4.1.6 Security measures protecting assets against transitional vulnerabilibos exploited through input manipulation during product state changes shall be specified (e.g. excephon handling for out-of-range values, see SANS top 25).
NOTE: Triggers for state machine changes should be considered.
17 Software Weakness Analysis
17.1 The product shall undergo software weakness analysas per Sections 17. 18, and 19 of the Standard tor Software Cybersecurity for Network-Connectable Products. Part 1: General Requirements. UL 2900.1.
17.2 The product shall contain no known weaknesses unless otherwise stated in the vendors risk management fda and also satisfying the CWSS score established as part of the risk management process.
18 Static Source Code Analysis
18.1 The product shall comply with the Standard for Software Cybersecurity for Network-Connectable Products, Part 1; General Requirements. UL 2900-1, Sections 18 and 19.
19 StatIc Binary and Bytecode Analysis
19.1 The product shall comply with the Standard for Software Cybersecurity for Network-Connectable Products, Part 1: General Requirements. UL 2900-1, Section 19.
ORGANIZATIONAL ASSESSMENT
20 Lifecycle Security Processes
20.1 Quality management processes
20.1.1 The product shall be developed under a Quality Management System per the Standard for Medical Devices — Quality Management Systems – Requirements for Regulatory Purposes, ISO 13485.
20.1.2 The software development lifecycle shall comply with the applicable requirements of the Standard for Medical Device Software – Software Life Cycle Processes, IEC 62304. or equivalent.
20.2 General procurement processes
NOTE: Compliance Is to be determined by inspection of the Risk Management File.
20.2.1 For software components integrated into the product, the vendor’s Quality Management System shall address security considerations In the procurement process.
20.2.2 For components to be integrated into the product, the vendor (i.e. product developer) shall establish documented procurement procedures that include review of supplier security specifications for compatibility with organizational secunty policies and procedures.
20.2.3 The vendor (ie. product developer) shall plan the supplier selection, establish selection, evaluation and re-evaluation criteria, and establish a supplier qualificahon process based on the supplier’s atMlity to address dehned security criteria and provide products that satisfy the vendor’s security requirements.
20.2.4 The vendor (i.e. product develGper) shall perform ongoing surveillance of the supplier’s compliance to the security requirements. The vendor (i.e. product developer) shall also.
