Part II: Baking in Security for the Internet of Things

February 27, 2015
Cybersecurity Predictions and Trends: Post by Brian McKenney
Brian McKenney

This is my second post devoted to the efforts underway to address the lack of built-in security in the Internet of Things (IoT). This lack of "baked in" security can have serious consequences, including unauthorized access to services and data, denial or disruption of access to services, and the installation of backdoors and malware, which I discussed in an earlier post. There are six key initiatives now in place to close this major security gap. Four of these initiatives focus on interoperability and security standards for a broad view of "things" and two focus on standards and guidelines for specific devices/things. My last post dealt with the broad view and this time I’ll narrow in more and take a look at some specific products. I'm also going to offer some thoughts on what all these efforts might mean for the future.

Nest Developer Program

In early 2014, Google acquired Nest Labs, Inc., a maker of smart thermostats and alarms that has a partner developer program to encourage the creation of apps and services that work with its devices. The Nest Developer Program boasts a near real-time data application programming interface (API) that offers subscription-based access to data shared by the Nest Thermostat and Nest Protect (a smoke and carbon monoxide alarm). Built-in controls to ensure privacy and security for device access and associated data are a key element of the Nest Developer Program. This includes the initial provisioning of the device, granting access to the device by user/services (e.g., permissions), and ensuring web or PIN-based authorization. For authorization, OAuth v2.0 is used to securely create a trust agreement between a Nest user, a client (an application or service developed by a Nest developer), and a resource server (Nest's API servers). With built-in security, consumers can control who is allowed to access their devices and establish authorized agreements between themselves and Nest services.

Cybersecurity for Medical Devices

Medical device complexity and migration to Information Technology (IT) networks have presented new, cybersecurity challenges to safe device operation in the clinical environment. In October 2014, the U.S. Food and Drug Administration (FDA) provided cybersecurity guidance for medical devices to encourage vendors to consider cybersecurity in the design and development of new devices. Lifecycle risks, such as vulnerability patch management, are addressed. The FDA also convened a workshop in October 2014 that drew over 1,300 health and public health stakeholders to develop collaborative approaches to medical device and healthcare cybersecurity. The medical device community is using the challenges and potential solutions identified by the workshop to develop a strategy to mature and strengthen the development of medical device cybersecurity. Work is ongoing and additional engagement is expected to reach a consensus on development and interoperability in 2015.

Summary and Conclusion

What does this all mean? As I’ve noted, most of these initiatives—from the broad-based in the previous post to the narrowly focused described here--began in 2014. This underscores the degree to which IoT definitions and frameworks are still in the early stages.

The last post discussed how two initiatives—the National Institute of Standards and Technology's Cyber-Physical Systems Public Working Group and the Industrial Internet Consortium--are developing reference architectures for a broader view of things/devices. The proposed IIC reference architecture not only covers IoT security as a capability, but it also addresses composability aspects. For instance, it considers how the deployed IoT capability can deliver safe and secure behavior, be resilient and reliable, and support privacy expectations.

Vendors and organizations are participating in multiple forums and pursuing multiple approaches. Consortiums and alliances are establishing interoperability requirements, identifying standards to ensure device connectivity, establishing test beds to validate interoperability, and defining needed security services to IoT. Two initiatives--the Open Internet Consortium and Allseen Alliance--have released open source platforms to help developer's bake-in interoperability and security. There are also initiatives focused on specific things. The Nest Developer Program concerns the Nest Thermostat and Nest Protect, and the FDA targets medical devices in its cybersecurity guidance. At some point, initiatives that focus on specific things should be viewed as supporting the broader context of IoT interoperability and security.

Although the snapshot that I've created over the course of these two posts shows multiple players working on similar objectives and initiatives (e.g., reference architecture, open source platform), the message for IoT security should be that secure and interoperable things are on the horizon. These many initiatives represent plans and progress for developing a common understanding of IoT security lexicon, architectures, and standards. Expect to see more progress in 2015. With similar objectives and the continued need for baked-in security in the IoT, it will be interesting to see how these efforts overlap and converge to create common standards and implementations.

In future posts, I'll provide an update on IoT security advances, especially industry advances and harmonization of IoT security frameworks and standards.