What kind of security do embedded systems need?

Although embedded computing systems are crucial business tools for many companies, their security is often overlooked. Systems such as ATMs, payment terminals, vending machines, ticket kiosks, medical computer tomographs, and even automated gas stations handle financial and other confidential data that criminals can use to their advantage. This makes these systems attractive targets for cyberattacks, so protecting them from cyberthreats should be a priority for any company. However, despite their apparent similarity to conventional computers, embedded systems have a number of significant differences that must be considered when developing a security strategy; otherwise, companies may face a range of serious challenges.

Features of embedded systems

Usage model. Unlike a conventional computer, which is typically used by a single employee for a wide range of tasks, an embedded system can have an unlimited number of users, and usually provides a meager set of functions built into the system during its initial creation. Interaction with such systems is often carried out using specific input devices (such as a digital keypad or a touch screen with a narrowly specialized user interface) that do not permit the execution of arbitrary commands and files. Ports for connecting external peripherals to these devices are usually accessible only to technical specialists. Communication with the outside world takes place through the internet and local network; in addition, embedded systems are often used with functionally-limited storage devices such as banking, savings or discount cards. Such systems should in no way be used for reading emails or visiting websites — that way attackers cannot rely on these vectors for infection. However, the significance of network connections is increased. And this is one of the main channels used for attacks on embedded systems; after all, almost all types of embedded systems have a connection to the company’s local network — meaning that once inside this network, attackers can reach these specialized machines. As for ports, the specific physical location of such devices can help a hacker.

Physical location. To facilitate the usage model, the vast majority of devices based on embedded systems are located in public spaces. Typically, device components are protected from unauthorized access by a sturdy steel casing and interaction restrictions. However, all devices require some degree of maintenance, so even those with the most robust encasing need to be openable with a key. And this is where attackers can enter. Having gained access to the hardware part of the device, they can connect a standard mouse and keyboard, a storage device with the malware they want to use, or even an operating system that can allow them to bypass the hacked device’s own OS. In some cases, attackers even connect a single-board computer with which they can hack the system or, for example, analyze commands that make the dispenser issue banknotes to the user. The rest is pretty straightforward: the hacker just needs to introduce their tools into the embedded system and then they can make it do whatever they want — from dispensing money or conducting shadow transactions to stealing user data. Unless, of course, the embedded system is properly protected.

Long-term use and limited system resources. Embedded systems are built for specific, highly specialized tasks, so they usually have only the “necessary and sufficient” level of processing power. Since devices using embedded computer systems often have a long service life, it’s not uncommon to encounter functioning ATMs or cash registers with weak, outdated hardware. From a security standpoint, this can pose a significant problem: such a configuration is clearly not compatible with many of the latest security solutions.

Outdated, vulnerable software. The long life of expensive devices based on embedded systems generates another side effect: outdated software. Often, it’s simply impossible to use a newer OS on a modest system configuration, and current specialized application software may not work on the old OS. And sometimes, the new programs necessary for working with the unique peripherals of the device (cash dispensers, card readers, medical monitoring systems, tomographs, and so on) may simply not exist. The consequence of this is that such systems for which security updates are no longer released are actively targeted by hackers. But finding a solution that will work on an old OS, such as Windows XP, and at the same time protect against current threats is extremely challenging; the vast majority of security product developers have discontinued their support for legacy operating systems.

Weak internet connection. Some devices, such as ATMs, ticket terminals and automatic fuel dispensers, may be located in remote places where there’s no wired internet. Also, wireless network access in such places is usually based on cellular communication, so it may work slowly and with interruptions. Application software is designed for such a scenario; for example, transactions can be serviced asynchronously by a bank — they are performed when the connection allows it. However, many modern security solutions are much more reliant on a stable communication channel. In an effort to reduce deployment time and the size of installed software, they rely heavily upon cloud infrastructure, which means that if the connection is poor their performance may be impacted.

Regulatory requirements. Since the vast majority of embedded systems handle valuable financial and personal data, their operation is regulated by relevant legislation. Though regulatory bodies mandate the presence of reliable protection, its implementation is largely left up to companies; however, the task is to minimize the risks of an incident occurring while ensuring that detailed logs are recorded for investigation if an incident does occur. Moreover, the list of recommendations may include certain technologies, such as system integrity control, which are simply unavailable in typical endpoint security solutions, or are provided only in server versions.

Seeking a compromise

