Right now, the world is filling up with Internet of Things (IoT) products – they’re used by individual consumers in their homes, by companies in their offices, and by industries in large-scale automated processes. They’re multiplying exponentially – from about 6 billion devices in 2016 to about 31 billion in 2020, according to ZDNet. They’re growing fast and wild from individual startups, hyped up and presented with false advertising, with no governing body to regulate their security requirements or overall quality.
As the number of IoT products continues to grow by levels of magnitude beyond the human population, it becomes an increasingly daunting task to try to corral them in any way. The quality of IoT products varies widely, and it’s unclear which are truly secure and which are just calling themselves secure.
Cigarettes include health warnings from the Surgeon General, raw meat includes instructions about handling it safely and consuming it before an expiration date, and medicine bottles can’t contain false advertising about what their product can do. But what about when you buy an IoT gadget for a friend’s birthday or a Wi-Fi enabled plant-watering system? Where are the FDA grades of quality? Where are the expiration dates?
We know we need to get to a place where IoT products are less mysterious and more secure across both consumer products and industry automation, but how? If there is a path, legislation may be the solution, and that work has already begun.
Right now, IoT marketing is focused on its ability to connect to Wi-Fi or Bluetooth, or an app that can control a device remotely, not its security features or how long the vendor intends to support the software. Internet-connected devices do not have to provide information anywhere about their use of multi-factor authentication (MFA), end-to-end encryption for data privacy, or password policies. They are pitched, funded, and sold in the way that their companies choose to sell them, without oversight or regulation. Any IoT product can claim to be “secure” or “encrypted” in the same way that any product can claim to be “organic” – it doesn’t hold a legal definition and does not help consumers make informed decisions.
That means that for now, all the weight of informed decision-making is on consumers, and the fear that vulnerable designs will lead to attacks isn’t just hypothetical, it’s happening. Baby monitors have been used to spy on households and speak to children since at least 2013, researchers proved that a Jeep could be fully controlled remotely in 2015, and in 2016, the Mirai botnet took control of IoT devices to perform a distributed denial of service (DDoS).
Right now, we’re being sold organic Wi-Fi devices with bad password policies, no guarantee of support to patch their software, and no vulnerability disclosure policy if bugs are found. What’s sold as the “next generation of home assistant” may not really have any security features at all and could eavesdrop on your family while installing malware to use your device in a botnet. There’s no good way to sort the snake oil from the truly security-minded products, which can make the situation overwhelming for security experts and consumers alike.
Since IoT covers such a wide scope, the goals should be finite and clear. Based on the work that’s already been done, it seems that the focus of improving the state of IoT is twofold:
The two goals work together to guide the improvement of security in existing products, new iterations of devices, and future IoT devices. By establishing standardized definitions that are meaningful to security, products can be required to adhere to them in an enforceable way. Agreeing on the language of security will weed out companies that either neglect security or use false advertising to oversell and underdeliver on the product.
To raise the quality of IoT devices, organizations need to establish meaningful definitions and security requirements, and then penalize companies that are negligent in their security practices and in their advertising.
With these goals in mind, let’s see what progress has been made on them so far:
In the U.K., there are now foundational practices that all U.K.-based businesses must comply with called the Code of Practice. In plain language, the main three practices are as follows:
The Code of Practice was established in March 2018, but there are no current ways to enforce these rules. They are a part of an intentionally slow rollout plan that lets U.K. companies gradually catch up to the rules. Without a clear timeline, it will be hard to motivate companies to start improvements, but establishing basic security requirements (like wearing hard hats on a construction site) is a good idea, even if the requirement currently lacks teeth.
Every few years since 2003, OWASP compiles a Top Ten list of vulnerabilities. Since 2014, they’ve also put out an IoT Top Ten list. Like the U.K. rules, the list is full of foundational common sense pitfalls to avoid when securing IoT devices, including insufficient privacy protection, lack of device management, and weak, guessable, or hardcoded passwords.
Moving from the broad to the specific, a good example of industry and feature-specific guidance is Amazon’s Alexa Voice Service hardware security requirements. These requirements both advise developers on how to turn high-level concepts into actionable advice, and also recommend vetted vendors who can test for their standards of compliance. These standards for the most part follow the OWASP IoT Top Ten, but also set out some good specific benchmarks for encryption standards and Bluetooth security specifics.
For an in-depth discussion on developing secure firmware, we recommend reading “Secure Firmware Development Best Practices” by the Cloud Security Industry Summit’s Supply Chain Technical Working Group. This whitepaper covers establishing a root of trust, secure boot methods, and how to implement secure firmware update procedures. It establishes a benchmark for firmware security when it comes to protecting firmware integrity and encourages developers to let legacy technology die (goodbye IPMI and Legacy BIOS Boot). The checklist is a great resource for developers, and supplies guidance on developing a threat model specific to your product.
Much of the legal work being done around IoT now is determining what is negligent and not industry best practices, with FTC lawsuits and class action lawsuits as the main path toward improving IoT security in the US. The goal of this ad hoc approach is to establish precedents by choosing to pursue the worst manufacturers for negligent security practices. For example, the FTC filed a lawsuit in 2017 against D‑Link for not taking “reasonable measures” to secure their IP cameras and routers, which (among other security threats) allowed them to be used in the 2016 Mirai botnet. In July 2019, D-Link finally settled with the FTC and agreed to make improvements.
Although it’s unlikely that there will be any nation-wide mandates about IoT, California recently passed a law about it — SB-327 — that came into effect this year, and since the majority of IoT devices are created in California, we may see even more clearly defined security requirements soon.
The Federal Trade Commission (FTC) has also filed a suit against an Indiegogo-funded smart lock called Tapplock for not avoiding “reasonably foreseeable” vulnerabilities. In the case of Tapplock, that meant that they did not have a security program, users could not revoke access to users that they added, and unauthenticated attackers could discover and interact with a Tapplock’s Bluetooth MAC address when in range to then unlock the lock.
“Reasonably foreseeable” may feel vague and flimsy, but when something is advertised as unbreakable but is easily broken, there’s a clear issue. Courts compare these insecure products to relevant industry standards, and as the edges of IoT security become more solidly defined through the courts, moving targets like this become easier to legislatively pinpoint.
Addressing this situation through legislation is an intentionally high-level approach. It makes a statement that negligence in the security space is something that won’t go unpunished, whether it’s a toothbrush, router, or temperature control system. Determining negligence sorts out the unavoidable acts of God (a covert nation-state attack compromising your system) from the foundational missteps (no password required) that result in attackers stumbling into a system-wide exploit chain.
Legislation seems to be the best solution toward securing IoT, but it wasn’t the first step. Against a potentially overwhelming numbers of devices, the goals of wrangling needed to be clear first to inform what direction companies, industries, and governments should take to rein in the fast-growing IoT ecosystem.
And even before goals were established, someone had to determine that this was a problem worth solving, then start to have difficult conversations with involved parties about what the real problem really was. Those conversations started to define goals and baselines, which in turn guide further conversations that will shrink the gray areas about benchmarks and requirements and further focus the conversation.
It’s hard to know where to draw the line, but with these targets already in motion, it seems like the best approach is to start defining the definite good things and definite bad things (no support, no new versions, default password, backdoor access, includes malware, etc.), and then use those to narrow down the murkier gray area between those two extremes.
IoT is not only new, it involves businesses working in a new modality. The work of a single developer can quickly affect billions of users on an incredibly large scale in an unprecedented way. One milk farmer can’t poison the whole world with a tainted batch, but one programmer could create an insecure app that goes viral. If the app that controls their Wi-Fi or Bluetooth product allows attackers to access external data, they could compromise users’ personal and payment information across a country in a day.
Small startups working without legal departments in a new field without norms are a difficult thing to regulate using traditional legislation tactics. Unlike building codes (which are well established and based on thousands of years of humans gaining knowledge about structural engineering), IoT products are new for both the creators and legislators. Because of this, many startups use the Google defense – “if Google does it, it’s OK if I do it too.” – but no company should be used to define industry-wide standards. It’s not a legal precedent just because it came first.
Establishing definitions supports the goals of increasing safety and transparency of products. Because of the work already done around IoT security and industry standards, we’re getting closer to having legally binding definitions for terms that will mean something significant to consumers and also guide judgment in cases of negligence. Instead of low-fat, organic Wi-Fi, we could see products in the future with credible features like the following:
Defining good security is a necessary step toward a better IoT, but we’re not unrealistic dreamers. We certainly don’t expect anything to change overnight, and whatever standards get passed down through government mandates or industry compliance guidelines won’t change the security of products already on the market or in use. IoT is a massive issue and it requires discussion and on an equally massive scale. Technology moves quickly, and cultural norms and legal precedents have a long way to catch up. This phase is about setting down a solid foundation to build on going forward.
So we’re at the bottom of the hill pushing a Wi-Fi-enabled rock up. Governments and industries are establishing baselines, but it’s slow. What can you do to improve the security of IoT devices right now? Well. it depends who you are.
If you’re a consumer, know that you can’t trust that your Wi-Fi-enabled cereal dispenser isn’t sending your audio and data internationally, so be wary and do research. Remember how medicine used to proudly include cocaine and arsenic? That’s the stage of development that consumer IoT products are in right now. Don’t expose yourself to unknown risks if you can avoid them. Buy products that let you change the password and that state how long they will support the device with updates.
If you’re a developer or hardware engineer, include security in your product development from the ground up. Create a threat model specific to your device. Find industry and device-specific requirements and suggested measures (like for Amazon’s Alexa) and implement them yourself. Divide your security recommendations up into things you must do (requirements) and what you may do (best practices), and then check them off as you go.
If you’re an vendor looking to err on the safe side of security, don’t wait for laws to slap your hand. That means regularly testing your products and environments beyond compliance – both internally and with external testing. Pen testing lets you view your environment from an external perspective to see if you lack security measures that an organization like the FTC would consider “reasonable precautions.”
If you’re a lawmaker or industry influencer in a position to establish baselines, focus on establishing the clearly bad and clearly good to narrow down the amount of gray area in between.
If you’re a security consultancy like us, the laws won’t change how you comprehensively test the products and environments for your clients, but it may affect what their initial scope requests are – if there are new compliance requirements for internet providers and for consumer electronics the way there are for medical and payment handling services, then be sure to cover those, but still explore these systems in depth to find out if the products are failing at their stated tasks or in areas not covered by compliance.
The Internet of Things is slippery. It’s changing with the limits of technology faster than governments or class action lawsuits can ever hope to move, but it matters too much to give up on it. To keep up with IoT, consider security early, expect new security threats to develop, and test your product against real-life scenarios.