RECMGMT-L Archives

Records Management

RECMGMT-L@LISTSERV.IGGURU.US

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Norman Owens <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Sun, 20 Nov 2005 01:41:13 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (80 lines)
To Hugh's question: 

If the higher security encryption keys slows down the system more (50%
estimated)  than less secure keys, how much speed do we want to trade
off for security? 

>>>The encryption appliance vendors promise no more than 5% slow downs and then only if the tapes are maxed out on bandwidth which is usually hard to do.

If the encryption key is stored on the system and the system is down
how do we access the key? 

>>>Most solutions offer a means of transporting encrypted encryption keys to a secondary site because if the appliance has to be replaced then you'll need to download the original keys.  
 

If password protected files are stored on transferable, portable media,
don't we have the same risk as losing a lap top? 

>>>Not sure that this refers to.

Encryption slows back up, if we face a disaster such as a storm or
hurricane, won't slowing down the back up create more risk?
If we are in disaster recovery, won't the slowness of the system create
recovery problems? 

>>>Mistaken premise if an appliance is used.

Can't the $50 - $100,000 be spent more effectively? 

>>> Not sure where the price range comes from.  Seems very high on the upper end.  But to the effective part, how much would you have to spend to set up a comparable process which would ensure that no matter what, your data could never be stolen during tape transport.  You have that possibility with encryption where you need at a minimum, the original tape, an encryption appliance, and ready access to the encryption keys to steal the data.  It would probably be more cost-effective for the potential thieves to plant hackers into the company to steal the data then to plot to get all 3 of the needed components.
 

 

Gerard J. Nicol writes: 

> Hugh/Jay, 
> 
> I am not sure if encryption does slow backups. Encryption is a CPU intensive
> operation. CPU speed increases significantly each year. It is IO and Network
> speeds that increase at a slower rate than data growth. 
> 
> What needs to be understood here is the obvious disconnect between how IT
> people think, and how most other people think. 
> 
> In IT, theoretically nothing is impossible. In practice IT is about
> trade-offs. 
> 
> Trade-offs are the basis of the SLA (Service Level Agreement). 
> 
> For instance, does it annoy you that Windows takes 60 seconds to start? We
> can fix that for a price. Oh, you are too stingy to pay that price, so let's
> agree that 60 seconds is OK. 
> 
> If we are talking about tapes here, I think people are missing the point if
> they think it is about encryption. 
> 
> Although privacy is now a critical part of our society, the ability of
> society to continue to function is more important. 
> 
> If your offsite vendor is leaving your tapes on the curb, or sending them to
> an airfield never to be seen again forget encryption, use the money to put
> in place a strong contract and SLA with a competent vendor. 
> 
> That way, in the event that you need your tapes for a true disaster you are
> not left pondering how the company might now be out of business but at least
> if the tapes turn up in the hands of someone who has a spare 3490 tape drive
> at home people's privacy might be protected. 
> 
> If you are interested in discussing what you should be putting in an SLA, I
> would be more than happy to assist. 
> 
> Gerard 
> 
> List archives at http://lists.ufl.edu/archives/recmgmt-l.html
> Contact [log in to unmask] for assistance
 

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance

ATOM RSS1 RSS2