We announced today that OpenTable selected us as their global PCI Compliance solutions partner. Our solution helps OpenTable comply with PCI Compliance requirements and increases credit card data security. The solution is currently being rolled out in the latest version of their Electronic Reservation Book that is used by 11,000 restaurants around the world.
The OpenTable team has been great to work with and we couldn't be more excited about the partnership.
Comments: 0 | Post a CommentEric Ogren, writing for SearchSecurity.com and Evan Schuman and Fred Aun, from StorefrontBacktalk.com, have some insightful commentary regarding the tactics used by hackers to breach Heartland and how they relate to the limitations of the current PCI Compliance standard.
I think the key take away here is that compliance does not necessarily equal security. Here are a few highlights from their articles:
Eric Ogren
1. The hackers ran their malware through 20 AV products to test detection avoidance. AV is very good at stopping known attacks of mass destruction, but is quite a bit less good about catching low profile designer attacks. Effective security should augment AV filters with technology that reflects control over the unique aspects of the organization's server and endpoint configurations. IT has choices here – application whitelisting on locked-down servers will prevent execution of unauthorized software, thin clients prevent attacks from persisting at endpoints, virtual desktops and servers give IT control over endpoint configurations and automated patching systems close windows of vulnerabilities. PCI should be more assertive in recognizing that signature-based schemes and reputation services will not catch low volume activity that is the trademark of malware designed to steal information.
2. It would be nice if PCI could have protected 7-Eleven and others from the same attack technique that befell TJX years earlier.
Evan Schuman and Fred Aun
1. One retail security expert, who has firsthand knowledge of defending against these defendants and who agreed to discuss the indictment if neither her name nor employer was identified, said much in the indictment points out inherent weaknesses in PCI. The back door approach used, a time-honored hacking technique for decades, is a red flag. “Being on the inside, these probably would have passed right through firewalls as the data would be travelling in the ’safe’ direction. Also note that any gains a company would have from a password rotation scheme would be negated by the installation of a back door. My main point there is that password rotation schemes are not an effective defense, and shouldn’t be elevated to such by PCI or corporate ’security policies.’ In any case, Hackers 2, PCI 0.”
2. The SQL injection tactic points out an especially significant PCI flaw, the expert said. “PCI doesn’t say boo about SQL injection attacks. It only says you must maintain secure systems and applications and review the applications annually. But reviews are ineffective on unknown bugs – they can only help recognize bugs the reviewer actually knows about.”
3. Another concern that she listed involved Heartland details. “The attackers installed sniffers to capture the traffic, they did not harvest data intentionally stored by Heartland on hard drives. PCI doesn’t say anything about encrypting data on private networks, only that you must protect stored cardholder data or encrypt data traveling over open, public networks. And the networks obviously have the business need-to-know, that’s what they do: carry data. That’s a three-point shot for the Hackers; Hackers 6, PCI 0.”
4. Yes, PCI compliance may have successfully defended Heartland against lesser attackers. But the bottom line is that Heartland could have been (and probably was) breached while being 100 percent PCI 1.1 compliant on all their points. The real observation here is that PCI DSS compliance was completely ineffective against these guys, no matter how the PCI guys spin it.
Comments: 3 | Post a CommentI've wondered how PayPal seemingly signs up any merchant without doing any underwriting or risk assessment. Well, now I think I have my answer. They do it after the fact.
There is a lot of risk associated with providing credit card processing services to a business. If a merchant sells something that they can't deliver, don't deliver, partially deliver, deliver poorly, or that is defective in some way, and the business can't remedy the situation with their own financial resources, the credit card processor is on the hook for all the chargebacks and losses.
Merchant account providers can do a number of things to address these risks including a reserve requirement. Reserve requirements come in different shapes, sizes and flavors. Some are 6 month rolling reserves, some are fixed amounts, some require upfront money and others are collected as part of the processing volume.
When cash flow management is one of the most important components of running a business, a reserve requirement is probably something better identified before, rather than after, the fact.
Comments: 0 | Post a Comment© 2010 Braintree Payment Solutions. All rights reserved. Braintree is a registered ISO/MSP of Wells Fargo Bank, N.A., Walnut Creek, CA
