1. Introduction

This first part of the UL 2900 standard is applied to networked products that must be evaluated against threats, malware and security breaches. This standard defines all the general requirements to be met from a software point of view, therefore it does not contain how to verify the functional specification of the product nor the hardware requirements.

This standard describes:: a) The documental requirements to be provided to face the evaluation.; b) The requirements related to security risk control in the architecture and design of the product.; c) The requirements related to the risk management process carried out by the developers.; d) The methods employed to evaluate a product when threat and malware exist.; e) The techniques to ensure the source code does not have different weaknesses to the already identified in the risk management process.

The following sections and subsections describe at high level what security requirements must be met by the product and by the vendor in order to successfully pass all the evaluation.

2. Documental requirements

The vendor must provide product documentation to describe all the design functions, the security functions and the risk management functions provided by the product, identifying its interfaces and besides, all the libraries and executable code contained in the product.

The design documentation must contain a risk analysis for the product as detailed throughout the standard to evaluate all the risks detailed in it.

Additionally, the product guidance documentation must show the commitment of the general security objectives along the entire lifecycle of the product. Hence, it must provide indications about secure configuration and intended use of the product, software updates, environment requirements, authorization and authentication methods and security protocols supported by the product.

3. Risk controls in the architecture and design

The product must comply with all the risk control requisites detailed in the following subsections. It will be needed to perform a risk analysis to evaluate and document the measures not supported by the device.

3.1. Access control authentication and authorization

The product must implement authentication and authorization measures to access to the functionalities that may affect its integrity. It must implement mechanisms to prevent perpetual authorization such as an inactivity time out.

Moreover, if it supports the use of an authentication credentials mechanism, it must allow to configure the complexity and length the passwords it but considering that its minimum length must be at least 6 characters and implementing measures to protect against brute force attacks such as implementing delays to perform a new authentication attempt after 10 sequential unsuccessful authentication attempts.

If the device supports role-based access control, then it must allow managing the user list to modify their privileges and to ensure that if an authentication method different from user/password is used, then it cannot be bypassed.

3.2. Remote communication

The product must ensure the integrity and authenticity of all remote communication making use of validated cryptographic mechanisms such as hash, digital signatures, Message Authentication Codes, etc.

3.3. Sensitive data

The product must ensure the confidentiality of all sensitive data generated, stored, used or communicated by the product. For that, the product must use a validated symmetric and asymmetric cryptographic algorithm.

3.4. Product Management

The product must allow to perform software updates and to revert to the previously installed version if the software update fails. For that, the device must implement measures to verify the integrity and authenticity of the firmware updates in online and offline mode making use of one of the cryptographic mechanisms employed to ensure the integrity of the remote communications.

Additionally, the product must maintain a log of all security events related to the unsuccessful authentication attempts, change of user authentication credentials, failed updates, etc. These logs must be stored in non-volatile memory to not allow non-privileges users to modify or remove them.

Regarding the product decommissioning, the product must allow secure erasing all the configuration data, sensitive data and personal data using one of the mechanisms specified in the SP 800-88.

4. Risk management by developers

To perform a good risk management, the vendor must perform the following tasks along the product design stage:

Identify all the product functionalities , and the sensitive data (generated, processed, stored or communicated by the product) associated with them.
List the threatsfor the product identifying which product functionalities and data are affected by them. In addition, the vendor must perform an assessment of the impact of each threat based on their occurrence probability, the data that may be affected and the vendor’s assumptions
Establish the risk controlsneeded to reduce the risk of threats to an acceptable level considering the risk controls required by this standard and additional controls. Moreover, the vendor must define a traceability matrix to associate risks with controls.

The threats classification must be made using a known scheme such us Common Attack Pattern Enumeration and Classification (CAPEC) or Damage, Reproducibility, Eploitability, Affected Users, Discoverability (DREAD).

Additionally, if any of the listed threats corresponds to a known vulnerability associated with the software, the risk assessment must:

Contain a description of each threat specifying their associated identifier in the Common Weakness Enumeration (CWE).
Carry out an identification of the affected software parts by each threat.
Show the result of the risk analysis for each threat and the needed control measures to decrease the risk.

5. Methods employed to find vulnerabilities and exploits when threat and malware exist

5.1. Known vulnerabilities testing

The entire source code including the third parties code must be tested to verify it does not contain additional known vulnerabilities to the accepted by the vendor with an acceptable risk level. The known vulnerabilities can be consulted in the National Vulnerability Database (NVD).

5.2. Malware testing

The source code must be analysed employing malware analysis tools depending on the Operating System where the software is installed.

5.3. Fuzz testing

Fuzz testing is required to check that the use of invalid or unexpected inputs on the device external interfaces does not cause device misbehaviours such us device reset, data corruption, configuration reinitialization, information revealing, information modification or system fails without recovering before 2 minutes under test.

5.4. Penetration testing

The product must have no known vulnerabilities that can be exploited in less than 2 minutes. The penetration testing must consist of evading the risk control used by the product trying to cause a DoS, exploiting the vulnerabilities classified with acceptable risk or elevating privileges on the product.

6. Software weaknesses in the source code

The source code must have no weaknesses different from the classified as acceptable by the vendor in the risk analysis. To carry out the source code analysis it is necessary to employ static source code analysis tools to analyse all the binary and bytecode files.

7. Conclusion

These brief notes provide a short overview about the general requirements to be fulfilled by a device that is going to be evaluated against the UL 2900 standard to face possible threats, malware and security breaches. Because of these general requirements are applied to Network Connectable Components of Healthcare and wellness systems (UL 2900-2-1), Industrial Control Systems (UL 2900-2-2) and Security and Life Safety Signalling Systems (UL 2900-2-3), it will be necessary to consult each of these documents to know in depth all the security features and documental requirements that must be fulfilled. Check our E-Health and Industrial-IoT, services to develop your device complying with the requirements of the standard or to assess if your implementation already meets the requirements.