Checker ATM Security©
by gMV

Any software that a fraudster deploys in your ATMs in order to obtain data, steal cash or perform any other action intended to commit fraud is by definition ATM malware. It does not need to be a virus or have any specific replication or infection capabilities. The main thing to consider is that it is not your software, but the fraudster’s.

The purpose of checker is to prevent ATM malware being deployed in your ATMs and to alert in case such an attempt is detected.

In order to prevent malware infections, the checker solution deploys an agent in every ATM. This agent enforces so called ATM security policies, which are strict rules regarding what is and is not allowed to happen in your ATM. The agent is easy to install and consumes very few resources.

The checker security paradigm revolves around controlling access to all ATM computer resources, and therefore security policies are also known as ACLs (Access Control Lists). These ACLs take the form of XML text files that are generated in a central checker server using the checker console and sent to the ATMs, where security is enforced from boot time. Several commands to control when and how security is enforced can be sent from the server to any or all agents in real time.

Communication also takes place from agents to checker server in order to inform of security violations (or intents) as well as to report a number of agent’s status conditions.

Special components called checker gateways mediate the communication between agents and server in order to provide security (eg. authentication and encryption) as well as to isolate the complexity of communications management from the server, thus ensuring scalability in large networks. Both gateways and server should be placed in the customer’s internal network. All information managed by and received by the server is stored in a checker database.

The concept of whitelisting is embedded in checker since its origins in 2006. The concept itself is quite straightforward: No action can happen in the ATM unless it has been previously identified as legitimate.

The concept of whitelisting in checker is wider that in other solutions, because it does not just refer to execution of permitted processes. It includes all possible actions in the ATM computer that can be managed from the operating system, i.e. access to files or folders, access to libraries, to the registry, to the network, to the keyboard, the mouse… essentially everything that can be controlled is controlled. The possibility to control all these access constraints from a single agent using different, related combinations of rules makes checker a very powerful and versatile security control.

Controlling resources requires a reliable means to identify them. All file-based resources that reside in the ATM disk are uniquely identify by means of state-of-the-art cryptography hashes such as SHA-256. Both rules and hashes are included in the ACLs and signed form the server for authentication. This same technology is further used to ensure that these resources are not modified, a feature that is known as Integrity Control.

Although the checker agent is capable of denying all attempts to stop or otherwise tamper with its execution, this protection is only active insofar the Operating System used to boot the ATM includes the checker protection. If it were possible however to boot the ATM from a different medium (say an CDROM or a USB pen drive) than the ATM HDD where checker is installed, an attacker could access the ATM hard drive and manipulate checker (or anything else for that matter) to disable the ATM protection. In order to avoid such attacks, checker features Hard Disk Drive Encryption (HDE). An encrypted drive cannot be manipulated as any change will render the contents of the drive useless. Checker uses the standard AES-256 algorithm to encrypt the disk.

Checker cannot use standard drive encryption based on passwords or similar technologies that require a user to be present at boot time since an ATM is an unattended device. Neither is it secure to store encryption keys in the ATM drive since those could be reverse engineered. Instead, checker uses special technology called Smart Environment Detection to build (i.e. calculate) the encryption key at pre-boot time based on ATM hardware and network identifiers collected in real time. As a result, a hard drive removed from its original ATM or even within the ATM but disconnected from the network cannot be manipulated or reverse engineered.

Checker HDE can be commanded from the checker console in one click. Encryption time varies from a few minutes to a couple of hours depending on the ATM, but the ATM can operate normally while it is being encrypted so there is no downtime. The encryption process can also be performed during the HD base image creation at the Data Center/Factory/Provider Center of the disks.

Considering the complexity of a Windows system, that may involve hundreds of processes and thousands of DLLs, building an exhaustive yet tight whitelist for the entire functioning of the ATM computer might be challenging. Checker features unique self-learning technology that helps the user building a whitelist in about one hour. This process is known as self-learning and involves running the ATM (possibly in a laboratory) while all actions taking place during ATM operation are being recorded by checker. Additional tools to collect hash values and a best-practices guide ensure that building ACLs for any ATM is a simple process that requires a minimum training.

Extensive experience with checker has demonstrated that efficient coexistence between ATM security and operations requires special attention. It is usually the case that an ATM field engineer needs to perform special tasks in the ATM that would not be wise to whitelist as a general rule. In order to cope with this situation checker leverages the experience of many customers to feature a specific Operator Mode that can be entered into when a properly authenticated field engineer accesses an ATM. This mode allows the field engineer to execute any application during a limited time slot. In addition, every action performed by the engineer will be recorded and sent to the Checker Server. When the time slot is finished or the ATM is rebooted the agent resumes full protection.

This special Operator Mode can be either commanded from the checker console or at the ATM using the so called Operator Mode USBs. Those special USB will allow the engineer to turn the agent into operator mode by just plugging the pendrive into the ATM computer. Operator USBs are built from regular inexpensive USB pendrives and are univocally identified by their serial numbers. But unlike when using regular USBs, Operator Mode USBs achieve higher security because they are encrypted. Encryption is done in a standalone application for PC included within checker and its purpose is twofold: On the one hand it provides a better authentication than USB serial numbers, which can be easily forged. On the other hand it hides the contents of the USB thus preventing reverse engineering. Encrypted Operator Mode USBs will automatically be recognized in those ATMs running Checker and are useless elsewhere.

All relevant security events that happen in the ATM are controlled by the agent and immediately registered both in the ATM and in the server. Security related events can be customized in several ways and sent to thrid party tools if necessary. The checker console can also be used to watch this events as they happen in order to react accordingly.

When you manage the security of a network with thousands of ATMs you need a way to get a quick feeling of the situation as well as the ability to investigate any potential problem in a minimum time. Checker provides a management dashboard that is designed based on the experience of checker customers worldwide. This is complemented with extensive reporting capabilities.