What are the differences between “end-to-end” encryption and “old-fashioned” encryption, apart from marketing hype? There are tons, and many are worth the time it takes to understand and plan for these issues because they will affect both your compliance and your overall data security. This week, we'll highlight three of these differences.
Last week, I noted that Visa’s new Data Field Encryption Best Practices (DFEBP) are designed to “compliment, rather than substitute for PCI DSS.” Since then, I’ve had several discussions with folks who want to know how the implementation of an end-to-end encryption approach can be integrated with their million-dollar-plus investments in enterprise encryption and key management systems. The last thing anyone wants to hear is that they spent tons of money to meet PCI DSS 3.4 and 3.6 (encryption and key management), only to be told that they wasted their money.
One fellow was especially upset about Visa’s reference to ANS X9.24 as the key management best practice, mainly because it’s so focused on encrypting PINs and is not meant to be a general-purpose key management system. Based on our research relative to encryption and key management, I suspect this concern will mushroom into a real battle unless technology vendors can make it clear how investments in enterprise key management systems will be preserved while still meeting ANS X9.24. These standards were, after all, designed for the financial services industry.
Anyone involved in PCI needs to do a little research on what they will have to do to reconcile their key management systems with the various options for end-to-end encryption. Everybody knows (or should know) that key management is ten times harder to make work than end-to-end encryption. So the next time people bring up end-to-end encryption, ask them to explain--in detail--how the proposed key management will work with their existing key management system. If you can’t get a sufficiently detailed answer, maybe it’s time to talk to somebody else.
One of the most important changes being driven by the end-to-end encryption juggernaut is the encryption of cards at the point of swipe. As long as we continue with existing magnetic stripe cards, encryption at the point of swipe greatly reduces the chances that data can be “sniffed” as it traverses internal networks on its way to an encryption server.
Given PricewaterhouseCoopers' recent report to the PCI SSC on the potential role of Virtual Terminal systems in reducing PCI DSS scope by eliminating any local storage of card data (even if encrypted), I suspect we’re going to hear more about the pros and cons of smart (and more expensive) POS systems versus greater centralization of POS payment security through the use of virtual terminal systems.
The issues are, again, protecting investments at the POS and how to ensure that whatever you implement will afford both compliance and reasonable security while having the longest potential lifespan. Right now, I’m thinking that virtual terminal approaches have the edge. Why? Simply because the more regulations and standards (such as PA-DSS and PIN transaction security) that are focused on protecting locally captured and stored data, the faster the POS hardware and software will “age.” And the more it will cost to upgrade stores and ensure consistency of compliance over a typical two- to three-year POS upgrade cycle.For merchants, this is another area where it’s time to consider making some difficult architectural choices. Data security and PCI compliance have driven millions of dollars in spending at the POS for a lot of retailers. Increased centralization and use of virtual terminals would seem to make sense for many more companies than currently use the technology. If nothing else, I am suggesting it’s worth discussing the option because it may potentially reduce the impact of PCI DSS on the POS in the future.
Most merchants would be thrilled to get rid of PCI compliance tasks. Because it seems unlikely that the standards will simply “go way,” the next best option is outsourcing compliance management. Comparatively simple tasks such as IP address scanning were designed to be implemented as services (from Approved Scanning Vendors) from the start.
But the advent of end-to-end encryption and tokenization have raised the prospect of actually outsourcing the vast majority of PCI compliance tasks by having payment processors and payment gateways actually control most of the process from the initial card data collection. That is, at the POS, online shopping cart or call center software via remote key management and transaction tracking through the use of tokens.
Yes, there are (and will continue to be) issues with how this process works and the extent to which these approaches really “remove” merchant systems from PCI scope. But that’s not my point. My point is that by truly “outsourcing” PCI compliance, are you also reducing your ability to really understand and measure your risks (of, say, a security breach) and is that what you want?
Enterprise risk management (ERM) models have several variables connected to technology-related risk, security breach risk, etc. The potential financial impact of these factors is often in the tens of millions of dollars.
What is really interesting about this point is that the PCI DSS mandates have caused what appears to be a fundamental shift in the willingness of even large organizations with extensive, well-trained IT teams to consider IT security outsourcing to an extent that I’ve not seen before. I’m not suggesting this is right or wrong, just that our research is showing a much greater willingness to consider “security as a service” and “compliance as a service” at levels beyond what we would have expected only a year ago.
I figure that as long as these merchants have considered how they will bake this into their ERM models, it's fine. I just suspect that for many merchants, this discussion hasn’t happened yet--and it needs to.
Each of the three decisions/issues highlighted in this column are worth millions, especially to larger merchants. For this reason, I’m really interested in what you think and where your organization stands on these points. As always, if you’d like to discuss this topic, visit the PCI Knowledge Base and fill out our “Contact us” form or send me an E-Mail at [email protected].