Archive for July, 2010

26
Jul
10

Advice To Merchants

Barring the card brands developing a truly secure card processing process, the PCI DSS and related standards are likely to be with us for quite a while.  That said, what is the future of complying with the PCI DSS?

For merchants, if you are not seeking out point-of-sale (POS) solutions that do not store cardholder information, you should be as soon as you possibly can.  That includes finding card processors that do not require you to store cardholder information and can provide you access to cardholder information when you need it for resolving disputes and chargebacks.  According to Robert McMullen, CEO of TrustWave, the majority of breaches TrustWave investigated occurred with POS systems.  So the rational approach to resolving this problem is to get rid of the cardholder data stored on these systems.

The problem with this is that most merchants, large or small, think that they need to store this information for some reason.  If you are a merchant in the United Kingdom, France, Italy and other select European countries, then you do need to have the PAN unencrypted, however it only is required on an original printed receipt, it is not required to be stored anywhere else.  So, all merchants need to put POS solutions in place that do not store cardholder data.  You do not need it and it puts you at risk if you do store it.

The next thing merchants need to do is to find a card processor that does not require the merchant to store cardholder data.  This can be a processor that uses tokenization or whatever, but the bottom line is that the processor does not return cardholder data to the merchant’s systems.  These processors typically provide secure Web-based systems that allow the merchant to view all of their transactions processed and, if necessary, provide a method to decrypt the PAN for dispute research and chargebacks.  Merchants need to restrict access to the processor’s applications to only those people that absolutely need access to perform their job.  These people should be reviewed at least quarterly to ensure that they continue to require access.

For those of you that just cannot get rid of cardholder data, there is the option of hashing.  Hashing allows applications such as fraud discovery, member tracking, rewards programs and similar functions to continue, they just do not have access to the actual PAN.  A hashed PAN results in the same hashed value, so research and analysis of PANs can still occur.  It is just that if you need to see the real PAN, you will have to go to the processor’s system to obtain the real PAN.

The travel industry, in particular hoteliers, are really behind the eight ball on PCI because of their need to keep the PAN for sometimes years because of the way reservations work.  However, this is where tokenization can earn its keep.  If a hotel takes a reservation and gets back a token when the credit card is authenticated, then the hotel can use the token however many times in the future for check in and check out.  Again, there is no reason for the hotel to need to retain the actual PAN.

The bottom line to all of this is that there are ways to minimize your organization’s PCI compliance efforts just by getting rid of the data in the first place.  So, stop putting forth efforts to comply and get with the movement to get rid of the cardholder data in the first place.  I have had a few clients go down this road and PCI compliance is now a piece of cake.  Their networks are still in scope for transmission, their applications in some cases do process cardholder data, but there is not storage which makes them much, much less of a target.

18
Jul
10

An Open Letter To Acquiring Banks

Get with the program people!

The PCI standards have been around for almost four years now and you would think with all of the press that has been given the PCI standards that the key participants in the standards would be intimately knowledgeable with these standards.  However, the more and more I talk to acquiring banks, the more I am amazed that most acquiring banks still are not with the program.  It is time for all acquiring banks to get a clue about the PCI standards and their responsibilities regarding the PCI standards.

Acquiring banks have many responsibilities under the PCI standards.  The first of which is to understand and support the PCI standards.  However, it is painfully obvious from trying to work with acquiring banks that most are clueless about the PCI standards, let alone do they understand their responsibilities.  Card brands and the PCI SSC have focused on educating QSAs, merchants and service providers in the PCI standards to the detriment of educating acquiring banks.  I cannot tell you how many conversations I have had with acquiring banks where they have no idea of what their responsibilities are regarding the PCI standards let alone regarding knowledge of the PCI standards themselves.  What I dearly love are those acquiring banks that tell me that they have no responsibilities in regards to the PCI standards, that it is a merchant program.

This is not just a problem in the United States, this problem is worldwide.  This is a very big issue in Asia where acquiring banks seem to be totally clueless about the PCI standards.  It is a bit better in Europe, but because European acquiring banks have been brainwashed to believe that Chip and PIN gives them a security edge, the acquiring banks there are not aggressively promoting PCI compliance.  But at least the European acquiring banks seem to have a basic understanding of the PCI standards and some of their responsibilities.

Another responsibility of acquiring banks is to be the final arbiter between merchants or service providers and their QSAs.  According to the card brands, if a merchant or service provider is at loggerheads with their QSA over whether a PCI requirement has been met, the acquiring bank is supposed to be the final arbiter of that dispute.  Yet in the handful of instances where I have been involved in such disputes, the acquiring bank has provided limited or no assistance with the dispute.

An even bigger problem is with small merchants that are trying to decide which Self-Assessment Questionnaire (SAQ) to file.  Again, the card brands have stated that the decision regarding which SAQ to file is the responsibility of the acquiring bank and no one else.  Yet time and again, our small merchant clients contact my Firm because the acquiring bank has told them it is up to a QSA to determine the SAQ to file.

