As a bit of a public service -- and since many of the customers I work with are trying to evaluate all their options for this pressing problem -- I thought I'd list the products I know about that support tape encryption. I'm keenly interested to hear if I forgot any -- thanks.
Please note that anything labeled "statement of intention" is subject to change. Unless otherwise noted, these products are available now. Software -------- ASE SLiKZiP http://www.slikzip.com/szabout.htm Data21 ZIP/390 http://www.data21.com/products/zip/default.asp IBM (*) Statement of Intention (for 2005 delivery) [Issued July 27, 2005.] http://www.ibm.com/common/ssi/rep_ca/7/897/ENUS205-167/ENUS205-167.PDF IBM (*) FILCRYPT [Withdrawn from marketing in July, 2005, in anticipation of new product (above).] Innovation Data Processing FDRCRYPT [Now in testing. Later version planned for ICSF support.] http://www.innovationdp.fdr.com/products/fdrcrypt/index.cfm McAfee E-Business Server for OS/390 ("PGP") http://www.mcafeesecurity.com/us/products/mcafee/encryption/ebusiness_server_os390.htm Online Technical Productions (*) MegaCryption/MVS http://www.megacryption.cc PKWARE SecureZIP for zSeries http://pkzip.com/products/enterprise/zseries/sz/index.php (*) Supports ICSF hardware crypto acceleration (if available), relieving some processing overhead from CPs. Hardware -------- CentricStor CentricStor-Decru Encryption Appliance http://www.centricstorusa.com/English/Products/CentricStor_DataFort.html IBM TotalStorage Products [Statement of Intention issued July 27, 2005. No delivery date(s) specified.] http://www.ibm.com/common/ssi/rep_ca/1/897/ENUS105-241/ENUS105-241.PDF SecureAgent Software SecureTape Solution http://www.secureagent.com/securetape/securetape2.htm NOTES and COMMENTS ------------------ 1. Products vary in whether they use ICSF for key management services (in addition to crypto acceleration). Regardless, careful planning is required for key management to assure authorized recoverability, especially in DR situations. Loss of keys means data loss! Treat the key database just like any other precious security resource, such as RACF (or ACF2 or TopSecret) databases. 2. In some sense encryption of backup tapes is philosophically incompatible with rapid and easy data access in the event of an emergency, so many organizations will initially opt for tape encryption only when tapes leave the data center (e.g. for partner exchange). 3. Hardware-based approaches typically require compatible equipment at recovery and recipient sites, although some may offer a lower performance software fallback option. 4. Products vary in whether they support pre-compression (and in the effectiveness and processing intensity of that pre-compression) prior to writing to tape. Encrypted data arriving at the tape drive will typically not compress well, so plan accordingly. 5. Products may vary in their ability to generate tape formats readable on non-zSeries systems. However, nearly all use standard encryption formats such as AES that generally interoperate cross-platform. 6. None of these solutions will solve the problem of tape recipients who then intentionally or inadvertantly lose authorized custody of data once unencrypted. (If the data lands on somebody's notebook computer which is then stolen, same problem.) In other words, data protection involves end-to-end planning and procedures. 7. ICSF crypto performance will vary according to chosen encryption algorithm and server model. For example, every zSeries system has at least two types of hardware acceleration: crypto card-based (such as the CryptoExpress2 PCI adapters) and PU-based (CPACF a.k.a. CP Assist). If the goal is to offload as much processing work from main CPs, then, generally, storage-related encryption (including tape) works best on the CP Assist hardware. Network-related encryption (e.g. SSL) does well with the crypto cards. CP Assist has a more limited set of supported encryption algorithms, so choose carefully. 3DES is available, but the System z9 adds AES (and SHA-256) into CP Assist. Organizations starting to use more AES, especially for storage-related encryption, should factor that into capacity planning and model upgrade decisions to see if a System z9 would offer any financial savings. Most monitoring products (Tivoli OMEGAMON, TMON, MainView, etc.) offer standard or optional ICSF monitoring to keep tabs on resource utilization. 8. I've concentrated on z/OS-related products in this list. I'd very much like to add options for the other operating systems to this list if someone has done homework on that. (Some on this list do.) 9. Many organizations are attempting to shift certain tape exchanges toward secured network exchanges. That shift may be viable in many situations, and z/OS already has ample support for network-related encryption, such as SFTP and SSH. But please note that FTP, despite its popularity, has some quality of service weaknesses. For example, unless FTP'ing between two very recent z/OS releases (where there's some special handshaking), there's no guarantee an entire file will arrive. (FTP has some problems signaling end of file.) You should run an independent after-verification of some sort to make sure a file arrives complete and intact. Also, FTP is NOT a good way to integrate applications (again, despite its popularity in that role). Sit down with a zSeries software architect if you're in that situation to do some good planning. ---------------------------------------------------------------------- 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
