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 [ref 44]¹ regarding Secure Operating Systems (part D), Credential Management (part F), and Software Updates (part J).

Req No	Requirement	Compliance Class And Applicability	Primary Keyword	Secondary Keyword
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.	Mandatory for all classes	System	Software
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.	Mandatory for all classes	System	Software
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.	Mandatory for all classes	System	Software
2.4.5.4	If remote software upgrade is supported by a device, software images shall be encrypted or transferred over an encrypted channel.	Mandatory for Class 2 and above	System	Software
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.	Mandatory for Class 2 and above	System	Software
2.4.5.6	To prevent the stalling or disruption of the device’s software operation, watchdog timers are present, and cannot be disabled.	Mandatory for Class 1 and above	System	Hardware Software
2.4.5.7	The product’s software signing root of trust is stored in tamper-resistant memory.	Mandatory for Class 1 and above	System	Hardware
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.	Mandatory for Class 2 and above	System	Software
2.4.5.9	There are measures to prevent the installation of non-production (e.g. development or debug) software onto production devices.	Mandatory for Class 1 and above	Business	Process
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.	Mandatory for Class 1 and above	Business	Process
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.	Mandatory for Class 2 and above	Business	Process
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.	Mandatory for Class 3 and above	System	Hardware
2.4.5.13	The product’s software source code follows the basic good practice of a Language subset coding standard.	Mandatory for Class 2 and above	Business	Policy
2.4.5.14	The product’s software source code follows the basic good practice of static vulnerability analysis [ref 37]² by the developer.	Mandatory for Class 2 and above	Business	Process
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.	Mandatory for Class 1 and above	Business	Process
2.4.5.16	Software source code is developed, tested and maintained following defined repeatable processes.	Mandatory for Class 1 and above	Business	Process
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.	Mandatory for Class 2 and above	Business	Process
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.	Mandatory for Class 2 and above	Business	Process
2.4.5.19	Where present, production software signing keys are under access control.	Mandatory for all classes	Business	Policy
2.4.5.20	The production software signing keys are stored and secured in a storage device compliant to FIPS-140-2/FIPS-140-3 level 2, or equivalent or higher standard.	Mandatory for Class 1 and above	Business	Policy
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.	Mandatory for Class 2 and above	System	Software
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.	Mandatory for all classes	Business	Policy
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.	Mandatory for Class 2 and above	Business	Process
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.	Mandatory for Class 2 and above	System	Software
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).	Advisory for all classes	System	Software
2.4.5.26	Support for partially downloading updates is provided for devices whose network access is limited or sporadic.	Advisory for all classes	System	Software
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).	Mandatory for all classes	System	Software
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.	Mandatory for all classes	System	Hardware Software
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.	Mandatory for all classes	System	Software
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.	Mandatory for all classes	System	Software
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.	Mandatory for Class 1 and above	Business	Policy
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]³.	Mandatory for Class 2 and above	System	Software
2.4.5.34	Any caches which potentially store sensitive material are cleared flushed after memory locations containing sensitive material have been sanitised.	Mandatory for Class 3 and above	System	Hardware Software
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.	Mandatory for all classes	Business	Policy
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.	Mandatory for all classes	Business	Policy
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.	Mandatory for Class 2 and above	Business	Policy
2.4.5.38	Maintenance changes should trigger full security regression testing.	Mandatory for Class 2 and above	Business	Policy
2.4.5.39	IoT devices must allow software updates to maintain security over the product lifetime.	Mandatory for Class 2 and above	Business	Policy
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.	Mandatory for all classes	Business	Policy
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.	Mandatory for Class 1 and above	Business	Policy

Enhanced Privacy standard for Anonymous Signatures ISO/IEC20008 [https://www.iso.org/standard/57018.html] ↩
Supply Chain of Trust by Hayden Povey of Secure Thingz and the IoTSF [http://www.newelectronics.co.uk/article-images/152099/P18-19.pdf] ↩
Examples of security vulnerability advisory programs: [https://www.us-cert.gov/report https://ics-cert.us-cert.gov/ICS-CERT-Vulnerability-Disclosure-Policy ] ↩

Footnotes​

Footnotes