The IoT Security Challenge and Regulatory Responses

The four IoT mega trends described in our previous blog post raise some questions about security and regulation. In this part we will investigate the key drivers behind current and future IoT regulation.

Why is IoT security becoming such a strong concern now?

As the number of IoT devices grows exponentially and the capabilities of Internet of Things systems constantly evolve, both information density and sensitivity are increasing. In addition, IoT systems are continuously moving from being passive sensor systems to active control systems. This is true both for industrial applications, as control systems are being connected and moved out of their air gapped silos, as well as for consumer devices that start to control smart homes and other systems. This development leads to an increased concern for the security of the various IoT devices.

Many IoT systems are based on standard operating systems. An embedded Linux device is no different from a full Linux server when it comes to capabilities and functions. On the one hand, this makes device development easier and faster. The downside is that this makes the unit just as susceptible to attacks as a regular server. In contrast to a server deployment, an IoT system usually does not have a dedicated system administrator. Some companies have recently started to focus more on OT (operational technology) and include this as a part of their IT strategy for IoT devices, but this is far from common yet [1]. 

An embedded Linux device is no different from a full Linux server when it comes to capabilities and functions.

This raises the question of who is responsible for securing these devices throughout their lifecycle, as libraries might need to get updated and new attack vectors are identified. IoT systems can be misused for attacks on public infrastructure both in the physical world as well as on key internet and communication infrastructure. Since these devices are highly distributed, it is very difficult to fight these attacks. At the same time modern society is building an increasingly complex technical infrastructure that is more and more controlled by automated systems. This infrastructure has to work flawlessly, because society depends on it. Both industry and society generally are pushing for an increasing digitalization and it seems that most people acknowledge the opportunities and benefits that this can bring. At the same time, most experts have concerns about the lack of technical minimum standards, that operational responsibilities throughout the lifecycle are not clearly defined and that there is no standard procedure if a security risk surfaces.

Developing geopolitical factors introduce additional concerns with regards to IoT. Many countries are in a secret (or not so secret) arms race to develop or extend offensive cyberattack capabilities. The well-known Stuxnet worm is only one example. This link shows some recent cyberattacks. These are only minor attacks and only the ones that are publicly known. But it clearly shows that these do happen and increase in frequency.

Badly secured IoT technology can bring down a whole country and this has not gone by unnoticed by think tanks and strategic advisors that flag their concerns.

Why is there so little regulation in place so far?

This is a question that is difficult to answer. In my humble opinion, this is a combination of lack of competence in some regulatory agencies, bad international collaboration, conflicting commercial interests and lobbyism that prevents extensive regulations. It is also hard to define exactly who should carry this responsibility and ultimately the financial burden this can pose. It is easy to think that any company utilizing industry 4.0 IoT components (which often are just legacy M2M devices connected to the internet) should be responsible for their own security. But when a company decides to build a new factory building, they need to adhere to all kinds of regulations: for snow load on the roof, air flow in the building, amount of light at the workstations and all machinery is of course CE and FCC compliant. So, it is not completely clear why regulators don’t demand more security from IoT components and projects. Especially, when public infrastructure is at stake, there should be minimum security requirements. When a utility company is installing smart home components that can actively impact the power grid or a manufacturer of electrical vehicle chargers is connecting these to the internet, there needs to be some minimum certification and clearly defined responsibilities throughout the product lifecycle. 

IoT projects come with their own specific challenges. These projects often consist of a multitude of components from different vendors that are being integrated into a project by one or more system integrators. Who should then carry the overall security responsibility?

Who should carry the overall security responsibility… and for how long?

Here is a very typical and simple example case to illustrate this: A system integrator uses a 4G cellular gateway to gather wireless sensor data and transmits this to a cloud backend for further analysis. The 4G cellular gateway manufacturer delivers the hardware with a standard support user. For convenience the standard user and password are then “support” and “support”. If this gateway is rolled out into production at large scale without fixing this, who will be responsible? The system integrator or the vendor / manufacturer? Does it make any difference if this was clearly stated in the gateway manual with a request to change this, or if it was not mentioned at all? 

Another very typical challenge follows from this: The system integrator purchases the gateway as an item that will be included into the system. They pay a one-time sum to purchase the gateway. The gateway manufacturer promises to update the operating system within the general guarantee of the hardware device if there are any vulnerabilities. This guarantee is good for one year. There is no additional service contract between the system integrator and the manufacturer. The IoT system has a lifetime of 10 years. So, what happens and who is responsible when a new bug like Heartbleed is discovered within the lifetime of the system? This can even become more complicated when the system operator is selling the overall system not with a service contract but as a one-off delivery (which still is common for many IoT projects). Would the final customer be responsible for the device and who in this value chain is capable of fixing this from a technical point of view?
How would this scenario change based on two assumptions?

• The compromised IoT gateway is used to attack other devices that are part of the IoT project, so the damage is contained within the project.
• The gateway is used as part of a botnet attacking critical public infrastructure.

