Privacy and Consensual IoT
Privacy and Consensual IoT
IoT architects need to take user privacy seriously. Here's how to bear user consent in mind when it comes to configurability, testability, operability, and releasability,
Join the DZone community and get the full member experience.Join For Free
Consensual IoT is the application of the idea of consensual software to the Internet of Things. Consensual IoT means that all IoT providers need to respect and take all measures in their power to protect users’ privacy and safety. They need to explicitly ask for consent when in doubt. They need to care not only about the safety of devices and the physical environments around them but also the safety of personal and location data.
According to Danielle Leong from GitHub’s Community and Safety Team, the term “consensual software” means getting explicit consent from users to interact with them and to disclose their personal data.
Assuming users’ consent to expose data or have them unwillingly participate in certain interactions must be actively discouraged not only because of the security risks, but also to ensure users are in control of their interactions with the software. On top of that, data exposure leaves the door wide open to abuse (for example, it used to be possible to add GitHub users to a repository without their explicit permission, so users could end up listed as contributors of repositories with racist names without there having been any action on their side).
Leong stresses the need to have meaningful discussions about consent and security in design phases. Thinking about user wants, requesting explicit permissions (opt-in by default, not opt-out) to interact with them, and keeping audit trails are all crucial for building trust and safety in the software.
Trust will sustain the exponential growth of IoT. But fixing today’s frequent hacking and manipulation of devices won’t be enough. We need to aim for consensual IoT to (re)gain users’ trust.
Specifically, trust in IoT requires safe device data storage, secure data transmission, secure data center data storage, and controlled access to devices and third-party integrations.
Why IoT Security Is Not There Yet
IoT security is difficult to implement due to the number of factors to address. IoT backends require the same security as any web system, but we also need to care about the physical security of devices and the security of the networks they are connected to. However, the technical challenges are generally not hard to solve.
Although we might be tempted to point out negligence, the real reason why those challenges are not addressed is the lack of a coherent business model, as highlighted by Alasdair Allan during his QCon London 2017 keynote on “Security War Stories: The Battle for the Internet of Things.” When the financial value for IoT providers resides in selling the device, the incentive to deploy secure software is missing. Functional and “plug-and-play” are the differentiators today, not configurability, and security.
Usage-based IoT business models, on the contrary, provide financial incentives to deliver reliable devices and software, effectively leading to a service provider model focused on operability and support.
Just like web or mobile applications, software running in physical devices needs to be consensual, as well. However, there are additional challenges for IoT.
First, current architectures often treat devices as dumb terminals with little to no configurability built in. Accompanying mobile apps might help here, but only if they allow configuration of data sharing, along with modes of operation.
The second concern is the lead time to roll out a software update into the device. If we take the GitHub example, requesting explicit consent for adding repository contributors (the “repository invitations” feature) required multiple adjustments to the software: UI changes, email notifications, database changes to keep state, etc. What seems like a simple update often hides complexity and requires changes to multiple layers. The level of complexity will depend on how modular and testable the software architecture is. Nevertheless, final rollout of the feature probably wasn’t that hard or time-consuming because we’ve built the mechanisms for rapid releases. That is not the case for IoT, where frequently deploying software updates to physical devices is not the norm yet.
Further complicating matters, a single vulnerability in the device’s software (including OS) can be exploited across a large number of devices carrying that same software. This has already led to massive exploits with botnets, such as the now famous record-breaking DDoS exploiting Internet-connected security cameras. The same applies to privacy abuse, such as the recent Burger King ad purposely triggering Google Home devices to read out a marketing blurb. Google took three hours to stop the abuse (apparently by updating the device’s database of sound clips to ignore), yet there was no inherent issue with the device. Thus, there’s a need to think ahead of possible interactions and misuse of the device!
Capabilities Required for Consensual IoT
Obviously, we need technical solutions for specific security issues. But we might only be fighting fires if we don’t grow the capabilities required to develop secure and reliable IoT systems. What are the core capabilities required for consensual IoT?
This could fall under Operability below, but configurability is so crucial for consensual IoT that we need to single it out. Often, IoT devices need to send data over the network to fulfill a goal, but that does not equal a wild card for all data collected by the device to be sent over at any time.
For example, an energy meter needs to send usage data to the energy provider, but shouldn’t send location data by default (if compromised, it could allow an attacker to establish usage patterns and find out when the house is empty). With IoT, we’re not only talking about privacy breaches only but physical danger, as well.
Configurable devices need (more) conservative defaults to respect their users. This goes beyond secure defaults. For example, allowing a device to connect to a public network with a generic default password is neither secure nor conservative. Transmitting encrypted location data (if not critical for the service) by default might be secure but still disrespectful.
Testing the software in the device in isolation (data is being correctly measured and transmitted) is important, but testability for IoT systems means we can also reproduce the ecosystem around the device and how users and other systems interact with it.
In modern web systems, we aim at production-like environments for testing. We can reproduce an actual live system using the exact same (version-controlled) scripts and tools for provisioning and deploying applications.
We need the same production-like environments for IoT testing to ensure data is secure and not exposed to attacks and to exercise device configurability, ensuring users have correct and sufficient control over how their data is being used.
The difficulty for IoT is mimicking the connectivitywith external actors. In our test labs, we need to go for the lowest security denominator. This means, for example, assuming our device will connect to insecure wireless networks, or that an attacker can connect to the device via Bluetooth or even gain physical access to USB or other ports!
A good test pipeline needs to cover what’s “inside” the system border (for example, functional tests of the software running in the device or performance tests on the backend) as well as interactions with what’s “outside” our control (e.g. other devices in the same network or third parties that the device is sending data to). We need things like test rigs and digital twins in order to do this. But above all, we need proactive and continuous IoT testing skills.
We also need to test for operability, making sure our logging and monitoring works. Beware that this is a never-ending work in progress. As we face new issues in operation, we realize what pieces were missing in our logs and dashboards and amend and re-test them.
We live surrounded by complex sociotechnical systems. Forward-thinking organizations acknowledge that they can’t possibly pinpoint, much less test every possible failure scenario. That’s why they increasingly focus on operability (like centralized logging, event tracing using correlation IDs, and monitoring) of modern systems and actively invest in cultural acceptance of failures as sources of learning (post-mortems, blameless culture, and shift-right testing).
IoT adds even more complexity; thus, we need to apply the same ideas to allow quick diagnosis and recovery from incidents.
We need to actively explore potential failure modes of our software, both standalone and in interaction with other systems. Attackers will explore them if we don’tdo it first. In the worst-case scenario, where we fail to prevent data from being leaked or abused, we need to be able to quickly identify which interactions took place before and after the incident, look for deviations in usage patterns, and learn how could we have identified the problem earlier.In short, minimize exposure as much as possible, but be prepared for abuse to happen and have the mechanisms in place to identify and diagnose them quickly.
It’s not enough to identify and diagnose incidents. We also need to be able to take swift action. Often, fixing the problem requires a change in the software running on the device.
It might be a one-line change as in the energy meter example (stop sending location data) or it could be a more complex change requiring backend modifications (imagine that the energy provider was tracking customers’ consumption based on meter location, not on a customer ID).
Regardless of the change size, being able to deploy frequently, quickly, and reliably is fundamental for IoT, either to fix a problem or to provide more control to users over their data and device interactions.
Modern mobile and web systems rely on Continuous Delivery techniques (such as deployment pipelines or canary releases) to test changes at multiple stages, from source control to a subset of instances running in production to a full rollout to the entire live environment. If a change fails to produce the expected results in production, it should be straightforward to redeploy the previous good version from an artifact repository.
Consensual software should be the norm in today’s world, including in IoT. We need strong security in place as a key enabler of consensual IoT. We also need strong capabilities to make our IoT systems configurable, testable, operable, and releasable.
There’s a wealth of techniques stemming from the Continuous Delivery and DevOps movements that we can apply when developing and operating IoT systems. Unfortunately, incentives for all the above won’t be there until IoT moves to a service-driven business model.
Opinions expressed by DZone contributors are their own.