It is a fact that more often than not, security falls by the wayside during the product development process. In other cases, announced features are initially omitted, to be added later, as soon as they are finished. Cynics may speak of “bananaware” which matures either en route or after sale - just like bananas, hence the name. Whenever a security issue is discovered, some effort is made to relieve the problem – until the next one rears its head. It has been said many times before: security needs to be part of the development process. It cannot be added later on once the development is already two thirds of the way complete. The entire issue is not limited to the software side of a product but the hardware as well.
More power
The key to making the Internet of Things possible is inexpensive computing capabilities with low power consumption. There are plenty of off-the-shelf components that are used which fit those requirements. Custom chips are only used if no other practical means of achieving a certain functionality is available. Many devices that can be bought today do not have microprocessors (otherwise known as a CPUs), but microcontrollers instead. Most CPUs that we are familiar with are multipurpose devices that can perform a wide variety of tasks and have lots of computing power. Using a CPU would just be too wasteful and expensive in an IoT application. In contrast to this, a microcontroller that you would find in a smart thermostat or a refrigerator has a limited amount of computing capability, because it only needs to perform a handful of functions. Using low-powered hardware of course makes devices more affordable for customers, but for interconnections and true "smartness", a lot of computing power is required - this is where cloud platforms come into play. The devices in our homes and in our pockets are no more than input and output devices of a cloud platform that users have no direct control over. We will get into more detail about this later in this article. Other than just being an inexpensive alternative to a full-fledged CPU, microcontrollers also lack some security features that are present in modern CPUs – and even on modern CPUs hardware security is not without its share of problems.
Less security
Process isolation makes sure that certain memory areas are inaccessible to other processes. This ensures that system processes remain stable and cannot be tampered with easily. On the hardware side, this is achieved (among other things) by using a Memory Management Unit, or MMU for short. In simplified terms, an application needs to ask the MMU first before being able to access an area of memory. In microcontrollers, this MMU is often missing. The lack of an MMU is not the only issue that potentially compromises security. With the time-to-market in the consumer market getting ever shorter, manufacturers struggle to secure their platforms properly and the lack of certain security features in the hardware itself does little to make the job easier.
To make life even more difficult, adding security often compromises performance and/or the “user experience”. This mix makes for a delicate balance which tends not to be in favor of security. In theory, all it takes to elevate privileges is flipping one bit in a specific memory area. In offline applications with no network connection at all this would not be a cause for major concern, but when adding a susceptible device to a network, it is definitely a reason to start worrying. Never connecting an IoT device to any network would theoretically address the issue, but it would also defeat the purpose of those devices.
About Microcontrollers
Microcontrollers are usually based on old CPU designs and remain in production much longer than the CPU it was based on. Many microcontrollers that are used today are based on very old processor designs from the 90s, 80s and sometimes even the 70s. For instance, controllers that are used in household appliances might have a descendant of the famous MOS 6502 CPU in them, which was used in early home computers, such as the iconic Commodore C64 or the Apple II. Others are based on the Motorola 68000, which had seen use in machines from DEC, SGI and Apple in the late 1970s and early 80s, as well as several game consoles from the 1990s.
Modern SOCs (System-On-a-Chip), some of which are technically microcontrollers, too, also have their own RAM and flash memory on board which saves manufacturers the cost for adding dedicated memory chips to their design. On the other hand, some components are sometimes left out, such as a Memory Management Unit (MMU). Instead, memory management is realized in software. This reduces manufacturing costs, but also removes one obstacle for an attacker who intends to run malicious code on a device. By manipulating a vulnerable application, the attacker can access memory areas more or less directly.
The frequency of updates (or lack thereof)
Our computers and smartphones receive updates for applications as well as the operating system on a regular basis. Things look decidedly different for IoT hardware. Some devices do receive updates over the network. Others require manual intervention and yet others cannot be updated at all which results in a lot of lost sleep for security professionals. Installing updates remains one of the key measures to take when it comes to securing any system. When looking at much of the IoT landscape out there, updates are often few and far between. Many low-end devices do not even have an update facility. Others require the user to manually download and install it. Past experience has shown that not automating updates and relying on users to keep their devices updated is not a good idea. Microsoft users have learned about this the hard way when Blaster, Lovesan or Sasser struck. Updates were available, but they were not automated. As a result, hundreds of thousands of PCs were infected. Things have improved greatly since then – home users hardly need to do anything to keep their operating systems updated. For IoT hardware, we are not there yet. While the operating systems on our PCs and mobile devices have a relatively clearly defined product lifecycle, things look different for other connected devices. Every manufacturer addresses updates differently with approaches from not providing updates at all to (mostly) automated updates. Interestingly, some companies at least used to be against any updates, as a case from 2014 shows: A spokesperson from Nest stated that “The reason we pulled the product is that we didn't want to sell a product that required an update.” It would be nice, of course, if we did not even need to worry about having to update all the things, but not needing any updates ever would imply that there is no progress and also that software is "secure by design", neither of which is the case in reality.
Standards, available technologies and scaling
A few of the challenges facing IoT manufacturers include the availability of a connection to a device. Many devices “go to sleep” when they are not in operation, which means that they can neither be reached to trigger an update nor do they have the capability to initiate updates by themselves. In an ecosystem with a central hub to which all devices connect, data transfer could be realized, but there are no standardized procedures for this yet - every IoT vendor handles the management of their products slightly differently. Manufacturers also need to figure out ways of making the update files manageable in size AND avoid prolonged outages during the update process. Since most IoT hardware has limited hardware capabilities which limit their ability to process large files, decreased file sizes are desirable and also improve an ecosystem’s scalability. File sizes that are too large may put a network under severe stress. Addressing this issue in a way that allows updates “over the air” (OTA) would also bring large benefits to the companies making the IoT devices: updates can be pushed out directly from the manufacturer, without the need for user interaction for every update or even costly product recalls. It is also not as if technologies for this do not exist – in fact, the opposite is the case. So standardizing update procedures across the board would make sense on more levels than just convenience and security. By making OTA updates possible, manufacturers would have the chance to improve security significantly while opening up new revenue opportunities (such as “unlocking premium features” on a device). As with many things, there is also a potential downside to this, mainly in updates breaking compatibility with other components. Depending on the context in which a device is used, a software update also would require the re-certification of the entire device - this could be a problem in several industries, such as health care. The certification processes for several industries would also require a major overhaul to take the IoT on board. As you can see, there are a lot more factors to take into account when addressing the issue of updates.
Coordinated efforts
n order to provide comprehensive improvements in IoT security, a number of things needs to happen. Apart from including security considerations early on in the development process, manufacturers really need to make updates easier or, in some cases at least possible. Since many IoT devices such as smart plug sockets do not have any input devices beyond the one button on the front, the solution can only be OTA updates. As we have learned in the world of PCs, leaving the responsibility for updating programs solely to the user is not going to work for the majority of users. Given the likelihood of a longer service life, manufacturers also must commit to providing regular updates for that time, even though, admittedly, few figures exist on the duration of an IoT device’s actual service life. Even if no functionalities are added in updates (e.g. due to hardware constraints), security patches should still be made available. It gets even more complicated: IoT ecosystems can also be interconnected using devices such as your Amazon Echo. This means, interconnections between services need to be secured properly as well. If you want to check whether or not you left the lights on in your living room after you left for work, then you have at least two cloud-based services involved to get this information: you contact the Amazon ecosystem via your smartphone app. The Amazon ecosystem in turn contacts the infrastructure of whatever vendor made your lighting controls. If any of those connections are compromised or the transmitted data is tampered with, then this might represent a security issue. So there are security considerations on one hand as well as usability issues on the other. For any cloud-connected service, you need a dedicated user account. If you intend to connect a manufacturer’s ecosystem to Amazon Echo, this access data needs to be stored with Amazon as well. It becomes especially interesting when adding smart door locks to the equation.
There is now some legislation is now underway in the United States, which attempts to force manufacturers to assume more responsibility for the security of their products. If put into practice as it is proposed, devices would need a third party certification and procedures need to be in place which decommission or disable devices which are not compliant with security standards anymore. This also implies that devices with known vulnerabilities (defined as “listed in the NVD” or other vulnerability database) must either be provided with updates or their connectivity must be limited. Alternatively, the vendor can apply for a waiver if he can prove that mitigating steps were taken which make a vulnerability unexploitable. The act even includes a passage, which specifies that any security flaws must be disclosed and fixed “in a timely manner” as well as regulation for properly securing interconnections. Hard-coded credentials or credentials which cannot be changed would also be illegal. Since it is difficult to anticipate the development in hard- and software even for the next five years, this is going to be an interesting challenge.
Still, the bill addresses many of the concerns that IT security specialists have concerning IoT devices. We shall follow progress with great interest.
Conclusion & Outlook: slow is smooth and smooth is fast
In terms of security, a lot of companies are in the process of missing the boat. Other put in a good amount of effort and actually achieve something. It will be very difficult to straighten out the convoluted mess that is the Internet of Things. By all means, this is not to discourage diversity and innovation - there are still many great ideas out there which can be put to great use. Let people have all the Wifi-enabled kitchen faucets, vacuum robots and washing machines they want. However: if security falls off the back of the cart - which happens more often than not, there is going to be a lot of trouble in store for businesses and consumers alike. Yes, a product will might go to the development process a lot slower when security experts are on board. It might be more complex when designing an update routine. But: it will definitely pay off in the long run. If any issues are detected after the product has been launched, they can be addressed quickly, efficiently and effectively through an update. No need to scramble and come up with quick and dirty fixes for a problem that nobody anticipated. No product recalls or manual update downloads. Taking the time to improve security from the word "go" will very likely not take longer than pushing the product out as quickly as possible despite its flaws and having to fix it later.
This would be a neat thing to have - but we are not there. Not yet. Politicians, governments and security experts have read manufacturers of insecure devices the riot act countless times and made plenty of suggestions. Now it's the industry's move to act on those. The best moves the industry could make is to slow down their product development to accommodate security, in order to become faster to react to new threats.
In the next part of this mini series we will take a look at the challenges facing the Internet of Things in terms of security vs. usability as well as sustainable market strategies which contribute to increased security and privacy.
