When we first started with PCI-DSS many years ago, most of our clients were service providers – payment gateways, financial institutions, and two banks. They had their challenges – in some cases, their scope were containable (payment gateways) due to the limitation of locations – and in the bank’s cases, at least they understood the massive headaches they faced in getting their entire environment compliant (with ATMs etc all in scope).
We saw a shift over to service providers OF service providers – hosting companies, Data Centers, BPO, outsourced call centers etc. Their challenges were somewhat different – call centers especially, because of their central hub of connectivity – their telephony system, and another big problem: Email. Email issues in PCI are longstanding and absolutely difficult to resolve – and it reaches to most businesses – travel agencies, hospitality, healthcare, insurance and so on .
When email first came out in the late 60s and early 70s, I can almost imagine how excited the users were. I wasn’t born then. But I recall back in the Uni days, early days when IRC/ICQ first came out, the level of excitement we had in communicating with an actual human being a thousand miles away INSTANTANEOUSLY was so mind numbingly out of this world. Back then, we spend countless hours in the school lab, playing these text based dungeons and dragons online called Multi-User Dungeons or MUDs for short, and completely almost failing all our subjects in the process. But the excitement was there: communication.
In that sense, email is almost half a century old and is still going strong. Primary communications are still through email, for business and personal communications. Email was never built to be secure. In fact, like the wonderfully robust (but now phasing out) SMS, when it was first used, no one imagined it would become the backbone of world communication as it is today. Nobody decided back then: hey, let’s prioritise security! Hey, let’s ensure that nobody can tap into this email of ours and see our messages! Email was like the conversation in the bar. Anyone could be standing around you, or sitting next to you and listening in to your conversation — and it was ok.
Until now, it isn’t.
Well, at least from PCI-DSS perspective.
“Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, SMS, chat, etc.” – Requirement 4.2 (PCI v3.2)
Unfortunately, a lot of business utilises email as the primary channel for PCI information. Hotels we deal with, travel agencies we have worked with – call centers etc – email is sent with card data because of the convenience and the efficiency of the whole process. When we enter these environments and suggest them to look for alternatives to e-mail, we invariably face a force so strong, it’s like hitting the stone wall of Helm’s Deep: Business.
Try as we might, we often end up talking about how we can use email AND pass PCI-DSS.
Now, it’s not impossible. But by the time we are done, we are basically looking at something so extraordinarily difficult or so expensive we invariably end up taking the path of least resistance (and least cost).
But how would you have EMAIL AND PCI-DSS?
First of all, we need to understand that like water, email exist in many forms. Or rather many locations.
First of all, it’s on the endpoints. This is where the email containing card data is sent and received. So, you have data at rest. All endpoints, whether agents or cashiers, or call center workstations are in scope as CDE (card data environment). All endpoints need to have their data encrypted. You could opt for a full disk encryption, folder encryption or simply data encryption: either way, your key needs to be managed appropriately as well. If you allow devices like iPads or phones to access, you are in a world of hurt, because basically it becomes impossible to secure these devices.
The second form is in transmission. Because email isn’t point to point, it hops through multiple relays, and multiple routing points to get to where it needs to be. At any point of the journey, your email could be sniffed, or leaked. Thankfully, many email services like Office 365 is able to encrypt TLS1.2 on transmission. Obviously this helps a lot – but that’s still only on transmission.
The third form is on the interim server(s) – mail servers, relays or anything else in between before the message ends up in the recipient’s mail boxes. Whether you are running your own mailserver or using a separate provider’s, the challenge is the same. How do you ensure that the messages at rest, be it temporary or permanent, are protected?
Pretty Good Privacy (PGP) has been often offered as a solution by kindly QSAs to assist in this matter. The problem with PGP is numerous. One, it’s very old. And more importantly, it’s very difficult to use. To make it easier, some email clients had tried to simplify it, but in doing so may render it vulnerable to attacks (see the recent EFAIL attacks here: https://efail.de/). And what if we don’t send over our public key? Or forget to encrypt the communication? At best, it’s similar to the problem that QSAs have with the manual muting int telephony systems. In theory, it might work (if vulnerabilities are removed, and if users use text-based only encrypted messages), but practically is a different story. Even before the recent researches to PGP’s vulnerabilities, everyone basically knows that PGP doesn’t encrypt meta-data (the information needed to route email) – so subject lines etc are all visible. It may not look like much, but a resourceful hacker will find these information gold.
If PGP is not used – how about some of the recommended secure messaging systems like Signal or Telegram? The problem is that these are not email technologies and these have issues of their own. How do you filter out Signal? If you do receive Signal/Telegram messages on your phone, it brings your devices all in scope. How do you run a PANScan on your phone? How do you secure every phone device there as per PCI requirement?
So how do we use Email for PCI?
The only solution it seems now, is to have a PCI-DSS service provider for Email and to use them. As we don’t represent any service provider, we won’t list them down here, but a simple google search will give you some alternatives. Be aware though, to go through their AoC and ensure that their email service is fully certified. It may be likely as well for the QSA to request more information on the encryption and key management as well, as to whether keys are managed by clients on (likely, such as in the case of cloud services), managed by the provider, or they can provide a client-managed key cloud solution.
That’s only half the solution (if that manages to pass). The second problem you have is to limit the endpoints accessing the PCI compliant service as these are considered CDE. Now remember, everything connecting to the CDE becomes PCI scope. So for the rest of the organisation using email for other purposes or needing email on their phone etc (let’s call this corporate email, vs the secure email for PCI) – the corporate email needs to be segregated from the secure email. This means separate solution. This means separate emails for corporate and secure – in most cases, meaning separate email addresses. While theoretically you can split email through subdomains, the main domain still needs to accept the initial email before forwarding – so for instance if you want to have pcidss@mycompany.com come to your specific secure email provider, unfortunately, it will still hit the MX record (Mail Exchange) of mycompany.com, which means your corporate email gets into scope. It’s an endgame there. Once corporate email is in scope, it’s over. Everything else becomes impossible to be compliant.
So you need to have mycompany2.com for secure email. It doesn’t seem too difficult and it might be possible – but let’s say you have 10,000 agents or clients or service providers in the field – how do you re-educate an entire workforce to get them to resend? Remember, you can’t incrementally ‘migrate’ – i.e continually use the old email and then forward it over to the secure email – you need to completely move over to the new email service and shut down processing card on the old email. This means a lot of lost business, a lot of customer experience issues, a lot of complaints – all adding up to business issues.
After that, isolating receiving end points becomes an issue as well. All endpoints come in scope so depending on your business, this could be a secure room with only a few systems, or a distributed nightmare if you have 200 branches or outlets receiving these emails. This isolated segment is CDE, so anything it touches becomes NON-CDE in scope. Yes. It’s a nightmare. Any shared services will be pulled into non-CDE but in scope. If you want them to also use their corporate email, corporate email comes in scope. All endpoints subjected to full PCI controls. On top of that, most QSAs will likely require additional controls like data loss prevention to be present in the gateway or endpoints if let’s say the CDE systems are hooking on to another potential channel to send email (like the corporate email). Key management also comes in play for the full-disk, folder encryption at rest in the endpoints.
Overall, the massiveness of using email for PCI is difficult. I think the whole point that business wants to use email for PCI data is either the ease of use, or not changing the current way of doing business. Both are not on the cards – even if email is continually being used, the ease of use is no longer there for PCI. Also, the customer experience and frustration could be ten times worse that searching for another solution like secure repository or customer portal, or tokenisation or something. The amount of complaints foreseen in implementing new procedures, new techniques, new solutions etc – these are not just operational security nightmare, it’s a business nightmare. Plus your entire business becomes hinged on the service provider being PCI certified. What if they decided not be? Or they fail their next audit? Or they get acquired by a competitor?
If a business is willing to embark on the complexity of getting email in scope for PCI, a humble suggestion we have would be to look for alternate solutions and have them on the table as well. Because once everything is scrutinised and risk is assessed, then they would have the full picture of what they are dealing with.
For more information on PCI-DSS or any compliance or IT advisory, please drop us an email at avantedge@pkfmalaysia.com.
