For many years, . the number of IoTs has been growing exponentially. We read in the news that the number of devices connected to the Internet of Things is now in the tens of billions.
We also see them in our own homes – we have smart lighting, automatic heating, autonomous vacuum cleaners, and smart refrigerators. And in the corner of the room, Alexa or Siri may be telling us about the weather forecast. This is a positive development. Not only are the devices convenient at home, they are very important to society, for example to increase efficiency in industry, enable power distribution in smart cities and to automate transportation. These systems are becoming so complex that manual systems are no longer an option.
This growth rate has come with a price: security. It is said that the IoT industry today is repeating the information security and cyber security mistakes made by the IT industry 10 years ago. According to Forbes the number of attacks against IoTs was almost 3 billion in 2019 and it is growing. The attacks can be in the form of building botnets for DDoS attacks, for taking direct control of industrial systems or to use the IoT as a bridgehead to get into the main network. Unlike for EMC there has been lack of cyber security standards that have added to the problem. Missing an established level of security has been a challenge for the market, but also for the manufacturers and their buyers as the different parties all have defined their own set of requirements.
In July 2020 ETSI did however publish the standard ETSI/EN 303 645 named “Cyber security for consumer Internet of Things”. And this standard has already been taken into use both in Finland and UK, as well as the standard covers the requirements e.g. of the Californian cyber security act introduced this year.
So, what specifically, needs to be considered when doing a security evaluation to this standard? In this article, we are using the upcoming cyber security standard for IoT products: ETSI/EN 303 645. (NB: this is not a complete list, only examples. The complete standard can be found here)
Passwords must be easy to change, and if preinstalled, they should be unique and randomized. Cryptography is necessary for authentication (not sending usernames and passwords in clear text) and the product must be protected against brute force attacks (trying a high number of passwords).
Storing Security data such as usernames or passwords, is to be done securely. For example, passwords can be stored as a code generated from a one-way coding (hash). Only the code is stored. When a password is entered, it runs through same coding and is compared with the stored code. Also, there shall be no hard-coded critical security parameters in device software source code.
Minimize exposed attack surfaces by closing all unused network and logical interfaces. Minimize code to what is required for functionality and for running the software with the least level of privileges. For example, a software program may not be allowed to delete files.
There must be a function to delete user data from the unit and personal data from associated services, and the user is to receive confirmation of successful deletion.
Protect sensitive personal data by encrypting the data when transmitted. The system must also inform, request consent, and allow for changes to the use of personal data from the user, including all sensing capabilities, for example a camera or a microphone.
Software updates are to be secure, and security updates shall be timely, depending on the risk. Consumers are to be informed of required security updates, with easy or automatic mechanisms for updates.
For easy installation and maintenance, the product shall have appropriate security options turned on by default. A guide or wizard may be used, but secure settings should require a minimum of human intervention, if any.
Run secure booting of system to ensure software integrity is recommended. E.g. by having a hardware device which cannot be altered and there by always can be trusted. (Hardware root of trust).
Secure communication using updateable, best practice cryptography.
If IoT is collecting data the user must be informed of what data is collected, by whom it is being used and for what purpose. For example, the daily on-time may be collected and sent to the manufacturer for development purposes.
If there is loss of power or network the IoT should restart and reconnect after loss of power, and the IoT should remain as functional as possible during loss of network and reconnect when available.
The IoT software shall check for valid input data and recognize improper input, such as out of range data. It should not try to process unexpected input or execute a code written in a free text input field.
EMC is not particularity mentioned in the standard but is nonetheless important when it comes to “loss of network”. Many IoT systems are depending on continuous connections to the IoT devices and any loss of connection is regarded as fault condition. This is the case e.g. for a fire- or intrusion alarm system, where loss of contact naturally will trigger the alarm to go off. For future IoT products being constructed, ensuring cyber security should be as natural as ensuring electrical safety, EMC and radio requirements, and the recently introduced EU Cyber Security Act will be a natural supplement to the existing European directives.
There are three main objectives of cyber security, often abbreviated as ‘CIA’:
Confidentiality:
To prevent unauthorized access to sensitive data
Integrity:
To ensure the data can be trusted
Availability:
To ensure the data is available when needed
The balance in importance of these three objectives may vary in different systems. For example, for a public telephone directory confidentiality is not an issue, but integrity and availability are. So, for cyber security, the first thing to do should be a risk analysis.
Jens Bryntesson Nemko Sweden AB