More On PCI DSS 2.0

Just attended the PCI SSC’s Webcast with Bob Russo describing the coming changes to the PCI DSS.  For those of you that missed it, there is a re-broadcast of it on Thursday, August 26, if you want to hear things straight from the horse’s mouth, so to speak.  Just go to the PCI SSC’s Web site and register under Education, Webinars and you will see the link to register.

The first piece of trivia was in regards to calling the standards 2.0 versus 1.3.  Mr. Russo explained that the 2.0 designation was to acknowledge that they were moving from a two year to a three year standard lifecycle for the PCI DSS and PA-DSS.  Later on in the presentation, he explained that any additional clarifications or enhancements within the lifecycle would be numbered 2.1, 2.2, etc., indicating that we can expect tweaks to the standards throughout the three years.

The biggest news out of this presentation is that requirement 6.5 will now apply to all in-scope applications, not just Internet-facing or browser-based applications.  Based on all of the breach research that has been conducted, they have finally realized that any application in the cardholder data environment (CDE) is a potential hazard, not just those on the big, bad Internet.  However, this is likely to cause problems for all of those legacy systems on HP (DEC) VAX, IBM iSeries and zSeries as well as other “antique” platforms.  It is hard to apply a lot of the OWASP/CWE/CERT/etc. secure coding standards to applications that are not written in Java, PHP, .NET and the like.  Some of these standards will apply, but the majority will not.  Since a lot of QSAs have almost zero experience with these sorts of old platforms, it will be interesting to see if merchants and service providers start complaining more about their QSAs lack of experience.  This change will have a major impact on organizations that are running custom software that does not face the Internet and were getting a pass in prior years on requirement 6.5 because of that fact.

Another interesting tidbit is that there will be more guidance forthcoming on issuers and the pass they are being given on meeting requirement 3.2.  As you may recall, issuers are required to retain chip/track data and other sensitive information which violates requirement 3.2 although one could argue it is pre-authorization data.  In prior QSA training sessions we had been instructed to handle issuers with care because of this and to essentially state that requirement 3.2 was ‘not applicable’ because the organization being assessed was an issuer.   We were not given an actual date that this guidance will be issued, just that it is coming in the future.  I will be anxious to see the additional guidance when it is issued.

The pre-release of PCI DSS 2.0 and PA-DSS 2.0 will happen sometime in early September, before the first Community Meeting in Orlando.  However, the pre-release will only be to Participating Organizations, so not even QSAs will see the standard until likely the Community Meeting and possibly not until their release on October 28.  He recommitted to the standards being released on October 28 and the effective date of January 1, 2011.  The other piece of interesting news is that the old standards will be sunset later on in 2011 meaning that there will be a cut off for the previous PCI DSS and PA-DSS standards.

I am sure we will hear more about this in the coming weeks.

Advertisement

Twelve Character Long Passwords

This past week researchers from Georgia Tech released a paper saying that the days of eight character long passwords is over and that twelve character long passwords had arrived. The researchers based their efforts on the use of the latest graphics cards that have the computing power of a supercomputer, have software development kits and can be programmed in C.  However, the telling quote about their research came from the CNN Web site which stated, “The researchers used clusters of graphics cards to crack eight-character passwords in less than two hours.”

The first thing I thought of was, “What kind of system administrator lets a brute force attack on a single account run for two hours?”  The answer was no one, not even stupid ones allow that to happen.  As a result, this seemed to be a lot of “Chicken Little” reporting if you think only about a brute force attack in the traditional sense.

But the more I thought about it I did come up with potential uses for their work.  Wireless technologies are a method of communication where a hacker could obtain passwords without setting off alarms.  So, there is a potential threat, but not as great as the news reports are making you believe.

Then there is the portability, or lack thereof, of a system packed with a bunch of graphics cards.  Yes, we will find a way to shrink it in time, but for now, it’s not a possibility.  So even while the wireless scenario is a threat, without the portability, it too is relatively minor.

This is the problem with security research.  You really have to read the research paper to understand if the threat could actually be used outside of the laboratory.  In the case of this threat, most system administrators have put the following controls in place to stop such attacks.

• Accounts lock after three to five invalid logon attempts.  No running a brute force attack against accounts for two hours straight when you only get three to five logon attempts.
• Once locked accounts can only be unlocked by contacting the help desk.  So you lock the account, you just call the help desk right?  Think the help desk will wonder why you are constantly asking for a reset?  Eventually, you will not be able to convince the help desk to reset the account.
• The help desk requires users to uniquely identify themselves by answering a question that only the user would know the answer.  Now you will have to do research into the user to determine their children’s’ names, birthdates, pets’ names, etc.  That of course implies that you got past bullet number two.

The bottom line is that this is why security standards such as the PCI standards are built in layers.  As researchers discover new threats, there are other controls in place to prevent the failure of the control now in question.

However, where security people frequently mess up is in connecting the dots between the current threat and threats exposed months or years ago that were written off because they were believed to be blue sky thinking.  I have seen examples where, in combination, the current threat plus older threats could be used to compromise security.  It was just all in how the threats were put together and the order they were executed.

This is why I think it is very important that security professionals need to understand their opponent and think like the opponent.  If you cannot understand how to put together an attack, it is very difficult to defend against it.  The best security professionals I have ever worked with thought like their adversaries.  They were always trying to see things through their opponent’s eyes and think of ways to circumvent controls.  It was through this sort of analyses that these top security people were able to create almost impenetrable defenses.  I say almost, because even these super security pros understand that security is not perfect.

The Chip And PIN Debate – Part 4

This is my last post on EMV which I am sure will please a number of people.  Although I know this debate will only continue.  There are a lot of people out there that have taken large swigs of the Kool Aid and blindly believe that EMV is nothing but good and perfect with no bad side.

After all of these posts bashing EMV you probably believe that I despise EMV, but I do not.  What I despise is that EMV is portrayed as the savior and it is not.  This is no different than how the card brands portray the PCI DSS as “the be all to end all” of security standards which it is not.  Just like the PCI DSS will never eliminate all breaches, EMV will never eliminate all fraud.  However, in both cases, they will reduce their number of respective incidents that occur to a more manageable and acceptable level.

In part 2 I pointed out that from a card present fraud perspective; EMV really brings no incentive to change.  In part 3 I pointed out that EMV has security issues, so it is not a perfect solution.  So what can be done to give EMV a feature or attribute that would improve its adoption through the rest of the world?

I stated in my original post that EMV can be used to also secure on-line transactions, but are not used to secure on-line transactions because the banks, card brands and Web developers could never agree on a standard for such functionality.  Not that the banks, card brands and Web developers really tried to come together and create a standard.  However, without such a standard, it is impossible for Web sites to cost effectively implement their end of the EMV on-line security solution.

Card not present fraud is out of control.  It is growing at 25% to 30% annually around the world, even in those places that have EMV.  No one seems to be doing much about it.  However, EMV could provide a solution to a tremendous reduction in card not present fraud if such an on-line security standard were developed.  The beauty of this solution is that the hardware and software already exist for the most part on the client end.  What is missing is the standard between the client and the Web site that would create an authentication between the card and the Web site that would be nearly impossible to replicate.

The bottom line is that EMV could be used to take a lot of the risk and threat out of on-line transactions with little effort.  So let us lobby the banks, card brands and e-Commerce vendors to come together and create something good of EMV.

The Chip And PIN Debate – Part 3

In my last post I discussed the statistics surrounding the adoption of Chip and PIN.  In this post I want to go back and discuss the issues from my old post regarding security risks regarding Chip and PIN.

In my original post I discussed a number of shortcomings regarding EMV.  A lot of those issues were taken from old sources as well as some that were questionable.  I apologize for the misleading information in some cases.  However, the reason I included a number of these old issues was that they still can be an issue to the EMV card as not every financial institution has necessarily converted their entire card base to newer EMV standards.  I know this to be true because one of my clients manufactures EMV cards and they continue to produce cards to older standards.

EMV, like any other security method, is not perfect.  So what are the viable issues?  Here is my take on the security issues for EMV.

