Eek! Is My Email System in PCI Scope!

I once saw a t-shirt that read: You Can't Patch Stupid.

It is tough to argue with the wisdom of that statement or its directness, particularly when it comes to receiving unsolicited emails containing cardholder data.  The real issue, though, is what is a merchant to do when they receive such unsolicited orders or gifts?  Did the sender just put the institution's email system in scope?  Can they process the transaction "just this once?"

I encounter this situation often enough that I developed an approach for my clients, which I'll describe below.  Just recently, the PCI Council addressed this issue in their Assessor's Newsletter.  That perspective, too, we'll explore.  The fact that the Council feels the need to address this issue should at least make readers of this blog feel they are not alone.  

Let's start by defining PCI scope.  You can think of your scope as being in two parts.  The first part is the Cardholder Data Environment (CDE), which includes all the systems, people, and processes that store, process, or transmit cardholder data.  The second part of your PCI scope is any system connected to the CDE.

Most institutions have successfully segmented -- which in PCI-speak means isolated -- their email and administrative systems from the CDE.  However, just when you think you are safe along comes a student, parent, donor, alum, ticket holder, or whoever sending you an email with their card information (and the security code too, just for fun).

Did this kind soul just throw your entire email system into scope?

The answer is: it does not have to.  My advice to clients is that they need to do a few things when this happens.  Here is where annual PCI training comes in to play.  The big thing is that you cannot process the transaction.  If you do, then regardless of any policy you may have, your practice demonstrates that you do indeed use email as a payment channel, so that system is part of your CDE (and every device connected to your email system is in scope...think about that!).

Instead, merchants must purge the email and contact the sender to tell them how they can complete their transaction. If you follow this procedure, you should be able to keep your email system out of scope.  Smart institutions make this part of their annual training to make sure.

Lest you think this is only me talking or that your merchants are the only ones with this problem, read on...

The following is from the June 2012 Assessor Update.  The FAQ of the Month deals with this precise issue:

What should a merchant do if cardholder data is accidentally received via an unintended channel? Merchants sometimes find themselves in a situation where a customer provides their cardholder data unsolicited via an insecure communication channel that was not intended for the purpose of capturing sensitive data.   In this situation, the merchant can choose to either include the channel into the scope of their cardholder data environment (CDE) and secure it according to PCI DSS, or implement measures to prevent the channel from being used for cardholder data. Some suggestions for merchants to prevent any further capture of cardholder data via unsecured methods include: Implementing controls to prevent acceptance of cardholder data via unsecured channels Responding to customers in a manner which does not propagate any further unsecured transmissions of cardholder data Implementing best practices and customer communications to proactively prevent customer use of unsecured channels for cardholder data Cardholder data received via an unintended channel should be either immediately removed or secured according to PCI DSS and incorporated into the merchant's CDE. If a merchant does not wish to bring a communication channel and its supporting systems into the scope of their CDE, controls should be in place to prevent the capture of cardholder data and/or to securely delete cardholder data from this channel before the data can be further stored, processed or transmitted. If unsolicited cardholder data is received via an insecure method, the merchant should take immediate steps to minimize the security impact and prevent further exposure of that data. For example, if a merchant receives cardholder data in an email from a customer, the merchant's personnel should be trained to not 'reply' using the same email that contains the cardholder data.  Instead, the merchant's personnel should respond in a manner that does not further propagate the unsecured transmission of cardholder data.  This may be accomplished by removing all sensitive data from the email response before replying or by contacting the customer via an alternative communication channel to complete the transaction.  Merchants are encouraged to communicate with their customers on the risks of sending cardholder data through insecure channels, and to ensure their customers are aware of the merchant's secure methods for submitting payment information. By proactively encouraging their customers to use only secure payment methods, merchants can reduce the amount of cardholder data received via unsolicited or insecure channels.

There you go.  The best advice directly from the source: delete the data and don't process the transaction.  You may not be able to "patch" your customers, but you can keep them from expanding your PCI scope.

Now, about some of those other t-shirts I've seen...

P2PE Self-Assessment Questionnaire and Program Guide Available

The PCI Council released the latest SAQ for merchants using Point-to-Point Encryption (P2PE).  That SAQ together with the P2PE Program Guide are now on the Council's Documents Library.  You have to spin about half-way down to get to the PCI Point-to-Point Encryption section, but there you'll find both docs and the new AOC.

Before you leap to buy a P2PE solution and complete the SAQ P2PE-HW (no kidding, that's what it is called), make sure you will qualify.  As I forecast (guessed?) this latest SAQ is brief with only 18 questions or control requirements to address.  It focuses on Requirements 9 and 12, but the Council also tossed in parts of Requirement 3 (Protect Cardholder Data) for those who insist on retaining paper forms with PAN data and one part of Requirement 4 so you don't go emailing or texting cleartext PANs.  Actually, as forecast, it is pretty short and sweet.

That SAQ has some pretty strict requirements, though.  Specifically:

• You ONLY process cards using your approved P2PE solution
• You affirm that you are using a solution listed on the Council's website
• You have found and removed any legacy cardholder data from all your systems 
• You implemented the solution per the provider's P2PE Implementation Manual (PIM).

It is that first requirement that may cause some heartburn for merchants who process payments by a number of channels or use different vendors.  My guess is that you will need some decision from your Acquirer on that one.

As everyone knows (or should know), only approved P2PE solutions listed by the Council will count, for this SAQ and for everything.  Right now there are (is?) precisely zero approved solutions.  We can expect to see the first ones later this year and into 2013, so don't go jumping to sign a bunch of contract too soon.

In the meantime, keep monitoring P2PE developments.  This technology has the promise of reducing many merchants' PCI scope and risk (!).  It won't be free, but it could be a good deal in the long run.

P2PE, SIGs, and Other News from the PCI Council

The PCI Council issued their latest Participating Organization newsletter today, June 27.  There is some interesting news here on several fronts that may have an effect on a number of schools.  Here are some of the details.

As most of you know, NACUBO is a Participating Organization in the PCI Security Standards Council.  As one of your representatives, I get a copy of the newsletter and try to share with you -- NACUBO members -- all the latest.  

One of the more interesting pieces of news dealt with the emerging technology, Point to Point Encryption (P2PE).  Tomorrow, June 28, the Council will list both the new P2PE Program Guide and the latest Self-Assessment Questionnaire (SAQ) for P2PE merchants.  I am particularly interested in seeing the SAQ P2PE (or whatever it will be called) to see what it includes.  My guess is that it will focus on requirements 9 (physical security, particularly the POS devices) and 12 (policies).  In fact, there is a good chance that those will be the only requirements.  We'll all see soon.

The P2PE Program Guide will be of great interest to me as a QSA (and part of a P2PE QSA firm!).  This document will list the submission and listing process for P2PE solution providers.  Keep in mind that the only P2PE solutions approved and listed by the PCI Council will count, and only merchants implementing those approved solutions will be able to use SAQ P2PE.  In fact, approved solutions are the only ones you should be considering.

Another important announcement is the opening of the nomination process for 2013 Special Interest Groups (SIGs).  This year, there are  three SIGS -- ecommerce, cloud computing, and risk analysis.  Each SIG is finalizing its report for release later this summer.  Participating Organizations (and QSAs, too!) can nominate topics for a SIG.  My guess is there will be a limit again next year, and I doubt there will be more than three.  If you have any suggestions and your school is a PO, please make them to the Council.  If your school is not a PO, then forward your suggestions either to me (wconway@403labs.com) or my colleague Tom Davis (tdavis@iu.edu), and we'll see if we can toss it in the hopper.

Lastly, the Qualified Integrator and Reseller (QIR) program is getting started.  If you have a payment application that is installed or maintained by a system integrator or reseller, this program is important to you.  Make sure your installer or integrator or reseller is trained by the PCI Council and approved.  This program makes sure you get what you pay for: your PA-DSS application installed properly and according to the vendor's PA-DSS Implementation Guide.  It's your money and your risk, and I personally am a huge fan of this program.  It won't rid the industry of the bad players, but it may help you find the good ones.

Lastly, if you missed the Council's guidance on implementing mobile payments, you can click here to download a copy.