|
Re: [Networker] What's EMC/NetWorker's answer to Symantec's NetBackup encryption on the backup server
2006-12-14 17:16:21
On Dec 13, 2006, at 5:53 PM — 12/13/06, Tim Mooney wrote:
In regard to: [Networker] What's EMC/NetWorker's answer to
Symantec's...:
What's EMC's answer to this?
Symantec puts encryption on the backup server, 12/12/06
Symantec Tuesday announced a new encryption feature for its flagship
NetBackup backup and recovery software that takes the CPU-
intensive load
off of application servers and places the burden onto the backup
server.
Someone in marketing at Symantec probably thinks that's a great idea,
while we all know it's potentially a horrible idea. "Burden", is,
however, a fantastic word choice for their press release, so I commend
them on getting that right.
NetWorker has for years had support for doing encryption over the
wire.
It was extremely weak and almost no one used it. I've even heard EMC
employees describe it as "a joke". My opinion is that it was added
just
so EMC could have it on a checklist and say they had that feature.
Prior to NetWorker 7.3, the only encryption NetWorker did was so
minimal, it was useless. NetWorker 7.3 offers better encryption
support, but we all know that moving to that version is not something
one should rush into just yet.
There are two problems with doing data encryption on the backup server.
First, allowing the data to remain unencrypted at the application
level does nothing to ensure data confidentiality on the applications
server, which is also where the greatest security vulnerability lies,
especially with web based applications.
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.
A better solution for security purposes is to keep the data always
encrypted beginning with the point of collection. Waiting to do batch
encryption would work in some applications, but it still makes the
most sense to encrypt the data at the earliest possible point in the
life of the data. Waiting to encrypt the data at the point of backing
it up is too late in my view.
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.
I am working with the CISO here on an encryption project and I have
successfully gotten that point across.
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
|
|
|
