This video explains the models that have been proposed for security in IoT, particularly the OWASP and NIST models.
- [Instructor] The mobile revolution saw the number of endpoint devices exceed one billion in 2002. And the introduction of smartphone technology and tablets means that now the vast majority of mobile phones are online. An even bigger revolution is happening with the Internet of Things, with estimates ranging up to 100 billion connected devices and sensors by 2020. We've already seen that even at this early stage, security is a significant issue. Work is underway to establish the frameworks and architectures necessary to enable security design, development and deployment of IoT.
The scope of IoT includes many different categories of device, including wireless sensors, smart homes, low powered embedded devices, internet connected wearables, cars, transport systems, smart meters and so on. Consequently, it will be difficult to define a single architecture to suit everything, and the modular, scalable architecture that supports a range of use cases is necessary. The scope of IoT can be considered as having a number of use case domains.
The IoT security foundation defines seven domains or categories of device. Consumer domestic devices, which are also referred to as home automatic. Enterprise, including security and surveillance systems. Industrial, particularly control systems. Medical, both bedside and theater systems as well as worn and embedded patient technologies. Automotive and vehicle. Public agency at municipal as well as national level, and including smart city concepts.
And critical infrastructure such as intelligent transport, power and other utilities. An IoT references architecture has been proposed by Paul Fremantle of WS02. This is inherently vendor neutral and supports many technologies, although it's highly influenced by key open source projects and technologies. The architecture has, at the bottom there, the sensors, actuators and devices which provide data and respond to commands. Above this is the communications layer, providing the narrowband services, aggregation, and wide area connectivity required to allow transit of device data.
Bus services and aggregation may also be part of the local environment. The event processing and analytics layer takes the device data and transforms that to relevant information. These services may exist in the cloud, or may be at the central point of data processing. Access to the data in its raw and transformed form would be via web portals and APIs, and dashboards may be used to provide visual monitoring of data flows and processing outcomes.
This is a very general reference architecture, but it provides a start point for designing the wider IoT system in a coherent and layered manner. Of the architecture, there are four points at which we should consider security. The first is the bottom devices and sensors layer. Whether the devices are nano technology embedded sensors or large components of an intelligent transport system, they will have some security requirements.
These need to be designed and developed within the use case context, considering issues such as reliability, power efficiency and protection from denial of service or compromise. The second is the communications layer, which can be considered as the narrowband routing network necessary to connect the devices wherever they are to a gateway and then onto a wider area network. Normal communications security measures need to be in place to protect the data on these links from being intercepted, disrupted or modified.
The gateways also need to be protected from unauthorized access and misuse. Finally, the data will be aggregated and consumed by networked servers, which themselves will need to have standard, online server levels of security. Their access points, web portals and API interfaces will be key areas for security attention. In some cases, particularly where the servers are in the cloud, the devices may connect directly to their servers via cellular or wifi connectivity, and so avoid the additional narrowband network and gateway stage.
The key part of the response to the growth of and reliance on interconnected devices is to ensure they're available on demand, can be trusted to protect a user's privacy, and are not able to be compromised. Given the commodity nature of many IoT devices, these requirements mean they need to be designed using robust, trust and assurance frameworks. It's likely that some IoT devices will store, generate or transmit personally identifiable information, and their use will be subject to national privacy laws.
Traditional IT systems take a monolithic approach to security, which is based on auditing using controlled design more than 25 years ago. This hardly addresses the current cyber security demands, and is quite unsuitable for use as the basis of security and trust in the IoT. The use of enterprise security controls has not served well in the industrial control system sector, where the quite different demands of continuous operation are incompatible with routine patching and restarts.
Similarly, it's unlikely that a home light bulb will continuously check for patches, apply updates and monitor for cyber attack. With IoT modules at sub one dollar, a highly commoditized security paradigm is required. The evolution of the IoT requires an approach to security and privacy which is agile and adapts to unforeseen changes. It requires an approach which recognizes a global ecosystem using common solutions developed independently, compliant with high level principles but implemented with a sector specific interpretation of security.
The IoT security foundation has established a set of 33 principles for their IoT security, which are grouped around seven questions. The first question is, does the data need to be private? There are six security principles associated with this question. The first is that security should be considered right at the start of design. Security architectures for devices, networks and systems should be developed at the same time as the devices themselves, taking into account the intended use cases for the device.
Next, all attack surfaces on the device should be identified and security controls applied to manage the risk appropriately. Users should be informed of what private data is held on the device and how it's protected. While not part of this principle, would also be wise to minimize the amount of private data that's held to that required for effective operation of the device. Users and other authorized devices or systems should be able to review sensitive data to verify the device is maintaining privacy.
Sensitive personal identifiers should be removed or anonymized to reduce the risk of a privacy breach. And encryption keys should be securely managed. While designed to protect privacy, these security principles are good practice for protection of any sensitive data, and generally useful in delivering device security. The next question is does the data need to be trusted? If so, then there are eight principles which need to be considered as follows.
Integrity of software is verified. For example, using a secure boot process. The device or system uses a hardware-based root of trust. For instance, a burned in trusted root key which is used to verify the integrity of other elements of the trust chain. Authentication and integrity controls are applied to data. Compromised or malfunctioning devices can be identified and revoked. Data is isolated from other systems or services where applicable.
System testing and calibration ensures that data is handled correctly. Device metadata is trusted and verifiable. And reuse tried and tested security, rather than creating brand new designs. This set of principles aims to ensure that the integrity of software and data is maintained, and that the device has been built taking that into account. In addition, the principles ensure that device and user access to data can be controlled through authentication.
The next group of seven IoT security foundation principles are based around the question, is the safe and or timely arrival of data important? These are, data is accurately timestamped. The integrity of data in the device, server and other parts of the system is designed in from the outset. Devices should provide failure handling and status monitoring to meet availability requirements. Carriers and device managers can identify safety and timeliness needs in a secure, trusted fashion.
Any reliance on other systems or devices for availability is clearly detailed to the user. Devices should identify themselves to a network using a secure identifier. And be clear what functionality the device is offering and its intended use, and make users aware of any restrictions or limitations. This is an interesting group of principles, which again addresses integrity as well as availability in user identification. The key points are that service providers understand the timeliness requirements and that availability is monitored.
In traditional systems, this would be achieved with a service level agreement, but the form in which IoT service availability is specified is yet to be defined. The next question involves three principles and is, is it necessary to restrict access to or control of the device? The principles are that defenses against hacking are designed in from the outset. Development processes incorporate secure coding standards, penetration testing and so on. And service management occurs over an authenticated channel.
The key point here is that devices should be designed with security in mind and tested. The fifth group also involves three principles and its question is, is it necessary to update the software on the device? The principles are, the vendor updater management process follows best security practice. Only authenticated sources are able to provide security updates or patches. And users and managers are easily able to see a device's patching update status.
These principles may need interpreting in some IoT use cases as traditional patch and update downloads will swamp a narrowband network, and a new paradigm for continuous update will be needed. The next group involves three principles as well and addresses the question, will ownership of the device need to be managed or transferred in a secure manner? The principles to be considered are, provide a secure method to transfer ownership of the device to another user. Be clear which systems components, devices, data, network, et cetera are owned by the user, and ensure that change of ownership does not impact security updates.
Traditionally, we've owned devices, but the emergence of roaming profiles in the PC world has allowed us to use any device as long as it's able to obtain our profile. We still own smartphones, but there's now a great deal of debate on whether this may change, and device ownership may become an archaic concept. The last question is, does the data need to be audited? If so, there are two final principles to consider. Developers should provide managed access to IoT data, and the device should incorporate policy controls to disable unwanted features.
These two principles are generally good practice with managed access to IoT data going hand in hand with the early identification of user and device access. Disabling unwanted features, especially where they come at the expense of security, can be an important control. Currently, the majority of IoT devices are not actively managed or at best provide a basic software update check. However, as the use of mobile phones matured, so it became more important for service providers to offer active security management.
A similar capability is likely to emerge for IoT devices. Active security management includes updating the device software, remotely enabling or disabling certain hardware capabilities, remotely reconfiguring devices, disconnecting a rouge or stolen device, locating a lost device, and remote wiping of data. There's plenty of commentary on IoT security and a number of sources of generally useful principles. However, no one approach has yet dominated, and there's likely to be plenty of new ideas to be considered yet before one goes.
- Reviewing security issues and recent attacks
- Robot security concerns
- IoTSF Compliance Framework
- LoRa security
- Building security into IoT devices
- Moving to trusted execution environments
- Adding sensors and encryption to Marvin
- Generating packets with Paketeer
- The cURL tool
- Testing home IoT devices