In our increasingly connected world, embedded systems, such as those at the heart of IoT and IIoT devices, need to carry sensitive data. Accordingly, if you’re an embedded systems designer, you’re advised (certainly by us) to not only make security a priority from the start but also to think beyond just software measures. Securing embedded memory is the ideal starting point because, after all, that’s where the sensitive data resides. You should ask yourself ‘How Secure Is My Data?’
The process of securing embedded memory starts with understanding how data might be at risk, and that’s what we’re going to discuss in this blog. For convenience, we’ll refer to IIoT throughout this blog.
Risk Assessment
There’s much advice online about this subject, most of which urges you to take a step back and consider what the data is used for and why someone might want to steal or corrupt it. The advice is good, but most of it relates to general IT platforms such as PCs, laptops and tablets.
As an engineer, you’ll appreciate embedded systems, such as IIoT-enabled devices, are somewhat different from generic IT platforms. They’re far more application specific, typically designed to monitor and/or control an industrial process. Adding security is not as simple as installing some commercial AVS and, even if it were, you’d be forever updating it as it’s likely your IIoT-enabled embedded system is to have a longer service life than (say) a laptop.
An ideal form of risk assessment is to determine the attack surface. There are essentially three areas of vulnerability.
- There are many aspects of software that can be considered unsafe. These include the bootloader (many systems are vulnerable during boot), the OS (if it has one), the application service and how the application/OS manages memory. Regarding the last of these you may wish to refer to the Memory Buffer Overflow Attacks section of our ‘How to Secure Embedded Systems’ guide.
- Comms protocols. These include a wealth of wireless ones, such as Wi-Fi, LoRa and ZigBee. Vulnerabilities include jamming, denial of service and replay-based attacks (man-in-the-middle). Communications through the airwaves can always be intercepted, so you must consider the importance of that data.
- This will include unprotected interface ports and, of course, memory – within the micro, dedicated memory chips and any portable devices that your device may use for day-to-day operation or infrequent actions, such as firmware updates).
These three areas of vulnerability effectively equate to the three states your data will be in at any given time: in use (being processed), in transit (coming into or leaving your device) or at rest in memory. A hack (code alteration) can change how the data is processed/handled. Data can be intercepted in flight. And data at rest is at risk if a hack tries to read or replace it. There’s also theft of the physical device to consider.
Conclusion
Although this blog, Securing Embedded Memory part 1, was about determining how secure your data is, our advice is to assume your system will be operating in an increasingly unsecure environment (as other devices, perhaps not as secure as yours, join the IIoT).
This assumption is at the heart of ‘zero trust’.
Also, put aside the ‘why’ someone would want to steal or corrupt the data residing in or being handled by your IIoT-enabled device and fast-track to the effects of it happening. And as your data, and the program that handles it, reside in memory your risk assessment should focus on the ways in which it might be accessed by an unauthorised user.
In Securing Embedded Memory part 2 we’ll be looking at secure booting, authentication and encryption, plus more.
