Will We Learn Authentication Lessons From Global Payments Breach?

Weaknesses in knowledge-based authentication and mag stripe highlighted in security experts speculation about the breach

In spite of a Monday morning media conference call, details about the
Global Payments breach
that broke late last Friday remain sparse this week. But that hasn’t stopped the security community from speculating about the potential lessons we may learn from this latest megabreach. Though the conjecture covers numerous angles, the thematic elements tend to converge on authentication, both at the administrator account level, where many of these breaches occur, and at the card-holder level, when transactions are processed.
According to a conference call early on Monday, Paul Garcia, Global Payments CEO and chairman, reported that early forensics reports from his company show the breach affected Track 2 data from approximately 1.5 million cardholders. He also claims only a small number of Global Payments servers were affected by the breach.
Beyond these few explanations, though, the details from the call were incredibly light. and Global Payments did not field media questions following the call.
He said none of their merchant systems were compromised. Well, then what was compromised? says Avivah Litan, vice president and distinguished analyst for Gartner Research. Why do you tell us what didn’t happen? Tell us what did happen.
According to Litan, her confidential sources tell her a Central American gang broke into the company’s system by answering the application’s knowledge based authentication questions correctly. At the same time, other sources told her that over the past few days a yet-to-be-disclosed breach at a big New York-area taxicab company could have had connections to the Global Payments breach. She also pointed to reports from Brian Krebs of KrebsOnSecurity.com, who first broke the story and who today mentioned that the company that hosts the Global Payments website recently switched to Amazon EC2. Krebs also said he’d been contacted by a hacker who claimed Global Payments end-to-end encryption was circumvented by an inside source.
These seemingly unrelated details come into clearer focus for Litan when she considers a nervous call she received on Friday from a different third-party payment aggregation company that handles both taxicab payment aggregation and offers end-to-end encryption solutions.
Here’s what Im guessing when you put it all together. I am 99 percent sure it was a taxicab company or parking garage company that was definitely breached, and the way that I think it was related to this is those transactions all went to the cloud provider, she says. They were encrypted through the payment aggregation company, and some guy broke into an admin account by passing through knowledge-based authentication.
From there it was a matter of pivoting attacks up the stack through the cloud infrastructure to get deeper into Global Payments systems. It makes sense given the weaknesses of cloud infrastructure, she says.
I’m thinking, ‘Who uses knowledge-based authentication?’ Probably these not-so-sophisticated, and even the sophisticated, cloud providers. Cloud providers don’t like to distribute tokens or do anything too difficult, Litan says. Then that’s why the [Global Payments] CEO wasn’t lying by saying none of their merchant systems were compromised because it was the cloud security provider’s system that was compromised. That’s my theory, at least.
Such a complicated scheme would not necessarily be that far-fetched given the precedence set by many breaches caused by similarly advanced, multipronged attacks.
It would not be surprising if the investigation slowly reveals that the breach involved techniques such as Web application exploitation, maneuvering from a compromised public system into the internal systems, and that the presence on the network was a longer term than estimated, says Joe Levy, CTO of Solera Networks. These tend to be common characteristics of these kinds of events. And it underscores the fact that perimeter defenses are imperfect and will almost always be breached by a sufficiently motivated adversary. It also illustrates the insufficiency of our current incident response practices.
If a privileged user account proves to be the weak link as Litan supposes, then it would hardly be a surprise within the identity and access management community. According to most authentication experts, privileged account management has been in the stone ages, even in sensitive financial organizations.
Ben Knieff with NICE Actimize agrees with Litan’s view that the industry must do a better job of instituting alternatives to knowledge-based authenticators.
As a general rule, knowledge-based authentication is a pretty low bar from an authentication perspective, says Knieff, who acts as director of fraud product marketing for the firm. Whether that be shared secret questions that are set up or some of the more public records data type questions, there’s just not a very high bar for a committed criminal to get around.
According to Roy Adar, vice president of product management for Cyber-Ark, while many of these organizations may have strict rules about password management and strong authentication for normal user accounts, privileged and administrator accounts have lower standards due to the operational problems that come from tightening the screws to these oft-shared accounts.
Usually, there are no restrictions on whether the password is easy or hard to guess or to brute force or not. Also, those types of policies are not applied to the shared and administrator accounts, he says. The bottom line is that, for the regular user, there are very high security standards in place. But for the high value and highly privilege accounts, the level of security is much lower. Thats a problem were seeing all over.
It is still way too early to know exactly how Global Payments could have ran afoul of PCI DSS standards, if at all. But Knieff says this incident may even more importantly highlight the No. 1 difficulty of PCI in North America today.
The fundamental issue is that PCI is trying to build these barriers and protections around an inherently insecure method of payment, so it just makes it that much more difficult for those standards and practices to actually be effective, he says. The joke I made to somebody the other day is it would kind of be like putting a whole bunch of cash into a cardboard box and then sticking a whole bunch of bodyguards around it and leaving the cash around. At the end of the day, youve got a cardboard box instead of a safe sitting in the middle. Thats where we are with mag-stripe payments today.
Until EMV and chip-and-pin technology improves the payment authentication process over the antiquated magnetic stripe system in place today, our security options are limited, warns Knieff and others within the community.
EMV allows for an encrypted security key to be contained within the chip on the credit card, thereby making card-skimming or duplication virtually impossible or, at the very least, extremely difficult, says Jon Callas, CTO for Entrust. Although not broadly known, one of the additional key benefits of building EMV and NFC into payment cards is that this technology can also be leveraged for securing Internet-based payments using EMV CAP [Chip Authentication Program]. Imagine a scenario where, along with supplying your credit card number, you supply a one-time passcode [OTP] that is generated from the security key contained on your card. A criminal can still steal your card number, but without the ability to generate an OTP, the credit card number is useless.
Have a comment on this story? Please click Add Your Comment below. If youd like to contact
Dark Readings
editors directly,
send us a message
.

Last News
▸ ArcSight prepares for future at user conference post HP acquisition. ◂ Discovered: 07/01/2025 Category: security	▸ Samsung Epic 4G: First To Use Media Hub ◂ Discovered: 07/01/2025 Category: security	▸ Many third-party software fails security tests ◂ Discovered: 07/01/2025 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps