begin quoting John H. Robinson, IV as of Wed, Oct 04, 2006 at 02:00:16PM -0700:
> Andrew Lentvorski wrote:
> > *Theft* is now a bigger issue.
>
> The person most likely to steal from you works for you. Who are you
> protectng against, again? With your theory, you need to excrypt to
> disk. Which is what I said when I said let the application encrypt.
Actually, the biggest problem seems to be losing or "misplacing" backup
tapes, especially with outsourced "backup services". If I have 50,000
SSNs in my unencrypted database, and my offsite storage service
discovers that it gave my backup tapes to Another Customer by mistake,
*I* get to contact 50,000 people to report a potential disclosure of
sensitive information.
I agree that it's not _theft_ that's the issue. It's _disclosure_.
Losing track of sensitive information is a big deal, and if it isn't,
it damn well ought to be, and we need to crank up the penalties until
it is taken seriously.
> Most don't bother, so this is a real issue.
Bother to back up at all?
It would be better to lose the customer database than to have to tell
those customers that we've disclosed sensitive information about them.
Better to announce that your datacenter was flattened by a Boeing 747
and that there will be a "transition period" as you re-establish your
customer relations -- people will give you a break -- than to tell 'em
that you've revealed Sensitive Information -- which is entirely your
fault.
> > With proper redundancy, a system effectively never goes down. You can
> > lose entire sites if you have a geographical spread.
>
> If you are a Fortune 1000 company, you can do this. If you are a simple
> machne shop in New Orleans (Hi, Katrina!) y7ou may not be able to do
> this. You can contract for DR sites. This works until the DR people are
> flooded with requests for space and machine because of a widespread
> disaster (hi, Katrina!)
If you're a machine shop, your IT infrastructure is not critical.
Disaster Recovery contracts -- IT infrastructure that you can easily
transition to -- need to be managed so as to actually pick up the load
in case of a disaster. Too many contracts in the same geographical
area is a problem of the DR service (over-subscription is greedy, and
should cost them big) and your failure to perform due diligence.
("How many other customers do you have in this area? Lots? Okay, I'll
go elsewhere. Thanks.")
[snip]
> > It's all about risk vs. cost. Running a business nowadays, all backups
> > would be encrypted.
>
> You have a 500 server machine room. You have to restore them all. They
> are all encrypted. GO!
Install the fileserver. Boot remaining machines. DONE!
> Perhaps we are not even talking about the same thing, and if so, I
> appologise. If you did simply mean daily archives, and I am talking
> about disaster recovery, then we are speaking completely different
> languages.
I don't see those as different, in this context. If the data is not
under your control, you need to encrypt it, especially if disclosure
is an issue.
A website backup wouldn't need to be encrypted. An "e-commerce" backup
would be.
> > USB key in an offsite safe deposit box. This really isn't that hard.
>
> Key management is not that easy, either. For a very small small shop, or
> a home user, it is that easy. For a larger company, it gets harder. Who
> can access that safety deposit box? What if that person is not avalable?
> Or that person? What credentials are required?
Who has access to those tapes? What if that person is not available?
What credentials are required to access that information?
> If you want to really learn something, go attend some of the Disaster
> Recovery presentations at a Large Installation System Administration
> (LISA) conference. I was a bg proponent of encrypting backup tapes until
> I actually learned what it really entailed.
Interesting, but it doesn't sound like they addressed what I would
consider the key inputs to the decision to encrypt or not encrypt. Size
of the installation doesn't show anywhere on that decision tree on the
"no encryption" side of the scale.
Large installations imply large user-base, which implies expensive costs
when it comes to notifying people about disclosure. A university can
get away with "Sorry students, we released your information, nothing you
can do about it, suck it up, and now we've fulfilled our legal obligation
by notifying you that we screwed up, hahahahahaahaha!" -- but businesses
can't. Well, not always.
(I'm *peeved* that SDSU has disclosed sensitive information about me
multiple times. But I've graduated... what am I going to do, not give
them money?)
[snip]
> > And where is that key stored?
> >
> > Oh, right, on the unencrypted disk with the application itself. Oops.
>
> You say this as if this is not already a solved problem: five letters:
> HTTPS. We do this already. We manage it already. While Apache does not
> use t to ecrypt data, it does use the certifcate(key) to perform
> identifcation. You don;t store your HTTPS key unencrypted on the disk,
> do you?
...and now you have a key to remember. Who remembers that key? What
happens if they are not available?
Application keys and backup keys are just keys. They're either in
someone's head, or they're stored somewhere.
> > Key management is annoying, but it is not hard. However, it just needs
> > to be explicitly considered rather than being ad hoc. The question is
> > whether the annoyance is worth the gain. For a modern business, I
> > assert that it is.
>
> For a lot of things, I agree with you. For Disaster Recovery (backup)
> tapes, I disagree.
If you don't encrypt 'em, you're not obligated to keep much better track
of them, and of who is allowed access to 'em.
It's all about how much money you want to spend.
--
_ |\_
\|
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
