I don't see this replacing hardware encryption.

When I was at Legato, we actually looked at RSA for security within
NetWorker. I can't remember why it didn't go ahead.

Anyway, I see RSA being very much used within EMC's products. However, EMC's
problem, now, is that they have bought so many products/companies, the task
of integrating them all is huge!

Siobhan


On 15/12/06 3:07 PM, "Steven Weller" <sdweller AT SBCGLOBAL DOT NET> wrote:

> ...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
> 


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