Are you doing enough to protect your ATMs against logical attacks? Two jackpotting attacks this past summer in Taiwan and Thailand illuminate the emerging threats facing ATM networks. The fraudsters used malware and creative hacking techniques to force terminals to dispense large amounts of cash (the equivalent of $2 million in the Taiwan heist alone). Most likely the culprits are not the same, which makes one particular similarity between the two incidents even more striking – and a harbinger of things to come. In both cases, the software distribution mechanism of the victimized banks was exploited to introduce malware to the ATMs. Unlike typical jackpotting fraud, in which criminals gain physical access to each individual ATM to install malware, here we saw remote distribution of malicious software.
If we ignore for a moment the quality of the existing endpoint security setup on the attacked ATMs, the very fact that the attack came from the network itself poses new challenges in setting up defensive measures:
- How can an ATM distinguish whether it’s talking to a legitimate backend system or a spoofed one, like in the incident in Thailand?
- How can an ATM determine whether a software package received from one of those systems is legitimate or the result of a server hack, like in the Taiwan case?
- How can the operations team find out about an attempted or successful breach before it’s too late?
The answer begins with acknowledging that the self-service environment is a different beast than the office network. Sure, there are PCs inside the ATMs, they are running Windows, and they are connected to the TCP/IP network. However, the hardware, software and processes on and around the ATM are quite different from an office PC, and this should be reflected in the security measures being implemented.
At the most basic level, you should make sure that must-have standard security features such as full-disk encryption and hardening of the operating system are in place. Be sure your software protection is up to date and locked down – that is, you have implemented the proper whitelisting or sandboxing controls. Diebold Nixdorf’s Terminal Security Suite enables all of these measures in multi-vendor environments, which is critical to ensuring consistent security across an entire network. Combined, these precautions will typically cover more than 99% of the day-to-day operation, such as customer transactions, replenishment of cash and consumables and routine maintenance.
It can be challenging, however, to secure the less common or unplanned tasks: A field engineer fixing hardware or software issues may require temporarily lowered security settings, but in a controlled and verifiable manner. Software updates have to be regarded as a potential attack vector; therefore software packages have to be authenticated before installation. Suspicious activities at the ATM have to raise a red flag. ATM access rights are a crucial third layer of defense: A separation of power can ensure that critical tasks, such as creating software packages, can only be performed by designated staff.
We combine the security features of our Terminal Security Suite with advanced monitoring and management tools that enable our clients to implement this holistic approach to security. When selecting your security partner, consider these factors:
- Are they experienced in the unique challenges of self-service terminal security?
- Do they offer cryptographic signatures to authenticate software updates?
- Are their solutions refined enough to, for example, open up the security settings on an ATM’s PC for a restricted amount of time, without handing out any passwords?
- Security-related events, such as unplanned reboots or attempts to connect unregistered USB devices, should be logged in real-time at the server so an alert can be triggered quickly.
Is your organization prepared for the increasingly sophisticated fraud that the banking industry is facing?
Interested in learning more about securing your ATM fleet – or just have a question? Let’s start a conversation today.
This article originally appeared in the November issue of RBR’s Banking Automation Bulletin and has been posted to our blog with their permission.