December 12, 2006 by tim.

The 11/25/06 edition of The Green Sheet has a very interesting article entitled Card Associations Get Aggressive on PCI Enforcement. According to the article, Visa has publicly indicated its intent to begin levying fines for noncooperative level 1 merchants. Visa’s projection is that 65% of level 1 merchants will be compliant by year-end, according to Hector Rodriguez, director of Payment System Risk & Compliance for Visa. “Penalties may be levied to an acquirer if its merchants fail to comply with the PCI Data Security Standard, particularly in the event of a compromise or in cases where a merchant retains full track data,” according to Martin Elliott, vice president for Emerging Risk at Visa.

The article cites an interesting case involving a data breach at Chipotle Mexican Grill. “Prior to August 2004, the possible theft of patrons’ card data led to up to 2,000 incidents of fraudulent charges totaling $1.4 million, for which the restaurant became liable. … After the possible thefts came to light, [Chipotle] set aside $4 million to cover reimbursement of fraudulent charges, the cost of replacing cards, monitoring expenses, and fines imposed by Visa and MasterCard. … In its 2005 annual report, the company disclosed fines from Visa and MasterCard totaling a combined $1.3 million, which had been levied against the restaurant’s acquiring bank. Adding in legal fees, the chain’s total expenses related to its liability stand at $5.5 million….”

The article goes on to address the common misconception that fines are only levied by Visa and MasterCard when data breaches have occurred. “While Chipotle’s fines stemmed from an actual compromise, acquirers face potential fines of $10,000 to $100,000 monthly for their merchants’ failure to become compliant, according to Visa.”  Unfortunately, there are still some merchants and service providers that pretend that they are unlikely targets and that their risk is minimal – in effect, sticking their heads in the sand and ignoring compliance requirements.

According to Mr. Herman of Visa, Visa considers storage of full-track magnetic stripe data to be “an egregious violation, which is susceptible to fines ranging up to $100,000 per month until compliance is achieved.” The article also asserts that the Federal Trade Commission can “levy penalties that can go well beyond fines from the Card Associations.”

As has been noted in prior posts to this blog, there is a significant benefit for organizations that achieve and maintain compliance with PCI: safe harbor. According to the article, “Acquirers for all levels of merchants who are in full compliance with PCI at the time of a security breach would not be subject to Visa fines,” citing Mr. Elliott of Visa.

Given the investment that Visa and MasterCard have made in instituting the PCI standards, and given the scrutiny that Congress has imposed regarding data breaches and security, it would seem likely that articles like this will become commonplace in the near future.

Posted in Payment Card Industry / Credit Card Security, Electronic Payment Security - General | No Comments »

October 25, 2006 by tim.

Visa, in conjunction with the US Chamber of Commerce, has published an alert that identifies the leading causes of data breaches. Full details can be found at the Chamber’s website. The five leading causes of card-related breaches are:

1) Storage of mag stripe data
2) Missing or outdated security patches
3) Use of vendor supplied default settings and passwords
4) SQL injection
5) Unnecessary and vulnerable services on servers

Also, the GreenSheet recently reported that Visa has increased its efforts to enforce compliance with PCI standards. The article states that all Level 1 merchants were required to validate compliance by Sept. 30, and that there are approximately 20 level 1 merchants that are currently subject to fines ranging from $10,000 to $100,000 PER MONTH for failure to comply.

In the October issue of Transaction World magazine, Michael E. Smith, Senior Vice President of Enterprise Risk and Compliance for Visa USA, has published an article entitled Targeting the Main Source of Cardholder Data Breaches. He cautions that “…some payment applications may inadvertently store prohibited, sensitive cardholder information,” creating a situation where merchants don’t even realize that they have a security risk. He also advises that merchants should check the list of PABP (Payment Application Best Practices) validated products on Visa’s site at www.visa.com/cisp. And he emphatically states that “Visa expects all payment application vendors to adhere to the PABP.” This article is one of the most direct declarations that I have seen of Visa’s intent to make PABP mandatory for all payment applications.

Posted in Payment Card Industry / Credit Card Security | No Comments »

October 20, 2006 by tim.

Given the complexity of Payment Card Industry (PCI) compliance, many organizations may conclude that complying with the PCI DSS will then ensure compliance with the myriad of state and federal laws and regulations that address privacy and data security (see Payment Card Industry Compliance and Data Breach Laws). Dr. Heather Mark addresses the relationship between PCI compliance and privacy in this month’s edition of Transaction World magazine.

