Network Solutions Breach Revives PCI Debate
If Firms are PCI Compliant, Why are They Getting Breached?
August 10, 2009 - Linda McGlasson, Managing Editor
The recent data breach at Internet domain administrator and host Network Solutions compromised more than 573,000 credit and debit cardholders and begs the question: What more can be done to secure such systems? The incident also raises new questions about the Payment Card Industry Data Security Standard (PCI).
At the time of the breach, discovered in June, Network Solutions says it was PCI compliant. The breach was the result of hackers planting rogue code on the company's web servers, intercepting financial transactions between the sites and their customers, which are mostly small online stores.
So, if Network Solutions was PCI compliant, how could it be breached? Paul Kocher, chief research scientist at Cryptography Research Institute, says the fundamental limitation with PCI is that it attempts to distill security down into a static set of requirements, while adversaries aren't restricted to a rigidly-defined set of methods. "As a result, clever attackers will always find holes," he says. "PCI does provide some value by forcing merchants to put some effort into addressing the most common attacks, but the objective is to reduce total risk -- not stop all attacks."
Changes that would increase the burden on merchants could raise the bar further, Kocher notes, "Although it's not clear how much impact this will have on actual fraud rates." At this point, he sees no sign that security standards are anywhere near close to putting fraudsters out of business, and forcing them to work a bit harder doesn't necessarily mean they'll actually steal less. Kocher sees the most effective anti-fraud step the U.S. card industry could take would be to make a real effort to adopt smart cards. The secrets needed to copy stay in the chip, and terminals for card-present transactions simply do not have access to the secrets.
PCI Flawed From The Start?
PCI has been flawed from its very start, says Avivah Litan, a Gartner Distinguished analyst and information security expert. She offers these reasons:
- The standard relies largely on qualified data security assessors. "But there is no effective process in place to ensure the quality of the assessors themselves," she says.
- Assessors bear no liability or responsibility if they get the assessment wrong, Litan notes.
- PCI puts all the security responsibility on the retailers and payment processors, she says, while "Nothing gets done to change and update the core security of the payment system, which suffers from an antiquated decades-old architecture, itself."
The banks and card brands need to do their share to strengthen the security of the payment system by implementing end-to-end encryption and stronger cardholder authentication, Litan says.
While the industry awaits those much needed changes, PCI should and must be improved. "It's basically written as a one-size-fits-all standard," Litan says. The same standard applies to a mom-and-pop ecommerce store and to a global multinational retailer with thousands of stores and hundreds of thousands of point-of-sale terminals, she says. "It needs to be tailored to different scenarios, depending on the inherent card acceptor/processor risk and system configuration."
PCI Not Broken
Matt Davis, Audit and Compliance principal practice lead at SecureState, the Cleveland, Ohio risk management assessment firm, says PCI isn't "broken." He points to the Heartland Payment Systems data breach as one example. "Using the Heartland breach , we can figure out what happened," Davis says. "The basic problem was registers with malware that were sending credit card numbers back to China."
According to the PCI standards, Davis says, anti-malware needs to be in place. "The only problem with the standards is it used to say 'for systems commonly affected,' which really meant MS Windows. The affected systems were Linux and thus the standard was fixed to say all systems. But was that really the problem?"
PCI uses a layered approach because individual controls can fail, Davis explains. "So if malware breaks in, the firewall still works in this scenario. There is a big difference between compliance to the DSS and having validated compliance through an audit and scans. Their organization and their assessor 'thought' they were compliant to the standard, but they weren't." The failure was one of diligence by one or both parties, he observes.
 | PCI-DSS is about compliance, not about security. "End-to-End" or "Point-to-Point" encryption (whichever you call it) does not provide security. It will only offer *plausible deniability* for the implementing party and only during the transaction segment where the data is encrypted and that party has no knowledge of the key. The systematic collection of cardholder data may still occur on the same premises where the encryption begins, even if that is at the point of swipe. Cardholder data is in the clear on the card. Genuine security requires AUTHENTICATION of the card and the cardholder data it contains. This can be accomplished on both chip cards and ordinary magnetic stripe cards. |