Summing up, these systems are multi-user, single-task, low-power, and susceptible to specific attack vectors (network connection and/or direct device access). At the same time, they handle extremely valuable data (not necessarily financial data; it could be personal medical information in the case of medical equipment), for which not only confidentiality is important, but also integrity. There may be a number of difficulties regarding the data’s protection, as a typical endpoint security solution will face problems working on weak hardware, and generally won’t work on outdated operating systems, which are still quite common. If such a solution does run, there may be performance issues, and sometimes compatibility issues too (after all, the solution is intended for regular computers).

One of the approaches that many manufacturers of security solutions for such systems have taken is to completely prohibit anything that’s not needed for the device’s main task: application control technology in default-deny mode simply blocks any programs not initially included in the so-called allowlist. In theory, this means you don’t need any threat detection mechanisms; a virus simply won’t run, nor will any other unnecessary program, and such technology requires very few resources — allowing the solution to work even on very weak systems.

However, this approach may be powerless against, for example, code injection into a legal, already running process in memory — which can be achieved through exploiting those same vulnerabilities in outdated software. Techniques developed by hackers to exploit elements of the system itself for malicious purposes often mean that the use of actual malware is reduced to a minimum. Yes, there are also fewer options available to hackers in a weak system, but… a business dependent on embedded systems, such as a bank or retail network, is unlikely to use only devices belonging to just one generation. This gives hackers some room to maneuver. What to do? Should you install different solutions — products based on the default-deny principle on weak systems, and a regular antivirus for workstations on more powerful machines, hoping to avoid compatibility issues? Or try to find a truly universal solution?

Special protection for special devices

If you look at the current security solutions for embedded systems on the market, most vendors offer two options:

• An “economical” resource-efficient solution that can work on outdated systems but offers simple single-layer protection based on application control technology and default-deny mode. This option usually lacks the means to resist the full range of typical attacks on embedded systems, and is often managed separately from other products in the vendor’s ecosystem, creating additional challenges.
• A typical endpoint security solution. For newer systems, most manufacturers suggest installing the same solution that protects regular workstations. Undoubtedly, such solutions have an up-to-date stack of security technologies and can be integrated into the vendor’s ecosystem. However, they usually lack certain technologies specifically required for protecting embedded systems. Also, such solutions only work on the latest and most powerful devices, leaving behind still functional but outdated ones.

Even if both options are used simultaneously, the full range of problems cannot be addressed. Moreover, inconsistent management approaches can make the work of IT and security admins much more complicated (especially if solutions from different manufacturers are used).

Based on all this, let’s try to imagine the ideal security solution suitable for a wide range of embedded systems and their use scenarios:

• The solution should provide the maximum possible level of protection. In today’s world, this means having a stack of various technologies to protect against the range of attack vectors and techniques typically used on embedded systems of all types.
• The solution should provide maximum protection to systems with different capabilities — both old, low-spec ones, and the newer ones with plenty of computing power and memory. However, since it’s simply impossible to physically run every technology simultaneously on weak hardware, scalability is required. In other words, the solution should allow separate management of protection layers so you can disable unnecessary tools and activate those which provide maximum protection for a specific hardware and use scenario.
• The solution should support the most popular operating systems used to create embedded systems; that is — at least Windows and Linux.
• The solution should support outdated OS versions used on embedded systems that are still in operation.
• The solution should meet regulatory requirements, have recommended technologies in its security stack, and be able to perform detailed event logging in a centralized security event monitoring system (SIEM).
• The solution should be thoroughly tested for compatibility — at least with typical configurations of different types of embedded systems. Ideally, it should be supplied as part of a software/hardware system all components of which have been tested for compatibility by the manufacturer.
• The solution should have centralized management — ideally unified with other products in the vendor’s ecosystem to create a comprehensive security system providing monitoring and protection of all levels of the company’s IT infrastructure through a single console.

Kaspersky Embedded Systems Security

Many years ago, before fully understanding what a specialized solution for protecting embedded systems should look like, Kaspersky also attempted to use applications from the Kaspersky Security for Business product line for this task. However, it soon became clear that using a conventional application for the entire range of embedded systems was simply impossible. Therefore, the decision was made to develop a separate solution that could meet the ideal requirements to the maximum extent. The result was the emergence of Kaspersky Embedded Systems Security — initially supporting Windows and later Linux as well.

Our solution offers an exceptionally rare combination in the global market: a multi-layered technological stack for different platforms, very modest system resource requirements, and support for outdated OS versions (down to Windows XP SP2). At the same time, it’s part of Kaspersky’s rich security ecosystem. All of this means that Kaspersky Embedded Systems Security comes very close to the ideal solution that we describe above. You can familiarize yourself with the main features of the product on its webpage; for technical details, you can visit the Kaspersky support site sections dedicated to the product’s applications for Windows and/or Linux.