Man-In-The-Middle Attack
At the IEEE conference in February 2010 a number of researchers from the University of Cambridge presented a paper on a man-in-the-middle attack where they used somewhat expensive equipment to build hardware and software that essentially intercepted the communications between the EMV card and the terminal to fool both into believing that a transaction has been properly completed.  After this paper was presented there was a flurry of newspaper articles about the problem hyping it as the reason why EMV is a “false prophet.”  A few days later, a number of articles came out dismissing the research as bunk because of the expense and complexity of the equipment.

However, the flaw that these researchers found is more exploitable than most people think.  Terminals are more sophisticated that most people give them credit.  Today’s terminals are not the “dumb” devices of yesteryear.  Today’s terminals are like netbooks in disguise and run embedded Linux or Windows.  Vendors provide software development kits with these new generation terminals for the development of sophisticated solutions for processing credit cards, giving loyalty rewards and other merchant friendly purposes.  And after four years, it appears that the PCI SSC has recognized the threat from these new terminals and is modifying the PA-DSS to include them in the certification process.

I have personally been involved with a client that had their terminals tampered with by a gang to store cardholder data on USB drives embedded in the terminals.  These terminals were swapped for legitimate terminals by gang members posing as the night cleaning or the stock crew.  Then there is the Hannaford breach.  While we know that it was malware installed on the POS servers at each store, there has never been an official explanation given as to how the malware got on those servers.  Most people just assumed that the hackers somehow compromised Hannaford’s network and placed it on all of their servers.  But the rumor I heard was that the Hannaford breach was the result of tampering with their master ghost image for their POS server.  Hannaford had updated their POS hardware and software as part of their PCI remediation efforts (how is that for a real piece of irony) and had hired a third party to provide the additional resources necessary to ghost the new servers.

The bottom line is that there is ample evidence that data gathering at the source is a real threat.  Given the sophistication of terminals these days and the likelihood that they and POS software can readily be tampered with, the ability for a successful man-in-the-middle attack is higher than most people believe or want to believe.  As a result, it is not too farfetched that tampered with terminals or POS software could be created and distributed to unsuspecting merchants by unwitting or unscrupulous vendors and/or resellers.

Card Cloning
In May 2010, Lloyds-TSB admitted that a number of their customers had been the victims of card cloning.  Apparently, this is not your run-of-the-mill amateur cloning operation, as these cloners are cloning everything and determining the cards’ PIN.

It is not difficult to skim the magnetic stripe on an EMV card as most of them have a stripe so that they can be used in non-EMV situations.  Now a lot of you are probably wondering how the bad guys got the cards’ PINs.  It is just a simple use of a rainbow table to break the encrypted PIN block.  The problem with the current PIN block encryption specification is that it is published.  And though you might think that PIN encryption would be tough to beat, banks usually only change their private keys annually so if you have a card from a target bank, you can figure out the private key by using the information from a known card.  As a result, it is not difficult to generate the necessary rainbow table(s) to quickly crack PIN blocks.

Once cloned, the cards are used at ATMs around the world to obtain the victims cash.  Why ATMs?  Turns out that almost all ATMs, even those in Europe, still rely on a card’s magnetic stripe to conduct withdrawals not the chip.  To add insult to injury, it turns out that Lloyds-TSB’s and most other banks’ fraud detection systems ignore ATM withdrawals.  And because ATM transactions from foreign ATMs took anywhere from a week to a month to show up on customers’ statements, it usually was quite a while before the customer contacted the bank to dispute the transactions.

So until EMV is the configuration all over the world, the magnetic stripe is the weak link in the chain.

Card Theft

This is still a problem even with EMV.  The bad guys have taken a tip from the long distance telephone scammers of the late 1980s playbook.  It was that brief time before today’s truly portable cell phones and people relied on long distance calling cards.  I can personally remember at Newark Airport, the terminal had scammers shoulder surfing people as they made calls writing down the calling card numbers as they keyed them into the phones.

What today’s EMV scammer does is electronically shoulder surf at ATMs and merchants and then lifts the victims’ wallet or purse.  They then quickly conduct as many fraudulent transactions as possible before the victim can notify their bank of the stolen card.

