ATM Security (And Really Learning from the Past)

Tuesday, May 14, 2013

Andy Willingham


First let me say that I’m not saying that there is not a security model around ATM deployments. ATM security varies greatly depending on lots of factors. You have the hardware that they run on and the underlying OS. Most are run on PC type hardware and the OS varies from OS/2 (yes there are still some out there running OS/2) to Windows (I have no proof but I’d not be surprised to see a few that are still on NT but mostly XP and Win7 with some CE based) to various flavors of Linux. Then you have the vendor software (this includes old versions as well as various different configuration variations and features). Then you have any additional software that may have been added by the FI. This software may be from a 3rd Party or it may be written by the development team within the FI.

Then on top of all of this there are the “standard” things that impact security. Thankfully most are not internet connected. At least by design. Of course here is where deployment mishaps can bit you. If they are on the same network as the rest of your systems then you are asking for problems. Just as in SCADA systems that are supposedly air gapped such security measures are only as effective as the monitoring and enforcement that they go through. A rogue system plugged into the wrong (or right) port can suck all of the air out of a gap in a heartbeat. 

You also need to think about things such as How is it configured? Look at the hardware configuration and settings, the OS settings, various security policies, other network policies that are applied to each system. What additional agents is it running for management, security, etc.. 

There are lots of other things that go into ATM security that can have a big impact on ensuring that it is as secure as possible. I’m going to stop here because my intent was not to give a primer on ATM security because I don’t know enough to give more than the basics. If you want to talk true ATM security you need to go elsewhere.

What I did want to talk about is the fact that the recent ATM heist of $45 million dollars should have never happened.  Why you ask? Because this same basic attack took place a few years ago. RBS WorldPay was hit for $9 million using this same basic attack back in 2008. The attack wasn’t identical but it was close enough in nature that the lessons learned should have resulted in security improvements and controls that would have stopped or at least alerted the banks to this attack much quicker. What obviously didn’t happen was a true root cause analysis to not only find the root cause but to then learn from that and make changes. Then you also need to take what you learned from the RCA and think about how else could this attack have happened or what else could they have done using similar techniques.

We focus so much on the problem that we often fail to find and fix the root cause and if/when we do we feel that we have gone over and above and stop there. This is a problem. There is so much more that we can and should do to take our work and program to the next level. We have to take what we learn and apply it but we also have to see what else we can learn from it. Security researchers are good at this.  The bad guys are too. They take what we learn and use it against us. We get all excited about finding and fixing the root cause then we think that it would make a great papere and conference talk. We make it all fun and pretty and show the world. Then the world takes it and slaps us in the face with it because they were willing to learn more than we are. 

This is one of the big jobs of security that is so often overlooked. Our job is to secure but  we also need to drive change within our program and within the way that our business does security. Our industry is reactive in nature and we are striving to be more proactive and this is one way that we can. We have to go beyond thinking about what technology will make us proactive and think about what else can we learn from what we have already learned. Yes, this takes time and resources that many teams are already lacking in. It also takes someone who is good at thinking like this. It’s not something that will come easy to most of us but it is a necessary skill that has to be developed and implemented within our programs. We can’t keep playing catchup forever because there comes a time when you get so far behind that you will never catchup because catchup also involves cleanup and that takes more and more time. If we spend just a little extra effort in our analysis we can make changes that will have a positive impact with less resource consumption. Just as in software development it is easier and cheaper to prevent bugs than to fix them it is easier and cheaper for us to prevent incidents than to fix them.

Cross Posted from Andy ITGuy

Possibly Related Articles:
Banking Financial Services
Security ATM
Post Rating I Like this!
Johnnie Nix ATM machine are for our convenience but if we are not careful they can compromise our safety.
Discount theater tickets
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.