1

If a system applied to the following three practice/technologies to each e-mail, would it rate as PCI compliant?

  1. The email itself is encrypted
  2. Encryption is applied end-to-end in the transport layer
  3. The recipients were authenticated.
  4. The encryption key was sent separate from the email itself
Anthony
  • 1,736
  • 1
  • 12
  • 22
Dan Aronson
  • 11
  • 2
  • Send them the public key, they encrypt and send, you decrypt with the private key. Don't send the key that will decrypt it. – Fiasco Labs May 28 '16 at 06:19
  • SMTP transport-layer encryption cannot be end-to-end with current standards and common practice. Your MUA would need to connect directly to the recipient's MX to have any chance of end-to-end transport-layer encryption, and even then it's a far cry from guaranteed because you have no idea what the MTA running on the MX does with the message before the message is delivered to the final MDA, and what the MDA does with the message afterwards. Add to that the fact that many MXes reject direct mail delivery from consumer netblocks, and many more MXes implement greylisting. – user Jun 26 '16 at 16:30

1 Answers1

1

To make anything PCI-DSS compliant you'll have to go further than just defining some tech specs and leave it at that. PCI-DSS wants you to OPERATE a secure environment, not just design it.

So let's break it down.

  • You want to regularly send e-mails containing one or more PANs to one or more authenticated parties.
  • You've thought up a method of sending these emails over an encrypted transport and you'll encrypt the specific e-mails too.

To make this work you'll probably have to do the following, next to all the PCI-DSS related things you're already doing:

  • Check and/or update your Security Policy to allow PANs to be transported out of the CDE this way, with requirements for the exact method.
  • Determine who you are sending these e-mails to
    • For employees of the same entity, you're going to have to include their machines in the PCI-DSS scope (config standards, proper network config, disk encryption, vuln scans, the works) and train these employees on proper usage of the system according to PCI-DSS standards. Since your email server will store these emails it may come in to scope, too; discuss with QSA/consultant.
    • If the recipients are suppliers of some sort, make sure your contract with them states that they need to be either PCI-DSS compliant (if they participate in CC processing somehow) and/or need to sufficiently protect the data you are sending them. If they need to be PCI-DSS compliant, collect their AOC annually.
    • If the recipients are customers/merchants, your acquirer is probably going to want you to manage their PCI-DSS status too. Collect AOC or SAQ annually.
    • In both cases, you probably want to agree on some sort of retention period.

  • Design and implement processes to manage (rotate after a period,revoke in case of compromise,generally replace) the encryption keys used to send these e-mails, probably also those of the recipients (if you use PGP). See chapter 3 of PCI-DSS:

    • A way to authenticate/verify/enroll/unenroll recipients and the keys used for them
    • Have a secure way of dealing with the encryption keys within your application (private key needs to be encrypted, encryption passphrase can't be stored on the same server: will probably need split control to work with)
    • A process to assess if the used technology is still valid and a way to move forward when it's considered insufficient

  • Design and implement the actual product according to the change process:

    • Make sure you don't store unencrypted versions of the email in tempfiles or logs
    • Having a way of knowing what you sent where may help in case of issues
    • Have the system properly tested (also for security issues)

  • Have a (incident) process in place to deal with rogue/compromised recipients, compromised keys, etc.

It may be worth the effort to try and come up with a different solution that makes things easier for you. Why send PANs out if you can have people come to your system? That may be easier to deal with.

NSSec
  • 459
  • 2
  • 5