Quantcast StorefrontBacktalk » Search Results » PCI compliance
advertisement
advertisement

Visa Raises The Bar For PA-DSS Applications And Vendors

September 2nd, 2010

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.

Read more...

advertisement

Encryption Implementation Really Matters

August 26th, 2010

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.

Read more...

advertisement

I Wonder If My Card Issuer Has A ROC?

August 11th, 2010

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.

Read more...

advertisement

PCI Level 1 Merchant Compliance Up Slightly

August 4th, 2010

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


advertisement

Are Data Backups Unintentionally Expanding Your PCI Scope?

August 4th, 2010

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.

Read more...

Double-Check Your PCI Service Provider Contract

July 28th, 2010

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.

Read more...

PCI Compliance: An Updated Version Of The Newlywed Game

July 21st, 2010

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.

Read more...

PCI Self-Assessment Questionnaires Need Some Major Updates

July 21st, 2010

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.

Read more...

Retailers Need To Protect Themselves From Lying Vendors

July 14th, 2010

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!

Read more...

Enough With The PCI Finger Pointing Already

July 12th, 2010

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.

Read more...

TJX Settles Another Data Breach Lawsuit And Puts Itself In Charge Of The Oversight

July 11th, 2010

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.


Beware Falling Into The PCI Service Provider Trap

July 8th, 2010

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.

Read more...

Visa Revokes PCI Approval From Ingenico PIN Pads Following Breach

July 1st, 2010

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.

Read more...

New PCI Lifecycle Gives Retailers A Way To Game The System

June 24th, 2010

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.

Read more...

Visa To Franchisors: “We’re Here To Talk, Not To Listen”

June 17th, 2010

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.

Read more...

Toxic Waste: Old PIN Pads Never Die, But They Really Should

June 16th, 2010

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.

Read more...

Complying With Visa’s July 1 PA-DSS Mandate

June 10th, 2010

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.

Read more...

New PCI Stats Show First Time Drop In Level 1 Compliance

May 26th, 2010

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.

Read more...

ExxonMobil Discovers That A PCI Deadline Is A Deadline, Unless It Isn’t

May 26th, 2010

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.

Read more...

Wal-Mart And Chip-And-PIN: Where’s the Business Case?

May 26th, 2010

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.

Read more...

When You Change Processors, What Happens To Your Data?

May 19th, 2010

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?

Read more...

Avoid Paying For PCI Certification You Don’t Need

May 12th, 2010

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.

Read more...

New Data Breach Law Says Assessor—Not Visa—Has The Final Word

May 12th, 2010

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

Read more...

Blippy Fiasco Shows PCI Applies To Everybody—At Least It Should

April 29th, 2010

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.

Read more...

A Merchant Processing Score: The Anti-PCI

April 21st, 2010

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.

Read more...

When Does A Telephone Company Become A PCI Service Provider?

April 21st, 2010

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.

Read more...

TJX Adds Again To Its Breach Cost, But It Doesn’t Really Matter

April 21st, 2010

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.

Read more...

New PCI Changes: Network Segmentation, One-Way PAN Hashing

April 14th, 2010

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.

Read more...

The Latest PCI Compliance Stats Disappointing For Level 3s

April 14th, 2010

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.

Read more...

PCI Compliance Is Good; Data Security Is Better

April 7th, 2010

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.

Read more...

Budgeting For A Data Breach

March 31st, 2010

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?

Read more...

Squeezing More Value From Your PCI Assessment

March 25th, 2010

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

Read more...

PCI And Cloud Computing: It’s All About Scope

March 18th, 2010

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.

Read more...

Overpaying For PCI Compliance

March 10th, 2010

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.

Read more...

Should Retailers Use PCI Training To Enhance—Or Replace—Their QSA?

March 2nd, 2010

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?

Read more...

Missed A Vulnerability Scan? The PCI Council Just Threw You A Lifeline

February 24th, 2010

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.

Read more...

Chip-And-PIN Is Not A Free Pass On PCI

February 18th, 2010

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.

Read more...

PCI Council Changes Its Audio Recording Policy, Again

February 18th, 2010

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.

Read more...

Security Versus Scope: Choose One

February 11th, 2010

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.

Read more...

PCI Conundrum Of The Week: When Plastic Meets Paper

February 10th, 2010

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

Read more...

Data Breach Cost Numbers Games

January 28th, 2010

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.

Read more...

Will Old OS Cause PCI Violation? No, But Marketing Still Says So

January 26th, 2010

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

Read more...

Can Validating PCI Compliance Increase Your Vulnerability To A Breach?

January 25th, 2010

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.

Read more...

NRF + PCI = CIO Job Security

January 14th, 2010

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.

Read more...

A Look at PCI in 2010

January 6th, 2010

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

Read more...

When It Comes To PCI Compliance, Franchisors Are Screwed

December 16th, 2009

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.

Read more...

Why Are You More Afraid Of A QSA Than A Cyberthief?

December 16th, 2009

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.

Read more...

The Corporate Travel Card PCI Challenge

December 8th, 2009

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.

Read more...

Retailers Sue POS Vendor, Questions Raised Where PCI Duties Stop

December 2nd, 2009

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?

Read more...

PCI Human Train Wreck Coming Next Year For Level 2s

November 30th, 2009

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.

Read more...

Page 1 of 512345»

Newsletter

Quickly catch-up on the latest in E-Commerce and Retail Tech with our free weekly newsletter, with urgent bulletins as news merits.
advertisement

Most Recent Comments

Kill All The Passwords

This article does mention, but does not give enough attention to, the fact that the attacks discussed are only feasible when the encrypted password file can be copied and subjected to an offline attack. The trick is to have authentication performed on a separate, much more strongly secured host - such as an Active Directory Domain Controller, or a Kerberos server, or a NIS+ server, or even using something as banal as an LDAP-over-SSL authentication dialog. In these environments, the odds of the "password file" being stolen and subjected to an offline attack go to near zero, and only online attacks may be carried out by the attacker. With sensible exponential backoff between failed password attempts, lockout after a modest number of failed attempts on a single account, and pattern detection, that minimum 7 character password is quite secure enough. Passwords aren't dead yet for security purposes, and they will be with us for a very long while to come for practical purposes. The trick is to employ them correctly. Read more...
The possibilities you describe are years away from being implemented at best, so for the moment passwords are an ugly reality. Luckily, password managers can easily manage hundreds of passwords of any length. The only thing a user needs to remember is the master password. It seems like an easier task to educate users on how to use password managers rather than implement complex security technology on a global basis. Read more...

Too Much Encrypt = Cyberthief Gift

Encryption should be left to the experts. This does not mean retail managers should not have a high level understanding, but they must rely on certification and vulnerability tests to validate their implementations. It also means there is an opportunity for implementation modules with clear API’s that give casual users the means for implementing secure environments. Read more...
The next argument would be to store a hash for lookup purposes. But having a hash of the PAN sitting along side the encrypted PAN opens another potential attack vector similar to the expiration date discussion we are having here -- even bigger since the hash has much more resolution than the expiration date. Read more...
The poster comments here about resistance to known plaintext attacks are, of course, correct. However, the sense I keep getting is that "these attacks aren't realistic against modern cryptosystems." They are not effective against modern cryptosystems *when those systems are implemented correctly.* The problem is, as has been pointed out here, is a lot of people don't know enough about *how* to implement the cryptosystem. They know they want to use something like AES. However, they have no sense of key management, selection of IVs, etc. Read more...
There is absolutely no value in encrypting these small fields of data in the first place. Implement RBAC and auditing and call it a day. Read more...
And I think they reinforce my point why current PCI regulations are fated to never be successful at safeguarding cardholder data, at least not while sensitive data exists unencrypted in the merchants' systems. And if we can't adequately protect every system, the bad guys will continue to prey on the weak ones. The internet makes it easy to attack thousands of sites at once. With about seven million card accepting merchants out there, the poorly protected are plentiful. Read more...
Time perhaps for a new approach to training? Time for an approach to permit questions, doubts or concerns that may arise like this to be dealt with promptly and authoritatively by industry and standards bodies to the benefit of the whole PCI community? Read more...
In crypto terminology, just because you can do a chosen-plaintext attack does not mean that you can do a key recovery attack. So even if you can build a table of valid plain-cipher pairs for expiration dates, for example, that does not mean that you can use that information to recover the key used to calculate those ciphertexts. Read more...
I'd be less concerned about the size of the input, and more concerned about the IV and the consideration of a brute force attack (or other types of cryptanalysis). Read more...
P
@Steve Sommers In your example, isn't the problem that you're treating the PAN as a string, then encrypting the string without using a block chaining mode (i.e. you're encrypting each block of data independently) without an initialization vector? Read more...
Where your attack can give up a bit of information is that if I know my expiration date is January 2012 and it encrypts to 1111aaaa2222bbbb, I know that every entry of 1111aaaa2222bbbb in the table will also be an encrypted expiration date of January 2012. For that matter, the same issue exists with PANs. Read more...
I was thinking similarly to Rob, however, implementing that may not be feasible for everyone. Interesting topic. Read more...
This was something we found during our R&D cycle when determining the best was to encrypt CHD in our database. Another factor that played into our decision was the encryption algorithm itself -- different algorithms work better (and some worse) on small data sets. We found that 3DES, the dominant payment industry encryption algorithm, works very poorly for small data fields due to repeatable patterns in the limited data set. Read more...
If the argument is that bigger data fields having more possible permutations are harder to decrypt, it seems logical to merge the 4 key fields (PAN, Name, Svc Code + Expiration Date) into one large field and encrypt it as one field. This avoids leaving the weak calf (expiration date) isolated for the wolves to attack. Read more...

How Free Wi-Fi Can Shut Down A Restaurant

We walk into businesses every single day that have even the ISP leaving their modem/router/AP combo device completely open. It's amazing the number of times we have been able to demonstrate complete control of their network from something as simple as my Nokia cell phone. Read more...
This is a weak link in the chain. I bet that the council, in the next set of updates, will begin to take a close look at this issue but implementing it will be another matter altogether. One thing is for sure: If the hackers know there is a weakness, they will begin to exploit it. Many already have. Read more...
Richard, I think that is a great way to handle it - especially if the franchise is concerned that it may get caught up in the risk of its franchisee. Read more...
If people fully appreciated the complexity and the risks lots fewer stores would be offering free WiFi. It is more costly up front than it looks to do it right - and is potentially devastatingly costly when done wrong. I guess we should chalk this up as survival of the fittest in the franchise space. Bryan Larkin Read more...
If people fully appreciated the complexity and the risks lots fewer stores would be offering free WiFi. It is more costly up front than it looks to do it right - and is potentially devastatingly costly when done wrong. I guess we should chalk this up as survival of the fittest in the franchise space. Bryan Larkin Read more...
If the Franchise ownwer wants to offer free WiFi to compete with the shop across the street, then order the 'kit' with a set hardware and configuration and broadband service from the Franchise (or a recommended 3rd party provider)? Read more...
Todd, Since I have many years of experience in this area especially with pay at the table since my company was the first to make the breakthrough in successfully integrating the very first 802.11b payment terminal to an enterprise level POS system long before PCI, before anyone thought it could be done and to read that this is still taking is amazing. So I am asking myself several questions based on your article. Why is the POS plugged into a wireless router to begin with? I cannot think of any reason even for a small operation to do so, even for IP connectivity and does this not bring up a whole lot of issues for the MSP, would they not have exposure since I am assuming that the merchant is using the POS to conduct payment transactions for processing CC and DC. Guess we still have a ways to go. Read more...