V1: IoT Ecosystem Requirements

Control Objective

System security design performed before development, and a security process that continuously supports system development integrated into all phases of its life cycle, are necessary fundamentals for creating secure product architecture implementations. Iterative system threat modeling provides a means to prepare for malintent and develop mitigation plans as part of product design life cycles.

A secure development process ensures the identification and documentation of all sensitive information and functionality required for an IoT ecosystem, enforces all the security controls at the determined level, and ensures that end-users and customers get notified about vulnerabilities and that security solutions deliver on time. Ensure that sister OWASP verification standards, provided in the references section below, are incorporated as part of development processes.

The supply chain has vital importance for the security of every IoT product. A secure development process verifies that all security requirements for suppliers and third-party code implement controls with the appropriate security level and development-time features are not left on devices, exposing them to vulnerabilities.

To ensure the security of all software produced, the build process for the system software must be done in a secure build environment that verifies the integrity and authenticity of all components. The code must be written using best security practices and compiled using the best security options available.

System configuration changes must employ appropriate logging and monitoring capabilities to provide audit trails for security events. Attributes detailing events aid with investigations while overly verbose logs containing sensitive information introduce security risks.

Incident response planning is essential for IoT ecosystems to effectively detect, respond to, and recover from security compromises. Organizations must establish processes for handling device credential compromises and provide mechanisms for users to validate the legitimacy of connected devices.

A defined and openly communicated support lifecycle is equally important. By establishing a minimum security update period, providing security patches free of charge, and notifying users ahead of end-of-life, manufacturers enable users to make informed risk decisions and avoid operating devices that no longer receive security maintenance.

Security Verification Requirements

Application and Ecosystem Design

# Description L1 L2 L3
1.1.1 Verify that the IoT system is developed with the level of security (L1, L2, or L3) applicable to its capabilities and risks posed by the environment where it is deployed. ✓ ✓ ✓
1.1.2 Verify that all components and communication channels in the IoT ecosystem have been identified and are known to be needed. Remove or disable any that aren’t necessary. ✓ ✓ ✓
1.1.3 Verify that threat modeling is used as part of each product introduction design (i.e. new and mature) and security-relevant feature changes to identify likely threats and facilitate appropriate risk responses to guide security testing. ✓ ✓ ✓
1.1.4 Verify that security controls are enforced server-side and that data and instructions are not blindly trusted by server-side components. ✓ ✓ ✓
1.1.5 Verify that a responsible disclosure policy has been established and that it is easily found on the company website. Ensure that the policy provides a clear overview of how vulnerabilities can be communicated securely and how they’ll be followed up on. ✓ ✓ ✓
1.1.6 Verify that users and relevant stakeholders are informed when vulnerabilities affect products through established communication channels (website, e-mail, security advisory pages, changelogs, etc.). ✓ ✓ ✓

Supply Chain

# Description L1 L2 L3
1.2.1 Verify that each application (including firmware) in the ecosystem maintains a software bill of materials (SBOM) cataloging third-party components, versioning, and published vulnerabilities. ✓ ✓ ✓
1.2.2 Verify that potential areas of risk that come with the use of third-party and open-source software have been identified and that actions to mitigate such risks have been taken. ✓ ✓ ✓
1.2.3 Verify that devices are released with firmware configured with secure defaults appropriate for a release build (as opposed to debug versions). ✓ ✓ ✓
1.2.4 Verify that access to debugging interfaces (e.g. JTAG, SWD) is disabled or protected before shipping the device. Processors may refer to this as code protection, read back protection, CodeGuard, or access port protection.   ✓ ✓
1.2.5 Verify that debug capabilities in FPGAs are disabled on production PCBs.   ✓ ✓
1.2.6 Verify that devices are provisioned with a cryptographic root of trust that is hardware-based and immutable.   ✓ ✓
1.2.7 Verify that code integrity protection mechanisms are enabled and locked in hardware before shipping the device to customers. For example, ensure secure boot is enabled and the boot configuration locked.   ✓ ✓
1.2.8 Verify that third-party code and components are analyzed using static analysis tools to ensure backdoors are not introduced.   ✓ ✓
1.2.9 Verify that all components, including semiconductor drivers, SDKs, and modules (e.g. 5G, LTE, Bluetooth, Wi-Fi, ZigBee etc.) can be updated to provide security patches in alignment with the product’s support or end-of-life policy.   ✓ ✓

Secure Development

