The New PCI DSS Version Is Discussed

If you want to know about what’s coming in the next version of the PCI DSS, see this article.

The bottom line is that the new standard will be out in October 2010 and nothing much is changing, just clarifications.  However, this interview with Bob Russo does point out a few interesting tidbits.

The first is that end-to-end encryption sounds great, but needs to be further studied, defined and refined.  In addition, at the end points, the cardholder data must be decrypted, which means your key management procedures need to be bulletproof.  I had put up a series of posts last year right after Heartland discussed using end-to-end encryption.

The second thing I found interesting is his discussion of Chip and PIN.  Yes, Congress found this technology to their liking, but it has its own issues, some of which I discussed in a post a while back.  It’s not a be all to end all, but it does offer some additional features.  However, Mr. Russo neglected the fact that Chip and PIN cards do have magnetic stripes on them to be compatible with the rest of the world.

Finally, there will be more white papers, FAQs and the like written.

In general, not a lot to talk about.  However that can all change between now and then if we see some changes in tactics by the attackers.

Advertisement

Throwing Down The Gauntlet

I am having a bad day and just got done with a call with an acquiring bank and their PCI compliance coordinator.

What got me in a really foul mood was their demanding of my client that they take certain actions to better ensure the security of the acquiring bank’s transactions.  I do not know what it was, but their request just hit me wrong and I went on a rant.  However, after I was done, I started to think about it and said to myself, “Why not?”

My rant to this poor person revolved around why the card brands and acquiring banks do not expend their efforts to fix the credit card fraud problem instead of addressing the symptoms?  For the last ten years, the card brands have developed their various security programs that were merged together to form the various PCI compliance standards.  While these standards address the shortcomings of the existing processing environment, my impression is that the card brands are doing little, if nothing, to actually address the real problems.

How about we force the card brands to develop a truly secure credit card and related secure transaction processing?  Given the technology available today, one would think that with the right people involved, a secure credit card could be readily developed and at the same time, a secure transaction processing environment could be designed that does not allow the storage of cardholder data except at those points where it is required.  And at those points where cardholder data needs to be stored, these points are heavily secured, monitored and fortified against attack and the breaching of data.  Those projects alone would probably go so far as to reduce card fraud and breaches by 90% to 95%.

Yes, I know that such changes would not come quickly, but you might be surprised.  If a new, secure process and card was introduced and it provided the benefits that I think it likely would, a lot of merchants might actually have a reason to get on board and spend the money to fix the real problem.

So, how about it card brands and acquiring banks?  Are you up to the challenge?

Call Center FAQ Significantly Changes

On January 22, 2010 the PCI SSC issued an update to their clarification regarding their FAQ on call centers storing CVV/CVC/CID in their call recordings.  The bottom line is that call centers are no longer allowed to store such cardholder information in recordings that are maintained digitally, regardless of whether they are encrypted.

