Handling Privacy and Security Concerns in the IoT: Big Data and Privacy
New waves of Big Data generated by IoT will inevitably change the relationship that users have with their new devices. More intelligent devices will undoubtedly create new efficiencies and models of productivity. However, data on those devices also exposes a wider attack surface, making personal and sensitive information that resides on a greater number of devices, more vulnerable to data theft, device hijacking and other potential threats.
The Internet of Things (IoT) has already created vast amounts of Big Data, and it is only likely to increase further: usage data, product data, location data, personal preference data, relationship data, health data, all of which can be generated or stored on devices with limited processing and storage capacity. This resource limitation ushers in several interesting implications around data privacy.
The example of ‘smart’ athletic shoes in the earlier blog, for instance, generates several different side discussions. The ability for the training shoe to log GPS location data, time, speed, and other performance-related metrics is certainly a great advantage to the amateur athlete: firstly, the ability to collect that data, but secondly, to be able to store and share that data socially is certainly a service-improvement use case. The running shoe manufacturer can use that service improvement approach as a competitive advantage, offering a gadget-like feature other ‘dumb’ shoes do not have.
However, what are the consequences of generating and storing such data? The data on its own may not have significant value, but it can when it is combined with other data within a certain context. If that data contains GPS information, for instance, an individual with malicious intent could use that information to know where the shoe owner is (or will go, based on historical data), and also where the owner is not.
Identity of Things data landscape
The IoT, while bringing significant service improvements to consumers and manufacturers, also brings concerns regarding the privacy and security of the underlying data. This situation requires that there be definition of those involved in the data life cycle, alongside the context of their identity. The key definitions are the data owner, the data custodian, the data generator, and the data consumer.
The data owner will generally be an entity or individual that has accountability and access-control decision making for the data. The data custodian is simply where data is residing—generally at rest, but data transfers need to be considered here too. Custodians could include cloud storage solutions, social networks, or applications. Data generators could well be the low-level digital devices such as cars, refrigerators, home automation systems, locks, smart phones, and so on, not to mention manufacturing controllers and sensors. This data landscape is made complete by those who will access the data—the data consumers. This group is potentially the largest, with data consumers from various different organizations and view points, all with different claims and levels of data requirements.
Data generator device security
The data landscape in Figure 1 illustrates several basic security concerns.
The devices themselves will generally be of low power with limited processing and storage capacity. These limitations could potentially inhibit the ability for the device to perform any sort of encryption, either with regards to data stored locally or as it is transmitted over the either a local mesh-style network or indeed Wi-Fi. The devices themselves also need to perform some sort of registration or mapping, either to a local hub or a physical application or person.
The opportunity for “rogue” devices is obviously significant. How can a device be “claimed” or at least prove its own assurance? A paradox also occurs with devices that are capable of performing basic operating system functions—the more complex a device becomes, the attack vectors for malware and other security problems increase.
From a network perspective, technologies such as infrared and Bluetooth, while allowing for simple coupling and data transfer, have historically (pre version 2.1 of Bluetooth, for example) provided opportunities for encryption key compromise.
Another opportunity for security compromise could potentially come from devices when they are not online. One of the foundations of the IoT landscape is the idea that devices will always be on and always be connected. This continuous connectivity allows for bi-directional communication with regards to authorization enforcement. Using the simple policy decision point (PDP)/policy enforcement point (PEP) architecture, IoT devices may need to perform enforcement actions, allowing access or responding to human or machine interaction.
But if the local device needs to communicate to a hub or central policy service to make an enforcement decision, what happens when that communication is unavailable? A default fail-safe may impact the end user experience if, for example, the device is a consumer-facing one. But allowing a caching mechanism or some other local decision-making process could also introduce issues around policy synchronization or decision spoofing.
Devices will also need to capture and send data, generally to a central hub or to a local intermediary. Here device authentication to the hub is critical. Protocols such as Message Queuing Telemetry Transportation allow for the lightweight publishing and subscribing infrastructure that can form the basis for machine-to-machine data transfer. However, authentication of publishing devices is critical to avoid both rogue devices polluting data, as well as rogue clients reading data maliciously.
In our next blog, we will discuss how data privacy will require enhanced security mechanisms such as encryption authentication and access management measures. These and other security mechanisms will also leverage identity technologies to better protect and secure the information stored on IoT connected devices.
Simon Moffatt has over 13 years information security experience with a specialization in identity and access management. He is currently Principal Engineer at Open Source ISV ForgeRock. He may be reached at simon@ infosecprofessional.com.