In an earlier blog I discussed how embedded memory might be attacked through a forced memory buffer overflow, and I indicated how to protect against such an attack. However, while the countermeasures I suggested are relatively simple ones, certainly at the engineering level, there are other methods of attack which are harder to thwart. Also, the bigger picture of implementing cybersecurity is quite daunting, and that’s what I’m going to discuss here.
Most embedded systems tend not be designed with security in mind. Functionality, low power, small form factor and, of course, cost typically all have greater priorities. When a system is designed to connect to the IoT, its exposure to cyberthreats is a given. If a legitimate user can access a system remotely so can a hacker; and in many cases, they can do so without leaving a trace of ever having been there.
Without question, security should be taking a much higher priority than it currently is because, once an IoT-enabled embedded system is in the field it is part of an ever-expanding attack surface. For example, last month, IoT Analytics – a provider of market insights for IoT, M2M and Industry 4.0 – estimated there will be more than 27 billion IoT connections by 2025.
In addition, attack methods are becoming more sophisticated and cybercrime is now a business with, for example, ransomware as a service (RaaS) malware toolkits available on the dark web, as reported in a recent Cybercrime Magazine article. Also, state-sponsored cyberattacks are on the increase. These target critical infrastructure that is controlled by one or more embedded systems; and I discussed operating technology (OT) embedded systems in my earlier blog.
While ransomware attacks that make the news relate to companies and organisations having their PC-accessible files encrypted so that the hackers can demand a ransom to restore access, embedded systems are also at risk. Many are designed or retrofitted with IoT connectivity for diagnostics and updating purposes. Imagine a scenario where there are several hundred devices in service around the world, and there might be a just a few or even a single PC responsible for communicating with them. The PC/PCs would be an ideal target for a hacker, as all devices in the field could be given new code and a bootloader file (one that will not allow further updates). This means an entire family of embedded devices could be put out of commission.
Outdated = Higher Risk
Where embedded systems are intended for industrial applications, and join the industrial IoT (IIoT), they will most likely be expected to have far longer service lives than IoT-enabled white goods, for example. The ability to add new functionality to systems in the field is often a requirement and doing so remotely via the internet has its attractions.
However, most updates require a reboot; during which it executes commands that are not part of normal run-time operation. Unless the system is well-architected, it could be vulnerable to attack during the reboot.
The updates should be more than just new functions though. Security patches are essential. Many systems use the open-source Linux OS. Unless mechanisms are in place for the system to automatically check for updates it will be down to the user to check at regular intervals, as the longer a system goes without security patches the greater its exposure.
The designers of most IoT-enabled embedded devices – and here we are talking software, hardware and systems engineers – will be skilled at designing to meet those requirements I mentioned earlier; within budget and on time. They will have a very focused view of ‘their system’, its intended behaviour and the legitimate ways in which it will interface with networks and a ‘broader system’.
Few embedded systems designers are fully up to speed on all issue cyber, which makes it difficult to envisage how attacks might be made. If insufficient attention is given to cybersecurity, then the device and others on the network are at risk. Conversely, too secure (if there is such a thing) and other design goals are compromised. For example, user authentication might be slowed down by encryption and decryption performing addition handshakes between devices.
Walking the line between not enough and too much security is difficult, but I think we’re all in agreement there should be some security because even low-value IoT-enabled embedded systems/devices that perform minor tasks are a doorway onto a network, putting higher-value and more critical systems at risk.
In my next blog I shall offer some advice on how to secure your embedded system. In the meantime, you may wish to check out our ‘Securing Your Embedded Memory’ guide.
