[prev in list] [next in list] [prev in thread] [next in thread] 

List:       focus-ms
Subject:    RE: HOW TO encrypt and store mail and PCI DSS Skepticism
From:       "Thor (Hammer of God)" <thor () hammerofgod ! com>
Date:       2011-01-13 3:42:21
Message-ID: 58DB1B68E62B9F448DF1A276B0886DF16EBD1096 () EX2010 ! hammerofgod ! com
[Download RAW message or body]

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: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com] On Behalf Of \
                Eric C. Lukens
Sent: Wednesday, January 12, 2011 11:38 AM
To: focus-ms@securityfocus.com
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 <edgar.zapata@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-----


[prev in list] [next in list] [prev in thread] [next in thread]