She specifically addresses the legal requirement to provide a Notice, which is usually covered in the Privacy Policy on a website. She says that future articles will “attempt to answer the questions surrounding the intersection of privacy and security.” This should be a very helpful source of information for organizations trying to navigate these treacherous waters.

Posted in Data Breach Regulations, Payment Card Industry / Credit Card Security | No Comments »

October 13, 2006 by tim.

There is a great article in today’s edition of InfoWorld that talks about how the new credit card security requirements will have “repercussions across the entire high-tech industry,” according to writer Ephraim Schwartz. He specifically talks about how Visa’s Payment Application Best Practices (PABP) ”will quickly turn into de facto VISA requirements, as users of the software, such as merchants or card processors, face stiff fines for using noncompliant software.”

As a merchant, Visa mandates that it is your responsibility to use software applications that are PABP compliant. In fact, your merchant services agreement likely has already been revised with such language. However, simply choosing an application from the list does not satisfy the PCI Data Security Standards — the entire environment must be compliant, not just the application. This means that the server and entire network on which the payment application resides must comply with all of the PCI DSS.

Alternatively, merchants can outsource their payment processing to a Service Provider that has been recognized as fully PCI compliant by being included on Visa’s List of Compliant Service Providers.

Posted in Payment Card Industry / Credit Card Security | No Comments »

October 6, 2006 by tim.

Everybody knows that hackers focus their efforts on large e-commerce sites because of the huge treasure trove that these sites represent, right? Hackers aren’t going to waste their time going after small, virtually unknown e-commerce sites, are they? While this might be the conventional wisdom, Brian Krebs has a very interesting article in the 9/28/06 edition of The Washington Post that presents a totally different picture.

The article, titled ID Thieves Turn Sights on Smaller E-Businesses, describes how hackers penetrated a small e-commerce site and posted stolen credit card information “into an online forum that caters to criminals engaged in credit card and identity theft.” Mr. Krebs also exposes the sometimes false sense of security that is conveyed by security seals on sites.

I highly recommend this article as an expose’ of how this dark world operates. Certainly, it is good for a site to be tested by a security scanning vendor. However, as Mr. Krebs points out, this is not foolproof, and he cites examples of how hackers penetrated sites that were thought to be secure. Here is one particularly revealing line from Mr. Krebs’ article: “Jason Lam, who teaches a course on securing Web sites for the SANS Institute, a Bethesda, Md.-based security research and training group, estimated that Web site scanning services in most cases only identify about 60 percent of a Web site’s potential security problems.”

This article really exposes the need for all merchants and service providers to become fully compliant with the Payment Card Industry (PCI) Data Security Standard (DSS). Many merchants and service providers claim that they are secure because they use SSL, or because they pass all the tests from a scanning vendor, or because they have a firewall. Yes, these are all good measures, but they are just a small part of the rigorous requirements of the PCI DSS.

As a merchant, particularly a small- to medium-sized e-commerce site, the easiest way to comply with the PCI requirements is to avoid them altogether by outsourcing to a PCI-compliant service provider. But don’t just take their word for it — the only way to know if a service provider is PCI compliant is to find them in Visa’s official List of CISP Compliant Service Providers.

Posted in Payment Card Industry / Credit Card Security, Electronic Payment Security - General | No Comments »

October 3, 2006 by tim.

As if complying with the Payment Card Industry requirements, including the newly revised Data Security Standard, were not already challenging enough, any entity that stores sensitive personal information must also comply with a myriad of regulations such as data breach laws. About.com has an excellent section about identity theft and data breach disclosure.

Currently, there is no federal law that directly addresses data breaches, but numerous states have enacted their own legislation. Unfortunately, these laws are very diverse, with little consistency on even fundamental components like the definitions of key terms such as breach, personal information, and risk. Furthermore, since these laws protect residents of each of these states, an entity that stores personal information is subject to that resident’s state laws, even if the entity does not have a location in that state.

One of the best sources that I have found for concise information about state laws regarding data breaches is the Security Breach page on the VigilantMinds site. They provide an executive summary of state legislation as well as a matrix that compares key provisions of all of the state laws. In addition, they provide links to the actual legislation of each state. While this is certainly not a substitute for seeking legal advice on this matter, their site can save you and possibly even your attorney a lot of time.

Earlier this year, a draft bill was debated by the House of Representatives. The bill was called the Data Accountability and Trust Act (DATA), and if passed, it would have preempted all existing state laws. For now, the bill has been tabled. Dr. Heather Mark published an article entitled The Ever Changing Challenge of Compliance that gives an excellent overview of the provisions of this bill.

If your organization stores personal information, I hope that the links above will help you better understand the maze of regulations related to data breaches.

Posted in Data Breach Regulations, Payment Card Industry / Credit Card Security | No Comments »

September 29, 2006 by tim.

Earlier this month, the PCI Security Standards Council announced version 1.1 of the Payment Card Industry Data Security Standard (PCI DSS). It is a bit challenging to find a description of the changes from the original version, at least on the “official” sites. However, there have been some fairly informative articles in industry publications that address some of these points.

In an article in InfoWorld entitled Card Industry Targets App Security, Paul F. Roberts highlights how the new standards focus on application security, especially as it relates to track data. Citing an analyst at Gartner, Mr. Roberts writes that track data “is valuable to hackers and identity thieves because it can be used to make counterfeit cards.” Martin Elliott, director of corporate risk and compliance at Visa, also spoke with Mr. Roberts about the risks related to track data, and Mr. Roberts writes, “In fact, many merchants may be unaware that their payment applications collect and cache the track data, leaving the merchant unprotected while giving the merchant a misplaced sense of security.” Mr. Roberts has exposed the myth of security from packaged applications. Visa has published its Payment Application Best Practices to address these security concerns, as well as a List of CISP-Validated Payment Applications.

Another article, published in Transaction World under the title What’s Next With PCI Compliance, also addresses the Payment Application Best Practices. She points out how the credit card companies have imposed tighter restrictions on even lower volume merchants, stating that ”POS developers as well as smaller and mid-size merchants are now under scrutiny.”

Certainly, by imposing the tighter standards on payment applications and smaller merchants, Visa and MasterCard are forcing these organizations to spend drastically more on PCI compliance. However, with the proliferation of hacking, the entire payment network is only as strong as its weakest link, so even these holes must be plugged. As an alternative, these organizations — especially merchants — should investigate their options for outsourcing their payment processing to a certified PCI compliant service provider, which may offer substantial savings versus the costs of self-compliance.

Posted in Payment Card Industry / Credit Card Security | No Comments »

September 25, 2006 by tim.

What is a PCI Service Provider? 

Any company that stores, processes, or transmits cardholder data on behalf of another entity is defined to be a Service Provider by the Payment Card Industry (PCI) guidelines. Visa’s website provides the clearest information about how the PCI Data Security Standard (DSS) applies to Service Providers. However, Visa is just one of the companies participating in PCI, so a Service Provider must understand and adhere to the security program for all major credit card companies with its own set of requirements for compliance and registration.

How do we know what Service Provider Level we fit in?

Each of the credit card companies that participate in PCI has its own rules that define Service Provider Levels. For example, Visa, whose rules are available on its CISP for Service Providers page, defines the levels based on the number of annual transactions. However, there is one very important distinction in Visa’s rules that is overlooked by many service providers. By Visa’s definition, any service provider that stores, processes, and/or transmits cardholder data as part of a payment transaction is a Level 1 Service Provider. So in other words, a company that has access to cardholder data as part of a payment is automatically defined to be Level 1.

MasterCard is also very clear in defining the levels for Service Providers for its SDP program. MasterCard defines two categories of Service Providers: Third Party Processors (TPP) and Data Storage Entities (DSE). The Service Provider Levels Defined page defines all Third Party Processors to be Level 1.

What are the requirements for becoming a Level 1 Service Provider in compliance with the PCI DSS?

There are two primary qualifications of a PCI Level 1 Service Provider. The first is the successful completion of an On-Site PCI Data Security Assessment that is validated by a Qualified Security Assessor. To pass the Data Security Assessment, the company must demonstrate compliance with 100% of the requirements detailed in the PCI Security Audit Procedures, which contains over 250 specific points of compliance. The second qualification is successful completion of a PCI Security Scan by an Approved Scanning Vendor. Given the complexity of meeting the requirements, the compliance process often takes more than one year to complete.

Posted in Payment Card Industry / Credit Card Security | No Comments »