All these open questions give an indication of why regulation of IoT is difficult and most of all it has to be a coordinated effort. But without raising any liability questions it might be difficult to get the industry aligned. Additional security will create additional business opportunities but there is a cost as well. There needs to be an understanding that security is not only a cost but also adds value. Most other parts of the IT industry have understood this a long time ago. Otherwise it is not understandable why companies or governments still pay large sums for Windows 7 support [2].

Which regulations exist and how does the future look?

The regulators are awaking. There are good initiatives going on but often these are still recommendations and it is not always clear what the consequences of a breach actually are, or how they can be reported. Below are some example regulations:

California

California has passed a privacy law for the internet of things (IoT) that regulates connected devices. This law with bill number 327 [3] became effective 1^st of January 2020 and demands “reasonable security features” from device manufacturers. These security features are defined as follows:

• appropriate to the nature and function of the device;
• appropriate to the information the device may collect, contain, or transmit; and,
• designed to protect the device and any information contained therein from unauthorized access, destruction, use, modification, or disclosure.

So this law forces all manufacturers that want to sell in California to comply from 1.1.2020. More concrete the law demands that:

1. The preprogrammed password is unique to each device manufactured; or
2. The device contains a security feature that requires a user to generate a new means of authentication before access is granted to the device for the first time.

This would at least resolve the previously mentioned case of a gateway still running default users and passwords.

Oregon

Oregon also passed a law becoming active from 1.1.2020. They use the same “reasonable security features” language [link not available any longer].

Both regulations in California and Oregon were criticized by the security community because they were not going far enough. This is merely seen as a first step and a test balloon. However, it forced major manufacturers to finally fix the bad password habits. 

UK

The UK is working on a regulatory proposal for consumer IoT security. It is not fully clear when this will finally pass [5].

The content states the following:

1. All consumer IoT passwords need to be unique (and not resettable to non-unique factory defaults)
2. All manufacturers need to provide information about a public point of contact such that flaws can be reported. There is a responsibility to be “acted upon in a timely manner”
3. A device manufacturer needs to explicitly state the minimum length for which a device is getting security updates at the point of sale

Again, there are good intentions and the proposal accompanies/replaces the voluntary “Secure by Design Code of Practice” for consumer IoT security from 2018. But also this regulation is rather basic even though it surpasses the US ones.

United Arab Emirates

The United Arab Emirates have recently passed a regulation for IoT. This is both relevant to consumer and industrial IoT. The interesting case here is that they provide information about real sanctions. A breach of the IoT policy might result in a business being suspended from being able to deliver IoT services [6].

Key objectives from this regulation are:

1. a registration of the IoT service provider and they need to have information about their subscribers (subscriber’s name, address and ID, the device’s model and registration number…)
2. data protection with focus on purpose limitation, data minimization, storage limitations and storage requirements 
3. encryption standards – these need to fulfil the requirements of the UAE authorities
4. SIM card regulation (soft sim cards need approval)
5. Type approval of RTTE (Radio and Telecommunications Terminal) equipment used in IoT including a passus on “security by design)
6. M2M numbering plan

This regulation is more in line with a requirements document for an IoT tender and it leans a lot towards telco requirements. It probably is very flexible and can be used to enforce strict regulations but it gives less concrete action points for manufacturers of IoT devices as it focuses very high in the value chain.

Europe

Currently there are no real strong IoT regulations in place within the EU. There are directives and standards that cover a lot of the necessary technical topics. Some examples are a range of instruments to protect electronic communications networks, including the Directive on Security of Network and Information Systems (NIS Directive), the EU Cybersecurity Act, and the new telecoms rules.

In addition there is the Cyber Security for Consumer Internet of Things ETSI standard EN 303 645 [7]. This document has a lot of very good points and real examples. It covers many of the critical topics mentioned in the first part of this article and is definitely worth reading.

But the key question is: When will European standards and directives finally become binding? 

Currently, they will become binding when a contract is signed that mandates that a supplier is compliant with a specific standard. But in general, all standards like ETSI EN 303 645 are self-regulations for the industry and cannot be enforced by law if not implemented into contractual ground work. Therefore, it is important that tender processes refer to these standards and make them part of the deliverables. This in return will force suppliers to apply higher security standards to their deliverables pushing all the way backwards through the IoT value chain.

Future Outlook

Both legislators, the public sector, private companies and consumers start to demand more from the IoT industry. Since this is inherently a global industry some of these demands will quickly become standards and minimum requirements in order to stay competitive. This can already be seen with the firmware updates that gateway providers issued to fix their standard password problems. But in consumer IoT, with the existing margin pressure, it is unlikely that obligations and best practices are implemented without the possible consequences of strong sanctions, especially when rebranded Asian low cost systems are sold in Europe. Here stronger regulations are needed and also a good and preferably global way to enforce them properly.