# Description L1 L2 L3
1.3.1 Verify that each application in the ecosystem is built using a secure and repeatable build environment. ✓ ✓ ✓
1.3.2 Verify that GPL-based firmware has its source code published and that no sensitive or proprietary information is accidentally included in the process. ✓ ✓ ✓
1.3.3 Verify that banned C/C++ functions (e.g. memcpy, strcpy, gets, etc.) are replaced with safe equivalents functions (e.g. Safe C, Safe Strings library).   ✓ ✓
1.3.4 Verify that packages are downloaded and built from trusted sources. ✓ ✓ ✓
1.3.5 Verify that build pipelines only perform builds of source code maintained in version control systems. ✓ ✓ ✓
1.3.6 Verify that compilers, version control clients, development utilities, and software development kits are analyzed and monitored for tampering, trojans, or malicious code. ✓ ✓ ✓
1.3.7 Verify that packages are compiled with Object Size Checking (OSC) (e.g. -D_FORTIFY_SOURCE=2).   ✓ ✓
1.3.8 Verify that packages are compiled with No eXecute (NX) or Data Execution Protection (DEP) (e.g. -z,noexecstack).   ✓ ✓
1.3.9 Verify that packages are compiled with Position Independent Executable (PIE) (e.g. -fPIE).   ✓ ✓
1.3.10 Verify that packages are compiled with Stack Smashing Protector (SSP) (e.g. -fstack-protector-all).   ✓ ✓
1.3.11 Verify that packages are compiled with read-only relocation (RELRO) (e.g. -Wl,-z,relro).   ✓ ✓
1.3.12 Verify that release builds do not contain debug code or privileged diagnostic functionality. ✓ ✓ ✓
1.3.13 Verify that debug and release firmware images are signed using different keys.   ✓ ✓
1.3.14 Verify that debug information does not contain sensitive information, such as PII, credentials or cryptographic material. ✓ ✓ ✓
1.3.15 Verify that embedded applications are not susceptible to OS command injection by performing input validation and escaping of parameters within firmware code, shell command wrappers, and scripts. ✓ ✓ ✓

Logging

# Description L1 L2 L3
1.4.1 Verify that devices can collect logs about events with security implications, such as successful and failed authentication attempts, access to debugging functionality etc.   ✓ ✓
1.4.2 Verify that collected logs have the adequate granularity to enable actionable insights and alerts. Logs should include, at a minimum, the type of event, timestamp, source, outcome, and identification of involved actors.   ✓ ✓
1.4.3 Verify that devices contain or are synchronized with a reliable time source, to ensure the validity of log timestamps.   ✓ ✓
1.4.4 Verify that collected logs do not include sensitive information, such as PII, credentials and cryptographic keys.   ✓ ✓
1.4.5 Verify that collected logs can be securely retrieved from the devices over an online collection, either periodically or on-demand.   ✓ ✓
1.4.6 Verify that collected logs are preserved for the amount of time required by organizational policies and that they are safely deleted when the retention period is over.   ✓ ✓
1.4.7 Verify that the confidentiality, integrity and authenticity of collected logs is appropriately protected, both on the devices that created them and on other systems that store or process them.   ✓ ✓

Incident Response

# Description L1 L2 L3
1.5.1 Verify that an incident response plan is established that addresses potential security compromises of IoT devices, including procedures for identifying, containing, and recovering from security incidents.   ✓ ✓
1.5.2 Verify that an appropriate response strategy is in place for when device credentials (especially root keys or cryptographic material that cannot be remotely updated) are compromised.   ✓ ✓
1.5.3 Verify that users or administrators can obtain an overview of connected and paired devices to validate their legitimacy (e.g., by comparing identifiers such as MAC addresses or serial numbers).   ✓ ✓

End-of-Life and Update Support Policy

# Description L1 L2 L3
1.6.1 Verify that the manufacturer has defined and publicly disclosed a minimum security update support period for the product, including the end date of that period, and that this information is communicated to users in plain language at or before the point of purchase. ✓ ✓ ✓
1.6.2 Verify that users are notified when a product reaches the end of its security update support period, and that the notification states the date after which security updates will cease. Where technically feasible, this notification is provided in advance of that date and identifies any available migration paths or compensating controls. ✓ ✓ ✓
1.6.3 Verify that security updates are provided to users at no additional cost throughout the declared support period. ✓ ✓ ✓
1.6.4 Verify that security updates addressing critical and high-severity vulnerabilities can be delivered independently of feature or functional updates, so that users can apply security fixes without being required to accept unrelated changes.   ✓ ✓

References

For more information, see also: