6.3.12 The testing laboratory shall take reference from CLS Publication – Minimum Test Specifications and Methodology for Tier 4 [4] for this task. 6.3.13 It is of CCC’s intention that the test specifications shall be revised in the future to keep up with the evolving threat landscape. Search for potential vulnerabilities in the public domain 6.3.14 The testing laboratory shall examine sources of information publicly available to identify potential vulnerabilities for the DUT. 6.3.15 The testing laboratory shall also examine sources of information publicly available to identify generic vulnerabilities (vulnerabilities discovered on similar DUT-type) that could potentially be applicable for the DUT and determine if they are applicable for the DUT. 6.3.16 The testing laboratory can make use of several established sources. Examples are Common Vulnerabilities and Exposures (CVE), and public search engines (e.g. Google). 6.3.17 The testing laboratory shall also examine sources of information publicly available to check for DUT source code, binary code, developerconfidential data, DUT user credentials, or other information that may be available to a potential attacker. E.g. source code or DUT default administrator credentials hosted on GitHub. Vulnerability Analysis 6.3.18 From information collected through the preceding search for potential vulnerabilities in the public domain and from the report of the binary analysis covered under Tier 3, the developer shall devise a list of potential security vulnerabilities and potential attack paths. 6.3.19 The testing laboratory may make use of vulnerability scanning tools and techniques to identify potential vulnerabilities. 6.3.20 Malformed Input Testing (also known as fuzz testing) should be conducted to discover coding errors, security loopholes in the software of the DUT. It involves inputting massive amounts of random data to the DUT in an attempt to make it malfunction and discover potential flaws. 6.3.21 The testing laboratory shall make use of automated fuzzing software tools. Due to the limited time period, it is advised that the testing laboratory focus time and effort on interfaces that are deemed more critical. 6.3.22 It is expected that fuzz testing may result in device crashes which is different from an exploitable vulnerability. The developer, together with the testing laboratory, shall to their best effort, attempt to perform analysis on the crashes to determine if the issues are potentially an exploitable vulnerability. CLS Publication #2 | Page 17 of 49