ADSM-L

[ADSM-L] AW: [ADSM-L] AW: [ADSM-L] 3592 Drive Encryption

2008-01-14 10:58:00
Subject: [ADSM-L] AW: [ADSM-L] AW: [ADSM-L] 3592 Drive Encryption
From: "Herrmann, Boris" <Boris.Herrmann AT ARAG DOT DE>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 14 Jan 2008 16:54:59 +0100
Thanks to all for sending me information about data encryption. I used a lot of 
the arguments discussed here (and which I also don't know before) to 
(hopefully) convince our management in upgrading our drives with the encryption 
feature code. Now we are waiting for the upgrading costs information from our 
hardware seller ;-)   

With kind regards,
______________________________________
 
Boris Herrmann
Produktion / Heterogene Systeme 
 
ARAG IT GmbH
ARAG Platz 1, 40472 Düsseldorf
 
Tel:  +49 (0)211 964-1137
Fax: +49 (0)211 964-1155
Boris.Herrmann AT ARAG DOT de
www.ARAG.de
 
 
Geschäftsführer:  Ottmar Liebler, Hanno Petersen 
Sitz und Registergericht:  Düsseldorf,  HRB 10934
USt-ID-Nr.:  DE 119 356 473
 


-----Ursprüngliche Nachricht-----
Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im Auftrag 
von Curtis Preston
Gesendet: Samstag, 12. Januar 2008 06:29
An: ADSM-L AT VM.MARIST DOT EDU
Betreff: Re: [ADSM-L] AW: [ADSM-L] 3592 Drive Encryption


I must concur with Neil.  Being in Germany places your company under EU's Data 
Protection Act (I believe that's what it is called).  I believe it is far more 
stringent than what we have in the US.  (In the US, 38 of our 50 states require 
public notification of an unencrypted lost tape.  The number of such 
notifications was higher in 2006 than any previous year.)  Therefore, surely 
management believes that they need to protect against a lost tape, or they 
wouldn't be asking you to do it.  So you're not arguing over whether to do it, 
just how much it will cost.

ALL methods for solving this problem have a cost.  

Even if using TSM's software encryption is free to you, doing so will cause you 
to lose any compression you have on your tapes and increase the number of tapes 
you have to purchase by as much as 50-100% (depending on your compression 
ratio).  You may also need beefier servers to handle the extra load that 
software encryption brings.  This is NOT a good solution for large scale 
encryption.

There is also Decru & Crossroads that offer tape encryption boxes in the SAN, 
and Cisco has a blade solution coming (or here?).  (There was Neoscale, but it 
looks like they're folding.)  These boxes will compress THEN encrypt your data, 
allowing you to encrypt your backups at line speed without increasing your tape 
cost or switching drives.  They're not cheap, but they're top of line.  They 
have significantly more advanced key management than any of the tape drive 
solutions.

Then, of course, there's the tape drive encryption.  Since you have to swap 
tape drives anyway, I would seek a competitive big for the Sun's T10000.  Maybe 
a little competition will bring down the price, but it will (of course) not 
remove the cost totally.

A final solution would be to switch entirely to a disk-based backup system that 
employees deduplication.  Deduplication reduces the amount of backup data 
enough to allow many companies to replicate their backups offsite.  This allows 
them to have onsite and offsite backups without making tapes.  No tapes made = 
no tapes lost.  But this is obviously a major expense that would probably dwarf 
the cost you were given for upgrading to the encrypted drives.

I hope this helps.

---
W. Curtis Preston
Backup Blog @ www.backupcentral.com
VP Data Protection, GlassHouse Technologies 

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Strand, Neil B.
Sent: Wednesday, January 09, 2008 7:36 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] AW: [ADSM-L] 3592 Drive Encryption

I would ask your management how much a single lost tape with unencrypted data 
would cost.
- Public exposure
- Customer confidence
- Government/legal investigation
- Competitor acquiring your proprietary information

Encryption on tape drive provides a highly scalable, near zero impact, 
manageable, secure solution to protect your assets and your customer's privacy. 

If you have a mix of encrypted and unencrypted data being saved from each 
client, what kind of management problems would that introduce to your 
environment? How much effort would it take to prove that a particular file was 
encrypted when it was backed up?  With the encryption on drive solution and all 
media encrypted, I can show on which tape(s) the data resides and then show the 
line in the audit log produced by the encryption key manager showing that the 
tape drive with that volume was successfully sent the encryption key.

Your IBM vendor should be able to work with you to provide an upgrade path or 
trade in value for your old drives.

Cheers,
Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.
(410) 580-7491
Whatever you can do or believe you can, begin it.
Boldness has genius, power and magic.


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Herrmann, Boris
Sent: Wednesday, January 09, 2008 9:39 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] AW: [ADSM-L] 3592 Drive Encryption

Neil,

thanks for your detailed information. I've checked with IBM support. 
Unfortunately our 3592-E05 Drives are not encryption capable. IBM support told 
me that we can purchase a feature code (with the result, that all our drives 
would be replaced with new one), but our management didn't want pay anything.

They asked me, if there would be any other way to encrypt the data without any 
cost. I don't know any way except the TSM client encryption (but I think it's 
not pratically to encrypt every data on the client systems, or is it?). We make 
normal backups and archives, a lot of db2 api backups, TDP (Exchange, Domino, 
MSSQL) and Oracle RMAN backups. Every day we backup up about 3-5 TB.

