02
Jan
10

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.
Advertisements

14 Responses to “How Email Ends Up In-Scope And What To Do About It”


  1. 1 ssn
    January 5, 2016 at 6:58 AM

    Dear PCIGuru,

    In case emails are encrypted end-to-end on message level with strong cryptography (i.e. no possibility to decrypt a message on a compromised server sitting in between):

    Would that put the email server infrastructure out-of-scope (even though PANs are transferred in such encrypted emails)?

    We’re wondering if such an approach could allow the usage of email SaaS offerings, such as O365 (which are not PCI-DSS compliant on their own), without putting the whole email infrastructure into scope.

    Of course, this would require an according PKI and ensuring that not encrypted emails must not contain PANs.

    Thanks so much for your support!

    • January 5, 2016 at 7:37 AM

      Where email and other messaging solutions run into trouble is the requirement to use something like PGP/GPG or similar consistently to encrypt the messages with cardholder data (CHD) or other sensitive information. It’s that consistency that is the problem because most senders do not consistently encrypt their messages. But, in theory, if you had that sort of consistency, then the messaging platform could be out of scope.

  2. 3 Neon
    July 2, 2015 at 1:59 AM

    If the credit card numbers in invoice is masked / fully stricken out except the first and last 4 digits, then scanned and sent via email or fax, can we consider the receiver systems(email server & PC) out of PCI scope?

    • July 2, 2015 at 4:39 AM

      If the primary account number (PAN) is masked to the first four and last four characters, it is no longer considered cardholder data (CHD). And according to requirement 3.3 of the PCI DSS, you are actually allowed to display the first six characters of the PAN as well as the last four.

  3. 5 Neon
    April 28, 2015 at 3:04 AM

    If an application ENCRYPTS files with full PAN and send via email using SMTP server, do the SMTP server fall in PCI scope?

    • April 28, 2015 at 4:29 AM

      As long as the SMTP server cannot decrypt the files (i.e., it does not have access to the encryption keys), then the SMTP server is NOT in-scope.

  4. 7 Georges
    April 27, 2015 at 1:34 AM

    What are the actual problems you can have when the email system is in scope?

    • April 27, 2015 at 5:27 AM

      Given the way most email servers are implemented, if the email server is in-scope it puts the organization’s entire network in-scope for PCI compliance. This is because all workstations connect to it as well as these servers are also typically on the same network segment as all other servers. Network segmentation really does little to reduce scope because of the workstation connectivity issues. I’ve seen a lot of organizations go through some bizarre exercises to try and reduce scope, but all it does is over complicate email and make it virtually impossible to manage. As a result, it’s just easier to stop allowing cardholder data (CHD) to end up in email.

  5. 9 Gabe
    March 17, 2015 at 7:52 AM

    We use the email to send a document that contains the first and last four digits of the customers credit card, is this practice PCI compliant?

    • March 17, 2015 at 8:24 AM

      You are allowed to use the first six digits and/or the last four digits of the PAN to be PCI compliant.

  6. March 11, 2015 at 7:33 AM

    This is a dilemma we are facing. Our email server processes and sends order confirmations AND our employees are using OWA. So we have two ways that bring the mail server into scope. We have recently been discussing this with a technical consultant who was going to put OWA in the DMZ. BUT Microsoft does not support this configuration so that is out (unless we use a proxy). I’m interested in your comment to separate the organizational email from the CHD by implementing separate email solutions. Are you suggesting we use SMTP? Or do you have any other advice?

    • March 11, 2015 at 8:08 AM

      Your message was not clear. Are you processing orders from customers via email as an advertised and approved business channel or only sending order confirmations via email.

      If it is order confirmations only, then I would ask why you are including the customer’s full PAN in those confirmations as that violates the PCI DSS? Order confirmations should only ever contain a masked/truncated PAN, never the full PAN as the transaction should be complete at the point of order confirmation. Masked/truncated PANs are not considered cardholder data (CHD), so if your confirmations do contain a masked/truncated PAN, then your Exchange server is not in scope.

      If you are accepting orders and payment information via email as part of your standard business processes, then your only option is to have two servers. One server will be the one in-scope for PCI compliance one that accepts customer orders. The other server will be for your organization’s business email.

      • March 11, 2015 at 8:38 AM

        We do not accept orders via email and we don’t include any credit card data in order confirmations. These are confirmations we send after someone orders online. Otherwise we never use email to transmit any sensitive data. So given that, you’re saying the email server is not in scope?

        I’m confused about how OWA (Outlook Web Access) fits into the equation. Aside from order confirmations, stall use this to access email remotely. This external IP is not in the DMZ and per the requirement (all traffic is limited to IPs in the DMZ) . How does this affect the scope?

      • March 11, 2015 at 9:40 AM

        If the confirmations do not contain cardholder data (CHD), then there is no reason that you email server is in-scope for that reason.

        My guess is that because the email server is on the same network segment as your systems that process, store or transmit CHD is why it is ending up in-scope.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

January 2010
M T W T F S S
« Dec   Feb »
 123
45678910
11121314151617
18192021222324
25262728293031

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,836 other followers


%d bloggers like this: