UL 2900-1-2017 pdf download

UL 2900-1-2017 pdf download.Software Cybersecurity for Network-Connectable Products, Part 1: General Requirements.
12.3 The vendor shall document a risk evaluation method for the possible presence of known (types of) vulnerabilities In the product. This method shall describe the criteria that the vendor will use to evaluate the level of risk for each (type 01) known vulnerabilities that may be found in product. The method shall also establish the level below which a risk is acceptable to the vendor. The evaluation criteria shall be based on risk factors including, but not limited to. the CVSS score of the vulnerability, the intended use of the product and the environment in which the product would be used.
12.4 If the vendor has allowed for the presence of any known vulnerabilities In the product, the vendors security risk analysis for the product shall contain a description of each accepted known vulnerability:
a) CVE standard vulnerability identifier;
b) The software location of the vulnerability;
C) A risk analysis, performed and documented according to the method and criteria meant in 12.3, showing that the risk level associated to the presence of this vulnerability is acceptable.
12.5 The vendor shall likewise document a risk evaluation method for the possible presence of known (types of) software weaknesses in the product. This method shall describe the criteria that the vendor will use to evaluate the level of risk for each (type of) software weakness that may be found in product. The vendor shall make use of the Common Weakness Risk Analysis Framework (CWRAF), ref. (8]. The method shall also establish the level below which a risk is acceptable to the vendor. The evaluation criteria shall be based on risk factors including, but not limited to. the CWSS score of the weakness, the intended use of the product and the environment in which the product would be used.
12.6 In case the vendor is aware of and has accepted the presence of any software weaknesses in the product, the vendors secunty risk analysis for the product shall contain a description of each accepted weakness:
a) CWE standard weakness identifier;
b) The software location of the weakness;
C) A risk analysis, performed and documented according to 12.3, showing that the risk level associated with the presence of this weakness is acceptable;
d) External compensating controls to help further reduce the residual risk.
12.7 To verify compliance with 12.1 — 12.3 and 12.5, the security risk analysis for the product shall be evaluated along with the product design documentation. In particular, the following shall be determined:
a) Sufficient coverage dunng the secunty risk analysis with regard to the identification of product functionality and data and threats, impact, likelihood and resulting risk.
b) Sufficient adoption of risk controls listed in Sections 7 — 11 by either implementing each
control in the product or justifying why the risk level of not implementing a control is acceptable.
C) Sufficient implementation of risk controls per the requirements in Sections 7 — 11.
NOTE: Sufficiency is established via analysis of traceability through the risk management process.
12.8 To verify compliance with 12.4 and 12.6, the vendor’s risk evaluation methods for the presence of known vulnerabilities and software weaknesses shall be evaluated.
VULNERABILITIES AND EXPLOITS
13 Known Vulnerability Testing
13.1 The binary code and bytecode under test including those provided by third parties shall contain no known vulnerabilities, unless acceptable per 12.4.
13.2 To verify compliance with 13.1, all binary code and bytecode provided by the vendor according to
4.1(e) shall be evaluated for all known vulnerabilities applicable to the product published in the National
Vulnerability Database (NVD) at the time of evaluation.
NOTE: The NVD is currently accessible at htlps://nvd.nist.gov. 14 Malware Testing
14.1 The binary code and bytecode in the pioduct shall be scanned by at least one malware detection tool to Identify it any known malware exists in the final deliverables of the product. The maiware tools shall be applicable to the operating system that the software resides on.
14.2 To verify compliance with 14.1. all binary code and bytecode provided by the vendor according to
4.1(e) shall be inspected for known matware.
15 Malformed Input Testing
15,1 The product shall continue to operate as intended when subject to invalid or unexpected inputs on its external interfaces and shall not display unexpected behavior, such as. but not limited to the following:
a) The product resets or reinitializes its configuration:
b) A process crash or assertion failure occurs without a recovery to its previous state after the test is completed in 2 minutes or less:
c) A process hangs:
d) The testing uses resources of the product and the product does not relinquish these
resources after testing;
e) The product software throws an unharidled exception:
f) A storage data con’uption occurs:
g) The product loses the connection to the malformed input testing tool:
h) The specified behavior of the product is interrupted and the product does not continue to operate as intended within a timeframe defined by the manufacturer.