Five Trends That Will Change Retail Security
Written by David TaylorGuestView Columnist David Taylor is the Founder of the PCI Knowledge Base, Research Director of the PCI Alliance and a former E-Commerce and Security analyst with Gartner.
Around this time of year, I get nostalgic for the good old days at Gartner, when we used to make grand announcements about our visions for the future of technology. So here are five trends emerging from our research that will impact retail security in 2009 and 2010.
Both the evidence from security breaches and research by the card brands indicate that applications that collect, process or store confidential data are a major ongoing source of vulnerability. The lack of controls built into these applications enables all sorts of security failures, from weak passwords to the ability to extract to spreadsheets and e-mail highly confidential data, creating but not automatically removing temporary files containing such data, etc.
The PA DSS standard (formerly PABP), once it is fully enforced, will have an “up or out” effect on the application and developer businesses. Retailers should begin early in the New Year to evaluate the ability of their vendors to meet this standard and make plans to switch vendors if appropriate. In some vertical application sectors, as much as 10 to 20 percent of the vendors will exit the market.
Turns out the 1980s were a mistake, at least from the perspective of distributed computing. Remember all that valuable data we collected and distributed to “empower” marketing and other departments to improve customer analysis? We want it all back.
Essentially, tokenization only works properly when you centralize all your confidential data and create tokens to substitute for it. You may elect to have a third party manage that process for you, as the problem is actually much more complex than the “substitution” task I just described. In fact, if you have issues with encryption key management, you’ll have issues with tokenization. Even though it’s not easy, tokenization is facilitating what will be a massive “round up” of confidential data and it will change the way that confidential data is handled in the enterprise.
Many retailers assign the oversight of service providers, including those who collect, process or store their confidential data, to a manager in contracts administration. Even in organizations where there is a separate person for IT contracts admin, this person almost never understands the PCI or SOX implications that require a clear chain of custody for confidential data, even as it moves from the retailer to the service provider.
In addition, because the vast majority of service provider contracts do not prohibit retailers from sub-contracting some data management tasks, we have found that many retailers actually are not sure where their confidential data is being kept, who is responsible for protecting it, what procedures they employ and how they would be alerted (and alert the retailer) if a breach occurred.
The contract will likely have basic PCI compliance language. But what is still needed is greater due diligence of the service providers and their subcontracting relationships, in addition to analysis of the legal liability of day-to-day due care procedural responsibility for protecting your confidential data.
A separate project review to understand and measure the risks of “confidential data outsourcing” should be implemented. It’s certainly justifiable for many, given the risks that we have observed in our research.
Think, for a moment, about the implications for service providers of the paragraph above. Retailers and other merchants will start reviewing their service provider contracts, more customers will ask to visit or hire auditors to do inspections, and service providers will wind up spending much more time responding to customer requests for data security reviews and process documentation than some service providers can manage.
We have talked with perhaps a dozen service providers who are already overwhelmed by such requests. Beyond a crisis of time management, the additional demands from customers for security reviews and better documented procedures will also cause perhaps 10 to 15 percent of these service providers to get out of the business of handling confidential data. Over the next two years, we expect to see more of a shift to specialty service providers, who provide more secure data and application hosting and a higher price point than many merchants are currently willing to pay.
The idea behind “PCI Lite” is an implication of the risk-based merchant stratification that Visa had its member banks conduct of their Level 4 merchants in 2007 and 2008. Despite the current wording of the PCI standard, there is clear sensitivity in the review process to the lower inherent business and technical risks at most Level 4 merchants (e.g., dial up).
We expect this sensitivity will become more visible in the form of directives to banks, training for QSAs and education for the retailers themselves. I am not suggesting that we’ll see a “kinder and gentler” PCI or PA DSS assessment process.
I do believe that it’s important to the card brands to effectively extend PCI and security concerns to all the card-accepting businesses. And if they have to make changes to the enforcement process (and even to the standards) to make this work, I believe they are willing to do it.
We are currently working on two different reports based on our research, and we’d like your help. For the National Retail Federation’s “Big Show” in January 2009, we’re working on a “Cost-Effective Compliance” project that will feature many of retailing’s Best Practices in PCI. The other
PCI Knowledge Base effort is an analysis of the impact of PA DSS (Payment Applications Data Security Standard). If you are involved in either of these areas, or otherwise want to ask questions or discuss PCI, just send us an E-mail at David.Taylor@KnowPCI.com.
Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code.
-Marc
