For some, the Internet of Things is still a long way off – for others, it’s part of everyday life. More and more frequently, more or less “smart” devices are cavorting in our networks. This applies both to private networks and increasingly to corporate environments. The list of devices is as long as it is diverse. From multifunction printers and conferencing solutions to smart lighting solutions and “gadgets” and (voice) assistants, it’s all there. These devices are not generally “the devil”. Rather, the advantage of using them must be compared with the possible risk in order to be able to make a sensible decision.
It becomes problematic if you only “estimate” the risk – and unfortunately, that often happens. Let’s be honest: When have you ever really taken a closer look at the safety of a device in order to weigh up the risks? At least for me, I can say that over the years I’ve gotten a feeling for how something works, and then I often transfer this experience – incorrectly – to new scenarios. This often goes surprisingly well for a long time – until it no longer works.
“Phone socket home …”
Imagine the following scenario: You integrate a new device into your network. The appropriate configuration app on the desktop or mobile device allows you to conveniently set up the device and also configure it later. In the back of your mind, you now check various security aspects quasi-intuitively as well: Connection to the outside? If yes, then only out from the device; in you don’t need a firewall rule. Configuration and control via the app in the local network? Then they will probably communicate with each other via (W)LAN. Does the device need external services? Probably not, the app does that locally. This is certainly how many people think when integrating new devices – whether privately or in the company network.
But beware: As always, the devil is in the details! Who would expect, for example, that the command in the app to switch on the light always goes via the cloud, even if the app and device are on the same network? Put simply, the device listens for new messages (“Subscribe”) at an MQTT server. If you change the setting in the app, it sends a message to the MQTT server (“Publish”), which in turn is reported to the device. Although no ports are open “to the outside”, the device actively and permanently receives commands from outside. What at first glance looks like the gut feeling “then the app will probably send the command to the lamp in the LAN” is in fact a communication “over the wire” to, via, and from the outside.
Is the device online?
To be able to look at and assess the risk, the first step is to find out whether the devices also work “offline”. In the simplest case, you can cut the Internet connection (for example, pull the DSL cable in the router, cell phone in flight mode/only WLAN activated) and then see what or whether everything still works. Alternatively, you can of course look directly at the communication and record the network traffic. Please also note that different devices “call home” at different times and may also work without Internet – just better with it. Some IoT devices also require an Internet connection only initially for setup (for example, for licensing and installing firmware updates).
So check all devices brought into the network – especially those that are connected by users “just quickly”. In times of mobile apps that transfer the entered WLAN settings “quickly and conveniently” via Bluetooth to new devices, the effort required for integration has also been massively reduced. This does not mean that you have to completely technically check every single device. However, if a new class of device appears, caution is the order of the day, at least for the time being. Just because you don’t see the need for external communication at first glance (the app communicates locally with the lamp – doesn’t it?), doesn’t mean it doesn’t exist.
This article first appeared in the Security Newsletter of LANline, WEKA FACHMEDIEN GmbH. You can subscribe to the newsletter here.