IoT Security Top 20
November 3, 2016 - When making an IoT device here are the ‘top 20’ things to keep in mind.
By now, I’m sure most of you have at least heard of the latest wave of malware that is infecting ‘Internet of Things’ (IoT) devices, and causing massive problems through Distributed Denial of Service (DDoS) attacks. There are actually multiple streams of this, the most common being Mirai, but with new types emerging at a disturbing rate.
I expect that this sort of attack will only increase into the future. Why? Well, if we leave aside the fact that it’s easy (I’ll get to that) – it’s also both profitable and powerful. People are setting up services to ‘rent’ out their IoT botnets, literally as DDoS as a Service operations. It’s been referred to as the ‘democratization of censorship’, by one of the first individuals to feel the full extent of this new tool. If you have the cash, and you don’t like what someone is saying, you can now literally kick them off the Internet. A recent attack all but crippled access to the Internet throughout a large part of the US, and was potentially a ‘revenge’ attack.
The sad thing is that many of these attacks are based on simple problems in the security of the devices they infect. For example, the Mirai malware, as well as the more recent ‘new Aidra’ Linux/IRCTelnet malware, infects devices by attempting to log onto devices using a list of common (default) username/password combinations. Sometimes these attacks are made more simple through the use of simple, and unsecured, protocols such as Telnet, or use other attack vectors that aim for weaknesses in the software of the IoT devices.
We know how to fix these problems!
Now, I used to make stuff too – I understand the pressures on development, in terms of time and cost budgets. Although simple things like default passwords don’t take a lot of time to fix (for example, you could generate unique passwords and print them on the serial number sticker), they can get lost in the push to get product to market. I get it. I’m not here to rail at the product vendors, to say that products are insecure and it’s the IoT apocalypse; I do think that we’re facing a genuine crisis here, but I also feel strongly that it’s not ‘too late’ and we have the opportunity to fix these problems before they get out of hand.
The UL mission is ‘working for a safer world’. I firmly believe in that mission, and I equally firmly believe that IoT security is a safety issue. Security and safety are hard to separate in this day and age, and in fact in some languages there are not two words to describe them; security literally equals safety. Back when William Henry Merrill founded UL in the late 1800s, electrical safety was the thing – appliances and buildings were literally catching fire due to poor knowledge and practices around electrical safety. Now, we take it for granted that appliances and buildings won’t spontaneously combust (although there are some things UL still won’t certify – I’m looking at you Turkey Fryers).
So, in the interests of working towards a safer world, I’m here to help. Below I’ve provided my ‘top 20’ list of things to keep in mind when making an IoT device. This is not UL’s list – this is the world according to Andrew. This is not a comprehensive list – there are more than 20 things, but these are the top ones (according to Andrew). This list is not a guarantee of security – you could implement all of these and still have a security problem with your products.
However, this list is a start. If you just followed items 3 and 4, the Mirai IoT malware I have been talking about would not be affecting your devices. If you can follow all 20, I think you’ll be in an industry leading position – but of course, some of these items will have a larger commercial impact than others. Feel free to pick and choose. I am not here to judge. I am just trying to make the world a safer place.
- Allow for software updates, and ensure that these updates are cryptographically authenticated prior to installation and execution. Where possible include a monotonic identifier in each version that is used to prevent ‘roll-back’ of previous, vulnerable versions of firmware.
- Implement a power-on self-test that validates core functions and the integrity of firmware prior to execution. Implement a cryptographic chain of trust from the hardware during boot where possible.
- Ensure that any system defaults – such as passwords, certificates, or keys – are forced to be changed prior to initial operation.
- Ensure that parameters for which the disclosure could lead to the compromise of the device, such as secret/private cryptographic keys, passwords, etc, are unique per device.
- Device management services which may affect or alter the security of the device should require authentication prior to access. This authentication must be unique for each device, and implement a time-out to prevent perpetual authorization.
- Do not store passwords in clear text.
- Ensure that cryptographic keys are only used for a single intended purpose.
- Only utilize industry standard cryptographic algorithms and modes of operation for any security protocol (such as firmware authenticity checking).
- Ensure that methods used to generate or negotiate cryptographic keys ensures that these keys are sufficiently random.
- If the device may be utilized to communicate over an insecure or public network, allow for the use of an industry standard security protocol for this communication.
- Implement ‘least privilege’ in the execution environment of the device. Whenever possible keep the use of ‘root’ or ‘supervisor’ level privileges to an absolute minimum, and maintain secret data – such as cryptographic keys – at a highest level of privilege (ie hardest to access).
- Ensure that remote interfaces, such as web services, execute at the lowest privilege possible and require authentication for access
- Provide the ability for users to disable parts of the firmware which implement features they may not want, or they may use only intermittently.
- Implement protections to prevent the execution of data memory.
- Do not allow for direct execution of externally provided commands, scripts, or other execution parameters that are not within the defined functions of the device.
- Create and compile the firmware of the device such that it contains only code and systems required for the defined functions.
- Perform an auditable review of the firmware, and any updates, prior to release.
- Test the device to be sure that it is free of known, exploitable vulnerabilities prior to release.
- Implement a vulnerability management program to regularly monitor and address security flaws in the product prior to release and throughout the agreed lifetime of the device approval. Include as part of this a process to inform and distribute patches to customers.
- Any vulnerability management program should address processes to mitigate the compromise of cryptographic keys (eg root certificates) which are relied upon for the security properties of the device.
In my next post(s) I will try to outline ways in which you can implement some of the guidelines above. However, there’s probably a post in each one, so I will leave that for next time. If you have feedback on any items, think I’ve missed something, let me know – name’s Andrew Jamieson, and I work at ul.com, I’m sure you’ll figure out the email.