ATM Jackpotting attacks have been making the rounds through the news cycles, but much of the commentary has been missing the point: these attacks are merely a symptom of a bigger issue surrounding ATM management. Many of the controls organizations are implementing on their workstations and servers are not applied to the ATMs. Financial institutions can outsource some of the operational aspects of managing ATMs, but cannot be totally hands off when it comes to preventing, detecting, and responding to attacks.
In truth, ATMs are very similar to the computer you have sitting at your desk. While there is typically a hardened operating system installed, this computer is vulnerable to many of the issues that present a constant struggle for all endpoints. These endpoints need to be patched – both for operating system patches as well as drivers for the peripheral devices, such as PIN pads and Magnetic Strip/EMV readers. In addition, having a thorough vulnerability management program that includes these devices will verify the patch management efforts, as well as identify non-patch related configuration concerns.
These recent Jackpotting attacks also focus the spotlight onto the physical security of the ATMs. Attackers are able to gain physical access to the ATM, replace the hard drive, and reset the device through this new drive. If you have implemented host-based and network-based controls ahead of time, you will be able to spot this before any damage is done. Examples of host-based controls include endpoint protection software installed on the ATM hard drive, as well as physical tampering alarms on doors and device tilting/jarring. Network-based controls include network intrusion detection and network isolation. Financial Institutions should be evaluating both types of controls to detect malicious activity on the ATMs.
Many financial institutions will contract with a third party for all-things ATM management. This should include the physical maintenance, software maintenance (patching), and monitoring for physical and logical security events. Institutions need to thoroughly vet the selected third party for ATM management to identify the responsibilities of the third party, as well as the responsibilities of the financial institution. Specifically, the following controls should be explicitly called out:
Who will be responsible for the ATM network? Will this be an isolated vLAN on the institution’s network, or will the third party manage a completely separate network? In either case, what level of monitoring is available, or what are the alerting thresholds?
Who will be responsible for identifying patch availability, testing patch functionality, and deploying patches to all production machines? Ensure that if the third party is assigned this responsibility, they are being held to an acceptable Service Level Agreement (SLA) for timeliness of patch application.
How will ATM threats be monitored and reported? ATM jackpotting is not a new attack pattern, but was traditionally not an issue in the United States. A process should be in place to monitor for threats that may relate to your environment, such as the ATM jackpotting attacks in Mexico and Europe. Regardless of the third parties’ responsibilities here, we strongly recommend the FI performs this level of monitoring in-house. Reach out to the third party with questions on threats you are seeing, and identify what steps they have taken to protect your environment. A great source for these sorts of attacks is Krebs on Security.
In the event of an ATM-related incident, you will need to ascertain whether you took the necessary preparation steps? Many ATM attacks, jackpotting included, require physical access to the machine. This means many attacks take place during off-hours to minimize the chances of being seen. Performing periodic incident response testing provides multiple benefits. Your team will stay current on processes and expectations, and will start to think of the Organization’s response to major current events. Here are some questions to ask internally to determine the potential risk to your Organization. When considering your answers you should always keep it within your organization’s risk appetite.
- Have you performed an assessment of your ATM environment against the publicly-available attacks?
- Did you find any of your ATMs vulnerable?
- If so, are there mitigating controls you or your vendor can implement?
- Are there Indicators of Compromise (IoC) specific to these attacks?
- Who is responsible for monitoring for these IoCs (the Organization or a vendor)?
- How are alerts communicated to the institution, and in what timeframe?
Containment & Eradication
- Once an attack is identified, do you have the ability to disable other ATMs that are potentially vulnerable?
- How will the other ATMs be reviewed and certified as unaffected by the attack?
- How will you ensure the ATM has been deemed clean?
- What are the indications that the incident can be considered closed and business as usual can be resumed?
- Who has the authority to make this decision?
Once you return to business as usual, it is important to look back at the incident and identify areas for improvement. Based on your internal policies, you should also consider sharing these lessons learned with FS-ISAC or other local industry groups. Working together as an industry we can thwart attackers targeting vulnerable ATMs.
Financial institutions can outsource some of the operational aspects of managing ATMs, but cannot be totally hands off when it comes to preventing, detecting, and responding to attacks. The wave of ATM Jackpotting attacks shows that many of the key controls we implement in our core networks are not being applied to these ancillary systems. Internal networks have received a lot of attention and additional control investment, while many ATMs have been left behind as a vendor responsibility. FIs should be taking a more active role in ensuring these vendors are properly mitigating risks the ATMs are bringing into your Organization.