Granted, this is not a great way to make a living, but properly done, one can make a living.  With the new PCI PTS standard, even electronic shoulder surfing the PIN should be more difficult, but not necessarily impossible.  And with the prevalence of video monitoring everywhere these days, the chance of obtaining footage containing recordings of people entering their PINs is even greater.  So your new targets of hackers may be the DVRs that contain that footage.

Reverse Engineering Attack

This attack is a prime example of why some things should never be published on the Internet for everyone to see.

This is an attack that is developed by a person using their own credit cards as testing devices.  Even in today’s economy, banks issue credit cards to almost anyone that applies as long as their credit score is good.  Therefore it is not impossible to believe that someone would use their existing credit cards to reverse engineer keys.

First and foremost, all of the documentation is available on-line for anyone to see so the attacker has a readily available instruction manual for reverse engineering the standards.  All of the hardware and software development kits are readily available and in some cases can be obtained for little or no cost from vendors or through eBay.  If you think this is farfetched, remember that at this year’s Black Hat a guy explained how he learned to hack ATMs by buying them through eBay and other sources.  As I discussed earlier, what makes these attacks possible is that the private keys the banks use in their encryption do not change very often.  At most they change once per year, possibly even less than that.  As a result, anyone that desires can use off-the-shelf software to monitor the network and capture the traffic when the card authenticates.  From that traffic, the private key can be determined and then any card from a particular bank can then be easily cloned.

I am sure there are other attack vectors waiting to be discovered by some ingenious attacker.  I only wish I had the free time to look into this topic further, but that is for the attackers who have such free time.  But this is not to say that EMV would not bring something to the security table.  However, the bottom line is that there are risks with EMV and it is not the panacea that its proponents like to portray.  It has known and unknown flaws just like any other piece of technology.  So, let us all admit that fact and move forward.

UPDATE:  Here are some more links to other information regarding issues with Chip and PIN and explanations of the above threats.

http://blog.itsecurityexpert.co.uk/2010/02/chip-pin-weakness-smoke-screen-for-real.html

http://blogs.techrepublic.com.com/security/?p=3153

The Chip And PIN Debate – Part 2

In this post I would like to discuss from a statistical perspective why EMV is not making the impact on fraud that people are led to believe.  The following is the analysis I went through to prove this hypothesis.

So, let us compare a year of card present fraud in the UK to that in the US.  Unfortunately, I could only get statistics for 2008 for such a comparison.  However, for 2009, card present fraud amounted to around 16% of all fraud and that is 0.43% of the total charged on credit cards in the UK.  For comparison, the best I could come up with was 2008 for the US from the American Bankers Association which indicated that there was $788 million dollars in card present fraud which amounted to 1.6% of the total amount charged.

According to the UK Cards Association, in 2005 the last year before the rollout of EMV, card present fraud amounted to just over 30% of the total fraud incurred from credit cards.  I could not find the total amount charged in the UK that year, so I have no idea of how that amount of fraud related to the total charged.  However, given that card present fraud has remained steady at 16% of total fraud under EMV, I would assume that was the same with non-EMV cards so I would estimate that card present fraud amounted to around 0.86% of total fraud in 2005.

So a 1% card present fraud rate drove UK bankers to invent EMV?  At the time UK bankers began to discuss EMV back in the early 1990s, it was my understanding that card present fraud rates were at least double or even triple those in the US, which would put the total percentage of card present fraud at somewhere around 3% to 4.5% of total charges since card present fraud rates are relatively stable.  Unfortunately, I do not have access to figures to support that.  However, using just double that would mean that at 30% of all fraud in 2005, something must have been done to bring down the fraud rate before EMV was introduced.  I base this on the fact that card present fraud has remained static after the introduction of EMV which would mean that in 2005, card present fraud was around 0.86% of total charges.  Could it be that enforcing better procedures at the merchant level which is what the banks mandated before EMV was introduced drove down card present fraud to around 1% of the total charged?  It does appear that way.

EMV will save US banks and merchants a total of around $394 million dollars annually.  Given the estimated ten billion it will cost to convert totally to EMV, is it any wonder why banks and merchants have no incentive to convert?  The ROI is just not there.

