In the future, IoT devices will have a white-goods-equivalent rating scale, measuring not energy, but controls
In the future, IoT devices will have a white-goods-equivalent rating scale, measuring not energy, but controls
In the future, IoT devices will have a white-goods-equivalent rating scale, measuring not energy, but controls
In the future, IoT devices will have a white-goods-equivalent rating scale, measuring not energy, but controls
If you think about it, an IoT device is just another type of information system. Manufacturers of IoT devices are merely providing an environment of use outside of their organization, for us, consumers. Thus, the controls required for securing IoT devices are the controls used to secure information systems, focused on the environment of use of the IoT device. In our method, we start with a known standard for security controls and assessment procedures of information systems, namely NIST SP 800-53. We replace "Information System" with "IoT Device" and "Organization" with either "Environment of Use" or "Manufacturer". Then, we examine our use case for the IoT device again, and replace wordy clauses where not applicable. Grammar aside, we have transformed a known set of controls to an IoT specific set of controls.
When examining how different IoT devices gets used in their environment, patterns emerge. This is because almost all IoT devices have two things in common, a TCP/IP stack and a specific business purpose to fulfil. These common things allow us to group controls more consistently and ask which layer of operation does the control apply to. The layers we have selected to group controls are derived from the TCP/IP stack and the "Organisation, Mission and Information System View" of NIST. This grouping allows us to shortlist controls applicable to our use case, based on the patterns that emerge.
For different types of IoT devices, the same controls come up as important, over and over again. This allows us to break down the problem of how to secure an IoT device into a set of smaller questions, specific to the control objective of these re-occurring themes. We selected a dozen critical security controls as things that matter in IoT and offer ‘just enough’ security. We’ve done our best to make them comprehensive for everyone — including the consumers of IoT devices.
The manufacturer enforces access authorisations to the IoT device, verifying individual access authorisations before granting access to the IoT device, also controlling ingress/egress to it and maintains physical access audit logs and controls access to areas within the IoT device. The manufacturer also inventories the environment of use and changes combinations and keys on the IoT device when combinations are compromised.
The IoT device protects the confidentiality and integrity of transmitted information. This control applies to both internal and external networks and all types of IoT components from which information can be transmitted (e.g., sensors, mobile devices, wearables, printers, copiers, scanners). The desired level of security can be usually achieved through cryptographic mechanisms such as encryption, hash functions and digital signatures.
The IoT device monitors and controls communications at the external boundary of the system and at key internal boundaries within the system, and implements subnetworks for publicly accessible system components separated from the internal environment of use. Also, the IoT device connects to external networks or information systems only through managed interfaces consisting of boundary protection devices arranged in accordance with the manufacturer’s security architecture.
The IoT device uniquely identifies other devices before establishing a local, remote, or network connection. The manufacturer determines the required strength of authentication mechanisms by the security categories of IoT devices. The manufacturer also ensures that device identification and authentication based on attestation is handled by manufacturer-defined configuration management processes.
The IoT device prohibits remote activation of collaborative computing devices, except where the manufacturer explicitly allows it. The IoT device also provides an explicit indication of use to users physically present at the devices (explicit indication of use includes, for example, signals to users when collaborative IoT devices are activated).
The IoT device uniquely identifies and authenticates manufacturer users (or processes acting on behalf of manufacturer users). The manufacturer may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. The manufacturer employs passwords, tokens, or biometrics to authenticate user identities, or in the case of multi-factor authentication, some combination thereof.
The manufacturer identifies and selects the system accounts to support the missions/business functions. Assigns account managers and establishes conditions for group and role membership. The manufacturer, or the owner creates, enables, modifies, disables and removes IoT device accounts in accordance with manufacturer-defined procedures or conditions. Notifies account managers, authorises access and reviews accounts for compliance with account management requirements. Manages group credentials.
The manufacturer configures the IoT device to provide only essential capabilities. The manufacturer also prohibits or restricts the use of the a set of defined functions, ports, protocols and/or services.
The IoT device protects the confidentiality and integrity of information at rest. This includes both user information and system information (e.g. IoT device configuration, authenticator content, etc.). Manufacturer may employ different mechanisms to achieve confidentiality and integrity protections, including the use of cryptographic mechanisms or implementing Write-Once-Read-Many (WORM) technologies.
The manufacturer develops a security plan consistent with their enterprise architecture and explicitly defines the authorisation boundaries. Describes the operational context and operational environment of the IoT device in terms of missions and business processes. Provides an overview of the security requirements for the system. Describes security controls in place to meet these requirements, including reasons. Reviews, updates and protects the plan from authorised disclosure and modification.
The manufacturer defines mission/business processes with consideration for information security and the resulting risk to environment of use operations, manufacturer assets, individuals, other manufacturers and users. Manufacturer also determines information protection needs arising from the defined mission/business processes and revises the processes as necessary until achievable protection needs are obtained.
The manufacturer develops and disseminates an information security program plan. Provides an overview of the requirements for the security program and a description of the security program management controls and common controls in place or planned for meeting those requirements. Coordinates among organisational entities responsible for the different aspects of information security Ensures approval of the plan by a senior official with responsibility and accountability for the risk.
“An IoT Control Audit Methodology,” ISACA Journal, volume 6, 2017. Reprinted with permission from ISACA
CISSO, ISO27001 LA, SSP. Is an IT risk and security specialist at UBS. He has architected and implemented a number of processes and services related to IT risk management and control. He also provided security consultancy to research initiatives at his alma mater. His main research interests consist of corporate risk management, emerging technologies and evolution of modern IT threats.
PhD, CISSP. With over 15 years of experience in Cyber, Risk and Information Security. Yiannis has practiced NIST, Operational Resilience, CERT RMM, Ethical Hacking, Coding and Process Excellence.
Copyright © 2018 - 2022 Twelve IoT Controls - All Rights Reserved.