Skip to main content

2.4.7 Device Interfaces

This section's intended audience is for those personnel who are responsible for device security. Guidance is available from the IoTSF Best Practice Guidelines [ref 44]1 regarding Credential Management (part F) and Network Connections (part H).

Req NoRequirementCompliance Class And ApplicabilityPrimary KeywordSecondary Keyword
2.4.7.1The product prevents unauthorised connections to it or other devices the product is connected to.Mandatory for Class 1 and aboveSystemSoftware
2.4.7.2The network component and firewall (if applicable) configuration has been reviewed and documented for the required/defined secure behaviour.Mandatory for Class 1 and aboveBusinessProcess
2.4.7.3To prevent bridging of security domains within products with network interfaces, forwarding functions should be blocked by default.Mandatory for Class 1 and aboveSystemSoftware
2.4.7.4Devices support only the versions of application layer protocols that have been reviewed and evaluated against publicly known vulnerabilities.Mandatory for Class 1 and aboveBusinessProcess
2.4.7.5If a potential unauthorised change is detected (e.g.: an access fails authentication or integrity checks), the device should alert the user/administrator to the issue and should not connect to wider networks than those necessary to perform the alerting function. Failed attempts should be logged, but without providing any information about the failure to the initiator.Mandatory for Class 1 and aboveSystemSoftware
2.4.7.6All the product's unused ports (or interfaces) are closed and only the necessary ones are active.Mandatory for Class 1 and aboveBusinessProcess
2.4.7.7If a connection requires a password or passcode or passkey for connection authentication, the factory issued or reset password is unique to each device.Mandatory for all classesBusinessProcess
2.4.7.8Where using initial pairing process, a Strong Authentication shall be used, requiring physical interaction with the device or possession of a shared secret.Mandatory for Class 1 and aboveSystemSoftware
2.4.7.9Where a wireless interface has an initial pairing process, the passkeys are changed from the factory issued, or reset password prior to providing normal service.Mandatory for all classesBusinessPolicy
2.4.7.10For any Wi-Fi connection, WPA-2 AES [ref 51]2 or a similar strength encryption has been used. Migration to the latest standard should be planned.(e.g. WPA3). Older insecure protocols such as WEP, WPA/WPA2 (Auto), WPA-TKIP and WPA-2 TKIP/AES (Mixed Mode) are disabled.Mandatory for Class 1 and aboveSystemSoftware
2.4.7.11Where WPA-2 WPS is used it has a unique, random key per device and enforces exponentially increasing retry attempt delays.Mandatory for Class 1 and aboveSystemSoftware
2.4.7.12All network communications keys are stored securely, in accordance with industry standards.Mandatory for Class 1 and aboveSystemSoftware
2.4.7.13Where a TCP protocol, such as MQTT, is used, it is protected by a TLS connection with no known vulnerabilities.Mandatory for Class 1 and aboveSystemSoftware
2.4.7.14Where a UDP protocol is used, such as CoAP, it is protected by a DTLS connection with no known vulnerabilities.Mandatory for Class 1 and aboveSystemSoftware
2.4.7.15Where 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]3 or OWASP. Where insecure ciphers suites are identified they shall be removed from the product.Mandatory for Class 1 and aboveBusinessProcess
2.4.7.16All 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.Mandatory for Class 1 and aboveBusinessProcess
2.4.7.17Where there is a loss of communications or availability it shall not compromise the local integrity of the device.Mandatory for Class 1 and aboveSystemSoftware
2.4.7.18The product only initialises and enables the communications interfaces, network protocols, application protocols and network services necessary for the product’s operation.Mandatory for Class 1 and aboveSystemSoftware
2.4.7.19Communications protocols should be latest versions with no publicly known vulnerabilities and/or appropriate for the product.Mandatory for Class 1 and aboveBusinessPolicy
2.4.7.20Post product launch, communications protocols should be reviewed throughout the product life cycle against publicly known vulnerabilities and changed to the most secure versions available if appropriate.Mandatory for Class 1 and aboveBusinessPolicy
2.4.7.21If a factory reset is made, the device should warn that secure operation may be compromised until updated.Mandatory for Class 1 and aboveSystemSoftware
2.4.7.22Where 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.Advisory for all classesSystemSoftware
2.4.7.23Protocol anonymity features are enabled in protocols (e.g., Bluetooth) to limit location tracking capabilities.Advisory for all classesSystemSoftware
2.4.7.24As far as reasonably possible, devices should remain operating and locally functional in the case of a loss of network connection.Mandatory for Class 1 and aboveSystemSoftware
2.4.7.25Following restoration of power or network connection, 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, which collectively could overwhelm a network.Mandatory for Class 1 and aboveSystemSoftware

Footnotes​

  1. Enhanced Privacy standard for Anonymous Signatures ISO/IEC20008 [https://www.iso.org/standard/57018.html] ↩

  2. NCSC guidance on TLS management [https://www.ncsc.gov.uk/guidance/tls-external-facing-services] ↩

  3. NIST Special Publication 800-131A Revision 1 ”Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths” November 2015 ↩