Description (Control Specification)
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.
I6 Insufficient Privacy Protection
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 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf) validated). Use good sources of entropy for random number generation associated with key material. Ensure cryptographic modules perform power-up tests to include cryptographic algorithm tests, software/firmware integrity tests, and critical function tests. 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 (https://www.owasp.org/index.php/Main_Page) security guidance.
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 (https://www.nist.gov/publications/guide-bluetooth-security-1) document. Remediate any deficiencies. 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 (https://gitlab.com/brianr/CloudSA_IoT_WG/wikis/iot_botnets). 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.
I7 Insecure Data Transfer and Storage
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.
I8 Lack of Device Management
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 (https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf) hardware root of trust. 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.
Evaluate liability potential of an IoT system where the system interfaces physically with the public or workers. Define safety restrictions and post warning notices.
Create a continuity plan that details the contact information of system owners. Create a system for alerting these contacts, and when an IoT system is compromised or made unavailable, alert these contacts.
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
Establish a vulnerability management program for IoT systems. Perform periodic or continuous vulnerability assessments (annually, at a minimum) on IoT devices. Track updates to IoT protocol specifications in order to identify upcoming security/privacy updates in libraries. Maintain a risk register that is updated based on vulnerability information associated with deployed IoT devices/systems.
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.
Establish physical security processes that restrict physical access to IoT edge devices and alert on physical access attempts.
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.
I8 Lack of Device Management
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.
I8 Lack of Device Management
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 (https://tools.ietf.org/html/rfc7525) Transport Layer Security (TLS). 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.
I7 Insecure Data Transfer and Storage
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.
I7 Insecure Data Transfer and Storage
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
Define end-of-life procedures for IoT system hardware. For any hardware storing sensitive information, the procedure should be to dispose of the hardware securely and to maintain an audit log of the disposal process, including any individual that participates in the process.
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
"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."