RE: DMZ databases

["Scott, Richard" <Richard.Scott () bestbuy com>]

        > I was wondering what forms of database security anyone out there
is
        > currently recommending for Customer held information in public
databases.
        > One example could be Social Security numbers, another would be
Credit Cards
        > information and so on.
        > I have seen some solutions use the SQL encrypt/decrypting (e/d) of
a stored
        > procedure to access this information.  However, in the even that
the SQL box
        > is compromised internally, this isn't affective.  Using symmetric
        > encryption is the problem.  Where do we store the keys, and if we
write a
        > procedure to e/d the data., surely this could be executed by the
person
        > compromising the Database.
        > 
        <snip>
        Ryan Russell:
        Depends on what you need to do with the data.  If you need the data
in the
        clear, then the app needs to be able to decrypt it, no way around
it.  For
        example, if you're trying to allow customers to make purchases via
credit
        card, and not have to re-enter the card each time, then someone has
to
        store the card number somewhere.  Some places would like that to be
on a
        credit card clearing service's server, on the assumption that they
are
        more careful with that stuff.
        <snip>

        If you only need to verify or look up based on the customer giving
you a
        SSN or CC# each time they come in, ala a password, then you can
store a
        hash of it.

        Actually, I want to be able to store sensitive data that will be
used through out a customer experience say, needless to say credit cards and
such would include that.  My problem is that, given that this data could be
retrieved if the database box were to be compromised, how does one limit the
damage of customer sensitive information (not  just names and address!)

        Just storing the CC's et all in a clearing database for you
billing/fulfillment isn't going to be sufficient in many cases, as this data
once used is scrubbed.  Therefore a separate database will house this
information, for further use to provide a better customer experience.  It's
so often reported that web sites are streaming out CC information from a bad
CGI/perl script, and I believe this type of problem hasn't been addressed.
Ok, fine stick the database in a strong zone protected by firewalls, but one
must consider the inside job too.  I want a mechanism in place that can
secure this information, until, in the event of a break in, the breakees
find the encryption keys. 

        Yes, it's also the case that many Clearing service's server do not
always store this information in a secure form too, believe it or not!

        What are the common practices of holding this type of information?
Are e-commerce sites really depending on solid network security? Or are
people falling in to the false hope of using encrypted stored procedures or
alike, that only are useful until the breakee finds the stored procedure
??(security through obscurity )


        Cheers
        r.


Richard Scott   
BestBuy.Com
* Tel: 001-(612)-995-5432
* Fax: 001-(612)-947-2005
* Best Buy World Headquarters
7075 Flying Cloud Drive
Eden Prairie, MN 55344 USA

The views expressed in this email do not represent Best Buy
or any of its subsidiaries.