2.4.5 Device Software
This section’s intended audience is for those personnel who are responsible for device application quality e.g. Software Architects, Product Owners, and Release Managers. Guidance is available from the IoTSF (IOTSF.SD-BPG) regarding Secure Operating Systems (part D), Credential Management (part F), and Securing Software Updates (part J).
| Req No | Requirement | Primary Keyword | Secondary Keyword | Compliance Class And Applicability |
|---|---|---|---|---|
| 2.4.5.1 | The product has measures to prevent unauthorised and unauthenticated software, configurations and files being loaded onto it. If the product is intended to allow un-authenticated software, such software should only be run with limited permissions and/or sandbox. | System | Software | Mandatory for all classes |
| 2.4.5.2 | Where remote software updates can be supported by the device, the software images must be digitally signed by an appropriate signing authority - e.g. manufacturer/supplier or public. The Signing Authority should be clearly identified. | System | Software | Mandatory for all classes |
| 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 | Mandatory for all classes |
| 2.4.5.4 | If remote software upgrade is supported by a device, software images shall be encrypted or transferred over an encrypted channel. | System | Software | Mandatory for Class 2 and above |
| 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 are securely disabled when shipped. When a port is initialised or 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 | Mandatory for Class 2 and above |
| 2.4.5.6 | To prevent the stalling or disruption of the device’s software operation, watchdog timers are present, and cannot be disabled. | System | Hardware Software | Mandatory for Class 1 and above |
| 2.4.5.7 | The product’s software signing root of trust is stored in tamper-resistant memory. | System | Hardware | Mandatory for Class 1 and above |
| 2.4.5.8 | The product has protection against unauthorised reversion of the software to an earlier and potentially less secure version. Only authorised entities can restore the software to an earlier secure version. | System | Software | Mandatory for Class 2 and above |
| 2.4.5.9 | There are measures to prevent the installation of non-production (e.g. development or debug) software onto production devices. | Business | Process | Mandatory for Class 1 and above |
| 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 | Mandatory for Class 1 and above |
| 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 | Mandatory for Class 2 and above |
| 2.4.5.12 | Steps have been taken to protect the product's software from sensitive information leakage, including at network interfaces during initialisation, and side-channel attacks. | System | Hardware | Mandatory for Class 3 and above |
| 2.4.5.13 | The product’s software source code follows the basic good practice of a Language subset coding standard. | Business | Policy | Mandatory for Class 2 and above |
| 2.4.5.14 | The product’s software source code follows the basic good practice of static vulnerability analysis [NIST.SAMATE]1 by the developer. | Business | Process | Mandatory for Class 2 and above |
| 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 | Process | Mandatory for Class 1 and above |
| 2.4.5.16 | Software source code is developed, tested and maintained following defined repeatable processes. | Business | Process | Mandatory for Class 1 and above |
| 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 | Process | Mandatory for Class 2 and above |
| 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 | Mandatory for Class 2 and above |
| 2.4.5.19 | Where present, production software signing keys are under access control. | Business | Policy | Mandatory for all classes |
| 2.4.5.20 | The production software signing keys are stored and secured in a storage device compliant to FIPS-140-2 [FIPS.140-2]2/FIPS-140-3 [FIPS.140-3]3 level 2, or equivalent or higher standard. | Business | Policy | Mandatory for Class 1 and above |
| 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 | Mandatory for Class 2 and above |
| 2.4.5.22 | For a device with no possibility of a software update, the conditions for and period of replacement support should be clear. A replacement strategy must be communicated to the user, including a schedule for when the device should be replaced or isolated. | Business | Policy | Mandatory for all classes |
| 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 | Mandatory for Class 2 and above |
| 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 | Mandatory for Class 2 and above |
| 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 (constrained devices). | System | Software | Advisory for all classes |
| 2.4.5.26 | Support for partially downloading updates is provided for devices whose network access is limited or sporadic. | System | Software | Advisory for all classes |
| 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, or notifying the user of the priority and duration of the update and with the option of postponing or disabling the update). | System | Software | Mandatory for all classes |
| 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 | Mandatory for all classes |
| 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 | Mandatory for all classes |
| 2.4.5.30 | An update to a device must be authenticated before it is installed. Where the update fails authentication, the device should, if possible, revert to the last known good (current stable) configuration/software image which was stored on the device. | System | Software | Mandatory for all classes |
| 2.4.5.31 | Withdrawn as duplicate requirement | |||
| 2.4.5.32 | There is secure provisioning of cryptographic keys for updates during manufacture in accordance with industry standards. | Business | Policy | Mandatory for Class 1 and above |
| 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 [CERT-C.MEM03]4, [ISO.IEC.24772]5, [MITRE.CWE-226]6, [MITRE.CWE-244]7 | System | Software | Mandatory for Class 2 and above |
| 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 Software | Mandatory for Class 3 and above |
| 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. At the end of the support period, the device should reduce the risk of a latent vulnerability being exploited. This could be by indicating an error condition to the user or curtailing functionality. This action should be clearly communicated to the user during the procurement stage. | Business | Policy | Mandatory for all classes |
| 2.4.5.36 | Updates should be provided for a period appropriate to the device, and this period shall be made clear to a user when supplying the device. Updates should, where possible, be configurable to be automatically or manually installed. The supply chain partners should inform the user that an update is required. | Business | Policy | Mandatory for all classes |
| 2.4.5.37 | The device manufacturer should ensure that shared libraries (e.g. Clib or Crypto libraries) that deliver network and security functionalities have been reviewed or evaluated (note that the actual review or evaluation does not have to be conducted by the manufacturer if it has been conducted by another reputable organisation or government entity). Cryptography libraries should be re-reviewed for known security vulnerabilities on each update of the device. | Business | Policy | Mandatory for Class 2 and above |
| 2.4.5.38 | Maintenance changes should trigger full security regression testing. | Business | Policy | Mandatory for Class 2 and above |
| 2.4.5.39 | IoT devices must allow software updates to maintain security over the product lifetime. | Business | Policy | Mandatory for Class 2 and above |
| 2.4.5.40 | Hard-coded critical/security parameters in device software source code shall not be used; if needed these should be injected in a separate (secure) process. | Business | Policy | Mandatory for all classes |
| 2.4.5.41 | Where the device is capable, it should check after initialization, and then periodically, whether security updates are available, either autonomously or as part of the support service. Otherwise, the support service should push updates to the device. | Business | Policy | Mandatory for Class 1 and above |
Footnotes
-
NIST "Source Code Security Analyzers". https://www.nist.gov/itl/ssd/software-quality-group/source-code-security-analyzers. ↩
-
FIPS PUB 140-2, "Security Requirements for Cryptographic Modules", May 2001. https://csrc.nist.gov/pubs/fips/140-2/upd2/final. ↩
-
FIPS PUB 140-3, "Security Requirements for Cryptographic Modules", Mar 2019. https://csrc.nist.gov/pubs/fips/140-3/final. ↩
-
SEI CERT C Coding Standard Recommendation MEM03-C: "Clear sensitive information stored in reusable resources". https://wiki.sei.cmu.edu/confluence/display/c/MEM03-C.+Clear+sensitive+information+stored+in+reusable+resources. ↩
-
ISO/IEC 24772-1:2024 "Programming languages — Avoiding vulnerabilities in programming languages" - "7.27 Sensitive information not cleared before use [XZK]", October 2024. https://www.iso.org/standard/83629.html. ↩
-
MITRE CWE-226 "Sensitive Information in Resource Not Removed Before Reuse". https://cwe.mitre.org/data/definitions/226.html. ↩
-
CWE-244 "Improper Clearing of Heap Memory Before Release ('Heap Inspection')". https://cwe.mitre.org/data/definitions/244.html. ↩