The Internet of Things (IoT) is a broad concept, encompassing many technologies dispersed horizontally across all sectors. At the core, IoT applications are employed in a variety of monitoring and control functions, providing valuable metrics for both consumers and businesses: tracking, measuring, collecting, analyzing, detecting, alerting, disseminating, locating, and identifying. These operations can be performed remotely, can be scaled, and can be deployed in a low-cost manner. Such benefits provide compelling use cases for organizations and individuals looking for ways to improve efficiency and maximize resources. With the right mix of analytics, actionable intelligence can be pulled from such applications, enhancing processes and providing value.
However, with such a varied array of new functionalities being developed and deployed, the security considerations are numerous, not least because such applications are Internet connected. Their very advantage also brings new threat vectors that can be exploited. The problem is that existing security technologies are not so easily transposed to the IoT. The current security architecture focuses primarily on the “traditional” digital-first Internet, whereas the IoT requires an approach that takes into consideration analog and physical-first scenarios that were not of concern previously.
Notably, IoT applications can be directly linked to the issue of functional safety. As connected things quietly infiltrate various aspects of daily life, from connected vehicles to implantable medical devices, the risks of danger to human life increases substantially. Ultimately, safety considerations are intrinsically linked to the triad that is confidentiality, integrity, and availability. Strengthening any of those elements provides for the safer deployment of things.
The manufacturers of IoT devices and the developers of supporting applications are leaping ahead with little consideration or invested effort in security, generally, and this will undeniably affect functional safety over time. The consequence of shunting security to the side means that vulnerabilities will abound. This is already emerging prominently in the media, with numerous proof of concepts and much-publicized hacks of medical devices, connected cars, baby monitors, and CCTVs.
The issue with vulnerable things highlights the worrying trend that secure product development is not the norm. The reason for this omission is primarily dictated by market forces. Security is still an added cost and there is enormous pressure on time-to-market. In addition to market forces, there are technological barriers. Limited processing and memory capabilities, low-power requirements, new protocols (both open source and proprietary); all these require a different approach to security implementation. There is a constant trade-off at play between security and usability. Add to that issues of compatibility and integration between these various new technologies, and security becomes a minor consideration in this new market.
In order for manufacturers and developers to better understand where and how IoT applications are vulnerable, it can be split roughly into three core layers:
- Device: the perception layer, which measures data and collects information (integrated circuits, actuators, sensors, connectivity protocols);
- Infrastructure: the network and platform layer for the transmission of information, receipt, and organization of information (wired and wireless technologies, backend infrastructure, cloud computing platform, data center);
- Application: the analytics and end-user layer for analysis and processing of collected information, for transmission of commands back to the devices, for management and control (software platform, front-end interface, web/mobile application, management console).
At the device and infrastructure layers, security of the hardware and communication channels is most at risk, typically from unauthorized access, modification and disruption, and various attack techniques, including denial of service (DoS), man-in-the-middle, malware infection, asynchronous attacks, replay attacks, routing threats, side channel attack, differential power analysis, among others.
Both RFID and NFC, for example, are susceptible to a number of these attacks, as are protocols such as Bluetooth or Z-wave. Proof of concepts have shown that even encrypted communication of a Z-wave motion sensor can be intercepted, and so devices can be impersonated on a network and used to disable or fuzz other Z-wave devices.
At the application layer, however, is where real value can be created from the information collected and transformed into actionable intelligence. It is also the layer that provides the largest attack surface. The software behind the analytics functionality and end-user interface is critical as provides control.
Quality assurance and testing are key to minimizing design errors and bugs that could be leveraged as vulnerabilities. Buffer overflow, programming language use errors, and integer overflows are all common errors that can subsist during the development process. Errors in device protocol APIs, for example, can create vulnerabilities when communicating with a device.
The additional difficulty with IoT applications is that often the hardware is so closely entwined with connectivity and the application layer, that testing of just one layer is not easily done independently of the others, often due to the embedded nature of many IoT devices. Combined, of course, the attack vectors increase exponentially. The potential risk for human lives is non-negligible, especially when used in more critical settings, such as health monitoring or self-driving cars.
Ultimately, security considerations for IoT involve applying the same mindset and methodologies as for traditional security; although, the application in practice will be different and will vary considerably depending on use cases. These considerations are as broad as they are varied: from key management (embedding keying material at manufacture and provisioning new keys during operation), hardware anti-tampering security modules, processes for secure software development, establishing and provisioning access control policies, and managing software updates and patches, among other tasks.
In large part, the various considerations for hardware, software, or network-level security can be addressed more effectively at the start of a product development project. External factors also need to be included in this process, with regards to the underlying transport infrastructure, the impact of heavy usage, the limitations of lightweight components, the potential damage in case of subversion or degradation, the protection of the product’s own intellectual property, and those characteristics that are intrinsic to IoT applications (such as autonomy and momentum).
The difficulty, of course, is that there is no holistic view or end-to-end security architecture for IoT applications. The various phases and composite elements need to be looked at individually and various security technologies applied all along the process. Security must form a part of the inception process. This is where, for example, agile development, application lifecycle management, and DevOps need to integrate security during the design, development, and testing of IoT applications.
Developing secure APIs, web, mobile, and client applications; scanning and monitoring for vulnerabilities; safety and quality assurance; code reviews; security architecture evaluations; static and dynamic testing; all these techniques can be used. Any single one may not be sufficient, but a combination can help to significantly reduce the risks. The difficulty is to perform testing for a wide range of interfaces, but over time, it may be possible to construct a minimal set of requirements that can be ported across applications, that can be automated, and eventually, implemented through continuous integration in which testing can drive design and development.
Of real advantage to the new IoT reality is that the lifecycle of an application becomes much more accessible. The real game changer for IoT applications has been OTA functionality. The possibility of updating devices during their lifetime has pushed programmed obsolescence in decline. New features can be added and devices can be upgraded after sale. For security, this means that vulnerabilities can be managed and mitigated to some extent via OTA. Security can be continuously monitored, improved, and updated accordingly. Although not everything can be remedied via OTA, it is a significant step in enabling continued post-market support of an application and its supporting device.
OTA, and Internet connectivity generally, also provides new sets of issues for privacy. There are significant implications for both consumers and organizations amidst the wealth of data that can be collected by the IoT. The concept of privacy-by-design conflicts with the market-driven imperative of generating and accessing vast amounts of IoT data for commercial purposes. With the consequent use of cloud-based services to alleviate the burden from the limited computational and storage abilities of the various things in collecting terabytes of data and monitoring thousands of sensors, issues of increasing concern focus on the ownership, sharing, and confidentiality of collected data, particularly where personally identifiable information is conserved.
How can these dissonant convictions be harmonized? Anonymization of user and metadata might be one way, but there is still lost value to a commercial operator wanting to use such data to target individuals specifically. Perhaps the use of soft identities offers a plausible alternative. Many of these aspects are yet to be fully researched and implemented, and as yet, it is early days in terms of achieving universal privacy in IoT applications.
The connection of physical-first products on a multipoint basis and their exposure to digital applications represents the next frontier for cybersecurity as a discipline, which encompasses new privacy and functional safety concerns. The challenge is considerable, and the security implications will vary according to the application and to the understanding of the risk by those deploying it. At the core, however, stakeholders need to engage in these discussions at the start of product development in order to minimize the risks and the eventual costs that delay might incur.