PCI has nothing to do with keeping the admin from doing bad things, nor does one have to hire any third party to "monitor real-time logs." PCI doesn't dictate "compliant encryption," nor does it dictate how key management is handled. It says what has to be encrypted and under what circumstances, and that key management controls need to be in place, but it does not stipulate any particular process workflow. Logging and auditing need to be in place, but they don't get to say that an admin can't "do things" to the log. I won't get into your position of the card industry finding to something to "blame" on the merchant or other conspiracy theories.
And finally, if your DB was breached by the "foreign company" through some vulnerability, the "video camera in the server room" would have absolutely nothing to do with it. One, because there is no PCI requirement to video tape your server room, and two, unless you expect someone to be sitting in front of a terminal with a neon "I'm Hacking Over Here" sign it wouldn't matter anyway. I don't know what QSAs you have been working with, but if they told you any of that then you need to find a new one (that doesn't think "Geek Squad" references == security professionals). A few things... I've yet to see the reason WHY the emails have to be encrypted, and even if they do, what PCI has to do with it. If they are emailing credit card information around internally, then they would have to be encrypted at rest on the server, on the workstations (where personal folders or OST files would be) and in transit just as if they were being transmitted via HTTP(s) or telnet for that matter. PCI doesn't say "you can't send cc info if you email it unless you encrypt it" but rather "you can't send cc info *any* way unless it is encrypted." Encryption at rest is for offline attacks. Bit locker is fine for complying with encryption at rest requirements, however you would see a performance hit on the server. Someone said "bitlocker the exchange files" but Bitlocker is partition specific, not file specific. EFS *might* work technically, but it would not well, and it is certainly not supported on Exchange. There is no reason to deploy PGP as you can easily deploy a (free) MSFT CA and issue user certificates for S/MIME usage via Exchange (also free). Based on the question and subsequent comments, my guess is that this has nothing to do with an actual PCI environment where cc numbers and other information is being emailed around, but rather someone wanting to put some encryption scheme in place around their emails so that it can be presented as "PCI compliant" for purposes of illustrating some level of security to someone. I could certainly be wrong, but that's my feeling. t -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Eric C. Lukens Sent: Wednesday, January 12, 2011 11:38 AM To: [email protected] Subject: Re: HOW TO encrypt and store mail and PCI DSS Skepticism -----BEGIN PGP SIGNED MESSAGE----- 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 <[email protected]> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0uAwAACgkQN+w4PqsMNp1qTQCfXGjinCHCN8YMafrBNdFR9yCF yowAn1qRW8/HLxYPQO8EJD3rVrUr1YJm =7opS -----END PGP SIGNATURE-----
