Evan Schuman's StorefrontBacktalk

PCI Columnist Walt Conway asks, do most retailers know that the people who wrote their payment applications have criminal records and that the reseller actually knows this? Also, do chains realize they can implement tokenization without paying for an expensive upgrade? Visa does, and the company spelled it all out in its recently issued Top 10 Best Practices for Payment Application Companies.

This document should be required reading for retailers. Although it is aimed at software developers, resellers and system integrators, the document has just as much relevance for any merchant who uses a third-party payment application (which is just about all of them). What Walt hears Visa telling retailers is: “You should expect more than just a PA-DSS validation.” And the result is, everybody benefits, including smart vendors and resellers (who now have a basis to differentiate themselves) and their merchant customers.

PCI Columnist Walt Conway wants to withdraw one point from last week’s column while reinforcing the rest. To suggest that the key could be derived from encrypting too small and easily guessable a field was wrong. But the essence of the concern is that properly configured systems would not be vulnerable to this type of attack. How many retail chains do you know that who have properly configured security systems?

Retailers looking to purchase a product rather than develop one in-house have to be equally thoughtful. They should make sure the software vendors providing their POS applications have experts on cryptography as part of their development teams. It’s not enough to ask what algorithm or key length the POS uses or even to check that the application is on the PA-DSS list of Validated Payment Applications without understanding the operational implications of how that application handles cryptographic functions.

The PCI Council’s Frequently Asked Questions (FAQ) #5391 states that “PCI-DSS applies to any entity that stores, processes or transmits cardholder data and any such entity is expected to comply with PCI-DSS, including issuers.” Because that is the case, PCI Columnist Walt Conway wonders if his card issuer has validated its compliance with a Report on Compliance (ROC) prepared by a QSA. In addition to being retailers or service providers, everyone reading this column is a cardholder, so we all have a stake in this issue.

Conway wants to make it clear, though, that he does not believe card issuers should be ordered to validate PCI compliance. Rather, he believes issuers should voluntarily validate their compliance. And they should do it for three reasons: It is smart; it probably won’t be that difficult; and, most importantly, it is the right thing to do.

The latest PCI-DSS compliance stats for the U.S. released by Visa on Monday (August 2) show a tiny increase in the compliance rate for Level 1 retailers since the last report, from 95 percent to 96 percent. The increase, though, may be a statistical anomaly: The number of merchants in that category dropped from 360–where it had been for the last two reports–down to 358. If one of those retailers was non-compliant, that might explain the difference right there.

Level 2 also saw a one-percent increase, from 94 percent–where that group had been for the last couple of reports–to 95 percent. The compliance stats for Levels 3 and 4 were again not reported, beyond the vague level of “moderate.”

Are your automated backup systems expanding your PCI scope? Almost everyone agrees that backing up your important data is a smart thing to do. Except, that is, when it’s not. The problem starts when your sensitive data seeps into places you don’t expect.

Your backup systems then unintentionally spread cardholder data to locations you don’t suspect and expand your PCI scope in the process, pens PCI Columnist Walt Conway. Should you be concerned? Walt thinks you should be, and he’s not the only one–the PCI Council thinks retailers might have a problem, too.

Have you read your contracts with all your PCI service providers lately? These are the third parties that store, process or transmit cardholder data for you. PCI Columnist Walter Conway thinks you should check your contracts to know whether your service providers are doing all they can to help you become PCI compliant. He is specifically thinking about one particular PCI Requirement.

That Requirement is 12.8.2, which states that merchants need to “maintain a written agreement that includes an acknowledgment that the service providers are responsible for the security of cardholder data the service providers possess.” Some disappointing service providers seem to treat this requirement as an annoying inconvenience. They either pretend it does not exist or isn’t their problem. The result is that you, the retailer, are caught in the lurch.

Franchisee Columnist Todd Michaud has a little game he likes to play when meeting QSAs. It’s called “Is It Compliant?” In this game he provides the QSAs with a fairly common situation in his restaurants and asks them to tell him if they think it is compliant or not. It doesn’t matter if these QSAs are under contract (paid) or if he just bumped into them at an industry event. They could be doing a full audit or an assessment, providing paid-for advice or shooting the bull over a beer.

To date, Michaud has not received three answers in a row that match.He encourages StorefrontBacktalk readers to play his game at home. Find a few different QSAs and ask them some tough questions. Here are some fun ones to get you started.

While the PCI Council debates changes for their self-assessment questionnaires, PCI Columnist Walter Conway has listed some sorely needed changes. For example, how about SAQ A requiring that service providers be not merely PCI compliant, but certified as a Level 1 Service Provider.

Or requiring these merchants to have vulnerability scans to prevent the bad guys from hijacking their customers. Or how about addressing mail order/telephone order (MOTO) transactions and requiring that you cannot do MOTO and still qualify for SAQ A.

PCI Columnist Walter Conway is not a boxing fan, but he wants retailers to remember the fight referee’s opening instruction: “Remember to protect yourself at all times.” Why? Because, he is discovering that the number of vendors lying about PCI is soaring.

“I guess I could be diplomatic and say these vendors just don’t understand what PCI requires, but it is a bit late for that. PCI has been in effect for several years, so ignorance is no longer an excuse. That train has left the station,” he penned. “Any vendor that can’t properly describe how its application or service will impact a merchant’s PCI scope or compliance is–in this QSA’s opinion–simply not telling the truth.” Do we have examples? Oh, yes!

When it comes to PCI compliance, Franchisee Columnist Todd Michaud is sick and tired of everyone pointing fingers at someone else. Nobody wants to be in the line of fire when (not “if”) a breach happens. As a result, they spend most of their energy trying to figure out how to avoid liability rather than actually addressing the problem.

The majority of credit card breaches in 2009 were with Level 4 Merchants (under a million Visa transactions). Very few of these small merchants understand PCI compliance. Even fewer are actually compliant. Only a handful of small merchants are actually secure (at least relatively). Everyone in the payments ecosystem knows it is a huge problem, the 800-pound gorilla in the room. But no one has an answer.

