Evan Schuman's StorefrontBacktalk

Guest 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.

Leading retailers are spending millions to build customized security architectures only to be frustrated by assessors and acquirers who are looking for "brand name" security products. Should retailers give in and buy packages or just develop better documentation and testing procedures?

This is called the hazard of being too smart. Nothing is more frustrating to a really smart person (so my smart friends tell me) than to do something incredibly clever and then have to explain it to dumb people.

That’s the situation many retailers find themselves in when it comes to developing highly customized or integrated data security packages; they’re frustrated that they have to prove the effectiveness of the package to their PCI assessor or merchant bank, who just doesn’t seem to understand why the retailer didn’t just "buy a package."

In addition, many assessors or banks are looking for a level of testing and independent review that goes well beyond what the developers have put together. I’ve spoken to dozens of retailers who have spent millions of dollars on these systems. Most are very frustrated that assessors, banks and the card brands all seem to prefer packaged software, even if the packages would not meet the needs of the retailer’s business as well as the custom approach.

Even outsourcing is easier if branded. After about 170 hours of interviews for the PCI Knowledge Base, it’s clear that the "easy route" to passing a compliance review is to be able to list a dozen or so "brand name" security products with which your assessor, acquiring bank and the card brands are familiar. This is true even when it comes to the process of outsourcing.

We’ve talked with merchants who have been given a "hard time" (in their view) because their plan for removing card data from their environment involved developing a customized system for substituting non-card numbers for card numbers and then using a third party to secure and manage the single instance of the real card data. This process is often called "tokenization."

You can’t go wrong buying XXXX. In the IT business, whatever technology is being acquired often must be justified to a non-techie, usually the CFO. Branded packages have been the simple way past such reviews for decades. PCI simply exacerbates this situation by adding additional levels of detailed review. Because these people review dozens or even hundreds of merchants’ security each year, it’s logical that they would prefer the "shorthand" answers branded security offerings represent.

Upgrade your SDLC. I’m not suggesting that retailers give up on building custom security controls or management applications. Indeed, for some retailers, their existing environment can only be managed via such approaches. But I am saying that it is important to recognize that assessors, acquiring banks and the card brands will need to review whatever is developed, so building such things as a thorough (preferably external) code review into your SDLC is standard operating procedure for the leading retailers I’ve talked with.

When combined with thorough documentation specifically designed to meet an external security review (i.e., that makes specific reference to security policies that themselves have been reviewed for PCI compliance), then the "proof process" will become much easier.

Why using packages is good. The bottom line is that when PCI or other compliance reviews are conducted, there’s a valid reason for preferring branded products to homegrown ones. An application that has been installed and tested by multiple other merchants is statistically less likely to have vulnerabilities than code written by Retailer X’s developers and has only been tested by Retailer X’s developers.

An external compliance review process that has a built-in preference for packaged approaches is based on that logic. It’s the retailer’s job to prove the effectiveness of what they are doing to secure card data, and it’s important to understand the rationale for why some paths to providing this proof are easier than others.