RE: DMZ databases

[Ryan Russell <ryan () securityfocus com>]

On Thu, 30 Mar 2000, Scott, Richard wrote:

>       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!)

When does the data need to be used?  Only when clearing a transaction?  Is
there a requirement for the page to say 'Welcome back Ryan Russell", which
means the webserver needs at least that much?  Do I need to be able to
edit my name, address, etc..?  When editing, do I get to see what I
already had there, in order to update it?  As long as there is a
requirement for the web server to have some of this data in the clear at
some point, then you can't protect it from the web server.  If the web
server, DB server or even client computer get compromised, that data will
be available.  Crypto won't help, because you're talking about compromise
of an "authorized" computer.

>       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.  

You might be able to arrange for permanent storage... with some sort of
key field you hand over for each transaction.  That doesn't actually solve
the problem, it just outsources it.

> 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. 

One concept I've picked up from _Phil and Alex's Guide to Web Publishing_
http://www.photo.net/wtr/thebook/ecommerce.html
Is that it may be possible to use some public/private key crypto if the
web server doesn't eve need the full CC number.  You could have the web
server accept the CC# the first time, use the special public key to crypt
it, and hand it over to the special DB server.  You control the matching
private key.  No one but the private key holder can then do anything with
the card.  Later, when they want to buy something, the PO goes to the
special DB server.  You can control how the special DB server deals with
the crypted stuff.  Maybe it just has the key all the time and can process
at will, or maybe you have to walk up and type the passphrase to unlock
it.  The special DB server can have all the appropriate poison gas and
laser beams, etc...

>       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!

I'm shocked!  Seriously, I didn't mean to imply that they would
neccessarily actually be secure, but rather that one can point blame
elsewhere, which is of real value to some folks.  Perhaps it's actually
true in this case, since they are now the target and make the screw ups,
and not you.  When they get hacked, you get to be incredulous like
everyone else.

>       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 )

I think the vast majority of them just throw all the info into their
database and give it the usual amount of firewalling and hardening, which
is probably insufficient in most cases.  Lots more people understand
network security as compared to those who understand database
security.  (And I make to claims to understand DB security well.)  Since
net security is a much better understood topic, and that gets screwed up
so often, you can imagine the general state of DB security...

                                        Ryan