PCI’s Fatal Flaw: Protecting Only Payment-Related Systems
Written by Evan SchumanSecurity is nothing if not filled with seeming contradictions, and the latest version of PCI—slated to be officially unveiled next month (October)—is highlighting a beauty: To most effectively protect payment-card-related systems, protection must be focused on anything that is not related to payment card data.
How so? PCI’s jurisdiction is limited to payment data and, therefore, it phrases most of its guidelines and requirements in those terms. So a retailer that uses appropriate encryption, firewall and intrusion detection systems only on systems that directly handle payments would be compliant and praiseworthy.
But with today’s networked systems, cyberthieves seek out soft spots in the network just so they can somehow get inside. Once there, they’ll deploy a wide range of tactics to let other network parts allow them to roam and, hopefully, get into a payment system through a backdoor, leveraging some variation of trustedhost (if they’re in a secure network, something must have authenticated them and let them through).
That soft spot could be anything, ranging from a wireless handheld inventory scanner to a smart networked printer with IP access. Therein lies the conundrum: By solely protecting payment-involved network parts, an admin might inadvertently be making those payment processes much less secure.
Asa Holmstrom is the president of Columbitech, a wireless vendor that specializes in security, said that she routinely runs into retailers that are PCI compliant but very much at risk. "Professional (cyberthieves) out there go for the weakest link. They will go for the devices that are not protected, and that is the way they will get in," Holmstrom said.
Wireless security—which is one of those phrases guaranteed to get at least a few chuckles at any IT gathering—is a wonderful example of how far retail has to go to get secure today. And, Holmstrom argues, the expected changes in 1.2 are not likely to help.
PCI 1.2 "does not offer any improvements to help retailers get a more secure environment," she said. "PCI gives retailers a false sense of security."
The weakest link theory in security is hardly new, but as more retailers try and adhere to the letter of the law with PCI—and nothing more—they are going to run into problems, especially because PCI doesn’t have the jurisdiction to issue rules for any equipment that is not somehow involved in payment card data. Retail CIOs, on the other hand, have much more extensive jurisdiction. The question is: When it comes to security, will they use it?
The jurisdiction issue itself gets hazy. If a wireless scanner or a smart networked printer can be the start of a chain reaction that creates a payment card security breach, couldn’t that fall within PCI jurisdiction? Indeed, does it not have to?
That said, where is it reasonable to draw the line? PCI is a series of rules and guidelines to suggest some places the CIO, the IT director and various security executives must focus. Are retailers turning this help into a wall by morphing what should be a start point into an end point?
-Marc
September 4th, 2008 at 12:40 am
There are always those who take the path of least resistance and will enable the bare minimum for PCI compliance and will pick their QSA based on perceived ability to audit with a like framework. Others understand that security is not only about mitigating risk within the payment network system but having integrity as a retailer and want to implement security measures to protect their customers and their overall brand. Wouldn’t it change the game if the compliance status, fraud and breach data were open to consumers and part of earnings disclosure for public companies? CIOs would then probably have a more unified approach towards security and barely meeting PCI compliance would not be the only goal.
September 4th, 2008 at 7:22 am
Editor’s Note: Couldn’t agree more, but the retail industry (with lots of bank backing) would never support such a move. Call it the Scarlett Letter approach. It would be effective, virtually no-cost and it would never happen in America. A pity.
September 4th, 2008 at 10:06 am
If this is the case then what good is the PCI DSS Compliance? Is it then just another regulatory body to comply with? So instead of having QSA’s for each regulatory body why not have one come in perform their function and spread the recommendations and report across them all? Saves money and time.
September 4th, 2008 at 11:03 am
Are we asking too much? PCI is a data protection standard; it is not and never was intended to be a security standard. Put another way, PCI “compliance” is not the same thing as “security.” Being secure involves much more than meeting PCI or any other requirements.
I could make the case that PCI is built around the notion that complete security (whatever that means) does not exist. Your systems are vulnerable: an employee will lose a flash drive; someone will install an unauthorized wi-fi network; someone will download a trojan while surfing; a phisher will find a password. The idea is that when (notice I didn’t say “if”) there is a compromise, if PCI is properly implemented at least there should not be a data breach.
September 4th, 2008 at 12:34 pm
Excellent points in this article, Evan. There is no doubt that the PCI DSS standard is allowing retailers to give the appearance of security while ignoring real security – especially wireless security. Retailers need to go beyond the checkmark to protect the data they collect from customers. While there is nothing that can completely deter a determined hacker, there are certainly tools which can automatically and constantly monitor and defend the airspace – a full wireless intrusion prevention system (WIPS). And yes, I work for a company that provides that but it does not make me wrong. It is time that retailers understood their responsibilities and stopped passing the buck, or the loss of the buck, off to everyone else.
September 4th, 2008 at 3:11 pm
PCI DSS is supposed to ensure there are multiple layers surrounding payment information, to prevent the breach you mention. But PCI DSS never went far enough. It doesn’t ensure the protection of data in flight, or prescribe protection for the overall flow of data. So today, if a bad guy can access your network, he might be able to sniff some of that traffic as it flows past, or at some point where it’s being handled.
By omitting this very basic requirement from the beginning, the DSS rules encouraged retailers to approach data protection from a piecemeal approach. PCI states only “encrypt the data at rest.” Retailers took that to mean “encrypt this data on the cash register as best as you can, but because it arrives in cleartext you can encrypt the data on the authorization server another way, and we’ll encrypt the settlement data in yet another way.” Various teams in a single organization will have various ideas how to encrypt the data on their platform. Some may do it better than others. All were free to do it differently. As a result many retailers ended up with a patchwork quilt of encryption solutions that don’t interact with each other, and filled their systems with decrypt-action-reencrypt holes.
From the very beginning, PCI DSS should have mandated specific forms of encryption at specific points in the retail process. “Encrypt the mag stripe here in the register. Decrypt it here at the authorizer. Prepare settlement files in this format. Use ANSI X9.65:2004 encryption. Store the keys this way.” If they had been prescriptive the retailers would not have each had to scramble to arrive at unique solutions. And the retailers wouldn’t now have the balkanized mess of partial layers of protection.
From a security standpoint it would have been even better if PCI DSS had mandated the encryption at the registers and permitted the decryption only at the issuers. Again, the fewer places where decryption can occur yields fewer places where bad guys can attack.
But due to numerous retailer complaints that the PCI DSS restrictions were too onerous, the PCI caved in and allowed retailers to get away with these slipshod solutions. As a result, we are now stuck in a “patch, attack, revise PCI DSS, patch, attack, revise PCI DSS” loop. It would have been far cheaper for us all to have done it right once up front.
September 5th, 2008 at 5:41 am
I’d like to add my perspective, as a former security product manager (at Entrust) during the days of something called Security Electronic Transactions (SET) – maybe from a time before some of you were born ;o) (circa 1998).
Visa and Mastercard developed a standard that was comparatively rock-solid for protecting credit card transactions between cardholders, merchants and payment gateways. We had fun complying with the standard, in hopes of riding the wave to prosperity. They really wanted to do it right.
Sadly, the standard never caught on, for two reasons. Banks and merchants didn’t like how much it cost to implement, and cardholders had to download and install ‘Wallet’ software.
So, I think they quietly let it die, since MOTO transactions were the responsibility of merchants for chargebacks, and consumers were not at risk for more than $50. They could have changed the economic incentives to make SET more successful, but chose not to. Their interest since then has never really been in keeping everything secure to the max, so much as keeping the whole model profitable, which depends on easy use and reasonable security risks.
So, I think the card companies are close to achieving their goal, but I don’t doubt they’d like to tighten it up. They just don’t want another SET fiasco.
In the meantime, for small businesses who often have no other security guidance, the PCI DSS is not a bad starting point. Certainly PCI can be improved. It has evolved already, and I expect it will continue in the right direction; but just not on all stakeholder’s preferred timescale.
September 5th, 2008 at 8:40 am
“…PCI doesn’t have the jurisdiction to issue rules for any equipment that is not somehow involved in payment card data.”
The assessments that I’ve been involved in have interpreted that the PCI DSS also applies to any devices that can reasonably communicate with at least one system or component that handles payment data–even if that “other system” never touches the payment data itself. So, in the case of, say, a generic PC on the same LAN segment as a POS system, that PC would be within the scope of (and be required to comply with) PCI DSS’s requirements related to passwords, patching, etc.. This, in turn, has led my clients to adopt a segmented LAN architecture where POS and other card-handling systems exist on one segment, and everything else is on another. And that’s a good thing—fulfilling the intent of the standard while also in practice making the overall system significantly more secure.