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.
PCI Guru 
Our Legal and Fraud department (we act as eCommerce Merchant) get a few hundreds of emails from the police and courts about potential fraudulent transactions operated with credit cards. The email contains the credit card data in clear and are sent via letter and/or e-mail to the employees in Legal and Fraud department. There is a legal obligation to investigate the mentioned transactions and respond in the same way as contacted (letter and/or email) and archive the correspondence for the 5 + 1 years. Our Legal and Fraud department is a staff of approx.. 10. There is a generic e-mail account set.
To be PCI compliant, we are thinking of ‘segregating’ EMAIL SERVER (or have a new email exchange server) coming to generic e-mail account and ‘segregating’ ACTIVE DIRECTORY (different from corporate workstation and O365 Active Directory (AD).
How can above (segregation) be achieved? New or segregated exchange server? New or segregated AD?
Do we need to additionally have restrictions such as on communication integrations to facsimile, OWA access, forwards, downloads, copy/paste etc?
Are staff allowed to ‘view’ and ‘write down’ the PAN number (say on a piece of paper) to be able to get the corresponding Token (we already have external card tokenisation capability)? So that they can go and search and retrieve details required by police/courts from our repositories/archives using token.
How is such a scenario handled normally?
Most of my clients use a service such as Proofpoint or similar to halt emails that contain PAN or sensitive PII and send the email sender an email explaining the “proper way” of contacting your organization with such information.
That proper way is typically via a secure FTP (SFTP/FTPS) system that then encrypts the the information when it is uploaded. The reason for FTP is that in most instances, a bank is going to potentially upload a spreadsheet of accounts and secure FTP facilitates that transfer.
If you want to continue to use email, the only option is to contract with a third party secure email service that will encrypt the email at rest that then can be retrieved by your fraud group without having the messages enter your your corporate email system.
Hello,
I know this article is over a year old now, but it still appears high on Google. As for your general ideas about why the Email System, Lets say you are saying Exchange is in scope, I personally don’t agree with that. But then I am only going on the current infrastructure I am working on at the minute.
A Call Centre is apart of the CDE. All the users of the Call Centre has access to Exchange. The other departments in the business are not apart of the CDE, but they use the same Email System. My solution for this was to have Call Centre CDE on a dedicated VLAN, then the email and active directory services in another VLAN known as shared services. These shared services have access to the CDE VIA a firewall and on dedicated IP Addresses. The support departments are on a third VLAN, but also have access to Shared Services VLAN. but no direct access to anything in the CDE VLAN. I believe this in return allows the business to use a single Exchange server, but the Exchange Sever is in SCOPE of PCI DSS but not in the CDE. It has to be classed as in scope, as the end points in the CDE have access to this Exchange Service. OWA is enabled, but is disabled for any user account that belongs to the CDE Devices. The same princple is also applied Active Directory, File Servers and Print Servers. They are in-scope of PCI-DSS the management is low as they are not in the CDE.
It would be interesting to know your thoughts about the VLAN segmentation above, as I have higher managers who do not understand PCI and are basically turning a blind eye to every thing I recommend.
A question for another day, would be “Even if servers are out of scope, you should treat them as in Scope”
I look forward to a response.
Thanks/
Your “Shared Services” VLAN is in scope for PCI because they are “Connected To” the cardholder data environment (CDE). But the risk they present to the CDE will vary depending on what they provide. A domain controller probably presents much more risk to the CDE than your Exchange server, but both are still in scope. This is why a lot of organizations use Citrix or similar virtual desktop solutions to minimize scope to services such as email and other corporate applications.
Hi,
I completely agree the Shared Services are in Scope of PCI. That’s why we would put services such as Printm Mail, and Active Directory in that VLAN. Anything the CDE workstations do not need access to, end up in the out of scope VALN. Thus saving the business costs in regards to hardware and software licenses. As a sysadmin, I personally don’t know why you wouldn’t want such business critical systems to be classed out of scope. Being in-scope should help ensure they are maintained correctly ans the in-scope requirements compared to the CDE are not that bad in my opinion.
As for using Citrix, are saying the CDE End Users would have access to a virtual desktop\Application from the CDE device to access email and that makes it out scope? Surely that is not a cost effective method? I guess an example known to me would be. We have an application in the out of scope services VLAN. The CDE end users use remote desktop to access a terminal server to access this application. Are you saying accessing this said application over M$ Remote Desktop would be permitted and ensure the Terminal Server stays out scope of PCI? This is currently a huge debate in our office with it split 50/50.
Thanks for replying as I find this very useful! I am due to take my PCIP soon (Without Business Support) as I am new the PCI world and find it hard to discuss PCI Standards with my colleagues as I believe they have less knowledge than myself. An to put it frankly they want to fight PCI instead of accepting it.
Thanks Again!
Anything directly connected to the CDE is in scope. So your Terminal Services server would be in scope because it would be connected to the call center workstations that are Cat 1 devices. Exchange would be in scope as well if it were directly connected to the call center workstations. Hence the use of Terminal Services or Citrix to act as a buffer.
Hi,
Sorry to say, but I don’t fully understand your last reply, You are saying the use of terminal services or Citrix can be used as a buffer between CDE and other services. So am I correct in saying, that even using Citrix or Terminal Services as buffer, the terminal service and Citrix hosted services are still in scope of PCI? (I believe these services are in-scope)
Your previous statement reads that terminal services and Citrix makes these other services such as email out of scope, or am I reading that incorrectly?
Thanks,
The VDI solution is in scope. The workstation connecting to the VDI may or may not be out of scope depending on how you rank their risk to the CHD or if they are entering CHD (in scope).
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!
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.
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?
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.
If an application ENCRYPTS files with full PAN and send via email using SMTP server, do the SMTP server fall in PCI scope?
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.
What are the actual problems you can have when the email system is in scope?
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.
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?
You are allowed to use the first six digits and/or the last four digits of the PAN to be PCI compliant.
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?
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.
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?
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.