|
| "End-to-end encryption, where the first end is the card acceptor, and the second end is the card issuer -- not an intermediary, like a payment processor." This would obviously only be practical with a modified version of EMV, where the card encrypts the data. |
|
| Nobody is "Demanding PCI DSS become 'breach proof'", and no PCI critic is demanding perfect security. The proper question is, Should PCI be the primary weapon against CNP fraud? The following challenges are not yet adequately answered:
(1) What good does PCI really do against highly resourced organised attacks, and against inside jobs?
(2) Isn't the majority of the PCI regiume fundamentally a read-guard action, a rather crude response to the inherent insecurity of CNP transaction processing in which stolen numbers cannot be distinguished from originals?
(3) Can't we do more to design Internet payments infrastructure to resist replay attack, using e.g. asymmetric cryptography to differentiate original cardholder data from copies?
(4) And finally, as a security guy, I get vigilance and I get that there is no such thing as a breach proof system. Yet I think the orthodox security-as-continuous-improvement paradigm is not fair on small merchants. We don't demand that small businesses maintain their own vehicles, or install their own plumbing, or understand the building codes and do all their own fire prevention. Asking a small business to take responsibility for cyber security is just as impractical.
If we deployed asymmetric cryptography to prove the pedigree of personal account details, we could prevent almost all CNP fraud and at the same time strip away the majority of the PCI overhead. |
|
| RE: Litan states --
�End-to-end encryption, where the first end is the card acceptor, and the second end is the card issuer -- not an intermediary, like a payment processor. This is akin to the way PIN encryption works today. The data is encrypted at the card swipe and decrypted only by the card issuer.
This is incorrect. PIN pads are generally seeded to the acquiring processor, decrypted at the processor and reencrypted to the issuers encryption seed. Based on the previous definition of end-to-end, this is not a valid example (and an example of one hurdle true end-to-end encrytption will need to overcome). |
|
| I think to use a framework to test the security on any system is a must and necessary; however, if you really want to bullet-proof a system, you have to let the "smart" frauder to "test" it. Do you dare? |
|
| Demanding PCI DSS become "breach proof" is an attempt by the timid to have someone else define, in exacting specification, minimum actions necessary to provide CYA or plausible deniability for individuals. A standard, especially one with the organizational and technological reach of PCI DSS, cannot and should not attempt to define to that level of detail. Is it really necessary to tell someone they should be running antivirus on all platforms, not just those that are Microsoft? Does catering to the anti-Microsoft bias really improve security? Is it likely the organization that overlooked the obvious in that case would be more likely or less likely to overlook other areas of the standard that are not exactly defined to a level that any Do-It-Your-selfer could follow? Where does the dumb-ing down stop? Should they include in the standards the documentation of items like "placing locks on doors is a good thing to do"?
Security is about constant vigilance and proactive thinking. Not mindlessly implementing some generalized model that may not be exactly applicable to your business or architectural situation. Security is like other complexities in business. If you are not prepared to do it, or not good at it, hire someone. |
|
| PCI is nothing more than an attempt to get some companies to do what they should have been doing all along, but won't do because it doesn't add to profits. PCI compliance can only keep profits from falling when something bad happens.
Network Solutions could not have been in PCI compliance because their file integrity monitoring system (10.5.5) should have picked up the malware and their "at least daily" review of application and system logs (10.6) should have picked up the file changes and the outbound traffic from servers (!). Once again we see servers being allowed to talk to the Internet (1.2.1).
I wish more states would codify all of PCI because nothing gets the attention of management than the threat of their getting an involuntary roommate. I've seen firsthand how SOX finally made some companies clean up their act.
If they're not protecting cardholder data appropriately, how good a job are they doing with employee and customer non-public information? |
|
| Nothing has changed my outlook on the validity of PCI. I knew in the beginning that it would never prevent breaches, and still know that. PCI is a means for the card issuers and acquirers to push the expense of security onto the merchants, while turning a blank eye to their own systems' vulnerabilities. Why don't the issuers have to follow the same requirements as the merchants? Who PCI-assesses the issuers? Any program (PCI) that treats a line in a policy document the same as encrypting credit card numbers in your database is misguided and ineffective. The requirements need to weighted so that merchants will apply those that produce the most value. Then a passing score can be attained. The cost of trying to implement all of the requirements is onerous and can reduce your company's ability to compete. The issuers must realize that some credit cards are going to be breached, just as some credit card bills will never be collected. They need to work with the merchants and share the cost of breaches instead of pushing all of the costs onto the merchants while potecting their own profits. |
|
| I think it would be unfair to say that PCI is flawed. It is nothing more then a basic set of standards, a starting point. If we chose to believe it or not, a lot of companies would not even go that small step if they were not made to do so.
Security is always a hard sell to management as we are trying to "prevent" something that may never happen.
The real world is that it is not a matter of "if" you get a breach, but when and how bad.
I would agree that there are more things that could be done to make the payment system more secure.
End-to-end encryption would be a great starting point. Encryption of important or sensitive data is a good thing all across any network.
I would hope no one has the idea that compliant is the same as "impossible to breach".
The hackers and organized criminals have nothing but time on there side to look for and find the one small hole that gives them a in.
I think we have to be more realistic and do what we can to prevent a breach, but also to prepare for one and try to insure that the least amount of damage is done when it happens.
I also believe that we should be doing more to "look" for the issues before the bad guys find them, and that means more then a once a year audit.
Constant and vigilant vulnerability assessments, penetration testing and patch management allow you to see that you've got a problem and fix it before someone else finds it and uses it. |
|
| There are numerous issues here, many of which have been commented on. However, I have noticed an attitude on the part of most merchants to treat PCI Assessments like a final exam in a college course. "What do I have to do to pass?" is the most common question I hear.
Compliance is not like a final exam. You can't pass, then not worry about things for a whole year. Security is a DAILY responsibility, and passing a PCI audit only means you are compliance at that point in time. It takes a CONTINUAL EFFORT to remain compliant, which is where a lot of companies fall short. |
|
| Sorry, this is definitely one case where the glass is half empty! Of course there is no such thing as perfect security, but it's not fair to defend PCI on the basis that it doesn't guarantee you won't be breached. Customers and merchants deserve better than this.
As Avivah Litan points out, the payments system itself is flawed. In my view, a fundamental problem is that CNP online processes are based on decades old MOTO rules, that did not (and could not) contemplate the ease with which identity data gets stolen and traded on the Internet. Asking for more and more corroborating information to identify cardholders -- and then demanding that merchants protect that information against organised criminals -- is like putting out fire with gasoline.
Is PCI flawed? I do think so, but not because setting minimum security standards is a bad idea; of course it's a good idea. Rather, the deeper problem with PCI is its methodology. Like all audits, it's fundamentally a rear guard action.
We really need to aim higher. It's just not enough for PCI to "provide some value by forcing merchants to put some effort into addressing the most common attacks." |
|
| I think Mr. Taylor summed it up nicely: being compliant does not guarantee that a company can't be breached.
The PCI DSS is a helpful framework and good starting point for credit card data security. Merchants and service providers need to make security an ongoing focus and priority and avoid becoming overly reliant upon annual audits.
Bryan Johnson |
|
Comment on this article
