Building security, privacy and trust in IoT deployments
The T in IoT doesn't stand for trust, but it's a critical component of any IoT deployment. Follow the AEIOU vowel framework for an actionable blueprint of building trust in IoT.
IoT and industrial IoT make headlines every day. From the good, such as smart city initiatives, to the bad, such as the well-known Mirai botnet that targets the many vulnerable connected devices, to the ugly, such as the fact that the most important element of a secure IoT ecosystem is missing. That crucial element? Trust.
Unlike its cloud or data center brethren, IoT has unique characteristics that make baking in trust of the utmost importance. Namely, IoT devices have a much longer average lifespan than other devices -- sometimes measured in decades -- that often does not accommodate today's frequent hardware and software upgrade cycles.
Because the onslaught of IoT devices is inevitable, establishing trust with IoT devices is critical. With that in mind, the vowel framework -- AEIOU -- should provide an actionable blueprint for app dev, product development and security teams to follow. Let's take a look at each component.
A is for armor
In order to achieve the armor -- or holistic security -- needed to safely deploy IoT devices, teams must follow these security best practices.
Secure software development. In 2017, Senrio researchers discovered the Devil's Ivy vulnerability in Axis Communications security cameras, a problem that could be traced back to the third-party gSOAP code library. When exploited, Devil's Ivy enabled an attacker to remotely access video feeds or deny the owner access to the feed. Choosing the proper code library and ensuring secure software development could have prevented this.
Regularly scheduled and real-time patch management capabilities.
Hardened and tamper-proof hardware. This is especially important in hard-to-reach places, such as oil rigs, bridges and windmills.
Mandatory password changes. The October 2016 Mirai botnet attack was so successful because it targeted IoT devices with hardcoded or default credentials. Brute-force default password discovery is a common attack vector, and once discovered, all devices from that manufacturer are vulnerable. California's SB-327, which went into effect on Jan. 1, 2020, mandates that preprogrammed passwords be unique to each device manufactured and that devices contain a security feature requiring users to generate a new means of authentication before access is granted to the device for the first time.
E is for envelope
Unlike its cloud or data center brethren, IoT has unique characteristics that make baking in trust of the utmost importance.
Just as an envelope covers and protects the letter or papers contained within it, IoT devices must protect the data they collect, store and transmit. Teams can do this by considering the following:
On-device data protection. Most IoT devices have some form of on-device memory. The data on that memory needs to be protected (read: encrypted).
In-transit data protection. Some or all data collected on IoT devices is transmitted to a head-end location, often a gateway, cloud or data center. This data must be protected (again, read: encrypted) in transit.
Cloud data protection. Once IoT data reaches the cloud from the IoT device, it must be protected.
Data lifecycle management. For example, data that is stale or summoned to be disposed -- due to requirements under GDPR's or California Consumer Privacy Act's (CCPA) consumer rights, for instance -- needs to be digitally shredded.
I is for intentionality
Being in the know is critical -- regardless of what type of device or data it is. Teams should know the following:
What is the device doing and why. Have clear and simple articulation of what a device is doing -- for example, a camera in a park to capture its patrons' usage using foot traffic footage but the face will be obfuscated if accidentally captured. The counterexample is the sneaky introduction of a microphone in the Nest alarm system by Google.
Why the data is being collected. There must be clear articulation -- before and ongoing -- on what value the data is going to provide. In the previous example, the data will show how often a park is frequented and when support functions, such as janitorial services, need to be dispatched.
Data sharing activity. Is the data collected going to be shared with third parties? Why? And is this communicated to the data originator?
Hardware and software updates. A review of all five AEIOU tenets must occur whenever there is a hardware or software update. In the above Nest example, an update review when the microphone was introduced would have raised alarms.
O is for optionality
With GDPR, CCPA and other data privacy regulations that will emerge in the years to come, giving users choices is good practice -- not only to remain compliant, but also to boost company image and trust. Consumers should be able to do the following:
Opt in. Can the customer opt in to some or all device capabilities beforehand?
Opt out. There should be after-the-fact optionality, including data expunging or transferring. Much like GDPR's right to be forgotten mandate or right to data portability, are customers offered similar rights?
Data quid pro quo. What is offered to customers in exchange for their data? This may sound like a surprising question in the IoT world, but concepts like these are emerging, as seen in books like Radical Markets by Eric Posner and Glen Weyl. A forward-looking business can take the lead by offering tangible benefits -- such as discounts or freebies -- in exchange for increased instrumentation.
U is for ubiquity
Trust isn't a single product or policy. It must traverse the entire company, its products and departments.
Are trust principles applied uniformly across all product lines? What happens if there is a merger or acquisition? For instance, company A may adhere to IoT trust principles, but if it gets acquired by a less-than-trustworthy IoT behemoth, overnight, there is inconsistency in IoT trust principles from the combined organization.
Are customers in different geographies treated differently? When GDPR was first enacted, many companies followed the letter of the law by offering rights to EU citizens only. LinkedIn, by contrast, offered all its customers GDPR rights. An IoT vendor must make a choice. By offering a more comprehensive trust and privacy framework to all its customers, it will outshine the competition and become a more trusted vendor.
Is the set of guiding principles constantly updated to reflect the latest regulations, customer trends and competitive environment?