So what are the conclusions we can draw from this exercise?  Introducing EMV into the US would cut card present fraud by 50%.  However, since bankers and merchants believe card present fraud is already at a manageable level, there is no incentive to convert.  But the more telling conclusion is that EMV does not eliminate card present fraud like it is perceived by the public.  And that is something that the public deserves to know.

UPDATE: See this post from the FDR Atlanta.

http://portalsandrails.frbatlanta.org/2010/07/can-chip-and-pin-technology-address-payment-card-fraud-in-us.html

The Chip And PIN Debate – Part 1

Based on the comments posted to my blog lately, my Chip and PIN post has really hit a nerve.  As a result, I thought I should go back and re-examine that post as well as provide some additional information and analysis based on the comments left here.

First, I want to clarify that the PCI DSS and the rest of the PCI standards have nothing to do with the type of credit cards used by customers.  Yes, the PCI PTS indirectly deals with the card because it is all about terminals that read the card, but the PTS does not issue standards regarding the card itself.  So, whether we are talking about a traditional credit card with a magnetic stripe or the latest version of EMV (aka Chip and PIN), the PCI standards do not care.  And I challenge anyone to show me any PCI requirement that specifies anything regarding the security of the physical credit card.  Such a requirement does not exist and that, in and of itself, should be very telling.  The PCI standards do not discuss the type of credit card because, at the end of the day, the credit card is not the problem the PCI is meant to address; it is the data contained on those credit cards that get processed, stored or transmitted through applications and networks that the PCI standards are concerned.

Next, I want to reiterate that EMV was developed to address an immediate problem that was occurring in Europe in the late 1980s and early 1990s.  You see, EMV pre-dates the Internet, in fact, the original standard, v3.2, was issued just as the Internet was getting off the ground.  The problem EMV was developed to address was high rates of fraud with card present transactions.  This was just after the fall of the Iron Curtain and face-to-face transaction fraud was rampant by bankers’ standards.  However, let us be clear, it is not that EMV cannot be used to address issues with on-line transactions, but that is not what EMV was originally intended to address.

Has EMV been successful in addressing the original problem of card present fraud?  No doubt.  Europe’s card present fraud rates have dramatically dropped.  However, why has the discussion about bringing EMV to the masses of the world stalled?  It is because there is no driver for the banks to incur the costs related to such a conversion.  Why?  It all comes down to numbers.  According to The Nilson Report released in July 2010, while card fraud grew 7% in 2009, losses related to fraud as measured against total amounts charged actually dropped 0.1% to 4.7%.  And if you think bankers are interested in making changes when their approval ratings are sitting around that of used car salesmen, think again.

As I stated earlier, the only way banks can do such a conversion is to absorb the cost of the conversion, and that just is not going to happen at this time.  In addition, even with Wal*Mart’s chest thumping about EMV, the cost of converting all of the terminals in their stores to support true EMV is mind boggling.  But you say, “When Wal*Mart made their announcement they said their POS was EMV enabled.”  Sure, Wal*Mart’s POS is EMV enabled because all EMV cards come with the requisite magnetic stripe to be compatible with non-EMV terminals and their POS already supports PIN entry, so they are good to go.  What people did not hear from Wal*Mart is that they would still take about 5 to 8 years to convert all of their terminals to pure EMV starting with their major metropolitan stores and then throughout the remainder.  “And that,” as Paul Harvey used to say, “is the rest of the story.”

What I think confuses people is that the dollar amounts we are discussing are huge, some would argue obscenely huge.  In the immortal words of US Senator Everett Dirksen, “A billion here, a billion there, and pretty soon you’re talking about real money.”  And that is exactly what is going on with the dollar amounts behind these percentages.  The total amount of charges made in 2009 totaled a staggering $16.6 trillion US dollars.  Yes, that is trillion with its 12 trailing zeroes.  Fraud for all of 2009 amounted to $7 billion dollars which is a pittance when compared to the total.  Yes, these are all very, very large amounts of money.  But in an analysis, the size of numbers does not matter; it is all about the relationships between those numbers.

When a banker looks at the fraud losses, they see two numbers; the monetary loss and the percentage that loss represents.  At 4.7%, fraud losses are considered manageable and can be appropriately compensated for by interchange and exchange fees as well as chargeback fees.  That may be a cold way of looking at things, but that is how business is done.

PCI DSS and PA-DSS 2.0 Are Here – Almost

Well the long wait is beginning to end as the PCI SSC let us see some more information on the new PCI DSS and PA-DSS.  On August 12, the PCI SSC drew back the curtain on PCI DSS 2.0 and PA-DSS 2.0 by issuing a Summary of Changes document.

My first surprise was that there is a new version of the PA-DSS being released with the PCI DSS.  I knew that the PA-DSS was also being worked on, but I did not think that it would be released with the new version of the PCI DSS.

Even though the two standards are only changing in a minor or, in the words of PCI SSC General Manager Bob Russo, an “evolutionary way,” the PCI SSC is versioning the standards as 2.0, not 1.3.  For those of us in the software business, that would seem to indicate a major revision, not something minor.  So, while we have a glimpse of what is coming and it does appear minor, it still may have some major impact.

According to the PCI SSC’s release, the updated versions of the standards have been designed to provide greater clarity to the requirements, improve flexibility for merchants, help manage risks and threats, and align with changes in best practices.  Unfortunately, the devil is in the details, so until we see the revised requirements, we will not know if the standards have met these objectives.

The changes will be discussed at the upcoming Community Meetings in Orlando and Barcelona.  The updated standards are to be issued in final form on Thursday, October 28, 2010, and are to be in effect on Tuesday, January 11, 2011.

So, what are the changes?  Here is my take on what they are saying regarding the PCI DSS 2.0.

• The Introduction for the PCI DSS is being revised to clarify that requirements 3.3 and 3.4 apply only to the PAN.  The language in the Introduction is also being revised to align the language used with the PTS Secure Reading and Exchange of Data module.
• The PCI DSS Scope of Assessment section is being revised to clarify that all locations and flows of cardholder data needs to be identified and documented to prove that the Report On Compliance has been properly scoped.  For traditional retailers, this will not likely be much of a big deal.  However, for my clients that have a variety of retail and hospitality, it will be interesting to see the impact this may create.
• The PCI DSS Introduction and relevant requirements are being revised to take into account virtualization.  The Introduction will include definitions for virtual components.  Requirement 2.2.1 will be clarified to further define the “one primary function per server” as it relates to virtualization.  Since networks, servers and storage can all be virtualized, it will be interesting to see if they truly clarify this subject or if they just create more confusion.
• In PCI DSS requirement 1, they intend to provide clarification on the DMZ by clarifying secure boundaries between the Internet and the cardholder data environment.  Like virtualization, it will be interesting to see if they truly clarify things or just increase the amount of confusion.  I have posted my thoughts on this topic, so I am also curious to see how close I am to the PCI SSC.
• Requirement 3.2 will finally have a statement that Issuers need to retain Sensitive Authentication Data, aka track data, CAV2/CVC2/CVV2/CID and PIN block.  I know of a couple of instances where issuers were told by uninformed QSAs that they were not allowed to keep this information because the PCI DSS did not allow them to keep it.  This was even though in every QSA training session I have attended the trainers have always been very clear that Issuers are a very special case when it came to requirement 3.2.  However, I suppose since it was not in writing, there were QSAs that could not accept that fact.
• In requirement 3.6, the key management processes will be further clarified to increase flexibility of key changes, retirement/replacement of keys and further define the use of split control and dual knowledge.  It is surprising that this is an issue since QSAs are required to have a relevant security or auditing certification and almost all of the security certifications have requirements that you understand encryption techniques and key management.
• Requirement 6.2 is being adjusted to allow for a risk-based vulnerability assessment process so that those vulnerabilities with the highest ranking are addressed first versus just patching everything within a 30 day time period.  In my book this is just going to give organizations what they think is more wiggle room on patching.  It will also make testing this requirement more difficult for the QSA if they do not know what they are doing.  Most organizations have a horrible patching process and their systems are vulnerable as a result.  This will likely not help things get better.
• Requirement 6.5 is being rewritten.  First, requirement 6.3.1 is being merged into 6.5 to get rid of any redundancies for secure coding of internal and Web-facing applications.  Then 6.5.a is having CWE and CERT being added to the OWASP standard so that QSAs are not just quoting the OWASP standard as the only secure coding standard.
• Finally, requirement 12.3.10 is going to be updated to allow for the justification of copying, moving or storing cardholder data when being accessed remotely.  I can understand why this change is being made because of all of the people that are working from home or other remote locales.  Depending how this requirement is rewritten, this could be a problem for QSAs.  In particular if the PCI DSS allows the storage of cardholder data on remote systems.

