IoT security – “The safest software is the one not being on the system”

JAXenter: The Internet of Things is – by its nature – a little more prone to attacks from the outside than other systems: Many devices with different weak spots are connected, often to each other as well as a cloud. Are there any ground rules that you should keep in mind when setting up an IoT infrastructure?

If there is a problem or flaw in a system, you have many thousand vulnerable devices out there.

Christoph Engelbert: It’s not only about many different devices, I think the problem is deeper. If there is a problem or flaw in a system, you have many thousand vulnerable devices out there and software updates tend to take quite some time, many based on the situation that an update must be rock solid. Imagine an update breaking devices you can’t reach and that people probably can’t recover to a working state.

Anyway, in terms of general rules of security, it depends on the system. There is, however, a set of common sense rules, which often are forgotten or disregarded out of convenience during development.

SEE ALSO: Setting up a secure DevOps pipeline in 7 easy steps

If your system is built on top of Linux or FreeBSD, do not run your application or service as root. Surprise! But seriously, don’t do it. For all the same reasons as with servers or desktops.

In addition, only put on the system what you really need. Leave out software that is not necessary. The safest software is the one not being on the system. Also, your customers will love the smaller updates.

Keep ports closed. Only have open ports for the absolute necessary and use iptables or other firewalls to actively prevent access to ports. There could be a bug in the kernel itself.

Since we are speaking about the kernel, make sure you’re using a stable but also current version. I know this is hard sometimes, especially since many companies only provide like super old kernel versions, but try hard. Also remove everything from the kernel that is unnecessary. Same reasons as above.

Remove root logins from a debug UART connection. It doesn’t matter with or without password. If I get my hands on a device, I can read the flash, crack the password and get a login. If telnet or SSH is open, that’s even worse of a scenario.

There is so much more, but that should get you to a pretty good base state already.

JAXenter: IoT Security can be achieved on different levels: the hardware and the software. Obviously, both parts need to be taken care of, can you give examples on addressing security on a hardware and a software level?

Christoph Engelbert: Both levels are important. I think software is pretty much everything I said so far, plus many many things more. The most typical for your own application is don’t trust user input. Do not just take the input and run it as a command on the shell. Test and verify input and discard it if it doesn’t match what is expected. Escape queries. Stuff we have heard hundreds of times.

Leave out software that is not necessary. The safest software is the one not being on the system.

On the hardware level it is more interesting. Normally you as the developer (software or hardware) cannot really do something yourself. The chip developers though offer many solutions.

That said, the level of hardware protection depends on the system you’re developing.

Companies often try to prevent IP (Intellectual Property) theft, but forget about the possibility of reverse engineering the firmware and running attacks against your own environment or using your devices to run a DDoS against some third party.

On the hardware level, TPMs, hated or not, are a great way to store encryption and authorization keys. They can be used to authenticate against your services using client certificates and they can be used to decrypt software, verify update bundles and many many more.

The biggest factor, however, may be some kind of Secure Boot or Measured Boot. In this case the CPU knows a public key of an EC (Elliptic Curve) or RSA pair which is used to sign the actual bootloader or firmware. Before executing anything, it will validate the signature of the bootloader and make sure that it was signed by you. The bootloader then verifies the kernel and filesystem and so on. The idea is a chain of trust which goes all the way from the CPU to drivers and applications running.

This prevents most attack vectors with fake firmware updates. Together with the, unfortunately still often missing, server verification and firmware update signature check, you can prevent non-official firmware from being installed or executed pretty effectively.

Depending on the needs there may be other measures but I think that would go way too far.

JAXenter: To make sure your system is safe, you need to test it. Any testing method that is performing very well in the IoT context?

Christoph Engelbert: Obviously run your own tests first. Use tools to try to break into systems. The commonly known pentesting tools are a great start. Unfortunately I’m not aware of any tools specific to IoT security. Maybe I’m missing something or maybe we just found a market gap 🙂

Depending on what services you’re running OpenVAS or Metasploit are a good first run. Especially if you have webservices like an admin dashboard running.

There are a multitude of open-source, free or paid solutions. See what best fits your needs.

SEE ALSO: How security keeps up when developers drive open source

The second step is, hire an external company and run pentests, not only against your cloud infrastructure but also the devices.

Ask hacker groups, like the CCC (Chaos Computer Club), if they would like to help. Offer compensation and goodies like to keep the devices. The important bit here is, listen to them, take them seriously, react to questions and findings!

Ask hacker groups, like the CCC (Chaos Computer Club), if they would like to help. Offer compensation and goodies.

Oh yeah and in general, make sure that you always react quickly to security issues or vulnerability findings. It’s a bad habit to first dismiss any claim there could be something wrong. Take every request seriously. Let them know you’re looking into it and do it in a timely manner. Don’t expect them to wait months for an answer to a security problem. And, last but not least, work together with them. Let them show you their findings, let them explain how they did it. Give them praise and credit.

Missing any of the above points won’t make your marketing department happier than somebody finding a vulnerability and claiming afterwards “I told them, they were super responsive and acknowledged the problem and fixed it.” Believe me, bad handling of those situations spread like a wildfire.

JAXenter: How can you make sure that updates to one device or component do not open up the system in its entirety again?

Christoph Engelbert: There is no good way except to test it again. Have a company run a pentest. Have others try to break into your system.

But, as I said, as long as you try to keep the absolute minimum on the device and have all non essential components removed, you’re already one step ahead of most of the competition.

There is just no reason why a lamp should have a telnet or SSH service running.

JAXenter: Are there any tools or open source software components that you can recommend for a secure IoT system?

Christoph Engelbert: As I said before, unfortunately, so far I don’t know of any tools specific to IoT security. Happy if somebody knows and could share though.

The general pentesting tools are a great way to start. If you have the chance, maybe hire somebody with the hobby of breaking IoT devices and reverse engineering. You probably can’t get better knowledge and in-depth insight.

The post IoT security – “The safest software is the one not being on the system” appeared first on JAXenter.