Once again a number of systems were hit by ransomware. In Denmark, where I live, the high-profile case is Mærsk – the shipping/container/oil company. We only just got back to normal after the infamous “WannaCry”, which by chance was soft on Denmark, because we all had the day off 🙂
Clearly ransomware, as well as other vira, is something we will get used to in the future. We can expect this in desktop-computers, in cloud-servers and in IoT. All these systems are vulnerable because the overall majority run on either Linux or Windows. Target one of these operating systems, and you are targeting many millions of CPU’s.
If you think about it, many of these systems are really only using a fraction of the resources available. Not only in terms of CPU-cycles, but also when it comes to the functions they call. Most IoT systems are probably running a full lifetime, calling less than 20% of the functions they are surrounded by in the OS. This is due to the fact that the main OS’es are general-purpose by design.
So what if we could generate systems only including exactly the function calls we use at the given day of a release?
This is the concept of “unikernels”. See here for a super-short intro: http://containerjournal.com/2017/03/14/unikernels-use-cases-iot-cloud/
As stated in the article, the most obvious use-case is cloud-computers, where many of these micro-systems each run in a virtual machine. It saves on resources, but is also more secure. Each system only has a fraction of the “handles” a virus can pull. On top of this, two systems running different applications will have different “handles”. This will further inhibit the spread of the virus.
Even though cloud-computers are in the front with this technology, it is also possible to utilize in IoT.
If you have an hour to spend, I recommend the following YouTube video on “include OS” from CppCon 2016:
We are headed for interesting times!
In the Second Edition of “Embedded Software for the IoT”, in the new chapter on Security, I discuss the present situation. What are the weaknesses, how are they exploited, and what can we do better?
Yesterday, I participated in a webinar held by the Barr Group. This focused on four basic pillars:
- Static Code Analysis
- Code Guidelines
- Reviews & Inspections
These are very basic and well-known tools, but as the Barr Group has documented on several occasions, we are still to lazy in the embedded community. Way to few teams can say yes to the above four.