Does anyone have any other practical implementation of encrypting Volumes 
without hardware drive encryption?

With kind regards,
______________________________________

Boris Herrmann
Produktion / Heterogene Systeme

ARAG IT GmbH
ARAG Platz 1, 40472 Düsseldorf

Tel:  +49 (0)211 964-1137
Fax: +49 (0)211 964-1155
Boris.Herrmann AT ARAG DOT de
www.ARAG.de


Geschäftsführer:  Ottmar Liebler, Hanno Petersen Sitz und Registergericht:  
Düsseldorf,  HRB 10934
USt-ID-Nr.:  DE 119 356 473



-----Ursprüngliche Nachricht-----
Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im Auftrag 
von Strand, Neil B.
Gesendet: Montag, 7. Januar 2008 17:03
An: ADSM-L AT VM.MARIST DOT EDU
Betreff: Re: [ADSM-L] 3592 Drive Encryption


Boris,
   Verify that the library and drives are capable - may need a firmware upgrade 
or feature code - check with IBM.  You will also want to ensure you have the 
latest Atape driver installed.

   A logical library is either encryption capable or not - the drives in a 
logical library cannot be mixed.  If you implement library managed encryption, 
you have a great deal of flexibility over which volumes get encrypted and with 
which encryption keys they are encrypted with.

   I strongly encourage you to set up at least two, redundant Encryption Key 
Managers (EKM) because if a drive is unable to get a key, you get no volume to 
read from or write to and things can grind to a halt quickly.
   There are several IBM references including a Redbook on setting up the EKM.

   You may consider first creating a logical library with one or two drives and 
then testing various configurations with a small number of volumes and data 
that can be lost if you mess up.  If you lose the encryption key, you lose the 
data that was saved with it - you have been warned, no key, no data.

   I encrypt everyting that goes on tape (primary and copy pools) on the 
assumption that tape is easily transportable.  If a tape is ejected from the 
library (for any reason), all of the data is still protected by encryption.  
There is negligible performance impact with encryption on these drives.

   Plan on at least a 4 -6 week implementation and make sure you test and 
document your key and data recovery procedures and key changing procedures.

   I choose to implement library managed rather than application managed 
because it offered flexibility to have the encryption component managed by our 
security team without having them learn TSM.  It also allows encryption of 
media outside of TSM so if we need to ship a tarfile on tape, it can be done 
securely with a minimum of fuss.  Library managed also allows you to specify 
which tapes get encrypted - a volser range or a single tape to be encrypted 
with a specific encryption key (that key could be shared with a business 
partner).


Cheers,
Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.
(410) 580-7491
Whatever you can do or believe you can, begin it.
Boldness has genius, power and magic.


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Herrmann, Boris
Sent: Monday, January 07, 2008 10:10 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] 3592 Drive Encryption

Hello TSM'ers,

I've a question regarding Drive Encryption. We have a TSM Server v5.4.1.2 (on 
AIX 5.3.0.0) with a 3584 Tape Library and 3592-E05 Drives. We share this 
Library with our mainframe colleagues (one logical Library for mainframe and 
one logical Library for our TSM environment). Now our management wishes to 
encrypt our COPYSTORAGE-Pool volumes.

My questions:
Have anyone any experience with that issue and can give us some hints and tips 
how to implement the Drive Encryption. Need we additional Feature Codes for the 
Drives? Can we enable Drive Encryption only for our Logical Library without 
interfere our mainframe colleagues?


With kind regards,

Boris Herrmann

Produktion / Heterogene Systeme



ARAG IT GmbH

ARAG Platz 1, 40472 Düsseldorf



Tel:  +49 (0)211 964-1137

Fax: +49 (0)211 964-1155

Boris.Herrmann AT ARAG DOT de

www.ARAG.de <http://www.arag.de/>





Geschäftsführer:  Ottmar Liebler, Hanno Petersen

Sitz und Registergericht:  Düsseldorf,  HRB 10934

USt-ID-Nr.:  DE 119 356 473





IMPORTANT:  E-mail sent through the Internet is not secure. Legg Mason 
therefore recommends that you do not send any confidential or sensitive 
information to us via electronic mail, including social security numbers, 
account numbers, or personal identification numbers. Delivery, and or timely 
delivery of Internet mail is not guaranteed. Legg Mason therefore recommends 
that you do not send time sensitive or action-oriented messages to us via 
electronic mail.

This message is intended for the addressee only and may contain privileged or 
confidential information. Unless you are the intended recipient, you may not 
use, copy or disclose to anyone any information contained in this message. If 
you have received this message in error, please notify the author by replying 
to this message and then kindly delete the message. Thank you.

IMPORTANT:  E-mail sent through the Internet is not secure. Legg Mason 
therefore recommends that you do not send any confidential or sensitive 
information to us via electronic mail, including social security numbers, 
account numbers, or personal identification numbers. Delivery, and or timely 
delivery of Internet mail is not guaranteed. Legg Mason therefore recommends 
that you do not send time sensitive 
or action-oriented messages to us via electronic mail.

This message is intended for the addressee only and may contain privileged or 
confidential information. Unless you are the intended recipient, you may not 
use, copy or disclose to anyone any information contained in this message. If 
you have received this message in error, please notify the author by replying 
to this message and then kindly delete the message. Thank you.