-----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 <edgar.zap...@sitel.com> 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-----
