Re: HOW TO encrypt and store mail and PCI DSS Skepticism

Hash: SHA1

I'm responding 2 ways, first is the way a person who really wants to
be PCI DSS compliant would answer and secondly as a PCI DSS skeptic.

The problem is that PCI DSS really demands that you do find a way to
keep the admin from doing that. If you can't, then everything the
admin does needs to be monitored and you have to find a way to prevent
the admin from removing their traces. Generally, they recommend this
be done by having another person monitor a central logging solution or
hiring a third-party to monitor real-time logs. Events where logs stop
showing up would have to be investigated as possible abuse by the
admin. Also, without encryption, PCI DSS has a flat-out prohibition on
using email to send CC numbers internally and externally. If email is
the primary means of communication and there is a legitimate need to
communicate credit card numbers internally, then email encryption is
the only way to go. However, it has to be PCI DSS compliant
encryption. That means recovery keys held by multiple people and all
sorts of other difficulties. The full PGP product would meet all the
requirements if implemented properly.

As a PCI DSS skeptic, I'd second the criticism of PCI DSS not really
being able to stop the admin from doing things. But there's two sides
to this story that I've learned from working with several QSAs. PCI
DSS does help merchants protect card-holder data, but that's only half
the reason the card brands came up with PCI DSS. It also pushes all
the risk and responsibilities away from the card brands and towards
the merchants, banks, and payment processors. If a merchant has a data
breach and the card brands want the merchant to take the blame, they
*will* find something wrong since they get to decide what a failure is
and rewrite the "interpretation" rules as they go. A failure to fully
comply with any one requirement will cause you to lose your
"safe-harbor" protections that PCI tells a merchant they get when
they're compliant. For example, if your database was hacked from a
foreign country through a vulnerability in the database software, but
your video camera recording of the sever room were missing a few hours
of recording, they'd find that you had failed. Visa even brags that no
breached merchant was ever found to be in compliance of a post-breach
audit. I honestly don't see how any merchant can expect to survive a
real, post-breach audit from a QSA. That said, I think all merchants
should make an effort to comply with the standard, there's nothing
that wrong with it. Your best bet for PCI DSS is to reduce your risk
by keeping CC numbers for as little time as possible, preferably just
as long as it takes to get the card number to the payment processor
and no longer. Let the payment processor have the risk of storing it.
Then if *you* have a breach, it'll likely be small enough to fly under
their radar unless a sniffer or skimmer sat on your cash register for
a significant amount of time.

- -Eric

Alex wrote:
On 12 January 2011 19:30, Edgar Zapata <edgar.zapata@xxxxxxxxx> wrote:
Thanks Kurt.
I guess that won't do. As far as I know, and based on the tests that
we've been performing, it only provides for a way so in case the disks
are robbed/stolen they won't be readable unless you have a key (stored
in a say removable USB drive).
It won't prevent the system admin from reading the contents of the
mails or even making copies of the .edb and .stm files for later misues.

We're still searching and testing so I'm open to suggestions.

Thank you.

Well if you want it for PCI Full disk encryption is fine. The goal is
not to prevent the sysadmin to read sensitive data. The goal is to
prevent unauthorized people to do so.

If you want to prevent every other user except the ones in each email
conversation to read the data exchanged, then you should use PGP/GPG
or something equivalent. But even then, that won't stop the sysadmin
from accessing the corporate desktops/laptop, retrieve the user's
private key and then use it to decrypt the emails.

You shouldn't try to prevent your sysadmins from accessing sensitive
data, he's in charge of your systems and he has control of them. You
should trust them, separate their duties where possible and, above
all, audit their actions.

My 2 cents.

- --
Eric C. Lukens
IT Security Policy and Risk Assessment Analyst
University of Northern Iowa

Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -