I1 Weak, Guessable, or Hardcoded Passwords
I3 Insecure Ecosystem Interfaces
I9 Insecure Default Settings
I4 Lack of Secure Update Mechanism
I5 Use of Insecure or Outdated Components
I2 Insecure Network Services
I7 Insecure Data Transfer and Storage
I3 Insecure Ecosystem Interfaces
I7 Insecure Data Transfer and Storage
I1 Weak, Guessable, or Hardcoded Passwords
I3 Insecure Ecosystem Interfaces
I3 Insecure Ecosystem Interfaces
I7 Insecure Data Transfer and Storage
I2 Insecure Network Services
I7 Insecure Data Transfer and Storage
I2 Insecure Network Services
I7 Insecure Data Transfer and Storage
I2 Insecure Network Services
I3 Insecure Ecosystem Interfaces
I8 Lack of Device Management
I6 Insufficient Privacy Protection
I8 Lack of Device Management
I2 Insecure Network Services
I9 Insecure Default Settings
I3 Insecure Ecosystem Interfaces
I10 Lack of Physical Hardening
I1 Weak, Guessable, or Hardcoded Passwords
I9 Insecure Default Settings
I1 Weak, Guessable, or Hardcoded Passwords
I9 Insecure Default Settings
I7 Insecure Data Transfer and Storage
I9 Insecure Default Settings
I2 Insecure Network Services
I3 Insecure Ecosystem Interfaces
I7 Insecure Data Transfer and Storage
I1 Weak, Guessable, or Hardcoded Passwords
I3 Insecure Ecosystem Interfaces
I3 Insecure Ecosystem Interfaces
I6 Insufficient Privacy Protection
I5 Use of Insecure or Outdated Components
I9 Insecure Default Settings
I9 Insecure Default Settings
I10 Lack of Physical Hardening
I7 Insecure Data Transfer and Storage
I9 Insecure Default Settings
I10 I10 Lack of Physical Hardening
I3 Insecure Ecosystem Interfaces
I9 Insecure Default Settings
I2 Insecure Network Services
I3 Insecure Ecosystem Interfaces
I9 Insecure Default Settings
I5 Use of Insecure or Outdated Components
I10 Lack of Physical Hardening
I4 Lack of Secure Update Mechanism
I8 Lack of Device Management
I1 Weak, Guessable, or Hardcoded Passwords
I7 Insecure Data Transfer and Storage
| | **5. Communicate securely** | Security-sensitive data, including any remote management and control, should be encrypted in transit, appropriate to the properties of the technology and usage. All keys should be managed securely. |I3 Insecure Ecosystem Interfaces
I7 Insecure Data Transfer and Storage
I2 Insecure Network Services
I5 Use of Insecure or Outdated Components
I9 Insecure Default Settings
I10 Lack of Physical Hardening
I8 Lack of Device Management
I9 Insecure Default Settings
I8 Lack of Device Management
I9 Insecure Default Settings
GP-PS-01: Consider the security of the whole IoT system from a consistent and holistic approach during its whole lifecycle across all levels of device/application design and development, integrating security throughout the development, manufacture, and deployment.
GP-PS-02: Ensure the ability to integrate different security policies and techniques.
GP-PS-03: Security must consider the risk posed to human safety.
GP-PS-04: Designing for power conservation should not compromise security.
GP-PS-05: Design architecture by compartments to encapsulate elements in case of attacks.
GP-PS-06: For IoT hardware manufacturers and IoT software developers it is necessary to implement test
plans to verify whether the product performs as it is expected. Penetration tests help to identify
malformed input handling, authentication bypass attempts and overall security posture.
GP-PS-07: For IoT software developers it is important to conduct code review during implementation as
it helps to reduce bugs in a final version of a product.
GP-PS-08: Make privacy an integral part of the system.
GP-PS-09: Perform privacy impact assessments before any new applications are launched.
GP-PS-11: Identify significant risks using a defence-in-depth approach.
GP-PS-12: Identify the intended use and environment of a given IoT device.
GP-OP-01: Develop an end-of-life strategy for IoT products.
GP-OP-02: Disclose the duration and end-of-life security and patch support (beyond product warranty).
GP-OP-03: Monitor the performance and patch known vulnerabilities up until the “end-of-support" period of a product’s lifecycle.
GP-OP-04: Use proven solutions, i.e. well known communications protocols and cryptographic algorithms, recognized by the scientific community, etc. Certain proprietary solutions, such as custom cryptographic algorithms, should be avoided.
GP-OP-05: Establish procedures for analysing and handling security incidents.
GP-OP-06: Coordinated disclosure of vulnerabilities.
GP-OP-07: Participate in information-sharing platforms to report vulnerabilities and receive timely and critical information about current cyber threats and vulnerabilities from public and private partners.
GP-OP-08: Create a publicly disclosed mechanism for vulnerability reports, e.g. Bug Bounty programs.
GP-OP-09: Ensure the personnel practices promote privacy and security – train employees in good privacy and security practices.
GP-OP-10: Document and monitor the privacy and security training activities.
GP-OP-11: Ensure that cybersecurity roles and responsibilities for all workforce are established and introduce personnel assignments in accordance with the specifics of the projects and security engineering needs.
GP-OP-12: Data processed by a third-party must be protected by a data processing agreement.
GP-OP-13: Only share consumers’ personal data with third parties with express consent of the consumers, unless otherwise required and limited for the use of product features or service operations.
GP-OP-14: For IoT hardware manufacturers and IoT software developers it is necessary to adopt cyber supply chain risk management policies and to communicate cyber security requirements to its suppliers
and partners.
GP-TM-01: Employ a hardware-based immutable root of trust.
GP-TM-02: Use hardware that incorporates security features to strengthen the protection and integrity
of the device – for example, specialised security chips / coprocessors that integrate security at the transistor level, embedded in the processor, providing, among other things, a trusted storage of device identity and authentication means, protection of keys at rest and in use, and preventing unprivileged from accessing to security sensitive code. Protection against local and physical attacks can be covered via functional security.
GP-TM-03: Trust must be established in the boot environment before any trust in any other software or executable program can be claimed.
GP-TM-04: Sign code cryptographically to ensure it has not been tampered with after signing it as safe for the device, and implement run-time protection and secure execution monitoring to make sure malicious attacks do not overwrite code after it is loaded.
GP-TM-05: Control the installation of software in operating systems, to prevent unauthenticated software and files from being loaded onto it.
GP-TM-06: Enable a system to return to a state that was known to be secure, after a security breach has occured or if an upgrade has not been successful.
GP-TM-07: Use protocols and mechanisms able to represent and manage trust and trust relationships.
I4 Lack of Secure Update Mechanism
I8 Lack of Device Management
I9 Insecure Default Settings
GP-TM-08: Any applicable security features should be enabled by default, and any unused or insecure functionalities should be disabled by default.
GP-TM-09: Establish hard to crack, device-individual default passwords.
I1 Weak, Guessable, or Hardcoded Passwords
I9 Insecure Default Settings
GP-TM-10: Personal data must be collected and processed fairly and lawfully, it should never be collected and processed without the data subject’s consent.
GP-TM-11: Make sure that personal data is used for the specified purposes for which they were collected, and that any further processing of personal data is compatible and that the data subjects are well informed.
GP-TM-12: Minimise the data collected and retained.
GP-TM-13: IoT stakeholders must be compliant with the EU General Data Protection Regulation (GDPR).
GP-TM-14: Users of IoT products and services must be able to exercise their rights to information, access,
erasure, rectification, data portability, restriction of processing, objection to processing, and their right not to be evaluated on the basis of automated processing.
GP-TM-15: Design with system and operational disruption in mind, preventing the system from causing an unacceptable risk of injury or physical damage.
GP-TM-16: Mechanisms for self-diagnosis and self-repair/healing to recover from failure, malfunction or a compromised state.
GP-TM-17: Ensure standalone operation - essential features should continue to work with a loss of communications and chronicle negative impacts from compromised devices or cloud-based systems.
GP-TM-18: Ensure that the device software/firmware, its configuration and its applications have the ability to update Over-The-Air (OTA), that the update server is secure, that the update file is transmitted via a secure connection, that it does not contain sensitive data (e.g. hardcoded credentials), that it is signed by an authorised trust entity and encrypted using accepted encryption methods, and that the update package has its digital signature, signing certificate and signing certificate chain, verified by the device before the update process begins.
GP-TM-19: Offer an automatic firmware update mechanism.
GP-TM-20: Backward compatibility of firmware updates. Automatic firmware updates should not modify
user-configured preferences, security, and/or privacy settings without user notification.
I1 Weak, Guessable, or Hardcoded Passwords
I4 Lack of Secure Update Mechanism
I8 Lack of Device Management
GP-TM-21: Design the authentication and authorisation schemes (unique per device) based on the system-level threat models.
GP-TM-22: Ensure that default passwords and even default usernames are changed during the initial setup, and that weak, null or blank passwords are not allowed.
GP-TM-23: Authentication mechanisms must use strong passwords or personal identification numbers (PINs), and should consider using two-factor authentication (2FA) or multi-factor authentication (MFA) like Smartphones, Biometrics, etc., on top of certificates.
GP-TM-24: Authentication credentials shall be salted, hashed and/or encrypted.
GP-TM-25: Protect against ‘brute force’ and/or other abusive login attempts. This protection should also
consider keys stored in devices.
GP-TM-26: Ensure password recovery or reset mechanism is robust and does not supply an attacker with
information indicating a valid account. The same applies to key update and recovery mechanisms.
I1 Weak, Guessable, or Hardcoded Passwords
I3 Insecure Ecosystem Interfaces
GP-TM-27: Limit the actions allowed for a given system by Implementing fine-grained authorisation mechanisms and using the Principle of least privilege (POLP): applications must operate at the lowest privilege level possible.
GP-TM-28: Device firmware should be designed to isolate privileged code, processes and data from portions of the firmware that do not need access to them. Device hardware should provide isolation concepts to prevent unprivileged from accessing security sensitive code.
I1 Weak, Guessable, or Hardcoded Passwords
I9 Insecure Default Settings
GP-TM-29: Data integrity and confidentiality must be enforced by access controls. When the subject requesting access has been authorised to access particular processes, it is necessary to enforce the defined security policy.
GP-TM-30: Ensure a context-based security and privacy that reflects different levels of importance.
GP-TM-31: Measures for tamper protection and detection. Detection and reaction to hardware tampering should not rely on network connectivity.
GP-TM-32: Ensure that the device cannot be easily disassembled and that the data storage medium is encrypted at rest and cannot be easily removed.
GP-TM-33: Ensure that devices only feature the essential physical external ports (such as USB) necessary for them to function and that the test/debug modes are secure, so they cannot be used to maliciously access the devices. In general, lock down physical ports to only trusted connections.
I1 Weak, Guessable, or Hardcoded Passwords
I3 Insecure Ecosystem Interfaces
I6 Insufficient Privacy Protection
I10 Lack of Physical Hardening
GP-TM-34: Ensure a proper and effective use of cryptography to protect the confidentiality, authenticity and/or integrity of data and information (including control messages), in transit and in rest. Ensure the proper selection of standard and strong encryption algorithms and strong keys, and disable insecure protocols. Verify the robustness of the implementation.
GP-TM-35: Cryptographic keys must be securely managed.
GP-TM-36: Build devices to be compatible with lightweight encryption and security techniques.
GP-TM-37: Support scalable key management schemes.
GP-TM-38: Guarantee the different security aspects -confidentiality (privacy), integrity, availability and authenticity- of the information in transit on the networks or stored in the IoT application or in the Cloud.
GP-TM-39: Ensure that communication security is provided using state-of-the-art, standardised security protocols, such as TLS for encryption.
GP-TM-40: Ensure credentials are not exposed in internal or external network traffic.
GP-TM-41: Guarantee data authenticity to enable reliable exchanges from data emission to data reception. Data should always be signed whenever and wherever it is captured and stored.
GP-TM-42: Do not trust data received and always verify any interconnections. Discover, identify and verify/authenticate the devices connected to the network before trust can be established, and preserve their integrity for reliable solutions and services.
GP-TM-43: IoT devices should be restrictive rather than permissive in communicating.
GP-TM-44: Make intentional connections. Prevent unauthorised connections to it or other devices the product is connected to, at all levels of the protocols.
GP-TM-45: Disable specific ports and/or network connections for selective connectivity.
GP-TM-46: Rate limiting. Controlling the traffic sent or received by a network to reduce the risk of automated attacks.
I2 Insecure Network Services
I3 Insecure Ecosystem Interfaces
I7 Insecure Data Transfer and Storage
GP-TM-47: Risk Segmentation. Splitting network elements into separate components to help isolate security breaches and minimise the overall risk.
GP-TM-48: Protocols should be designed to ensure that, if a single device is compromised, it does not affect the whole set.
GP-TM-49: Avoid provisioning the same secret key in an entire product family, since compromising a single device would be enough to expose the rest of the product family.
GP-TM-50: Ensure only necessary ports are exposed and available.
GP-TM-51: Implement a DDoS-resistant and Load-Balancing infrastructure.
GP-TM-52: Ensure web interfaces fully encrypt the user session, from the device to the backend services,
and that they are not susceptible to XSS, CSRF, SQL injection, etc.
GP-TM-53: Avoid security issues when designing error messages.
I2 Insecure Network Services
I3 Insecure Ecosystem Interfaces
GP-TM-54: Data input validation (ensuring that data is safe prior to use) and output filtering.
GP-TM-56: Implement regular monitoring to verify the device behaviour, to detect malware and to discover integrity errors.
GP-TM-57: Conduct periodic audits and reviews of security controls to ensure that the controls are effective. Perform penetration tests at least biannually.
CTIA Cybersecurity Certification Test Plan
for IoT Devices
Device Terms of Service and privacy policy are readily
available. The Terms of Service cover “end of life” for the device.
I1 Weak, Guessable, or Hardcoded Passwords
I3 Insecure Ecosystem Interfaces
I9 Insecure Default Settings
Device supports automatic and manual installation of patches from an
authorized source.
I4 Lack of Secure Update Mechanism
I5 Use of Insecure or Outdated Components
Device supports manual installation software upgrades from an authorized
source.
I4 Lack of Secure Update Mechanism
I5 Use of Insecure or Outdated Components
Device supports the gathering audit log events and reporting them to an EMS using
IPsec, SSH, TLS, or DTLS for encryption and integrity protection.
Device supports logging of anomalous or malicious activity based on
configured polices and rules.
Device supports generation and validation of digital
signatures
Device supports an effective mechanism for encrypting data stored on
the device.
I2 Insecure Network Services
I3 Insecure Ecosystem Interfaces
I9 Insecure Default Settings
RSM-01
RSM-02
Adopt a standardized industry recognized risk management approach. Baseline security requirements should be established for developed or acquired IoT components to comply with applicable legal, statutory, and regulatory compliance obligations. Deviations from standard baseline configurations should be authorized following change management policies and procedures prior to deployment, provisioning, or use. Compliance with security baseline requirements should be reassessed based on business needs.
"Perform a risk assessment. Analyze sources, storage and transmissions of sensitive data across devices, gateways, applications, data stores, mobile applications, cloud services, fog computing services and network infrastructure. Analyze data classification mechanisms and data security capabilities to protect sensitive data from unauthorized use, access, loss, destruction, and falsification. Analyze the potential for trusted insiders to misuse their privileged access to data. Analyze data retention periods and end-of-life disposal requirements. Identify safety risks. Prioritize risks based on impact and likelihood. Decide on risk migitations for each risk - mitigate, defer or accept the risk.
Perform a risk assessment as follows:
•Analyze potential risk if the security of each of the following components would be compromised: sources, storage and transmissions of sensitive data across devices, gateways, applications, data stores, mobile applications, cloud services, fog computing services and network infrastructure.
•Analyze data classification mechanisms and data security capabilities in order to protect sensitive data from unauthorized use, access, loss, destruction or falsification.
•Analyze the potential for trusted insiders to misuse their privileged access to data.
•Analyze data retention periods and end-of-life disposal requirements.
•Based on these analyses, identify your organization’s safety risks. Prioritize these risks based on potential impact and likelihood of occurrence.
•Choose and implement risk mitigations for each potential security threat: actively mitigate, defer or accept the risk."
TSP-01
TSP-02
TSP-03
TSP-04
TSP-05
TSP-06
TSP-07
TSP-08
Document an enterprise IoT cyber security policy. Require all IoT implementations to comply with this policy or apply for an exception. Your enterprise IoT cyber security policy should include, at minimum, encryption, monitoring, auditing, authentication and access control, as well as physical security controls that must be applied to each component of your IoT system. Monitor frequently to identify out-of-compliance implementations.
Monitor and validate the update (patch/version) status of each IoT device in your inventory. Flag devices that are out of policy or are unreachable due to disconnection. If the issue cannot be resolved (connection and update) through the IoT system, then an email, call or personal visit may be required, depending on the criticality of update and device use.
Monitor for duplicate or compromised IoT devices. Establish rules to identify devices authenticating with the same identity credentials, which may indicate a security compromise. Investigate and remediate issues upon detection.
Document a minimum cryptographic policy for TLS, DTLS and other cryptographic protocols. The policy should define acceptable algorithms, key lengths and modes of operation. Align the policy with guidance from the latest revision of NIST SP 800-131A.
Document password policies that define minimum complexity requirements for IoT system users, administrators and service accounts. Define aging requirements for passwords. Define lock-out policies for all components of the IoT system.
Document a data security policy for the IoT system. Define the organizational data classification levels and map minimum data security requirements to those classification levels.
Document an identity management policy for the IoT system. Define appropriate uses for symmetric keys, passwords and certificates. Restrict the provision of duplicate identity credentials (keys, certificates, passwords) to no more than one device, user or service.
Document a device security management policy for the IoT system. Define the minimum frequency for performing updates to firmware and software. Define minimum safeguards against malicious code that could compromise IoT devices. Define minimum frequency for applying patches to third party libraries.
I1 Weak, Guessable, or Hardcoded Passwords
I8 Lack of Device Management
| | | | | | | | | |GVN-01
GVN-02
GVN-03
GVN-04
GVN-05
Create a governance framework for the IoT system. Define who is accountable for the security of distributed systems and their interconnection to cloud and other data services. Identify executive leaders responsible for each individual system, and define the specific responsibilities for securing those systems. Identify and document the roles and responsibilities of employees and third party users for protecting data and assets within your IoT systems.
Document all standards, as well as regulatory, legal and statutory requirements relevant to your IoT system. Communicate the impact of these requirements to individual IoT system owners.
Perform independent security assessments of IoT inventory at least annually to ensure the organization addresses nonconformities of established policies, standards, procedures, and compliance obligations.
Audit user, administrator, service and device accounts within the IoT system at least annually. Take action to disable any accounts that are determined to be unnecessary, unauthorized and expired.
Establish procedures to cleanse data as it moves from the Production environment to the DEV/QA environment in order to reduce the risk of replicating sensitive operational information to the DEV/QA environment when debugging is required.
PRV-01
PRV-02
PRV-03
PRV-04
PRV-05
Implement and enforce technical and policy mechanisms to restrict administrator ability to track location or other sensitive attributes of system users. Implement access controls and logging procedures to prevent insiders from disabling these controls without the system logging the event.
Perform a privacy assessment of the Public Key Infrastructure (PKI) that issues credentials to IoT devices and services. Analyze the potential for tracking of user locations and activities based on correlation to the issued PKI certificates. If determined that a privacy concern exists, implement anonymity mechanisms within the PKI such as Location
Obscurer Proxies and Pseudonym Certificate Authorities.
Perform an analysis to document metadata generated by the IoT system. Classify metadata based on sensitivity level. Monitor for leaked metadata classified as sensitive, and define actions for remediating leaks when discovered.
Perform a privacy impact assessment (PIA) at the onset of new device development. Subjects covered during the PIA will include at a minimum: deletion of data from a device; mechanism used to inform users of the data collected; obtaining and storing consent from users authorizing the use of data; the means for providing users access to review and edit personal data before it is transferred; and notice concerning the timing and frequency of data collection; as well as the ability for users to opt-in to data sharing.
Update privacy impact assessment (PIA) annually. Communicate key findings of the PIA to all system administrators. Track compliance with PIA results on a continuous basis.
SCN-01
SCN-02
SCN-03
SCN-04
SCN-05
SCN-06
SCN-07
SCN-08
SCN-09
SCN-10
SCN-11
Whenever passwords are used within an IoT system, evaluate whether certificates can be used instead. When possible, update systems to require certificates for authentication instead of passwords.
Authentication credentials can be bound to the specific application authorized to make use of those credentials when using IEEE 1609.2 certificates for IoT devices. If using IEEE 1609.2 certificates, designate an application-unique identifier and use within the IEEE 1609.2 SSP/PSID bits. Validate the SSP/PSID fields when making authorization decisions.
Document all IoT device configuration files. Digitally sign those files and store them in a secure repository. Use these digitally signed files to restore devices. Validate the digital signature of the file after provisioning to the device.
Restrict access to IoT device configuration files. Require pseudo access to modify configuration files on IoT devices.
Log all changes to configuration files. Log all access attempts to modify configuration files. Monitor continuously and audit on a regular basis.
Minimize privileged operations that run as root and do not run network services (e.g., web servers) as root.
Implement IoT system role-based access control (RBAC). Include standard roles for users, services and devices (e.g. device, local user, system operator, auditor, application, gateway).
Identify privileged operations within the IoT system. Establish elevated roles mapped to those privileged operations. Roles may include trusted device, privileged local user, system administrator, trusted application, and trusted gateway.
Implement an audit user group responsible for managing audit log data, including reviewing and rotating data off of devices. Restrict read access of security logs to this audit group. Provision audit group members with read access, but do not provide write privileges to any audit logs.
Implement additional authorization procedures when warranted, such as geofencing systems and time-of-day restrictions.
Implement authenticated discovery services. Authenticate all service discovery queries and drop requests that fail authentication.
I1 Weak, Guessable, or Hardcoded Passwords
I3 Insecure Ecosystem Interfaces
SDV-01
SDV-02
SDV-03
SDV-04
SDV-05
SDV-06
SDV-07
SDV-08
SDV-09
SDV-10
SDV-11
SDV-12
SDV-13
SDV-14
SDV-15
SDV-16
SDV-17
SDV-18
Adopt a software assurance maturity model (SAMM) to establish a secure development lifecycle for all developed IoT devices and components (e.g. OpenSAMM).
Select an IoT integration framework to standardize secure on-boarding, configuration management, asset management, discovery and secure connectivity across newly developed IoT devices.
Enforce the concept of least privilege. Limit applications and services that run as root and require authentication for all access. Do not run network services (e.g. web servers) as root.
Establish good password processes. Do not hardcode passwords into the device and do not provision duplicate identities or passwords across multiple devices. Require password changes on a regular basis.
Establish responsible disclosure policies and procedures and implement feedback loops to update product backlogs when a security vulnerability is identified or reported. Work with independent testers that report vulnerabilities to ensure the vulnerability is closed.
Integrate chip-to-cloud capabilities that leverage microcontrollers (MCUs) with pre-provisioned cloud trust anchors to support more secure bootstrap and zero-touch provisioning of IoT devices. Use secure MCU hardware features to protect sensitive material and cryptographic primitives and to perform trusted bootloading by validating software prior to booting.
Use cryptographic coprocessors to offload CPU-intensive cryptographic operations. Design IoT products with cryptographic agility to support updates to algorithms and key sizes as existing approaches become obsolete. Make use of well-tested cryptographic modules (ideally FIPS (140-2
Eliminate or lock-down unnecessary hardware features of IoT devices (e.g. un-needed radios or USB interfaces). Disable or password-restrict any test interfaces (JTAG, UART, GPIO).
Apply tamper protection for security-critical components of the IoT device ranging from simple seals and/or locked covers to piezo-electric circuits depending on the threat environment.
Select a device real-time operating system (RTOS) that provides enhanced security features, such as application sandboxing, secure boot, access controls, trusted execution environment, kernel separation, and a (minimized) microkernel.
Do not store API keys and other credentials in public-facing source control systems (e.g. gitlab/github). Publish procedures for the secure handling of API keys. Do not hardcode API keys into firmware, mobile applications, or any client-based application. Monitor at least quarterly to verify that API keys and other credentials are not stored in public-facing source control systems.
Integrate MCUs with hardware-based separation architectures for higher assurance requirements. Label and operate security sensitive applications to run in the trusted side of the hardware only. Implement limited command interfaces between the trusted and untrusted components of the MCU. Configure the device to perform attestation of software (measure the security state of the software) prior to entering into trusted modes and use controlled execution to prevent timing delays from revealing sensitive information.
Implement tamper-response mechanisms such as zeroization of key material and other sensitive data when warranted by the threat landscape.
Select a device RTOS that is certified for use in specific industries, such as air travel and other transportation systems, industrial control systems, medical devices.
Establish supply chain practices. For example, subscribe to security alerts from all third party components and frameworks. Review updates immediately for proposed deployment.
Use static and dynamic analysis tools to validate the security of all third party libraries.
Validate the authenticity and integrity of all third party libraries and software components within an IoT system.
Develop web services in accordance with OWASP (
I1 Weak, Guessable, or Hardcoded Passwords
I3 Insecure Ecosystem Interfaces
I10 Lack of Physical Hardening
SNT-01
SNT-02
SNT-03
SNT-04
SNT-05
SNT-06
SNT-07
SNT-08
SNT-09
SNT-10
SNT-11
SNT-12
SNT-13
SNT-14
SNT-15
SNT-16
SNT-17
SNT-18
Disable non-authenticated Bluetooth pairing procedures (e.g., JustWorks).
Audit the security of bluetooth implementations using the bluetooth security checklist found in Section 4.4 of the NIST SP.800-121r2 (
Task network security tools to search for new botnet activity, and immediately remove infected IoT devices upon detection. Keep up to date on botnet characteristics using the CSA IoTWG botnet tracker (
Securely configure all supporting software and infrastructure (e.g., web servers, mobile applications, cloud services) supporting the IoT system. Refer to specific secure configuration guidance for your system implementation.
Configure whitelists between IoT devices, gateways and servers. Provision certificates to enable TLS or DTLS-based authentication for all MQTT and HTTP interactions with backend computing devices.
Establish procedures for monitoring misbehavior and revoking credentials when a server/gateway is suspected of being compromised.
Establish a security plan for mobile applications. Ensure mobile devices receive updates from approved/trusted repositories. Require the use of only approved mobile devices for managing IoT devices. Ensure that mobile devices store identity/key material in hardware-backed secure storage locations (e.g. Android KeyChain/KeyStore and iOS KeyChain).
Install Near Field Communication (NFC) technology devices in locations that do not lend themselves to installation of sniffers in close proximity. Establish physical security protection measures (e.g. cameras/guards) to monitor access to these devices.
Configure a Software-Defined Perimeter (SDP) that authenticates IoT devices prior to connection to a network, and restricts activities based on pre-approved roles and privileges.
Use a network visualization tool to monitor the operating state and health status of IoT devices, gateways and services. Use simple heartbeat monitoring to monitor device connectivity or SNMPv3 traps for monitoring CPU utilization, memory, and other abnormal behaviors.
Define physical boundaries for WSNs and limit the power rating of ZigBee and ZWave devices to minimize signal leakage.
Set up Wireless Sensor Networks (WSN), such as ZigBee, ZWave and Bluetooth, to be disconnected from the Internet with only authorized gateways exposing internet connectivity.
At least quarterly, scan the physical environment to look for anomalies, such as radiofrequency (RF) attacks and rogue device insertion.
Require all communications with an IoT device to be initiated by the device. Log and alert about unauthorized connection requests
Disable the default ZigBee Trust Center (TC) key and generate/use a non-default key for protecting the confidentiality of keys in transport.
Distribute ZigBee Master Keys out of band. Never pass master keys over the network. Master keys are used to establish additional key material.
Rotate ZigBee Network Keys at least annually, and disable prior keys upon distribution/establishment of the new network key.
Supplement Z-Wave networks with AES 128 cryptographic keys for authentication. Use these keys in addition to the standard 4-byte Home ID to access a Z-Wave network.
OPA-01
OPA-02
OPA-03
OPA-04
OPA-05
OPA-06
OPA-07
OPA-08
OPA-09
OPA-10
OPA-11
OPA-12
Create maintenance plans to routinely inspect and maintain IoT hardware. Keep parts in inventory for repairing and replacing IoT devices immediately upon detection of a problem.
Use predictive maintenance analysis to calculate expected performance issues or breakdowns in IoT systems. Implement preventive solutions based on this analysis.
Set up cloud services to support regional failover of nodes and gateways. Test annually to ensure that failover is automatic in the event that a single region goes offline.
Set up monitoring procedures to identify and alert on abnormally heavy traffic transmitted from IoT devices, which may indicate a security compromise. Configure cloud services to automatically rate limit connections from clients upon detection to guard against potential DDoS attacks.
Work with Cloud Service Providers (CSPs) to define Service Level Agreements (SLAs) for uptime percentages and response timing (for incidents/patches). Hold CSPs accountable for any breaches of a SLA.
Store configurations of IoT devices in the cloud. Configure digital twins, device shadows, etc. in order to support interfacing to device logic even when the physical device is disconnected. At least annually, test that you can update device configurations while IoT hardware is offline by taking the device offline, transmitting a configuration change command, and then bringing the device back online.
Set up Wireless Sensor Network (WSN) gateways in a cluster formation to better handle heavy load and support failover in the event a single gateway goes offline. Configure IoT nodes to contact backup gateways when a primary gateway fails. At least annually, test failover capabilities and load shedding/distribution capabilities.
Set up metropolitan-scale Wireless Sensor Network deployments using clusters of nodes deployed to geographic regions in order to minimize points of interconnection and reduce long-haul traffic.
Deploy network monitoring tools and monitor IoT networks for congestion. Establish prioritized traffic flows (e.g. differentiated services) and execute dynamic rerouting (e.g. WSN/SDN) upon detection of congested communications.
Cache messaging at gateways for at least 1 day (or more, depending on your environment) to ensure availability of messaging should IoT nodes be offline.
Scan geographic areas for jammers attempting to suppress Radio Frequency (RF) communications. Execute incident response plans when detecting such an event.
Monitor IoT node power levels by configuring nodes to alert on battery drainage. This may help combat attacks aimed at draining the energy from critical routing nodes in
WSN architectures. Investigate any discovered incidents associated with excess battery drainage.
I3 Insecure Ecosystem Interfaces
I8 Lack of Device Management
ACT-01
ACT-02
ACT-03
ACT-04
ACT-05
Deploy an inventory management system and record details about each IoT device in inventory. Use this inventory management system to track the version of each IoT device, including firmware and patch status; RTOS version/image version; application/library versions; lost or decommissioned status; to whom devices are assigned; and location of devices.
Monitor devices to identify those out of compliance with organizational policy and require updates or patches.
If possible, implement an online database to automatically update changes to your IoT asset/inventory database. If automation of this process is not possible, schedule the task at a minimum quarterly.
Establish naming conventions for your IoT devices, and configure unique identifiers to each device. Identifiers should be unique across the enterprise and designed in a manner that will allow further incorporation of large quantities of additional devices at a later time without naming conflicts (e.g. during mergers/acquisitions).
Use unique identifiers to track devices across their lifecycles and as the basis for provisioning cryptographic identities/certificates.
CMP-01
CMP-02
CMP-03
CMP-04
CMP-05
Acquire IoT devices that integrate hardware security mechanisms and use hardware roots of trust for storage of cryptographic material and to secure operation of cryptographic functions, including secure boot and firmware signature validation.
For devices not capable of implementing hardware-based security, use software security mechanisms to protect key material and cryptographic functions.
Evaluate legacy IoT devices annually for technology upgrades. Legacy devices that do not support hardware security roots-of-trust should be replaced as soon as possible. In the interim, use gateway security mechanisms to extend the security boundary and to mitigate risks exposed by these legacy devices.
Require that all gateways use a FIPS 140-2-validated (
Acquire IoT products that have undergone testing and received a device security certification that is applicable to your legal, statutory, and regulatory compliance obligations. Device certification can vary by industry, environment, usage, and other critical applications.
TMM-01
TMM-02
TMM-03
TMM-04
TMM-05
Conduct threat modeling at the onset of any device or system development. Use a standardized approach to threat modeling that includes identifying components, data flows, and high-value code. Define the threats, prioritize (e.g. rate) the threats, and identify mitigations. Communicate the outputs of your threat model into the system requirements backlog, and track these requirements to completion across the lifecycle of the product or system.
Validate security requirements by creating security tests and performing those tests on each product or system release.
Identify threat intelligence feeds applicable to your specific industry. Maintain an understanding of the types of attackers that typically target your systems, and their motivations.
Monitor for newly identified vulnerabilities in your products, including in product dependencies. Monitor for newly released patches from your suppliers.
Monitor for new botnets targeting IoT devices, and communicate relevant characteristics (ports/services) to network security teams immediately so they may take action.
I3 Insecure Ecosystem Interfaces
I5 Use of Insecure or Outdated Components
IMT-01
IMT-02
Document all audit mechanisms. Verify that only assigned audit group members are able to read audit logs and that no user is able to write to these logs. Ensure offloading of audit log data (e.g. from device to cloud or gateway) is integrity-protected (e.g. HMAC or digital signature) and that the integrity protection is maintained with the log during long-term storage. In all cases, validate the integrity of log files prior to review.
Establish an IoT Incident Management Plan. Identify business and technical Points of Contact (PoCs) for each IoT system and inform them of what their roles and responsibilities are in the event of a security incident. Define the roles of third party organizations in incident responses (e.g. vendors and service providers). Define a chain-of-custody for log/audit data captured from devices. Define and establish escalation procedures and forensics activities that must be performed on devices. Consider acquiring automated forensics capabilities in real-time from networked devices.
I8 Lack of Device Management
I10 Lack of Physical Hardening
MSU-01
MSU-02
MSU-03
MSU-04
MSU-05
MSU-06
Define misuse patterns and establish policies for revoking credentials. Implement procedures for reporting and adjudicating misbehavior. Establish and implement procedures for revoking credentials within one day of de-authorization.
Employ analytics tools that in near-real-time gather and analyze device use and data streams about device misuse.
Define all security-relevant events, including elevation of privilege attempts; successful/unsuccessful firmware update events; configuration changes to IoT devices and service software; account modifications; and tamper events. Monitor for these and other relevant security events across your entire IoT system, including any devices; cloud services; mobile or network services; and storage systems. Define thresholds for each type of security event and trigger investigations when thresholds are exceeded.
Log every failed remote access attempt (SSH, Web, etc.). Create a process that automatically alerts a security administrator upon detection of five sequential invalid attempts in a 30-minute period.
Automatically transmit security event data to the cloud for storage and analysis. Record at minimum the initiator, receiver, timestamp, data and event type.
Establish an enterprise IoT wireless detection capability. Actively search for rogue wireless devices operating within your locations. Actively search for network communications to well-known botnet C2C addresses/ports. Actively search for unauthorized communications to vendor IP addresses. Immediately disable any identified devices/communications and investigate the cause of the infraction. Implement a system that will alert users when unintended violations occur.
SOP-01
SOP-02
SOP-03
Evaluate the safety impacts of an IoT system, log all safety risks, prioritize these risks, and implement mitigations for each risk. Incorporate device and environmental controls to enforce safety requirements.
Conduct fault tree analysis (FTA) to identify and prioritize safety risks associated with your IoT system.
Design and implement an enterprise logging capability. Protect the integrity of all logs from generation to storage in order to enable a chain of custody.
CLS-01
CLS-02
CLS-03
CLS-04
CLS-05
CLS-06
CLS-07
CLS-08
CLS-09
CLS-10
CLS-11
CLS-12
CLS-13
CLS-14
CLS-15
Provision unique identities to all cloud servers. Require servers to authenticate to each other and to all gateways.
Configure cloud gateways to accept communications from only trusted devices and to require encrypted communications. Document authorized ports and protocols on cloud gateways, and disable non-authorized ports/protocols. Blacklist any unauthorized device that attempts to communicate with your system, and log and report the action to an administrator.
Configure gateways to close connection to the cloud upon completion of communications and to initiate new connection when they need to send data again.
Work with Cloud Service Providers (CSPs) to ensure the data processed within their cloud meets privacy guidelines that are applicable to your legal, statutory, and regulatory compliance obligations. Consider implementing privacy by design principles before migrating data to the CSP allowing data owners to recover and retain data control (in case of SLA breach by Cloud Provider).
Configure cloud services securely. Follow the guidance from applicable CSP security guidance protocols for your specific CSP.
Keep all cloud infrastructure updated and patched.
Monitor all API calls and alert about any potential API misuse.
Authenticate IoT devices to cloud services. Deny access to any device that fails authentication, and log that access attempt. Set thresholds for the number of failures in a time period that trigger an alert to security administrators, and detail how the alert will be delivered. For example, if a device fails authentication more than five times in 30 minutes, then flag the sequence as a security event and alert a security administrator.
Require authentication to IoT service management consoles. Provision unique identities for each operator and administrator with access to the management console.
Provision unique identity for each system with access to the management system's API.
Use authentication best practices for management console and API login.
Limit network access to the management console and APIs by source IP addresses and/or device authentication.
Log and check all administrative activities through the management console and APIs.
Protect the computers used to remotely access your management console or APIs from malware and other threats.
Implement a secure staging system for Over-The-Air (OTA) updates in order to protect from intrusion and malicious logic. Apply integrity controls to files prior to transmitting them to edge devices.
I3 Insecure Ecosystem Interfaces
I4 Lack of Secure Update Mechanism
I7 Insecure Data Transfer and Storage
I8 Lack of Device Management
COM-01
COM-02
COM-03
COM-04
COM-05
COM-06
COM-07
COM-08
COM-09
COM-10
Define authorized MQTT topics. Create and enforce an access control list within the broker to restrict IoT devices from publishing content or subscribing to unauthorized message topics.
Ensure all MQTT messages that include a password in the password field are encrypted using TLS.
Use certificates to authenticate MQTT transactions instead of the native username/password capability.
Consider throttling traffic to MQTT server on both global and per-client basis.
Route MQTT traffic through a firewall.
Reduce the maximum MQTT message size to limit an attacker’s ability to overload the system by sending large messages.
Install MQTT brokers only on hardened OS with secure access.
Encrypt all TCP-based communications (e.g. REST, MQTT, AMQP) between system components using X.509-authenticated (
Encrypt all UDP-based communications (e.g. Constrained Application Protocol,CoAP) between system components using the Datagram Transport Layer Security (DTLS) protocol specified in IETF RFC 7525 or newer standards.
Encrypt all wireless communications in your IoT system.
DAT-01
DAT-02
DAT-03
DAT-04
Document data collected, processed, and stored within your IoT system. Classify that data based on data type and value (criticality to the organization and sensitivity). Tag data with metadata that can be used to identify types of data in your system.
Implement data security controls based on the classification of each data type.
Catalog internal and third party data sources. Enforce authentication on all data hosted within the IoT system. Track the lineage of data throughout the system as data is cleaned, reduced, modified, and aggregated. When creating these procedures, test and demonstrate the ability of your security protocols to effectively pinpoint the source of data and any users or processes that have acted upon any data used within an automated IoT decision process.
After cataloging data in an IoT system, identify any locations and systems that store the data, and apply Data-at-Rest encryption controls to those locations and systems. Monitor to ensure new systems and components are not implemented without having been evaluated for their security when storing sensitive information.
RMT-01
RMT-02
Establish service level agreements with suppliers. These agreements should include incident management support (including support during forensic investigations) and a timeline for both minimum vulnerability disclosure and patch updates.
Establish policies and procedures for third party access and management of any leased IoT devices. This includes data that can be transmitted out of the organization (e.g. instrumentation data),authorized roles, and minimum access security requirements for management of the devices within your organization’s networks. Enforce these controls and monitor for abuse.
CRD-01
CRD-02
CRD-03
CRD-04
CRD-05
CRD-06
CRD-07
CRD-08
CRD-09
CRD-10
CRD-11
Establish secure key management processes for IoT systems that include, at a minimum, key generation; key derivation; key establishment/transport; key storage; key lifetimes; and key zeroization/destruction. Keys should be generated on devices whenever possible, assuming those devices have a sufficiently random source of entropy. Central key generation and distribution is acceptable if secure transport mechanisms are used to deliver key material (including out-of-band provisioning).
Establish policy to ensure private keys are never shared across multiple devices or groups. Incorporate forward-secrecy whenever possible for key derivations (e.g. do not use static mechanisms). Keys should always be stored in a secure element (software or hardware) capable of restricting access to keys by unauthorized actors. Keys should be limited in lifetime when possible to no more than three years and ideally only one year. Use automated mechanisms for key updates (e.g. rotation or derivation).
Establish a specialized key management user group to configure key management securely for your IoT devices and services.
Establish a process for securely bootstrapping IoT devices onto your networks. Give preference to IoT devices capable of zero-touch provisioning, as these devices are pre-loaded with manufacturer credentials embedded in the hardware. Zero-touch provisioning requires a trusted, out-of-band process for loading serial numbers and public keys of devices to be provisioned. If zero-touch provisioning is unavailable, set up a trusted facility to register device serial numbers and preload identities/keys/certificates into the device prior to fielding on the network. In all cases, encrypt all account registration and update commands.
Audit and identify devices that contain default passwords and change those passwords immediately upon deploying (preferably before connecting to a network). Identify devices that share passwords with other devices and change those passwords immediately. Identify devices that share remote access keys and update those devices immediately with unique credentials per device
Whenever possible, given the amount of IoT devices that populate networks, it is preferable to use certificates instead of passwords for remote access of IoT devices. as passwords become difficult to manage as quantities of devices increase. If passwords are used to access IoT devices remotely, then update those passwords at least once a year. When possible, implement mechanisms to update those passwords automatically.
Establish a process and acquire technology to manage the secure update of device certificates and trust anchors. Opt for automated update capabililities when possible. Restrict access for updating device trust anchors to authorized administrators.
Establish certificate management policies. Define minimum requirements for validation of device identities (enrollment) prior to certificate provisioning. Device identify validation should be based on (a) in-person review, or (b) automated provisioning based on established key material (e.g. by manufacturer).
Establish operational certificate lifetimes of no more than three years. Manufacturers may embed device identity certificates with no expiration, but these certificates should only be used to establish short-term operational certificates.
Establish automated certificate processes to include renewing certificates.
Establish a process for certificate revocation that includes required reporting channels, investigation methods, and authorities who can approve/disapprove placement on the revocation list.
I1 Weak, Guessable, or Hardcoded Passwords
I8 Lack of Device Management
UPD-01
UPD-02
UPD-03
UPD-04
UPD-05
UPD-06
Establish a configuration control board (CCB) to vet modifications/changes to IoT systems. The CCB should define processes for updates, which should include testing (functional, security, interoperability) of all updates prior to fielding.
Implement a test network that closely mirrors your IoT production environment. Test all updates/patches on the test network prior to fielding in production.
Define and follow a quality change control and testing process (e.g. ITIL Service Management) with established baselines, testing, and release standards that focus on system availability, confidentiality, and integrity of systems and services.
Perform static and dynamic security analysis scans on all third party code. Use software composition analysis tools to identify components with known vulnerabilities (e.g. OWASP dependency check).
Store integrity-protected firmware images of all IoT devices. Establish processes to restore IoT devices that are confirmed or suspected to have been compromised or corrupted. Test update processes at least annually across your different device types.
Configure all IoT devices to validate the software signature on firmware prior to updating. Monitor device audit logs to identify signature validation failures.Investigate all failures to identify root causes.
I4 Lack of Secure Update Mechanism
I5 Use of Insecure or Outdated Components
TRN-01
TRN-02
"Establish a security training program for IoT administrators. Include information on all of the following: allowable use policies, IoT assets used within the organization, procedures for bootstrapping trust in IoT devices, monitoring the security posture of IoT systems, approved processes for securely administrating IoT devices, and incident response procedures.
Require that IoT system administrators take this training annually."
"Establish a user security training program. The training program should focus on making all personnel aware of their roles and responsibilities in maintaining awareness and compliance with established policies and procedures. This includes applicable legal, statutory, and regulatory compliance obligations. Training should also focus on maintaining a safe and secure working environment, including policies and procedures related to the use of employee-owned IoT devices on the corporate network (e.g., smart TVs, wearables, etc.). Training should include information about the risks and privacy impact associated with IoT devices. If applicable, provide information on procedures for interfacing with corporate IoT devices.
Require that all users of IoT systems take this training annually."
I4 Lack of Secure Update Mechanism
I5 Use of Insecure or Outdated Components
I1 Weak, Guessable, or Hardcoded Passwords
I7 Insecure Data Transfer and Storage
I1 Weak, Guessable, or Hardcoded Passwords
I2 Insecure Network Services
I3 Insecure Ecosystem Interfaces
I5 Use of Insecure or Outdated Components
I9 Insecure Default Settings
I10 Lack of Physical Hardening