Our friendly Decru sales rep tells us their key management platforms
api's are being opened up so that netbackup and other vendors such as
storagetek drives can work with them - so you can envisage a complex
site - with a mix of solutions, but one key management platform...   Now
that's something to ask EMC which way they're heading ( but as per
previous comment regarding netapp owning decru, I have an expectation
that we'll be waiting a long time for something).

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT listserv.temple DOT edu] On
Behalf Of Curtis Preston
Sent: Friday, 15 December 2006 11:12 AM
To: NETWORKER AT listserv.temple DOT edu
Subject: Re: [Networker] What's EMC/NetWorker's answer to Symantec's
NetBackupencryption on the backup server

>There are two problems with doing data encryption on the backup server.

And there are problems with doing it at the app server too.  
Nothing's free. ;)

>First, allowing the data to remain unencrypted at the application level

>does nothing to ensure data confidentiality on the applications server

Agreed

>which is also where the greatest security vulnerability lies, 
>especially with web based applications.

Disagree.  These vulnerabilities are known and addressed.  (It's a
continuing process and you can't assume it's been done, but it could
happen.)

The biggest vulnerability, IMHO, is that you're handing a plain text
backup tape to a complete stranger that could lose it or steal it.
There's no amount of tracking you can put in place to ensure that never
happens.

>Second, if you encrypt your data at the level of the backup device such

>as what Neoscale and DeCru do, you get no protection until the data 
>gets to the encryption device, which is a bad thing for those of us who

>back up data over an untrusted network.

Then use untrusted network backup software, or VPN software.  That's
solving a different problem.  If you fix the lost backup tape problem
with backup software or application encryption, then you cause OTHER
problems, like the loss of all compression on your tape devices (ouch).
It also has HUGE performance ramifications.  If you're cool with that,
then have a blast.
The tape hardware encryption option solves a problem and doesn't hurt
anything other than your pocketbook.

>A better solution for security purposes is to keep the data always 
>encrypted beginning with the point of collection.

Yes, but that has other ramifications.  See above.

>Waiting to encrypt the data at the point of backing it up is too late 
>in my view.

It depends on the problem you're trying to solve.

>There is also the issue of who manages the encryption keys. Do you want

>to manage your organizations encryption keys? I sure don't. The 
>solution I am looking at encrypts data at the beginning of its life 
>cycle and provides tight control over who can access the encryption 
>keys.

Which brings me to another point.  I like what I've seen in key
management with the hardware encryption boxes.  I HATE what I've seen
with everything else.  If you're going to encrypt data at rest, you'd
better have really good key mgmt, and the only one's I've seen with that
SO FAR are these hardware boxes.

So, I AGREE that IF you could encrypt it at the source, and IF you could
manage the keys well, and IF you didn't hurt anything (performance,
compression), then you should do it.  I just haven't found anyway to do
that yet.  But I have found a way to solve this one problem without
hurting anything else.

To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or via RSS at
http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER


NOTICE
This e-mail and any attachments are confidential and may contain copyright 
material of Macquarie Bank or third parties. If you are not the intended 
recipient of this email you should not read, print, re-transmit, store or act 
in reliance on this e-mail or any attachments, and should destroy all copies of 
them. Macquarie Bank does not guarantee the integrity of any emails or any 
attached files. The views or opinions expressed are the author's own and may 
not reflect the views or opinions of Macquarie Bank.

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER