Iotsf Req V2

# Req Nr Iotsf Req Descr Prim Keyw Sec Keyw Mand Adv Sec Class
1 2.4.9.9 In device manufacture, all asymmetric encryption private keys that are unique to each device are secured as outlined in FIPS 140-2[ref 5].They must be truly randomly internally generated or securely programmed into each device. Business Process M 2 View
2 2.4.9.8 The cryptographic key chain used for signing production software is different from that used for any other test, development or other software images or support requirement. System Software A 0 View
3 2.4.9.7 The product stores all sensitive unencrypted parameters, e.g. keys, in a secure, tamperresistant location. System Hardware M 1 View
4 2.4.9.6 All the product related cryptographic functions have no publicly known unmitigated weaknesses, for example MD5 and SHA-1 are not used, e.g. those stipulated in NIST SP800-131A [ref 2]. Business Process M 1 View
5 2.4.9.5 All the product related cryptographic functions have no publicly known unmitigated weaknesses, for example MD5 and SHA-1 are not used, e.g. those stipulated in NIST SP800-131A [ref 2]. Business Process M 1 View
6 2.4.9.4 There is a secure method of key insertion that protects keys against copying. System Software M 1 View
7 2.4.9.3 There is a process for secure provisioning of keys that includes generation, distribution, update, revocation and destruction. For example in compliance with FIPS140-2 [ref 5] or a similar process. Business Process M 2 View
8 2.4.9.2 If present, a true random number generator source has been validated for true randomness using an NIST SP800-22 [ref 4], FIPS 140-2 [ref 5] or a similar compliance process. System Hardware A 0 View
9 2.4.9.10 All key lengths are sufficient for the level of assurance required such as detailed in NIST SP800-57 Part 1. Business Policy M 2 View
10 2.4.8.9 The product supports access control measures to the root/highest privilege account to restrict access to sensitive information or system processes. System Software M 1 View
11 2.4.8.8 The product securely stores any passwords using an industry standard cryptographic algorithm, compliant with an industry standard such as NIST SP800-63b [ref 26] or similar. System Software M 1 View
12 2.4.8.7 The product has defence against brute force repeated login attempts, such as exponentially increasing retry attempt delays. System Software M 1 View
13 2.4.8.6 Password entry follows industry standard practice such recommendations of the 3GPP TS33.117 Password policy [ref 17], NIST SP800-63b [ref 26] or NCSC [ref 48] on password length, characters from the groupings and special characters. System Software M 1 View
14 2.4.8.5 The product will not allow new passwords containing the user account name with which the user account is associated. System Software M 1 View
15 2.4.8.4 The product does not accept the use of null or blank passwords. System Software M 1 View
16 2.4.8.3 Where a user interface password is used for login authentication, the factory issued or reset password is unique to each device in the product family. If a password-less authentication is used the same principles of uniqueness apply. System Software M 1 View
17 2.4.8.2 Where the product has a secure source of time there is a method of validating its integrity, such as Secure NTP. System Software M 0 View
18 2.4.8.17 Where the product has the ability to remotely recover from attack, it should return to a known good state, to enable safe recovery and updating of the device. System Software M 0 View
19 2.4.8.16 The product allows an authorised and complete factory reset and all of the device’s authorisation information. System Software A 0 View
20 2.4.8.15 Where passwords are entered on a user interface, the actual pass phrase is obscured by default. System Software M 1 View
21 2.4.8.14 If the product has a password recovery or reset mechanism, an assessment has been made to confirm that this mechanism cannot readily be abused by an unauthorised party. Business Process M 1 View
22 2.4.8.13 The product supports having any or all of the factory default user login passwords altered when installed or commissioned. Business Process M 0 View
23 2.4.8.12 The product allows the factory issued or OEM login accounts to be disabled or erased or renamed when installed or commissioned. System Software A 0 View
24 2.4.8.11 The product only allows controlled user account access; access using anonymous or guest user accounts is not supported without justification. System Software M 1 View
25 2.4.8.10 The access control privileges are defined, justified and documented. Business Process M 1 View
26 2.4.8.1 The product contains a unique and tamperresistant device identifier (e.g. the chip serial number or other unique silicon identifier) for example binding code and data to a specific device hardware. This is to mitigate threats from cloning. System Hardware M 1 View
27 2.4.7.9 Where a wireless interface has an initial pairing process, the passkeys are changed from the factory issued, or reset password prior to providing normal service. Business Policy M 1 View
28 2.4.7.8 Where using initial pairing process, a Strong Authentication shall be used; requiring physical interaction with the device or possession of a shared secret. For example, Bluetooth Numeric Comparison [ref 38]. System Software M 1 View
29 2.4.7.7 If a connection requires a password or passcode or passkey for connection authentication, the factory issued or reset password is unique to each device. Examples are Wi-Fi access passwords and Bluetooth PINS. Business Process M 1 View
30 2.4.7.6 All the products unused ports are closed and only the required ports are active. Business Process M 1 View
31 2.4.7.5 If an unauthorised change is detected, the device should alert the consumer/administrator to an issue and should not connect to wider networks than those necessary to perform the alerting function. System Software M 0 View
32 2.4.7.4 Devices support only the versions of application layer protocols with no publically known vulnerabilities. Business Process M 1 View
33 2.4.7.3 In products with network interfaces, to stop bridging of security domains, the uncontrolled, and any unintended packet forwarding functions should be blocked to stop undesirable communication paths. System Software M 1 View
34 2.4.7.24 As far as reasonably possible, devices should remain operating and locally functional in the case of a loss of network connection and should recover cleanly in the case of restoration of a loss of power. Devices should be able to return to a network in a sensible state and in an orderly fashion, rather than in a massive scale reconnect. System Software M 0 View
35 2.4.7.23 Protocol anonymity features are enabled in protocols (e.g., Bluetooth) to limit location tracking capabilities. System Software A View
36 2.4.7.22 Where RF communications are enabled (e.g., ZigBee, etc.) antenna power is configured to limit ability of mapping assets to limit attacks such as WAR-Driving (see). System Software A View
37 2.4.7.21 If a factory reset is made, the device should warn that secure operation may be compromised unless updated. System Software M 1 View
38 2.4.7.20 Post product launch communications protocols should be maintained throughout the product life cycle to the most secure versions available with no publically known vulnerabilities. Business Policy M 1 View
39 2.4.7.2 The network component and firewall (if applicable) configuration has been reviewed and documented for the required/defined secure behaviour. Business Process M 1 View
40 2.4.7.19 Communications protocols should be latest versions with no publically known vulnerabilities and/or appropriate for the product. Business Policy M 1 View
41 2.4.7.18 The product only enables the communications interfaces, network protocols, application protocols and network services necessary for the product’s operation. System Software M 1 View
42 2.4.7.17 Where there is a loss of communications or availability it shall not compromise the local integrity of the device. System Software M 0 View
43 2.4.7.16 All use of cryptography by the product, such as TLS cipher suites, shall be listed and validated against the import/export requirements for the territories where the product is to be sold and/or shipped. Business Process M 1 View
44 2.4.7.15 Where cryptographic suites are used such as TLS, all cipher suites shall be listed and validated against the current security recommendations such as NIST 800-131A [ref 2] or OWASP. Where insecure ciphers suites are identified they shall be removed from the product. Business Process M 1 View
45 2.4.7.14 Where a UDP protocol is used, such as CoAP, it is protected by a DTLS connection with no known vulnerabilities. System Software M 1 View
46 2.4.7.13 Where a TCP protocol, such as MQTT, is used, it is protected by a TLS connection with no known vulnerabilities. System Software M 1 View
47 2.4.7.12 All network communications keys are stored securely, in accordance with industry standards such as FIPS 140-2 [ref 5] or similar. System Software M 1 View
48 2.4.7.11 Where WPA2 WPS is used it has a unique, random key per device and enforces exponentially increasing retry attempt delays. System Software M 1 View
49 2.4.7.10 For any Wi-Fi connection WPA2 [ref 51], or later versions with AES, or a similar strength encryption has been used and insecure protocols such as WPA and TKIP are disabled System Software M 1 View
50 2.4.7.1 The product prevents unauthorised connections to it or other devices the product is connected to. For example, there is a firewall on each interface and internet layer protocol. System Software M 1 View
51 2.4.6.9 Applications are operated at the lowest privilege level possible and only have access to the resources they need as controlled through appropriate access control mechanisms. For example, Products with one or more network interfaces, the uncontrolled, and any unintended packet forwarding functions should be blocked. System Software M 0 View
52 2.4.6.8 The product’s OS kernel and its functions are prevented from being called by external product level interfaces and unauthorised applications. System Software M 1 View
53 2.4.6.7 All OS command line access to the most privileged accounts has been removed from the OS. System Software A 0 View
54 2.4.6.6 All OS non-essential services have been removed from the product’s software, image or file systems. System Software A 0 View
55 2.4.6.5 If passwords absolutely must be stored in a local file, then passwords file(s) are owned by and are only accessible to and writable by the by the Devices’ OS’s most privileged account. System Software M 1 View
56 2.4.6.4 Files, directories and persistent data are set to minimum access privileges required to correctly function. System Software A 0 View
57 2.4.6.3 All unnecessary accounts or logins have been disabled or eliminated from the software at the end of the software development process. E.g. Development or debug accounts. System Software A 0 View
58 2.4.6.13 The product’s OS kernel is designed such that each component runs with the minimal security capabilities required (e.g. a microkernel architecture). System Software M 2 View
59 2.4.6.12 The OS implements a separation architecture to separate trusted from untrusted applications System Software M 2 View
60 2.4.6.11 The OS is separated from the application(s) and is only accessible via defined secure interfaces. System Software A 0 View
61 2.4.6.10 All the applicable security features supported by the OS are enabled. System Software M 1 View
62 2.4.6.1 The OS is implemented with relevant security updates prior to release. Business Process A 0 View
63 2.4.5.9 There are measures to prevent the installation of non-production software onto production devices. Business Process M 0 View
64 2.4.5.8 The product has protection against unauthorised reversion of the software to an earlier and potentially less secure version. System Software M 0 View
65 2.4.5.7 The product’s software signing root of trust is stored in tamper-resistant memory. System Hardware M 0 View
66 2.4.5.6 To prevent the stalling or disruption of the device’s software operation, watchdog timer are present, and cannot be disabled. System Hardware Software M 0 View
67 2.4.5.5 If the product has any virtual port(s) that are not required for normal operation, they are only allowed to communicate with authorised and authenticated entities or securely disabled when shipped. Where a port is used for field diagnostics, the port input commands are deactivated and the output provides no information which could compromise the device, such as credentials, memory address or function names. System Software M 2 View
68 2.4.5.4 If remote software upgrade is supported by a device, software images shall be encrypted whilst being transferred to it. System Software M 2 View
69 2.4.5.36 Where possible, software updates should be pushed for a period appropriate to the device. This period shall be made clear to a user when supplying the device. The supply chain partners should inform the user that an update is required. Business Policy M 0 View
70 2.4.5.35 An end-of-life policy shall be published which explicitly states the minimum length of time for which a device will receive software updates and the reasons for the length of the support period. The need for each update should be made clear to users and an update should be easy to implement. Business Policy M 0 View
71 2.4.5.34 Any caches which potentially store sensitive material are cleared / flushed after memory locations containing sensitive material have been sanitised. System Hardware M 3 View
72 2.4.5.33 Memory locations used to store sensitive material (e.g. cryptographic keys, passwords/passphrases, etc.) are sanitised as soon as possible after they are no longer needed. These can include but are not limited to locations on the heap, the stack, and statically-allocated storage [ref 47]. System Software M 2 View
73 2.4.5.32 There is secure provisioning of cryptographic keys for updates during manufacture in accordance with industry standards such as FIPS 140-2 [ref 5]. Business Process Policy M 0 View
74 2.4.5.31 Cryptographic keys for update integrity protection and confidentiality are securely managed in accordance with industry standards such as FIPS 140-2 [ref 5]. Business Process M 0 View
75 2.4.5.30 When a device cannot verify authenticity of updates itself, it shall be possible revert to the last known good configuration which was stored on the device before the update was attempted. System Software M 0 View
76 2.4.5.3 Where updates are supported the software update package has its digital signature, signing certificate and signing certificate chain verified by the device before the update process begins. System Software M 0 View
77 2.4.5.29 Where a device cannot verify authenticity of updates itself (e.g. due to no cryptographic capabilities), only a local update by a physically present user is permitted and is their responsibility. System Software M 0 View
78 2.4.5.28 Where a device doesn’t support secure boot, upon a firmware update the user data and credentials should be re-initialised. System Hardware Software M 0 View
79 2.4.5.27 Where real-time expectations of performance are present, update mechanisms must not interfere with meeting these expectations (e.g. by running update processes at low priority). System Software A 0 View
80 2.4.5.26 Support for partially downloading updates is provided for devices whose network access is limited or sporadic. System Software A 0 View
81 2.4.5.25 Support for partially installing updates is provided for devices whose on-time is insufficient for the complete installation of a whole update. System Software A 0 View
82 2.4.5.24 The software has been designed to meet the safety requirements identified in the risk assessment; for example in the case of unexpected invalid inputs, or erroneous software operation, the product does not become dangerous, or compromise security of other connected systems. System Software M 2 View
83 2.4.5.23 All inputs and outputs are checked for validity e.g. use “Fuzzing” tests to check for acceptable responses or output for both expected (valid) and unexpected (invalid) input stimuli. Business Process M 2 View
84 2.4.5.22 For devices with no possibility of a software update, the conditions for and period of replacement support should be clear. Business Policy M 0 View
85 2.4.5.21 Where the device software communicates with a product related webserver or application over TCP/IP or UDP/IP, the device software uses certificate pinning or public/private key equivalent, where appropriate. System Software M 2 View
86 2.4.5.20 The production software signing keys are stored and secured in a storage device compliant to FIPS-140-2 level 2 [ref 5], or equivalent or higher standard. Business Policy M 2 View
87 2.4.5.2 Where remote software updates can be supported by the device, the software images are digitally signed by an approved signing authority. System Software M 0 View
88 2.4.5.19 Where present, production software signing keys are under access control. Business Policy M 0 View
89 2.4.5.18 The build environment and toolchain used to create the software is under configuration management and version control, and its integrity is validated regularly. Business Process M 2 View
90 2.4.5.17 The build environment and toolchain used to compile the application is run on a build system with controlled and auditable access. Business Policy Process M 2 View
91 2.4.5.16 Software source code is developed, tested and maintained following defined repeatable processes. Business Process M 0 View
92 2.4.5.15 The software must be architected to identify and ring fence sensitive software components, including cryptographic processes, to aid inspection, review and test. The access from other software components must be controlled and restricted to known and acceptable operations. For example, security related processes should be executed at higher privilege levels in the application processor hardware. Business System Process Software M 1 View
93 2.4.5.14 The product’s software source code follows the basic good practice of static vulnerability analysis [ref 37] by the developer. Business Process M 2 View
94 2.4.5.13 The product’s software source code follows the basic good practice of a Language subset (e.g. MISRA-C) coding standard. Business Policy M 2 View
95 2.4.5.12 Steps have been taken to protect the products’ software from sensitive information leakage and side-channel attacks. System Software Hardware M 0 View
96 2.4.5.11 Development software versions have any debug functionality switched off if the software is operated on the product outside of the product vendor’s trusted environment. Business Process M 2 View
97 2.4.5.10 Production software images shall be compiled in such a way that all unnecessary debug and symbolic information is removed, to prevent accidental release of superfluous data. Business Process M 0 View
98 2.4.5.1 The product has measures to prevent unauthenticated software and files being loaded onto it. In the event that the product is intended to allow un-authenticated software, such software should only be run with limited permissions and/or in a sandbox. System Software M 0 View
99 2.4.4.9 All communications port(s), such as USB, RS232 etc., which are not used as part of the product’s normal operation are not physically accessible or only communicate with authorised and authenticated entities. System Hardware M 0 View
100 2.4.4.8 The hardware incorporates physical protection against reverse engineering. The level of protection must be determined by the risk assessment. System Hardware M 2 View
101 2.4.4.7 The hardware incorporates physical protection against tampering to reduce the attack surface. The level of protection must be determined by the risk assessment. System Hardware M 3 View
102 2.4.4.6 The hardware incorporates protection against tampering and this has been enabled. The level of tamper protection must be determined by the risk assessment. System Hardware M 1 View
103 2.4.4.5 Any debug interface (for example, I/O ports such as JTAG) only communicates with authorised and authenticated entities on the production devices. System Hardware M 1 View
104 2.4.4.4 The Secure Boot process is enabled by default. System Hardware M 1 View
105 2.4.4.3 The product’s processor system has a measured irrevocable hardware Secure Boot process. System Hardware M 3 View
106 2.4.4.2 The product’s processor system has an irrevocable “Trusted Root Hardware Secure Boot”. System Hardware M 2 View
107 2.4.4.17 The product shall have a hardware source for generating true random numbers. System Hardware M 2 View
108 2.4.4.16 Where the product has a hardware source for generating true random numbers, it is used for all relevant cryptographic operations including nonce, initialisation vector and key generation algorithms. For guidance see: NIST SP 800-90A [ref 3]. System Hardware M 0 View
109 2.4.4.15 Where production devices have a CPU watchdog, it is enabled and will reset the device in the event of any unauthorised attempts to pause or suspend the CPU’s execution. System Hardware M 0 View
110 2.4.4.14 Where the products’ credential/key storage is external to its processor, the storage and processor shall be cryptographically paired to prevent the credential/key storage being used by unauthorised software. System Hardware M 0 View
111 2.4.4.13 In production devices the microcontroller/ microprocessor(s) shall not allow the firmware to be read out of the products nonvolatile [FLASH] memory. Where a separate non-volatile memory device is used the contents shall be encrypted. System Hardware M 1 View
112 2.4.4.11 Tamper Evident measures have been used to identify any interference to the assembly to the end user. System Hardware M 2 View
113 2.4.4.10 All the product’s development test points are securely disabled or removed wherever possible in production devices. System Hardware M 2 View
114 2.4.4.1 The product’s processor system has an irrevocable hardware Secure Boot process. System Hardware M 1 View
115 2.4.3.9 There is a secure notification process based upon the IoTSF Vulnerability Disclosure Guidelines [ref 19] or a similar recognised process, for notifying partners/users of any security updates. Business Process M 0 View
116 2.4.3.8 A process is in place for consistent briefing of senior executives in the event of the identification of a vulnerability or a security breach, especially those executives who may deal with the media or make public announcements. In particular, that any public statements made in the event of a security breach should give as full and accurate an account of the facts as possible. Business Process M 0 View
117 2.4.3.7 Processes and plans are in place based upon the IoTSF Vulnerability Disclosure Guidelines [ref 19], or a similar recognised process, to deal with the identification of a security vulnerability or compromise when they occur. Business Process M 0 View
118 2.4.3.6 A policy has been established for addressing risks that could impact security and affect or involve technology or components incorporated into the product or service provided. Business Policy M 2 View
119 2.4.3.5 A policy has been established for interacting with both internal and third party security researcher(s) on the products or services. Business Policy M 0 View
120 2.4.3.4 The company follows industry standard cyber security recommendations (e.g. UK Cyber Essentials, NIST Cyber Security Framework, ISO27000 etc.). Business Policy M 2 View
121 2.4.3.25 Where a remote software upgrade can be supported by the device, there should be a transparent and auditable policy with schedule of actions to fix any vulnerabilities found. Business Policy M 2 View
122 2.4.3.24 There is a named owner responsible for assessing third party supplied components (hardware and software) used in the product e.g. The OS suppliers provided a completed IoTSF Framework Compliance Checklist [ref 19], document or equivalent. Business Role M 2 View
123 2.4.3.23 The security update policy for devices with a constrained power source shall be assessed to balance the needs of maintaining the integrity and availability of the device. Business Policy M 2 View
124 2.4.3.22 Where remote update is supported, there is an established process/plan for validating "updates" and updating devices on an on-going or remedial basis e.g. guidance on software updates is available from the IoTSF Best Practice Guidelines Part L [ref 44]. Business Process M 2 View
125 2.4.3.21 There is a point of contact for third party suppliers with security issues. Business Process M 1 View
126 2.4.3.20 Responsibility is allocated for control, logging and auditing of the update process. Business Process M 2 View
127 2.4.3.2 There is a person or role, who takes ownership for adherence to this compliance checklist process. Business Responsibility M 0 View
128 2.4.3.19 Responsibility is allocated for each stage of the update process. Business Responsibility M 2 View
129 2.4.3.18 Where real-time or up-time expectations are present, a procedure must be defined for notifying connected components of impending downtime for updates. Business Process M 2 View
130 2.4.3.17 The Security Policy shall be compliant with ISO 30111 or similar standard. Business Policy A 0 View
131 2.4.3.16 As part of the Security Policy, develop security advisory notification steps. For examples see US Cert programme [ref 46]. Business Process M 0 View
132 2.4.3.15 As part of the Security Policy, develop response steps and performance targets for Vulnerability Disclosures. Business Process M 0 View
133 2.4.3.14 As part of the Security Policy, publish the organisation’s conflict resolution process for Vulnerability Disclosures. Business Process A 0 View
134 2.4.3.13 As part of the Security Policy, develop a conflict resolution process for Vulnerability Disclosures. Business Process M 3 View
135 2.4.3.12 As part of the Security Policy, provide a dedicated security email address and/or secure online page for Vulnerability Disclosure communications. Business Policy M 0 View
136 2.4.3.11 As part of the Security Policy, develop specific contact web pages for Vulnerability Disclosure reporting. Business Policy M 0 View
137 2.4.3.10 A security threat and risk assessment shall have been carried out using a standard methodology such as OWASP, Octave or NIST RMF Risk Management Framework [ref 35] to determine the risks and evolving threats before a design is started. Business Process M 0 View
138 2.4.3.1 There is a person or role, typically a board level executive, who takes ownership of and is responsible for product, service and business level security. Business Responsibility M 0 View
139 2.4.16.6 The device manufacturer ensures that the identity of the device is independent of the end user, to ensure anonymity and comply with relevant local data privacy laws e.g. GDPR [ref 14] in the EU. Business Policy M 1 View
140 2.4.16.5 The device registration [ref 16] with the Service Provider shall be secure (method and reasoning needed in evidence). Business Process M 1 View
141 2.4.16.4 In case of ownership change, the device has an irrevocable method of decommissioning and recommissioning. system process M 1 View
142 2.4.16.3 The Service Provider should not have the ability to do a reverse lookup of device ownership from the device identity. Business Process M 2 View
143 2.4.16.2 Where a device or devices user wishes to end the service, all Personal Information shall be removed from the device and related services. Business Process M 1 View
144 2.4.16.1 Where a device or devices are capable of having their ownership transferred to a different owner, all the previous owner’s Personal Information shall be removed from the device(s) and registered services. This option must be available when a transfer of ownership occurs or when an end user wishes to delete their Personal Information from the service or device. Business Process M 1 View
145 2.4.15.2 The configuration shall be provisioned to the device just in time by authorised services, to replace any existing pre-configuration for secure operation. Business Process M 1 View
146 2.4.15.1 The configuration of the device and any related web services is tamper resistant i.e. sensitive configuration parameters should only be changeable by authorised people (evidence should list the parameters and who is authorised to change). Business M 1 View
147 2.4.14.7 A cryptographic protected ownership proof shall be transferred along the supply chain and extended if a new owner is added in the chain. This process shall be based on open standards like Enhanced Privacy ID, Certificates per definition in ISO 20008/20009 [ref 42]. Business Process M 1 View
148 2.4.14.6 A securely controlled area and process shall be used for device provisioning where the production facility is untrusted. For example, implements the controls required in Common Criteria EAL5+/6 certification [refs 6, 7, 8 and 9]. Business Process A 0 View
149 2.4.14.5 Where a product includes a trusted Secure Boot process, the entire production test and any related calibration is executed with the processor system operating in its secured boot, authenticated software mode. System Process A 0 View
150 2.4.14.4 The production system for a device has a process to ensure that any devices with duplicate serial numbers are not shipped and are either reprogrammed or destroyed. Business Process M 1 View
151 2.4.14.3 In manufacture, all the devices are logged by the product vendor, utilising unique tamper resistant identifiers such as serial number so that cloned or duplicated devices can be identified and either disabled or prevented from being used with the system. Business process M 1 View
152 2.4.14.2 Any hardware design files, software source code and final production software images with full descriptive annotations are stored encrypted in off-site locations or by a 3party Escrow service. Business Process A 0 View
153 2.4.14.1 The product has the entire production test and calibration software used during manufacture erased or removed or secured before the product is dispatched from the factory. This is to prevent alteration of the product post manufacture when using authorised production software, for example hacking of the RF characteristics for greater RF ERP. Where such functionality is required in a service centre, it shall be erased or removed upon completion of any servicing activities. System Software A 0 View
154 2.4.14..8 An auditable manifest of all libraries used within the product (open source, etc.) to support informed vulnerability management during deployment is maintained. Business Process A 0 View
155 2.4.13.9 Where a product related to a webserver encrypts communications using TLS and requests a client certificate, the server(s) only establishes a connection if the client certificate and its chain of trust are valid. System Software M 1 View
156 2.4.13.8 The related servers have unused IP ports disabled. System Software M 1 View
157 2.4.13.7 The product related web servers have repeated renegotiation of TLS connections disabled. System Software M 1 View
158 2.4.13.6 The product related web servers support appropriately secure TLS/DTLS ciphers and disable/remove support for deprecated ciphers. For example see guidance at ENISA [ref 27], SSL Labs [ref 29], IETF RFC7525 [ref 28] and NCSC [ref 50]. System Software A 0 View
159 2.4.13.5 The Product Manufacturer or Service Provider has a process to monitor the relevant security advisories to ensure all the product related web servers use protocols with no publicly known weaknesses. Business Process M 1 View
160 2.4.13.4 All the product related web servers’ TLS certificate(s) are signed by trusted certificate authorities; are within their validity period; and processes are in place for their renewal. System Software M 1 View
161 2.4.13.34 IoT devices should connect to cloud services using edge-to-cloud secure hardware (e.g., zero-touch provisioning). System Hardware A 0 View
162 2.4.13.33 Product-related cloud services monitor for compliance with connection policies and report out-of-compliance connection attempts. System Software M 2 View
163 2.4.13.32 When implemented as a cloud service, all remote access to cloud services is via secure means (e.g., SSH). System Software M 0 View
164 2.4.13.31 Product-related cloud services are designed using a defence-in-depth architecture consisting of Virtual Private Clouds (VPCs), firewalled access, and cloud-based monitoring. System Software M 0 View
165 2.4.13.30 Product-related cloud service databases restrict read/write access to only authorized individuals, devices and services. System Software M 0 View
166 2.4.13.3 All product related web servers have their webserver HTTP trace and trace methods disabled. System Software M 1 View
167 2.4.13.29 Product-related cloud service databases are encrypted during storage. System Software M 0 View
168 2.4.13.28 If run as a cloud service, privileged roles are defined and implemented for any gateway/service that can configure devices. System Software M 2 View
169 2.4.13.27 Product-related cloud services API keys are not hard-coded into devices or applications. System Software M 0 View
170 2.4.13.26 Product-related cloud services bind API keys to specific IoT applications and are not installed on non-authorised devices. System Software M 2 View
171 2.4.13.25 Where device identity and/or configuration registries (e.g. thing shadows) are implemented within a cloud service, the registries are configured to restrict access to only authorised administrators. System Software M 0 View
172 2.4.13.24 If run as a cloud service, UDP-based communications are encrypted using the latest Datagram Transport Layer Security (DTLS). System Software M 1 View
173 2.4.13.23 If run as a cloud service, the cloud service TCP based communications (such as MQTT connections) are encrypted and authenticated using the latest TLS standard. System Software M 1 View
174 2.4.13.22 Input data validation should be maintained in accordance with industry practiced methods as per NIST 800-53 SI-10 [Ref 33]. System Software M 1 View
175 2.4.13.21 Where a Product or Service includes any safety critical or life-impacting functionality, the services infrastructure shall incorporate redundancy to ensure service continuity and availability. System Software M 1 View
176 2.4.13.20 Where a Product or Services includes any safety critical or life-impacting functionality, the services infrastructure shall incorporate protection against DDOS attacks, such as dropping of traffic or sink-holing. See NIST SP 800-53 SC-5 [ref 32]. System Software M 2 View
177 2.4.13.2 Any product related web servers have their webserver identification options (e.g. Apache or Linux) switched off. System Software M 1 View
178 2.4.13.19 If run as a cloud service, the service meets industry standard cloud security principles such as the Cloud Security Alliance [ref 18], NIST Cyber Security Framework [ref 21] or UK Government Cloud Security Principles [ref 24]. System Software A 0 View
179 2.4.13.18 All the related servers and network elements prevent anonymous/guest access except for read only access to public information. System Software M 1 View
180 2.4.13.17 All the related servers and network elements support access control measures to restrict access to sensitive information or system processes to privileged accounts. System Software M 1 View
181 2.4.13.16 All the related servers and network elements store any passwords using a cryptographic implementation using industry standard cryptographic algorithms, for example see FIPS 140-2 [ref 5]. System Software M 1 View
182 2.4.13.15 The maximum permissible number of consecutive failed user account login attempts follows the recommendations of 3GPP TS33.117 password policy [ref 17]. System Software M 1 View
183 2.4.13.14 All the related servers and network elements enforce passwords that follows industry standard practice such recommendations of the 3GPP TS33.117 Password policy [ref 17], NIST SP800-63b [ref 26] and NCSC guidance [ref 48]. System Software M 1 View
184 2.4.13.11 All the related servers and network elements prevent the use of null or blank passwords. System Software M 1 View
185 2.4.13.10 Where a product related to a webserver encrypts communications using TLS, certificate pinning is implemented. For example, using OWASP [ref 31] or similar organisations’ certificate and public key pinning guidance. System Software A 0 View
186 2.4.13.1 All the product related cloud and network elements have the latest operating system(s) security updates implemented and processes are in place to keep them updated. Business Process M 2 View
187 2.4.12.9 The supplier or manufacturer of any device shall provide information about how the device(s) functions within the end user’s network may affect their privacy. Business Process A 0 View
188 2.4.12.8 The product / service can be made compliant with the local and/or regional Personal Information protection legislation where the product is to be sold for example GDPR [ref 14]. System Software M 0 View
189 2.4.12.7 There is a method or methods for the product owner to check/verify what Personal Information is collected and deleted. System Software M 0 View
190 2.4.12.6 There is a method or methods for the product owner to be informed about what Personal Information is collected, why, where it will be stored. Business Process M 1 View
191 2.4.12.5 The Product Manufacturer or Service Provider shall ensure that a data retention policy is in place and documented for users. Business Policy M 1 View
192 2.4.12.4 The product/service ensures that Personal Information is anonymised whenever possible and in particular in any reporting. System Software M 0 View
193 2.4.12.3 The product/service ensures that only authorised personnel have access to personal data of users. System Software M 0 View
194 2.4.12.2 The product/service ensures that all Personal Information is encrypted (both when stored and if communicated out of the device, see IoTSF guidance [ref 44] Part H on Network Connections System Software M 1 View
195 2.4.12.15 The supplier or manufacturer performs a privacy impact assessment (PIA) to identify Personally Identifiable Information (PII) and design approaches for safeguarding user privacy [ref 49]. Business Process A 0 View
196 2.4.12.14 The product or service only records audio/visual data in accordance with the authorization of the user (e.g., no passive recording without explicit authorisation). System Software M 0 View
197 2.4.12.13 Security of devices and services should be designed with usability in mind. Reducing user decision points that may have a detrimental impact on security and privacy. System Software M 0 View
198 2.4.12.12 The supplier or manufacturer of any devices or services shall provide clear information about the end user’s responsibilities to maintain the devices and/or services privacy and security. Business Process M 1 View
199 2.4.12.11 The supplier or manufacturer of any devices and/or services shall provide information about how the device(s) removal and/or disposal shall be carried out to maintain the end user’s privacy and security. Business Process M 1 View
200 2.4.12.10 The supplier or manufacturer of any devices or devices shall provide clear information about how the device(s) shall be setup to maintain the end user’s privacy and security. Business Process M 0 View
201 2.4.12.1 The product/service stores the minimum amount of Personal Information from users required for the operation of the service. System Software M 0 View
202 2.4.11.9 All application inputs and outputs are validated using for example a whitelist containing authorised origins of data and valid attributes of such data, see NIST SP 800-167 [ref 34]. System Software M 0 View
203 2.4.11.8 Secure administration interfaces: it is important that configuration management functionality is accessible only by authorised operators and administrators. Enforce strong authentication over administration interfaces, for example, by using certificates. System Software M 1 View
204 2.4.11.7 All data being transferred over interfaces should be validated where appropriate. This could include checking the data type, length, format, range, authenticity, origin and frequency. System Software M 0 View
205 2.4.11.6 Where passwords are entered on a user interface, the actual pass phrase is obscured by default to prevent the capture of passwords. System Software M 1 View
206 2.4.11.5 The product securely stores any passwords using an industry standard cryptographic algorithm, for example see FIPS 140-2 [ref 5]. System Software M 1 View
207 2.4.11.4 Where the application communicates with a product related remote server(s), or device, it does so over a secure connection such as a TLS connection using certificate pinning. System Software M 1 View
208 2.4.11.3 The mobile application ensures that any related databases or files are either tamper resistant or restricted in their access. Upon detection of tampering of the databases or files they are reinitialised. System Software M 1 View
209 2.4.11.2 Password entry follows industry standard practice such recommendations of the 3GPP TS33.117 Password policy [ref 17] or NIST SP800-63b [ref 26]. System Software M 1 View
210 2.4.11.1 Where an application’s user interface password is used for login authentication, the initial password or factory reset password is unique to each device in the product family. System Software M 1 View
211 2.4.10.9 A vulnerability assessment has been performed before deployment and on an ongoing basis afterwards. Business Process M 1 View
212 2.4.10.8 The web user interface shall follow good practice guidelines, such as those listed in the OWASP [Ref 30]. Business Policy M 1 View
213 2.4.10.7 Where passwords are entered on a user System Software M 1 View
214 2.4.10.6 User passwords are not stored in plain text Strong passwords are required, and a random salt value is incorporated with the password. For further info see the 3GPP TS33.117 Password policy [ref 17], NIST SP800-63b [ref 26] and NCSC [ref 48]. System Software M 1 View
215 2.4.10.5 The web user interface is protected by an automatic session idle logout timeout function. System Software M 1 View
216 2.4.10.4 Where a web user interface password is used for login authentication, the initial password or factory reset password is unique to each device in the product family. System Software M 1 View
217 2.4.10.3 Where the product or service provides a web based management interface, Strong Authentication is used to the web server. System Software M 1 View
218 2.4.10.2 Where the product or service provides a web based interface, public and restricted areas shall be separated for authentication. System Software M 0 View
219 2.4.10.15 All inputs and outputs are checked for validity e.g. use “Fuzzing” tests to check for acceptable responses or output for both expected (valid) and unexpected (invalid) input stimuli. Business Process M 1 View
220 2.4.10.14 Reduce the lifetime of sessions to mitigate the risk of session hijacking and replay attacks. For example to reduce the time an attacker has to capture a session cookie and use it to access an application. System Software M 1 View
221 2.4.10.13 Administration Interfaces are accessible only by authorized operators. Mutual Authentication is used over administration interfaces, for example, by using certificates. System Software M 1 View
222 2.4.10.12 All inputs and outputs are validated using for example a whitelist containing authorised origins of data and valid attributes of such data. System Software M 0 View
223 2.4.10.11 Sanitize input in Web applications by using URL encoding or HTML encoding to wrap data and treat it as literal text rather than executable script. System Software M 0 View
224 2.4.10.10 All data being transferred over interfaces should be validated where appropriate. This could include checking the data type, length, format, range, authenticity, origin and frequency. System Software M 0 View
225 2.4.10.1 Where the product or service provides a web based user interface, Strong Authentication is used. System Software M 1 View
Records : 225 of 225 | Page : of 1 | Limit