You have to wonder who is left among the U.S. entities that have not sued—and then settled with—TJX for its infamous data breach of more than 100 million card numbers. The latest to come up to the till: The Louisiana Municipal Police Employees’ Retirement System. But the settlement here—for $595,000—is not the interesting bit. Part of the deal was a change in an IT boss. The settlement specified that IT security efforts need someone to oversee operations. What was agreed? That the job be given to TJX’s own audit committee. The TJX board’s audit committee shall, through Dec. 31, 2015, “oversee security of [TJX's] computer system with respect to customer data, including [PCI] compliance,” the settlement said.

If you ever needed any proof of the strength of TJX’s legal position in these cases, you need look no further. When seeking an independent overseer, the best the plaintiffs could come up with was a committee within TJX’s own board? Setting aside the lack of independent perspective, this approach isn’t even a concession, given that the TJX board oversees such matters anyway. Want to freak out TJX investors? Tell them to imagine what this breach’s after-effects would have been had the attackers hit mobile transactions tied to debit cards. Were it not for zero-liability credit card programs, this legal outcome would be stunningly different.

Under what circumstances does a retailer become a PCI service provider? What about a shopping center operator that provides telecom services that its tenants use to authorize card payments? Consider, too, a college or university that outsources its bookstores or food court to a third party that continues to use the school’s network.

In the world of PCI, service providers are different from retailers. Retailers accept payment cards for goods and services, whereas service providers help enable those transactions by storing, processing or transmitting cardholder data for the merchant, writes PCI Columnist Walter Conway. Another difference is that merchants validate their compliance to their acquirer, while service providers submit their ROCs to the card brands. In the real world, these roles may get muddled, with merchants unwittingly crossing the line and becoming service providers.

In a move that seems to reflect a very different PCI approach coming from Visa, the world’s largest card brand has ripped the PCI approval from two Ingenico PIN entry devices after a data breach.

What makes this move especially interesting is how it undercuts two strongly held Visa positions, both in terms of publishing the names of vendors whose products are engaged in PCI naughtiness and in its position that no PCI-compliant retailer has ever been breached.

As we reported back in mid-April, the PCI Council has, this week, officially announced that the new versions of both PCI DSS and PA-DSS will move to three-year lifecycles. Because the PCI assessment cycle is only 12 months, this timing raises an interesting possibility for a retailer to game the system.

A retailer could, for example, validate compliance against the outgoing version 1.2 of the DSS in the fourth quarter of 2010 and use that same version again in the fourth quarter of 2011, just beating its retirement date, writes PCI Columnist Walt Conway. The implication is that such a retailer would not have to validate against the new version until the fourth quarter of 2012. This quirk of timing is more of a curiosity than a flaw resulting from the extended lifecycle. Conway doesn’t think anyone would recommend this strategy and, as a QSA, he argues very strongly that retailers–for their own sake–comply with the latest version of PCI as soon as possible.

When it comes to PCI compliance for franchisors, Visa is completely out of touch with reality. That’s from the pen of Franchisee Columnist Todd Michaud, who spent 9 hours with Visa execs at a franchisee symposium on Wednesday (June 16).

The morning was spent providing horror stories about how the sophisticated Russian organized crime syndicates responsible for the lion-share of breaches operate. The afternoon, meanwhile, was spent talking–indirectly–about what role tokenization and encryption may or may not play in the future of card data protection. Retailers representing more than 50,000 domestic locations were all in the same room, and not once were they asked their thoughts and opinions on the matter. “What a wasted opportunity,” Michaid wrote.

Do you accept PIN-based debit cards at your stores? Have you been accepting these PIN transactions for more than, say, six years? Lastly, are you aware that the first Visa-mandated sunset date for your old PIN Entry Devices (PEDs) is July 1, 2010? If you are like most major retailers, you will answer “yes” to the first two questions, but you might answer “no” to the last question. If that is the case, you are taking on increased risk and liability from these old PIN devices, pens PCI Columnist Walter Conway.

POS equipment, including PEDs, can last a long time. Older stores or POS locations that have not been upgraded may still have equipment that increases the risk of a data compromise. Therefore, retailers with locations or equipment over eight years old should check each of their PEDs against the currently approved lists.

In the same way you wouldn’t buy your gold Rolex from a street vendor, you shouldn’t buy a software payment application that is not on the PCI Council’s list of PA-DSS validated applications, writes PCI Columnist Walter Conway.

His advice to retailers: If an application is not on the list, don’t even include it in an RFP.

New PCI DSS compliance stats for the U.S. released by Visa on Monday (May 26) showed—for the first time—a drop in the compliance rate for Level 1 retailers, albeit a tiny one, from 96 percent to 95 percent. But it’s significant in that Level 1—the largest chains in the Visa empire—has always shown a steady increase and, at worst, a plateau.

The exact number of retailers in Level 1 was 360 chains in the figures released this week, which is the exact same number that Visa reported last month. Last month’s report covered activity through Dec. 31, 2009, and this week’s figures are current as of March 31, 2010. Those results suggest that four of last year’s compliant chains no longer are, bringing the number of non-PCI-compliant major chains up to about 18.

PCI deadlines are to be taken seriously, unless you’re $285 billion ExxonMobil with its approximately 2,200 gas stations in the U.S. Then it’s more like a suggestion.

Visa has given ExxonMobil branded retailers an extension from July 1, 2010, until Dec. 31, 2010, to update their EPOS systems. This change is a big part of the perception problem with PCI enforcement. Deadline exceptions need to be rare. But when they happen, they should be announced by the card brands—not via a leaked letter—along with the specific reasons for the extension.

Wal-Mart is waging an aggressive campaign to get the U.S. to adopt Chip-and-PIN. What PCI Columnist Walt Conway doesn’t understand is why Wal-Mart is doing this. What is the business case?

Conway can imagine a few scenarios, but none seems to be the answer. This issue is important to every retail CIO, so we need to understand what Chip-and-PIN will and won’t do, in addition to what the business case, if any, is for the U.S. and other markets to convert from magnetic stripe to Chip-and-PIN cards.

Have you ever wondered what happens to all your old card transaction data after you change your processor or acquirer? Most retailers have made such a change, and many make it a practice to rebid their card-processing contract every few years. After you move on, though, your data frequently doesn’t follow you. So, PCI Columnist Walt Conway asks, “What are your responsibilities if this old data gets compromised?”

Are you still responsible under PCI Requirement 12.8 for managing a service provider when you no longer have a relationship with that provider but it still has your data? Aside from PCI considerations, if a service provider–think tokenization vendor or loyalty program manager—simply goes out of business, how will you get your data back?

Retailers these days have far fewer PCI training options open to them. About the only game in town anymore for detailed PCI standards training is the PCI Council itself. But be sure to choose your program carefully.

Unless you are an L2 merchant who plans to self-assess, advises PCI Columnist Walt Conway, you could find yourself overpaying for a certification that you don’t need.

One of the top ongoing concerns about PCI compliance—the absence of a true safe harbor—has been obliterated in the State of Washington, thanks to a new law signed by Gov. Chris Gregoire. Well, obliterated to the extent that it otherwise requires reimbursement of a financial entity’s reasonable actual costs “even if the financial institution has not suffered a physical injury in connection with the breach.”

The law specifies that the post-breach game won’t fly in the state of Washington: A retailer “will be considered compliant, if its payment card industry data security compliance was validated by an annual security assessment and if this assessment took place no more than one year prior to the time of the breach. For the purposes of this subsection, a [retailer's] security assessment of compliance is nonrevocable.”

Most people, pens PCI Columnist Walt Conway, believe PCI applies only to merchants. But PCI actually applies to any entities that “store, process or transmit” cardholder data. If you do any of these three things, PCI applies to you.

In our increasingly strange new world of social networking and mobile commerce, a whole range of unexpected places will need to deal with PCI DSS. This week’s example is Blippy, the social exhibitionism site that last week posted more than just some members’ purchases online. It also posted their payment card numbers for the world to see.

What if we turned PCI compliance on its head and reversed the thinking?, asks Franchisee Columnist Todd Michaud. Instead of handing out fines for failure to meet the standards and then merely using a PCI failure as an excuse to deny a chain a preferred interchange rate, what if discounts were handed out for those who implement solid data security systems?

It is a somewhat simple concept: The amount of fees paid by a merchant to process a credit card transaction is directly related to how secure their environment is. You create a standard scorecard for each merchant’s “risk factors,” similar to a credit score.

PCI Columnist Walt Conway asks, “At what point does a voice over Internet Protocol (VoIP) vendor become a PCI service provider?” In other words, at what point does VoIP begin to affect your PCI compliance?

To that end, Conway was once asked, “If a VoIP network is used for cardholder data, what sections of PCI DSS would apply?” It was an easy question to answer: All of them.

With TJX having suffered well more than $47 million in out-of-pocket expenses from its infamous data breach (announced in 2006 but beginning as early as 2003), the $20 billion retailer is preparing to write still more checks. It has now set aside another $23.5 million for additional anticipated breach costs, according to its most recent 10-K statement filed to the SEC.

TJX has for years been the Poster Child for retail data breach. And to date, it is also the best example of how little material impact these breaches have.

When the new version of PCI becomes the law of the card-processing land in October, it will include new rules and clarifications on a wide range of key retail payment complaints.

Among the top changes, according to PCI officials, are: a requirement that retailers must perform extensive searches for cardholder data across all their networks and systems; clarification on strong one-way hashing of PANs; a move to a three-year PCI lifecycle; clarification on what constitutes acceptable network segmentation; new wording on what constitutes cardholder data; and the applicability of PCI for card issuers.

The latest PCI compliance stats—released by Visa this month—are a mixed bag, with Level 1s plateauing at about 15 major chains still non-compliant. But at the small and midsize merchant level, the numbers are so unimpressive that Visa has given up specifying the numbers. Not a good sign.

We now have three years of data to examine—2007 through 2009—so, to the extent that Visa has used the same categories during that time, we can add a bit of context to this information.

If you are like many CIOs, a lot of your security budget is driven by compliance requirements, including PCI DSS. Many merchants feel they are secure once they achieve PCI compliance.

But that is not necessarily true, pens PCI Columnist Walt Conway.

It has been said that there are two kinds of systems in this world: Those that have been breached, and those that are going to be breached.

If this premise is true, asks PCI Columnist Walt Conway, doesn’t it make sense for CIOs to budget for a serious data breach or similar contingency?

How do you use your PCI risk assessment? Requirement 12.1 tells you to have “an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment.” The questions for retailers and their CIOs are: “What do you do with that risk assessment once you are done? Do you use it to question your current practices and reduce your PCI scope?”

PCI Columnist Walter Conway opines that he hates to do a bunch of work and get nothing for it. “That’s too much like paying for dinner and then not sticking around to finish dessert. Often, merchants prepare a thoughtful risk assessment and then file it away (a.k.a., ’shelfware’) until their QSA returns the next year, at which time it gets dusted off, reviewed and, hopefully, updated. If that describes your situation, you could be missing a golden opportunity to reduce your PCI scope, lower your risk and cut your cost of PCI compliance.”

If you missed the recent RSA Conference–that annual Woodstock for security professionals worldwide–all you need to do is put the words cloud, security and compliance in a sentence with just about any verb and you can pretend you were there. The cloud is all the rage in corporate computing, and with good reason: It promises to significantly reduce your IT infrastructure investment and operating costs while improving availability. The issue for merchants is how to maintain security and validate PCI compliance in this brave new world of cloud computing. PCI Columnist Walter Conway asks, “Are PCI and the cloud incompatible?”

And he answers: Once your scope is addressed, you can tackle the other PCI questions–like separation of duties, encryption, key management, governance and the ability to conduct forensic investigation. You also will need to include due diligence of your cloud provider in your procedures for engaging a new service provider (Requirement 12.8). Personally, I’d like to know who else is sharing “my” cloud.

Are you paying too much to validate your PCI compliance? It’s possible, even likely, that you are, suggests PCI Columnist Walt Conway. The reason is not that your QSA is too expensive or that PCI is too demanding. Rather, the reason many merchants pay too much is that they forget PCI Requirement 0. You don’t know Requirement 0? It says: Minimize Your PCI Scope.

Failing to comply with Requirement 0 may be due to inertia or ignorance or both. Regardless of the reason, the result is excessive and unnecessary spending on people, process and technology, together with a lot of frustration.

Details of the PCI Council’s new “Merchant QSA” training program will be finalized in a few months, but it’s unclear how retailers will use it. PCI Columnist Walt Conway asks, is a few days’ training enough to qualify your Internal Auditor to lead a PCI compliance assessment?

What is the business case for using an Internal Audit instead of a QSA? Could the training—whether for a Level 1 or a Level 2 merchant—be used to build on or supplement a QSA? That is, will the Merchant QSA training be most useful to merchants as a valuable accessory rather than an entirely new PCI wardrobe?

The PCI Council may have thrown a compliance lifeline to retailers that are missing a required quarterly external vulnerability scan. This means you might—just might—be deemed PCI compliant even if through accident, poor planning or sheer blockheadedness you manage to screw things up and miss a vulnerability scan, pens PCI Columnist Walt Conway. Passing isn’t easy, and a successful result is not guaranteed. But if you do everything else right, your QSA may be able to assess you as compliant in spite of yourself. Then again, did the Council both offer an option and take it away?

During an onsite assessment, QSAs confirm that merchants have met PCI Requirement 11.2 by examining the passing vulnerability scans for each of the last four quarters. The problem is, what if the merchant has missed a scan? If this happens, is the merchant noncompliant until it can get four quarters of passing scans? Ouch.

Reports of the latest successful attack on chip cards based on the EMV standard should remind all of us once again that there is no such thing as absolute security. Retailers and consumers worldwide–especially those in Canada who are currently implementing chip-and-PIN–need to understand this fact and not count on any single technology to remain secure. That is why PCI remains relevant even in a chip-and-PIN environment.

From a security perspective, PCI Columnist Walt Conway pens, retail CIOs should understand a few things about these chip cards or smart cards (i.e., payment cards with an embedded integrated circuit or microchip). Chip cards can reduce fraud losses, but chip-and-PIN zealots can overstate the benefits.

The PCI Council, in an attempt to show that it can be flexible and truly is listening to industry feedback, is now on the third version of its controversial policy on audio recordings since the beginning of the year (which is fairly impressive, given that it’s only mid-February). On Wednesday (Feb. 17), the Council backed off some of its stricter requirements that all sensitive payment data on digital recordings must not be retained.

Saying that it was “a result of additional market feedback,” the Council ruled that the sensitive payment date on the digital recordings could be retained if the retailer can prove that the data in question can’t be queried. “The Council is now saying that call centers can keep this data—even if digital—so long as they protect it per PCI. That is big,” said Walter Conway, a 403 Labs QSA who is also StorefrontBacktalk’s PCI columnist.

Tokenization and end-to-end encryption are designed to secure information both in transit and at rest. In other words, the focus of each technology is security first. The fact that they can reduce PCI scope or make PCI compliance easier is a secondary benefit. That tokenization and end-to-end encryption vendors are starting to figure this point out is good news.

The smart ones—and the only vendors you should be talking to, by the way—will tell you that there is no silver bullet to make PCI go away, which is a victory for reality over marketing hype. But there is one thing you should know about reducing your PCI scope: It is pretty important. If retailers are going to get the full value for their investment in either or both of these technologies, opines PCI Columnist Walter Conway, they better look carefully at their implementation or they may find they will not get all that they paid for.

PCI rules have always—and wisely—discouraged using payment card numbers for anything other than processing payments. But sometimes those rules run contrary to long-established paper practices, procedures that pre-dated PCI’s creation. A good example of this conundrum involves a federal agency, tax-exempt status forms, and the procedure of copying a government-issued payment card (this one happened to be Visa branded) and placing a copy in the file cabinet.

This situation involves the U.S. government’s General Services Administration (GSA) and some GSA interactions enjoyed by Benjamin Moore & Co. (the paint people). The conflict cropped up when the chain was dealing with some military accounts in Hawaii. The issue comes down to needing that payment card copy in the files (tax-exempt rules) but being unable to save the copy of a Visa payment card (PCI rules).

Over the last few weeks, one of the most common questions we’re hearing discussed is “Is PCI really worth it?” These are multi-billion-dollar retail chains asking this question. But there’s a lot more behind the question than it might initially seem.

In a marked contrast to the same kinds of questions two years ago, the intent is not to ignore security. Indeed, many of the chains considering such a heretical question are already putting in place security procedures that go well beyond current PCI requirements. This isn’t a safety or security issue. It’s a simple CFO’s ROI balance sheet, contrasting the bureaucratic and paperwork costs of dealing with the very formal PCI procedure with the limited fines and other bad things that will happen if a chain suddenly stops pursuing PCI compliance. A report released this month from Ponemon tried to quantify the cost of breaches today, but its conclusions are rather underwhelming.

For your overflowing folder marked “Ludicrous PCI Scare Tactics That Too Many People Believe” comes a renewed effort from some security vendors to say that out-of-date operating systems this year will cause instant PCI non-compliance. The cure: Give the vendor a lot more money. (Funny how that “cure” seems to treat so many ills in these letters. It’s the Penicillin of PCI.)

A letter from a POS vendor making the rounds warns retailers—under the headline “Information Security Advisory”—that an out-of-date OS will cause lack of compliance with PCI. The warning isn’t true, but the popularity of this and related PCI claims is moving beyond annoying. Are these vendors lying or is marketing being allowed to make the claims without anyone checking? A recession drives marketers to desperate measures. (OK, so does prosperity, but let’s not go there.)

PCI Columnist Walter Conway argues that it may sound like heresy coming from a QSA, but he sees some merchants over-emphasizing their PCI annual assessment. The main event for them is a clean Report on Compliance (ROC) for Level 1 (and soon Level 2) merchants or a Self-Assessment Questionnaire (SAQ) for everybody else. They believe that once the ROC is signed, they can relax until the next year.

But PCI is not like that. PCI has requirements that demand regular attention if merchants are to remain compliant the other 364 days in a year. CIOs and merchants who focus only on their annual PCI validation may actually find that they unintentionally make themselves more vulnerable to a costly data breach. They also make their PCI revalidation the following year more difficult, and possibly more expensive, than it has to be.

For retail CIOs, this is the worst of times and it is the best of times. It may be the worst of times because the emergence of smartphones at the POS, the increase in the amount and availability of customer data, and the growing tokenization and end-to-end (E2E) encryption options may have CIOs (and their QSAs) reaching for the aspirin bottle. On the other hand, it may be the best of times because the CIOs who can address these challenges will be rock stars in their companies.

At the National Retail Federation (NRF) show this week, several vendors were pitching payment card readers (and other peripherals) that could attach to a smartphone, thereby converting it into a POS device. Some of the readers are already PCI PTS approved. With one of these and a Blackberry, merchants can move the POS from a fixed counter to anyplace inside – or even outside – their stores. And the best part is that merchants can have this wireless capability for a price far less than current wireless POS devices offered by most manufacturers. PCI Columnist Walt Conway can think of several merchants he works with that will be looking at these devices very seriously. But, he argues, the PCI implications are complicated.

PCI Columnist Walt Conway sees PCI 2.0 mandating the use of automated cardholder data discovery tools, will impose rules that will literally overrun the council’s PCI training program and will likely not alienate Level 2s enough to make a difference. (That’s the secret to a happy marriage, knowing the precise moment that an aggravation level will overtake apathy and stopping nanoseconds short of it.)

But Conway sees the data discovery prediction the most significant. “If you have a lot of locations, you have work to do setting up and scanning all those databases, workstations and servers. Especially watch to see if the Council decides to implement data discovery like it did wireless scanning (Requirement 11.1). If this happens, merchants will not be able to sample locations and will have to search each one. The good news is that you can conduct these searches internally and there are good open source products available. Your QSA likely would only need to verify the results of your automated discovery and to review the scope of your search.”

When it comes to franchise-based retailers, Franchisee Columnist Todd Michaud opines, PCI Compliance is broken, plain and simple. It simply does not address the complexities of the franchisee/franchisor business model and, in the end, leaves the franchisor holding the bag. Because each franchisee is a separate merchant, most large franchise organizations are only required to meet PCI Level 4 requirements. Chains are forced to make tough decisions about how much risk they are willing to accept and what they are willing (or not willing) to do to protect their brand integrity.

It boggles his mind that millions of dollars are spent each year to “secure” database lookup (authorization) and database write (settlement) transactions. Tokenization and encryption should have been required years ago. Although not all techies agree that this approach is best, I think we all agree that it is much better than nothing. But too many companies–my firm included–are going to have to spend too much money to implement such daydream adventures, so we keep living with a broken system. Unfortunately, this broken system has left franchisors with no “good” options.

Do cybercriminals concern you? Are you afraid that you might lose cardholder data? Are you worried that your internal users are downloading malware from the Web? If so, PCI Columnist Walt Conway has a question for you: Why are you more afraid of your QSA than you are of a cyberthief?

Consider this example: A merchant shows its QSA its Web application firewall (WAF) and asks the QSA to mark it compliant with PCI Requirement 6.6. But the QSA probes deeper, and he finds that the WAF is in “learning” mode, which means it is letting everything through. Indeed, the WAF has been in learning mode since it was installed after the last assessment a year ago, meaning it is pretty useless from a security point of view and definitely not meeting the intent of the requirement.

When PCI Columnist Walter Conway played high school football, the coach once said to him, “Son, there are three ways you can do things: the right way; the wrong way; and the coach’s way. Which way are you going to do things?” To which he replied, “the coach’s way, sir.” PCI can sometimes get like that when the card brands can’t agree among themselves as to whether something is in-scope or out-of-scope.

Most companies issue their employee road warriors with corporate travel cards. Companies also issue purchasing or procurement cards that their staff use to buy everything from office supplies to store fixtures. Most of these cards are American Express, MasterCard or Visa branded. Companies store the PANs in databases that are accessible to travelers and others who use the data for expense reporting and tracking. In my experience, the PANs get printed on hardcopy reports. The question for IT execs is, do you need to include these cards in your (merchant) PCI scope? The surprise answer is that it depends on where you store the cardholder data and, interestingly, on which brand of card you choose.

Now that a PCI lawsuit brought by four restaurants against a POS vendor and a systems integrator has been given class-action status, the case will survive and force a very interesting debate about exactly where a retailer’s PCI liability should start.

The case involves four Louisiana restaurant groups—doing business as Crawfish Town USA, Don’s Seafood and Steakhouse, Picante’s Mexican Restaurant, Mel’s Diner Part II and Sammy’s Grill—suing their POS vendor, Radiant Systems (which owns the Aloha POS systems used by these chains), along with systems integrator Computer World (not to be confused with the publication Computerworld). But when you drill into the details of the lawsuit, it gets more interesting. One of the key accusations against Computer World is that it used vendor default passwords for systems with many of these restaurants, for easier remote administration. The lawsuit correctly points out that PCI bans retailers from using such vendor default passwords. But that’s the key. It’s the retailers that are not permitted to use these defaults. Was integrator Computer World, in this scenario, acting as an agent of the POS manufacturer—as a reseller—or as an agent of the retailer–as an integrator?

Many Level 2 merchants are just now realizing that their PCI world has changed. Under rules announced this summer, Level 2 MasterCard merchants—like their Level 1 brethren—will require an onsite assessment by a QSA starting in 2010. But how big a difference, asks PCI Columnist Walter Conway, is there really between self-assessing and an onsite review? Actually, there are 525 differences.

Conway’s concern is the almost inevitable fourth quarter 2010 PCI train wreck as the new rules collide with human frailty and the calendar. The result may be that even some Level 1 merchants and processors don’t get their assessments (and ROCs) completed on schedule.