Focus on Microsoft
RE: HOW TO encrypt and store mail Jan 12 2011 05:30PM
Edgar Zapata (edgar zapata sitel com) (5 replies)
Re: HOW TO encrypt and store mail Jan 12 2011 06:27PM
Alex (alex tsr gmail com) (1 replies)
Re: HOW TO encrypt and store mail and PCI DSS Skepticism Jan 12 2011 07:37PM
Eric C. Lukens (eric lukens uni edu) (1 replies)

-----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 (at) sitel (dot) com [email concealed]> 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-----

[ reply ]
RE: HOW TO encrypt and store mail and PCI DSS Skepticism Jan 13 2011 03:42AM
Thor (Hammer of God) (thor hammerofgod com)
RE: HOW TO encrypt and store mail Jan 12 2011 06:00PM
Ahmed Helal (ahelal muzaini com)
Re: HOW TO encrypt and store mail Jan 12 2011 05:52PM
Laurent Barbier (lbarbier arkane-studios com) (1 replies)
RE: HOW TO encrypt and store mail Jan 12 2011 06:44PM
rwagg (at) robhome (dot) com [email concealed] (rwagg robhome com)
Re: HOW TO encrypt and store mail Jan 12 2011 05:49PM
arjunvyavahare yahoo com
RE: HOW TO encrypt and store mail Jan 12 2011 05:38PM
Kurt Dillard (kurtdillard msn com) (3 replies)
RE: HOW TO encrypt and store mail Jan 12 2011 07:23PM
Dave Balogh (Dave Balogh ivans com)
RE: HOW TO encrypt and store mail Jan 12 2011 06:33PM
Staats, Ryan (ryan staats sno wednet edu)
RE: HOW TO encrypt and store mail Jan 12 2011 06:21PM
Chinnery, Paul (PaulC mmcwm com)


 

Privacy Statement
Copyright 2010, SecurityFocus