Then there is the acquiring banks’ responsibility to follow the PCI standards.  Yet time and again, I run into instances where the acquiring bank is transmitting cardholder data insecurely to or from the merchant or service provider.  The number of acquiring banks that use FTP or electronic mail for the transmittal of cardholder data is just staggering and after four years of the PCI standards existence is unacceptable.  Yet, when you bring this issue up, a lot of the acquiring banks will tell you that PCI standards are for merchants, not for them.  The other excuse I hear is that the acquiring bank is working on securing their transfer of cardholder data.  Again, after four years of the PCI standards, you are just now getting around to securing the transmission of cardholder data?  Unbelievable.

This year we started receiving calls from banks and credit unions that drive their own ATM networks that had been requested by their ATM network interconnection provider such as NYCE and Pulse to obtain a PCI Report On Compliance.  What a wakeup call.  In a number of cases, the institution was shocked that the PCI standards applied to them and questioned us extensively to confirm that they really had to go through the process.

As a QSA out in the field, these attitudes are just no longer acceptable.  The PCI program flounders in part because one of the key constituents is not on board.  It is time for the PCI SSC and the card brands to educate the acquiring banks and get them engaged.

03
Jul
10

Why The PCI Standards Exist

After another spate of articles and speeches about the PCI DSS and why it is worthless, I thought it might be a good idea to explain why the PCI standards came to exist.

In 1999, Visa USA began to work on what became the Customer Information Security Program or CISP.  The first official version of the CISP was issued in the summer of 2003 with Visa asking select merchants to comply with the CISP as soon as they could.  The original impetus for the CISP was a response to increasing chargebacks that were the result of the fraudulent use of credit card accounts.  An analysis of these chargebacks had started to paint a picture of merchant employees that were increasingly using their access to point of sale (POS) and accounting systems to obtain credit card numbers and then using those numbers to commit fraud.

As development on the CISP progressed, Visa USA also started to see increasing instances where an e-Commerce site had been compromised and the credit card information stored on the site had been taken by an attacker and then was fraudulently used.  The reason these compromises had resulted in cardholder data being exposed was that application developers had used the same software design models for e-Commerce as those that were used by traditional POS.  This resulted in cardholder data being stored in databases that faced the Internet.

A year or so after the start of Visa USA’s efforts, MasterCard International began development of the Site Data Protection (SDP) standard.  Unlike the CISP, the SDP focused specifically on the security of e-Commerce sites.  MasterCard had monitored the rising fraud rate related to the compromising of e-Commerce sites.  Like Visa USA’s analysis, MasterCard’s analysis of the problem pointed to the fact that most e-Commerce sites were storing cardholder data in databases that faced the Internet and were not very well protected from compromise.  As a result, MasterCard approached the problem with the SDP which specified a basic level of information and network security for e-Commerce Web sites.

As work progressed on the CISP and further statistics on security issues were gathered, Visa USA began to recognize that the on-line payment applications themselves were the biggest problem related to the compromising of cardholder data.  As a result, Visa USA developed the Payment Application Best Practices (PABP) standard.  The PABP was published in late 2004 with Visa USA encouraging software vendors to use it as a benchmark for securing their software.

It has been suggested that the PCI standards were only developed to minimize the losses to the card brands and banks and do nothing for merchants.  However, the PCI standards were meant to protect everyone in the transaction process.  When a breach occurs, the first thing people remember is the name of the card brand(s) involved, the second name is likely the merchant or service provider and the third name is the franchisee if that is the case.  The card brands, service providers and franchisers discovered that their reputations were highly at risk, even though it was typically the franchisee merchant that actually created the problem.  Regardless of who caused the breach, the card brands further discovered that what people really remembered from breaches were the card brands’ names and everything else was forgotten.  As a result, the card brands became determined to protect their brand names and reputations.

There was another recent suggestion that the PCI DSS was not needed because market forces would resolve the security issues inherent in the conducting of credit card transactions.  The first problem with that idea is that most merchants and service providers are unconvinced that they are responsible for securing cardholder data, even after they might have suffered a breach.  They believe that it is the card brands’ problem to secure cardholder data because the card brands are the ones that generate the cards.  Unfortunately, the security of cardholder data is mostly outside of the control of the card brands, therefore the merchants and service providers need to be responsible for securing cardholder data as well.  The second problem with that idea is that for every security “expert”, there are a corresponding number of security baselines.  No one agrees on security, because everyone’s view is from their own perspective and the threats that they see or perceive.  As a result, some organizations have very strong and strict security (e.g., banks for example), while others have only marginal security.  The problem with this approach is that security is only as good as the weakest link in the chain.  So those organizations that have weak security practices become targets against the entire process chain.  As a result, in our interconnected world, that puts those organizations with strong security at risk if they are partners to those organizations that have weak security.  As a result, the card brands recognized that a single standard baseline was needed just to provide a basis for a consistent foundation on which to build additional security.

So, that is how we got where we are today.  Hopefully with this perspective you can now understand why the standards exist and their use in providing basic, essential security for cardholder data.




July 2010
M T W T F S S
 1234
567891011
12131415161718
19202122232425
262728293031  

Months