Good night everyone 💤 I was watching “Welcome to Derry” (the series, by the way, is not b…

Good night everyone 💤

I watched Welcome to Derry ( The series, by the way, is not bad, except that it’s not scary at all ) at two o'clock in the morning, when suddenly Yandex Station turned off on the screamer, the screen went dark and the firmware update began

Pennywise was able to connect to my speaker, apparently 🤡

But oh well. This won't scare us. But it gave me some thoughts, so I’m writing this post right now, without leaving the cash register.

In principle, the logic of such a station firmware update is quite clear. It’s really better to update IoT devices at night. Not only Yandex does this. This is a generally common practice. The user is most likely sleeping ( I'm so special, I watch horror movies at night ), the device is idle, and it is advisable to install the latest firmware as quickly as possible

But just the particular case of my nighttime insomnia creates quite such a case. It turns out that the user is not sleeping. And the station is definitely not idle

Six paragraphs of prelude to talk... about IoT security ( suddenly ). I know I can surprise 😎

The thing is that for a modern smart device, OTA updates are actually part of the security system. Because after purchase, a device can live at home for a few years, and during this time vulnerabilities will be found in its software, libraries, and network components. Therefore, it is definitely necessary to remotely and automatically deliver updates that close such unpleasant things

But a normal update mechanism shouldn't just follow a rule like "update at night"

The device must verify the source and signature of the update, ensure its integrity, safely survive a power loss during installation, and be able to recover or rollback if the new version fails to download. The update chain itself must also be protected. Otherwise, we will see a special case of an attack on the supply chain 🌝

And one more important detail. The device must understand when it can, in principle, be updated

In fact, “02:00–05:00” can be seen as a good approximation of the “no one is using the device” state. But still this is only an approximation

In my opinion, it is more logical to check the fact of use of the device. That is, we update only if the device is not currently in use

And if the update is incredibly important from a security point of view, then it makes sense to at least separately warn the user and give a short timeout before forcing installation

And I think this is a good example of what Security by Design ( for which I drown ) must take into account convenient scenarios for using the device, and not just security in itself

Security must not break or create difficulties in operating the device ( or anything else ). This is a very fine line that should not be crossed. Otherwise, you can make it so safe that it will be impossible to use it. And I also saw this in my practice 🥺

I understand that you may think that I have made a big deal out of a molehill, but in my opinion, this is a good example of how security should be part of the device, and not interfere with it and its use, as happened in my case

P.S. In defense of the Station: the jump scare has actually become noticeably scarier

🫡 Website | 🤔 Habr

#information_security
#internet_things