Re: Encrypted Tapes and DR [EMAIL PROTECTED]
Russell Witt wrote: That will work just fine Mark, if your DR site is dedicated to you and you have a running system there that is not recovered from your DR tapes themselves. If your DR is running at a Sunguard/IBM shared DR recovery site, then that will not work. In that case, you will have to have a backup of your RACF database (in un-encrypted form of course) and restore that first; re-ipl using the new RACF database (can RACF be re-activated with a new database without an IPL?); then restore the rest of your backups. DR is one of the biggest issues with any encryption product; and of course Key Management is the other major concern (don't let your digital certificates expire when you are still using them). I believe the EKM documentation indicates it will work even if the certificate is expired. So the real issue is to not delete them until you are sure they are not needed. However, I used the max allowed expiration date on my certs anyway :-). -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encrypted Tapes and DR [EMAIL PROTECTED]
On Thu, 10 Apr 2008 20:56:04 -0500, Russell Witt [EMAIL PROTECTED] wrote: That will work just fine Mark, if your DR site is dedicated to you and you have a running system there that is not recovered from your DR tapes themselves. If your DR is running at a Sunguard/IBM shared DR recovery site, then that will not work. In that case, you will have to have a backup of your RACF database (in un-encrypted form of course) and restore that first; re-ipl using the new RACF database (can RACF be re-activated with a new database without an IPL?); then restore the rest of your backups. DR is one of the biggest issues with any encryption product; and of course Key Management is the other major concern (don't let your digital certificates expire when you are still using them). I think he'll need an unencrypted copy of his ICSF databases, too, Russell. And yes, you can activate a new RACF DB without an IPL, but only if it has the same dsname as the one you're already running. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encrypted Tapes and DR [EMAIL PROTECTED]
Walt Farrell wrote: On Thu, 10 Apr 2008 20:56:04 -0500, Russell Witt [EMAIL PROTECTED] wrote: That will work just fine Mark, if your DR site is dedicated to you and you have a running system there that is not recovered from your DR tapes themselves. If your DR is running at a Sunguard/IBM shared DR recovery site, then that will not work. In that case, you will have to have a backup of your RACF database (in un-encrypted form of course) and restore that first; re-ipl using the new RACF database (can RACF be re-activated with a new database without an IPL?); then restore the rest of your backups. DR is one of the biggest issues with any encryption product; and of course Key Management is the other major concern (don't let your digital certificates expire when you are still using them). I think he'll need an unencrypted copy of his ICSF databases, too, Russell. And yes, you can activate a new RACF DB without an IPL, but only if it has the same dsname as the one you're already running. We have a one volume zOS 1.8 environment that includes its own RACF and ICSF databases. We restore it from the floor system, ipl it, enter the master keys into the cryptographic hardware, start ICSF and EKM and start restoring the encrypted full volume backup tapes. At the end of the test we erase the keys from the cryptographic hardware, securely wipe the volume that we ipled with(along with the restored volumes of course) and go home. -- Mark Jacobs Time Customer Service Tampa, FL We have a special climate-controlled room that keeps the worms at a low enough temerature so that they remain dormant. If the temperature varies by more than +-0.73K, the worms either freeze to death, or eat throught the CrTiAl alloy of the airlock doors. Dicey. -Branko Cibej [EMAIL PROTECTED], concerning the can of worms -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encrypted Tapes and DR [EMAIL PROTECTED]
--snip--- And yes, you can activate a new RACF DB without an IPL, but only if it has the same dsname as the one you're already running. -unsnip ISTR switch to new RACF database files by using a series of RVARY commands. It that no longer available? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encrypted Tapes and DR [EMAIL PROTECTED]
Rick Fochtman wrote: --snip--- And yes, you can activate a new RACF DB without an IPL, but only if it has the same dsname as the one you're already running. -unsnip ISTR switch to new RACF database files by using a series of RVARY commands. It that no longer available? It is still available, but it never allowed to specify new dataset name. So, you can switch. inact, act, but the dataset names are fixed in ICHRDSNT. However I see no problem here: you can simply copy any RACF db to existing (inactive) file. Or rename the files. In other words RACFdb is not aware of it's own dataset name - so the name can be changed. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encrypted Tapes and DR [EMAIL PROTECTED]
--snip R.S. wrote: Rick Fochtman wrote: --snip--- And yes, you can activate a new RACF DB without an IPL, but only if it has the same dsname as the one you're already running. -unsnip ISTR switch to new RACF database files by using a series of RVARY commands. It that no longer available? It is still available, but it never allowed to specify new dataset name. So, you can switch. inact, act, but the dataset names are fixed in ICHRDSNT. However I see no problem here: you can simply copy any RACF db to existing (inactive) file. Or rename the files. In other words RACFdb is not aware of it's own dataset name - so the name can be changed. --unsnip--- Yes I did change the dsname, and that change lasts through the life of the IPL. Learned it the hard way, when I forgot to update ICHRDSNT and it reverted to the old datasets after an IPL. I'm sure I'll be corrected if I'm wrong, but ICHRDSNT is only referenced at IPL time, when RACF is first initialized. Other security tools MAY behave differently. Look at the syntax of the RVARY command for dataset switching. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Encrypted Tapes and DR
Is anyone using the new Encryption Tape Drives (like TS3500) from IBM at a DR site? If so, how are the keys handled? Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encrypted Tapes and DR
I hear the name of the algorithm is WORN: Write once, read never :-) Sorry. We are looking at the solution and have been through some presentations. http://www-03.ibm.com/press/us/en/pressrelease/20254.wss Key management comes with the solution and DR considerations are allegedly built right in. I don't recall any of the details, but I do recall thinking their scheme might actually work. After all, sales folks always know their product perfectly and all software works exactly as documented :-) Even so, my personal take is that there are lots of complex little pieces that have to work perfectly or the data is irrevocably lost. Since the data includes your backups, well, there you are. Somehow the cost/benefit/risk equations don't quite add up in my poor, befuddled brainbone. HTH -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler Sent: Thursday, April 10, 2008 2:37 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Encrypted Tapes and DR Is anyone using the new Encryption Tape Drives (like TS3500) from IBM at a DR site? If so, how are the keys handled? Lizette NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encrypted Tapes and DR
Actually we have them in production and have sucessfully tested a restore of an encrypted tape in our disaster recovery environment. We use RACF to control the public piece of the key pair and ICSF holds the private key. Our DR environment has a completely separate RACF and ICSF databases from production. The way that we have set it all up to work is to create keypairs in both the production and DR environments, import the public keys from the DR environment into the production environment and attach these keys to EKM keyring. When we encrypt tapes we use both the production and DR public keys to wrap the data encrypting key on the tape. At DR the tape drives talk to EKM which sends the DR private key to the tape drive which sucessfully unwraps the data encrypting key protected by the DR public key. Does that make sense? Mark Jacobs Time Customer Service -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt Sent: Thursday, April 10, 2008 4:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Encrypted Tapes and DR I hear the name of the algorithm is WORN: Write once, read never :-) Sorry. We are looking at the solution and have been through some presentations. http://www-03.ibm.com/press/us/en/pressrelease/20254.wss Key management comes with the solution and DR considerations are allegedly built right in. I don't recall any of the details, but I do recall thinking their scheme might actually work. After all, sales folks always know their product perfectly and all software works exactly as documented :-) Even so, my personal take is that there are lots of complex little pieces that have to work perfectly or the data is irrevocably lost. Since the data includes your backups, well, there you are. Somehow the cost/benefit/risk equations don't quite add up in my poor, befuddled brainbone. HTH -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler Sent: Thursday, April 10, 2008 2:37 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Encrypted Tapes and DR Is anyone using the new Encryption Tape Drives (like TS3500) from IBM at a DR site? If so, how are the keys handled? Lizette NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encrypted Tapes and DR [EMAIL PROTECTED]
That will work just fine Mark, if your DR site is dedicated to you and you have a running system there that is not recovered from your DR tapes themselves. If your DR is running at a Sunguard/IBM shared DR recovery site, then that will not work. In that case, you will have to have a backup of your RACF database (in un-encrypted form of course) and restore that first; re-ipl using the new RACF database (can RACF be re-activated with a new database without an IPL?); then restore the rest of your backups. DR is one of the biggest issues with any encryption product; and of course Key Management is the other major concern (don't let your digital certificates expire when you are still using them). Russell Witt CA L2 Support Manager -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Mark Jacobs Sent: Thursday, April 10, 2008 4:09 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Encrypted Tapes and DR Actually we have them in production and have sucessfully tested a restore of an encrypted tape in our disaster recovery environment. We use RACF to control the public piece of the key pair and ICSF holds the private key. Our DR environment has a completely separate RACF and ICSF databases from production. The way that we have set it all up to work is to create keypairs in both the production and DR environments, import the public keys from the DR environment into the production environment and attach these keys to EKM keyring. When we encrypt tapes we use both the production and DR public keys to wrap the data encrypting key on the tape. At DR the tape drives talk to EKM which sends the DR private key to the tape drive which sucessfully unwraps the data encrypting key protected by the DR public key. Does that make sense? Mark Jacobs Time Customer Service -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
