Posted by Stefan Eberhardt | March 13, 2020
While all that stuff like TPM and secure/trusted boot is good to hide and secure what's inside the box, it helps to protect a system from mostly physical attacks. However, the attack scenario in the industrial environment is quite different.
In most cases, there is no public access to the systems and even if so, the systems are locked away in some sort of control cabinet or enclosure. The more problematic aspect is, that people started to connect systems that where never connected before, and by this exposing them to all kinds of threats that can come in over an ethernet interface. Regardless if it is a traditional LAN-cable or WIFI or G5 – the connection is definitively where most threats dip in.
So if embedded industries want to get a security foundation: As long as its not a consumer device, they should start using an individual certificate per device (which maybe is stored on the internal drive only) instead of just adding an additional mechanism to secure the boot process. Don't get me wrong, a secure key store is an important tool and mechanism, but first things first.
HOW SECUREOS SIMPLIFIES THE UPDATE PROCESS
To extend this a little bit: it is more important for most use-cases that the communication line to the server is secured, then that the key that is used for encryption is stored in a secure location. For sure, somebody could break the device and extract the key from the internal drive, but embedded systems are normally not accessible that easy, so that attack vector is not the most important to take care off in the first step.
And yes, we all learned from mostly Microsoft (thank you) that updates are an important mechanism to prevent threats. So, in the industrial environment we need them too, but the focus is slightly different:
- Owners don't want updates, they just want their system to run in a secure way
- Industrial machines get switched on/off like a desktop light and nobody allows them a graceful shutdown until something is done
- All machines in the field should behave the same
- They should run for 15-20 years
- Most of them are very custom and you cannot use a standardized operating system
So, we at Kontron Technologies address this with our SecureOS. For our customers, we tailor a hardened Yocto operating system to their specific needed HW and Software. Yocto is here an important element, because it allows us to control and patch everything. Also, it is important to update, so we have implemented an atomic update process. We check everything and roll it out, so that there are no devices in the field that have some updates, while some have not – instead they will all be on the same update-level. I often see the contrary, when standard Linux distributions are used, which works well when you do your POC or with a low volume product, but if its about several hundred devices a year or more, you should consider a different approach.
Of course, we also have a fallback mechanism integrated, so the system or the operator can always switch back to the last working version and so prevent downtimes.
DEVICE INDIVIDUALIZATION FOR MIXED CULTURES
So that’s basically the core of our SecureOS offering, but of course every customer is different - they require updates on different schedules, threat scenarios and exposure and of course they want to determine themselves when an update should be rolled out - that usually the 10-20% customization, that we do for our customers here.
So, summing up: If you want to secure a lot of control units in the field e.g. connected coffee machines, you have a good scenario for a monoculture, where all devices have exactly the same software and programs installed. If you require your devices to have different sets of programs installed and want to manage them from a centralized backend, you need a different approach That’s why we offer device individualization on top, focusing on which programs runs on which machine. For this we need of course some sort of bigger backend to control the distribution, but that’s something I'd like to explain in my next blog.