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.

People in remote areas depend on ATMs being in working order — it’s an indisputable social good. For some, they are the only way to get cash or pay for services. Consequently, such devices need to be secure.

Security challenges

The operability of terminals and ATMs depends on having a security solution able to cope with the latest threats — in other words, a security solution that is updated regularly. Let’s take a look at what issues can arise when protecting such devices, and what features the security solution needs to deal with them.

Difficulty of access. ATMs in rural areas give new meaning to the term “remote access.” If it takes police officers an hour to get there in case of emergency, an IT worker isn’t likely to arrive any faster. Therefore, an appropriate solution must support remote administration and updating.

Weak communication. Even developed countries have settlements with no wired Internet and unstable mobile network coverage. In some places, an ATM’s only communication channel is a 3G modem that struggles to get the job done even at maximum speed. Still, transmissions of transaction data and banking software updates need to be reliable and secure, so the solution has to be able to deliver updates even over a weak channel, without overwhelming the system with traffic.

Budget equipment. The chances that a rural village will be supplied with a top-of-the-range ATM model are slim. After all, there’s no security guard to protect it, and some enterprising robber might try to, say, blow it up to get the cash inside. Therefore, a smaller community is more likely to have an old machine housing a Stone Age processor and operating system — so its security solution must be able to run on outdated hardware and protect the OS that no longer receives updates.

Seclusion. In a big city, a payment terminal or ATM is almost never installed where no one can see it. That’s no coincidence — attackers want privacy to connect an external device to an ATM. Cybercriminals don’t necessarily need access to the cash trays; they can try to steal card details or modify the system so that transfers go to a different account than the account holder intended. Therefore, the ATM’s security solution must do more than simply detect the latest malware; it must also be able to monitor changes to critical files and logs, and block the connection of external devices and the installation of third-party programs.

Security solution

As you’ve probably guessed, the above is essentially a description of the latest version of Kaspersky Embedded Systems Security. Our experts have optimized the data-transfer process, making the product even easier to administer and update even over a weak communication link. And most important, the data exchange does not conflict with the basic functions of the device.

On top of that, the solution includes a new module for defeating network attacks. The module manages incoming and outgoing traffic, and it can block the exchange of data if it spots malicious network activity. It can also detect scanning of ports, brute-force attacks, and attempts to disable an ATM through a DoS attack. You can read more about the solution’s capabilities on its official page.

Theoretically, embedded systems should not be interesting to ransomware actors — it’s doubtful that anyone would pay ransom for a purely utilitarian system that holds no valuable data and whose hard drive is routinely reformatted anyway. But WannaCry does not choose its targets. As a result of the peculiar nature of the vulnerability it exploits, WannaCry has spread itself widely across local networks and infected all unpatched and unprotected machines.

Out of the blue

It would be unfair to say that this plague has been an eye-opener: The problem of insufficient security of embedded systems is not new, and it’s long been known that they traditionally have less (if any) protection than workstations and servers. But WannaCry brought the issue into the spotlight.

When speaking of embedded system, ATMs and POS terminals may come to mind. And indeed, some of them got infected, although they tend to have some protection installed because of compliance regulations and they are frequently seen in threat models. The infection of such systems as information panels, medical equipment, and vending machines looked like a bigger deal — to say the least.

Wow, even in my building lobby! #WannaCry #ransomware pic.twitter.com/ilPqHBmiB5

— Andrew Tinits (@amtinits) May 12, 2017

The owners of infected embedded systems don’t feel any better knowing they didn’t pay ransom to criminals; they still suffered noticeable damage.

• Inoperable vending machines, ATMs, or automated ticket kiosks mean cash shortfalls.
• A ransom note on a publicly accessible screen tells customers “Our security is bad.” It’s hard to assess the damage such a message does to a company’s reputation. Will a client who sees that message come back?
• Infected terminals require repairs. If you use hundreds of terminals, you can count how much money you’re going to spend, especially given the geographical distribution and urgency with which your personnel have to reinstall operating systems and make changes in security settings. And some devices may use outdated software that is challenging or even impossible to reinstall.

Going by the trolling in social networks, these screens did not go unnoticed.

Don't worry boss, no-one outside the company will ever know we were hit by #WannaCry pic.twitter.com/ciI2gdBVSR

— Graham Cluley (@gcluley) May 14, 2017

How to solve the problem

Why do embedded systems lack protection? There are two reasons. First, until now their security was often overlooked. Second, they tend to run on old hardware and use low-bandwidth Internet channels and outdated operating systems. They seem simply unfit to run security solutions on top of their hardware resources.

We have to admit that in a way, WannaCry has helped the world by highlighting the first problem. And it’s true that protecting embedded systems with traditional antimalware solutions may not be the most effective approach. That is exactly why we developed Kaspersky Embedded Systems Security specifically for a broad range of embedded systems. It’s less resource-intensive than a desktop security solution, but it prevents infection by employing a number of desktop-class security features.

In the case of a cryptomalware attack (including WannaCry), the solution works as follows:

• Default Deny mode is the core technology of the product. It precludes execution of any code, including scripts, if they haven’t been added to an allowlist. So even if cryptomalware has been able to penetrate a system, for example, by hiding in a legitimate software package, it won’t be able to execute itself.
• The Process Memory Protection component analyzes the integrity of processes in memory and prevents attempts to exploit vulnerabilities both known and unknown.
• Kaspersky Embedded Systems Security includes a centrally controlled firewall, which allows for quick disabling of the port used by a vulnerability once it is discovered.
• Technology that controls USB devices when they are attached further enhances the solution. This prevents infection by an untrusted USB device, for example, something that may happen during maintenance.
• The antimalware module, available as an option, cleans the system of any infected files.

According to our records, none of the devices protected by Kaspersky Embedded Systems Security has been affected by the WannaCry plague. This solution currently protects hundreds of thousands of embedded systems around the world, so it’s fair to say that it has passed this serious real-life test. Therefore, if your network infrastructure includes embedded systems running Windows Embedded, we strongly recommend trying our solution.