Networker

Re: [Networker] What's EMC/NetWorker's answer to Symantec's NetBackupencryption on the backup server

2006-12-14 23:20:35
Subject: Re: [Networker] What's EMC/NetWorker's answer to Symantec's NetBackupencryption on the backup server
From: Steven Weller <sdweller AT SBCGLOBAL DOT NET>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Thu, 14 Dec 2006 20:07:37 -0800
...but how do you see EMCs acquisition of RSA fitting
in here? What do you foresee the future holding?

--- Siobhán Ellis <siobhanellis AT HOTMAIL DOT COM> wrote:

> NeoScale have already opened up their API's
> 
> This war between netApp and EMC is annoying. No
> support for SnapVault, for
> example!
> 
> Siobhan
> 
> 
> On 15/12/06 11:24 AM, "Peter Viertel"
> <Peter.Viertel AT MACQUARIE DOT COM> wrote:
> 
> > 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
> > 
> 
> 
> Siobhán
> 
> 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
> 

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