>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