I found the changes to the PA-DSS to be the more interesting of those announced.

• The most interesting change in my opinion is the fact that the PA-DSS may now be applicable to hardware terminals.  I have always felt that this was a big hole in the PCI standards.  The fact that card terminals have software and applications, but those applications were not covered by the PA-DSS was just wrong.  Hopefully the PCI SSC and the card brands have agreed with my position.
• Requirement 4.4 of the PA-DSS will be aligned with requirement 10.5.3 of the PCI DSS so that applications are required to facilitate centralized logging.  One of the biggest problems with logging is that applications typically do not do enough of it.  Hopefully this change will address that situation.
• Requirements 10 and 11 will be merged to reduce redundancies.  Since these requirements deal with remote access and remote updating, this should make things a lot clearer and easier to assess.  However, I am fearful that this combination could result in unintended consequences and make things less secure.

Until we all get to see the actual detail behind the changes, all of the consequences are just scientific wild guesses.  So we shall see what it is the PCI SSC delivers in the way of details.

Asia Just Does Not Get PCI

I recently spent two weeks in Asia and I have to say, from a PCI compliance perspective, Asia just does not get it.

I was doing my expense report, going through my receipts and converting them to US dollars and I could not get over the fact that almost every one of the credit card receipts had the full PAN on them along with my name and the expiration date.  As a result, I do not understand why hackers in China and other Asian countries are trying to hack banks and merchants when there is a wealth of credit card data sitting on almost every credit card receipt generated in their own back yard.  Given what I saw while there, I am guessing that paper recycling centers and dumps would provide more credit card numbers than their hacking activities.

Asia is an interesting environment from a credit card perspective.  In most cases there are only one or a very limited number of acquiring banks in a country.  Acquiring banks mandate the use of their terminal.  So, if you wish to accept credit cards for payment, you use your acquiring bank’s supplied terminal.  If you want integrated POS, the acquiring bank either supports only certain POS solutions or they work with you and your POS solution vendor to provide you an interface to their terminal.  So, if you are a merchant in Asia, you are not going to get a lot of options for your credit card terminals and how they operate.

As an example of what it is like in Asia, the client I was working with actually had to fight with their acquiring bank to get them to fix their credit card terminals so that they did not print the full PAN on their receipts.  This client had to repeatedly argue with the bank to get the software in their terminals fixed so that the PAN was masked.  So, with the fix created, implemented and working, one would think that the acquiring bank would have rolled out this change to all their merchants.  Yet you would be wrong.  I saw the same terminals from this acquiring bank throughout my travels and they all printed the full PAN on their receipts.  So much for security.

And it is a large portion of Asia, not just China.  From the experience of my own travels and those of my business compatriots, this problem is in Taiwan, South Korea and Japan.  Only in Singapore did I see receipts with masked PANs most of the time.  There was an occasional receipt with a full PAN, but that was rare and usually with a very small merchant.

In questioning this situation, the rationale given is that credit cards have not penetrated Asian society yet.  While this is very true with China, Vietnam and Thailand, this does not make sense for Taiwan, Japan and South Korea where credit card usage and penetration are very high.  So, the only real reason this can be going on is that fraud due to taking PANs off of receipts is not a problem – yet.  Given the time it would take to fix every terminal in Asia, if I were an acquiring bank, I would be moving quickly to fix this issue before it becomes the major problem it will likely develop into.

Oh, and for the curious, since my company requires us to scan our receipts, I “erased” the PAN to the last four digits in a photo editing application before submitting them with my expense report.