The new FAQ (#5362) states that:

“It is a violation of PCI DSS requirement 3.2 to store any sensitive authentication data, including card validation codes and values, after authorization even if encrypted.

It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization; as card data can easily be extracted using freely available software.

On an exception basis, storage of CAV2, CVC2, CVV2 or CID codes in an analog format after authorization is allowed; as these recordings cannot be data mined easily. However the physical and logical protections defined in PCI DSS must still be applied to these analog call recording formats.

Audio recording solutions that prevent the storage or facilitate the deletion of CAV2, CVC2, CVV2 or CID codes and other card data are commercially available from a number of vendors. All other recordings containing cardholder data captured by call centers must be protected in accordance with the PCI DSS, including PCI DSS requirement 3.4.”

I am assuming that this change in policy is the result of the PCI SSC determining that, regardless of what we have been told in the latest reports from Verizon Business Services and other sources, there have been breaches of cardholder data that were the result of compromising digital audio recordings.

A big thank you to Emma Jenkins at VeriTape for pointing out this change.

UPDATE:  It appears that the FAQ has been changed again.  It now reads “It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization if that data can be queried; recognizing that multiple tools exist that potentially could query a variety of digital recordings.” adding back the “if that data can be queried” language.  There are plenty of commercial and open source tools that will search audio recordings, so of course this data can be queried.  Not sure of the motive here in this change.

The Great PCI Debate

If you have a chance, download a copy of this podcast.  There are two parts plus a transcript and it is well worth the effort.  I would like to thank Bill Brenner and Martin McKeay for having the foresight to get together a panel of people to discuss this topic.  I would also like to thank the panel for providing probably the best discussion yet of the pros and cons of PCI.

• Jack Daniel, a member of the National Information Security Group (NAISG)
• Ben Rothke, senior security consultant for BT Global Services
• Dr. Anton Chuvakin
• Ward Spangenberg, a Seattle-based security consultant
• Michael Dahn, a PCI QA manager and director for the InfraGard National Members Alliance (INMA)

Based on my interpretation of the podcast, here are the take aways that I got from listening to this great discussion.  Interestingly enough, some of them may sound very familiar.

• Security is not perfect.  There will always be a risk no matter what you do.
• There will always be organizations that just do not get it and never will.
• If controls are not consistently implemented, maintained and monitored, then your security measures will not matter.
• The PCI DSS is common sense not rocket science.
• The PCI standards are not perfect, but they are better than nothing.
• The PCI standards are a bare minimum and you must go beyond them to better ensure security.  However, if you can consistently execute the bare minimum, you are ahead of the curve.
• Most Level 2, 3 and 4 merchants are clueless about security let alone the PCI standards and will likely remain targets.

For reference, I have put in links to those relevant postings that I made on similar topics over the last year.

Two Good Security Articles You Should Not Miss

I ran across these today and thought I would pass them along.

The first article discusses the lessons that can be learned from the Google attack, also known as ‘Aurora’, on Web sites.  What is interesting is that if your organization was complying with the PCI DSS, the attack would have been almost immediately been identified.  At that point, the attack could have been mitigated.  And remember, mitigation can include unplugging your network from the Internet.  Granted, that is a drastic action to take, but this was a drastic attack and would have warranted such an approach.  Most organization’s incident response plans never discuss disconnecting their organization from the Internet.  However, disconnecting your organization from the Internet might be a valid action to take in certain circumstances such as with ‘Aurora’.

The second article discusses the issue of using proprietary encryption algorithms.  It amazes me the number of people that need to reinvent the wheel all in the name of putting their personalization and creativity on a given project.  Encryption is not a place to reinvent the wheel.  So all of you “experts” out there that think you can do better than AES, get over it.  You cannot do better.

If you are not keeping up on security, you really need to keep up.  To ease the pain, get a free RSS Feed reader such as FeedDemon and subscribe to a number security RSS feeds so that you can keep informed on security and threats.

Mobile Computing And PCI

Mobile computing is all the rage in Europe and is becoming quite a thing here in the US.  As a result, we are seeing more and more inquiries regarding PCI compliance and mobile computing.

First, let us make sure we all understand what we are talking about.   Mobile computing is defined as, “Using a computing device while in transit. Mobile computing implies wireless transmission, but wireless transmission does not necessarily imply mobile computing.”

Laptops, netbooks, smartphones and even cell phones are all capable of some form of mobile computing.  You can order laptops and netbooks with cellular modems built into them.  Smartphones run Windows Mobile, iPhone OS, Symbian and Palm webOS that make them essentially very portable computing devices.  And all of these devices have access to the Internet through a browser running a Java virtual machine and other common Web-based computing environments, making them capable of executing a lot of Web-enabled applications.

On the application side, a lot of organizations have mobile computing-enabled their Web sites.  Just pay attention to all of the “m.domain.com” URLs that are advertised on TV and the Internet.  TV stations, airlines and financial institutions are all jumping on the mobile computing bandwagon.  From a PCI compliance perspective, airlines are probably on the leading edge of the credit card transaction generation wave followed by financial institutions.  Over a mobile device, you can pay for a first class upgrade; purchase a premium seat near the front of the plane or in an exit row and pay for your checked luggage.  In the financial institution arena, you can pay bills and check your credit card balance.

Security experts are enthusiastic about mobile computing as they currently believe it is actually safer than doing similar activities on a PC.  But, they couch their enthusiasm with the caveat that this is only for the moment.  Most security experts believe that once mobile computing starts catching on in a big way that the hackers will follow and that will bring mobile computing into the same league as the traditional PC.

One of the biggest problems with mobile computing is the fact that most people do not have firewall, anti-virus or other security software on their mobile device.  This is particularly true for smartphones and cellular phones.  As a result, they are easy targets to compromise or infect.  In addition, the security on their mobile devices is limited if they have even implemented it at all.  A number of European financial institutions have addressed this issue by requiring their mobile banking customers to have such software on their mobile device.  In some cases, the financial institution is providing the software via their mobile Web site which is leading hackers to spoof the financial institution’s Web site to direct the user to load compromised anti-virus or firewall software.

And security gets very tricky in some mobile computing environments.  The trickiest of all is Windows Mobile.  It seems that Windows Mobile has a different version for practically every different smartphone it executes on.  And it is not just from Motorola to Samsung to LG that it is different.  It can be different between a given manufacturer’s models such as the Samsung Saga and Omnia.  As a result, software that runs on the Omnia may not run on the Saga and vice versa.  All of this incompatibility makes development of a standard security solution difficult and time consuming for Windows Mobile.  This is why the iPhone has taken such a lead in applications.  It has one and only one operating environment, making application development very easy and compatibility a given.

On the application side, the issue is with ensuring that a secure communication link is made between the mobile device and the application.  For a browser-based application, this is not a big deal.  Like their PC brethren, mobile devices support TLS.  You also need to keep in mind that most mobile browser-based application can be susceptible to the same attack vectors that PC browser-based applications are susceptible.  So, you need to send your mobile applications through the same code review and security assessment processes as your other browser-based applications.

Another issue with mobile computing is making sure that if the end user looses their mobile device, there is nothing truly lost.  Therefore, if you are saving user credentials or other sensitive information, you must make sure that that information is properly secured and cannot be readily obtained by anyone other than the proper end user.  Given my earlier comment about mobile device security, this can be a bit challenging.  Particularly from the standpoint that most mobile computing users do not want to log on to their mobile device.  And if they do have to log on, they want it as simple and convenient as possible.

SMS-based applications are where things can get interesting.  Just look at the impact SMS donations have had for Haitian earthquake relief.   In three days, the American Red Cross raised over $6M in donations using SMS.  Granted, this example of donations does not directly involve credit cards, but it could.  Numerous SMS-based applications have been and are being developed.  However, SMS is not as simple and secure as one might think.  Depending on how an SMS-based application is implemented, there may be the cellular carrier and other third parties that are in the middle of the communication stream and may therefore be part of the transaction’s PCI compliance requirements.  The only way to know is to get into the application itself and understand how it is architected.

Now do not get the wrong idea.  Mobile computing is not entirely a bad thing.  It is just an unexplored area of computing that needs more work and research before we get crazy with it.  While that will not likely happen, hopefully this article will explain where the risks exist and compensating controls can be put in place to protect the information that ends up being stored or transmitted on these mobile devices.

How Email Ends Up In-Scope And What To Do About It

Let us clarify this issue.  I am not talking about the occasional email that contains cardholder data.  Try as your organization might, a small percentage of customers are going to email their cardholder data to you no matter how often and how strictly you remind them not to do such things.  In the immortal words of the comedian Ron White, “You can’t fix stupid.”  The way to address these customer indiscretions is to immediately print them out and delete them from the email system so that you minimize the chance that they end up on the email system’s backups.  Once done with the print out, shred or redact it.

These occasional customer “brain farts” does not, in my humble opinion, place an organization’s email system in-scope.  If your QSA says that such occasional messages do place it in-scope, I would seriously push back on this issue.  The risk involved along with the randomness of occurrence does not warrant the time and resources to totally eradicate such problems.  However, your management needs to understand the risk this presents and agree to accept that risk.

With that said, there is nothing worse than telling a client that their email system is in-scope for PCI compliance.  Most of the time, they look like a deer caught in a car’s headlights.  They just stare at you like you just slapped them across their face or dumped a bucket of ice cold water on them.  So, just how does this happen?

Interestingly, the primary cause of an email system being in-scope is due to the fact that it is not segmented away from the ecommerce environment that processes, stores or transmits cardholder data.  Some of this is not due to improper implementation.  In a number of instances, this situation occurs because the ecommerce environment requires integrated access to the email system and putting a firewall between the two is not an option.

The second reason email ends up in-scope is that in almost every email system implementation, the email system has been extended to handle other forms of communication.  As a result, the email system becomes the communications hub of an organization.  The most common extension is the integration of a facsimile system.  These integrated facsimile solutions were a God send when they were introduced as they improved efficiency and accuracy in handling facsimile communications.  They allow facsimiles to be received and automatically delivered directly to either an individual’s or a team’s Inbox based on pre-defined rules.  However as any IT person will tell you, these facsimile solutions have ended up being a compliance nightmare when security and privacy requirements like PCI were introduced.

Another application that gets integrated with email is instant messaging (IM).  IM inside an organization is typically just as secure as internal email.  However, users typically want the ability to not only IM their fellow employees, they also want to IM customers and business partners.  It is the use of IM outside of the organization that creates the problem because the security measures available inside are not typically available through Yahoo, AOL and Microsoft.  Not that IM applications cannot be secured; it is just that they usually are not secured outside of an organization.

With all of these potential risks with email, what should an organization do to ensure PCI compliance?

• Do whatever you can to get your email system out of scope.  The last thing you need is to have the email system in-scope.
• Physically or logically segregate your organization’s email system from your cardholder data environment.  If it cannot be segregated, then implement separate email solutions for your cardholder data environment and the rest of your organization.
• If you are using your email system for communicating cardholder data, stop that practice immediately and begin remediating your current email database and the backups of that database.
• If you need to use facsimile for transmission of cardholder data, have those facsimiles delivered to secure devices, not through your integrated facsimile/email system.  Most printer and multi-function device manufacturers produce devices that can provide a secure facsimile delivery capability including encrypted storage of facsimile transmissions.  If you really need the automation capabilities, then implement a separate instance of email and facsimile solutions for this purpose.
• Make sure that everyone in your organization understands the risks that email, instant messaging, facsimile and other forms of communication present to the cardholder data environment.  Train all personnel to never transmit cardholder data via any electronic communications.
• If you are printing out electronic communications that contain cardholder data, make sure that you also have proper destruction or redaction procedures documented and implemented.  Periodically test those destruction and redaction procedures to ensure that they are operating as expected.
• As best you can, restrict IM capability to only internal use.  If IM connectivity is required outside of your organization, implement it securely over an encrypted VPN link or other secure communications channels.