CSA IoT Controls Framework

PreviousCTIA Cybersecurity Certification Test Plan for IoT Devices NextETSI Cyber Security for Consumer Internet of Things

Last updated 5 years ago

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."

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.

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.

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.

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.

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.

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.

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.