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