Last week marked the 50th anniversary of the ATM, a device that changed the face of personal monetary transactions forever. According to the ATM Industry Association (ATMIA) there are now close to three million of them worldwide, with over 70,000 in the UK alone where it all began. On 27th June 1967, the world's first "hole in the wall" was revealed at Barclays Bank in Enfield, London. Celebrations aside, I’d like to look at exactly what’s going on under the hood from a software perspective. Is securing them through industry best practice realistic and practical?
Many ATM vendors including Diebold Nixdorf and NCR will provide their terminals to customers preloaded with either full or embedded versions of Windows (XP and 7 are still the most common), with a layer of basic security software (AV) and teller software to dispense the notes. It’s then left to the customer to configure the build further with patching, firewall, and all the other stuff you would apply to any other Windows endpoint as best practice.
However, there is seldom consideration to user privileges that are used to access terminals in the event of servicing, applying updates and making configuration changes. You can pretty much guarantee that the majority of the 3 million ATMs that are in service and are run with admin privileges at some point. So, if it’s just Windows – why would such a valuable asset be accessed with such a high-risk account?
It’s well recognised in the industry that accessing Windows with full admin privileges presents the biggest risk to that machine, and indeed to the rest of your network. Skimer, Tyupkin, NeoPocket, Ripper, Cerber, Stuxnet and more recently ’NotPetya’, to name a few, all rely on one component to be successful - the presence of user admin privileges. In fact, 94% of Windows critical vulnerabilities last year were open to exploit only with the presence of user admin privileges.
Privilege Management (or, more specifically Privilege Elevation and Delegation Management) on the desktop and server space is widely regarded as a critical control, ensuring that privileges are only assigned to task, processes, and applications that require them. Service and maintenance access to ATMs can be accomplished under true least privilege, just as you would for desktops and server access. This, coupled with application control, is a powerful proactive security measure that’s proven to be highly effective in reducing the attack surface area for exploit. Less privilege = less risk. Engineers working under Privilege Management will still be able to function to enter/exit service modes, engineers can have break glass facilities in the event of ‘out of the ordinary’ requirements. Teller applications will carry the correct privileges on the system to dispense cash. UAC can be enabled, suppressed, and monitored for privilege access requests (UAC often disabled on ATMs to reduce the risk of showing users on-screen prompts when in service). All without the increased and frankly unnecessary heightened risk of exploit of a privileged account.
In summary, it's my opinion and experience that ATMs are just another Windows endpoint (unless they are Linux!) so should be treated with the same vigilance and best practice as any other Windows endpoint in your estate. It only takes one compromised endpoint in an estate to be a threat, so ATMs should not be overlooked and they should be treated in the same light as any other endpoint.
