I noticed on the list a question concerning file transfers bringing up the thought of tranlsation. Last year I submitted a White Paper to Cheryl Watson and she published in her newsletter in the summer. I predict the question will be more and more discussed because of the reasons I explain below.
Enjoy File Encryption - An IBM Enterprise Server Opportunity There has been much recent emphasis on the security of data with the focus being placed on encryption. But there are more fundamental issues being overlooked that lurk behind the requirement of data encryption. There is no disputing the need to adequately secure data that is leaving or coming into the enterprise. Until now, data being saved onto cartridges was often not encrypted, and was then entrusted to carriers and protectors who failed to do their duty. Many recent cases of disaster-recovery dumps getting lost attest to that reality. Encrypting data backup cartridges presents a few challenges with the biggest being key management. Once an installation starts encrypting, then key management will always be an issue. For a long time, file transfers of data in the clear (not encrypted) was thought to be safe if it were done using VPN (Virtual Private Network) clients - either running on a PC, or via site-to-site VPN links between companies, or via SSL (Secure Socket Layer) session encryption before transmission. But now the US Government has mandated that all files containing PII (Personally Identifiable Information) are to be encrypted before being transmitted. It will probably be extended to much of the private sector, especially those companies that have US government contracts. This mandate introduces a problem but also a tremendous opportunity for the IBM Enterprise Server or (what we used to call) the trusty mainframe. For many years the transfer of files between platforms (mainframes, UNIX, Windows, Linux, etc.) has been happening throughout the organization, and also to places outside of the organization. Secure FTP products are often being used, and sessions are secured using TLS or SSL, and sometimes a VPN tunnel. With the introduction of encryption, this means a very fundamental change in the way people will need to work in the future. Today, when a file is transferred from an EBCDIC mainframe to an ASCII UNIX system, the translation of the data occurs on the receiving UNIX system. It has been done this way because the receiving system knows what it is and knows what kind of ASCII is needed. This is true for UNIX to Windows, Windows to Linux, mainframe to Windows, etc. So it was never a problem for application systems being run by users because the translation requirement was handled automatically with the data arriving ready to use. One might assume that ASCII is universal but we learned recently that Windows ASCII is very close but not exactly the same as UNIX ASCII. This became apparent to me because a requirement stated that when a Windows ASCII file was sent to the mainframe, it could not be modified. I thought this was easy; because we would just accept the data as binary and send it forward to a UNIX system. But the UNIX system support people reported problems with certain characters. They were not happy with having to figure out why translation was not correct and with having to do further translation on their side. After many discussions, the requirement was changed so that Windows ASCII was translated to mainframe EBCDIC and then to UNIX ASCII. This seemed to work and everyone was happy. But now extend this scenario to non-technical people getting a file at some small server or PC. They want the data arriving ready to use, but that may not be easy when you introduce the notion of the data arriving encrypted. As a general rule, when one system encrypts its data before sending it, the receiving system will need to decrypt the data and have the responsibility of making sure any required translation is done so that the data is ready to use. Even assuming the receiving system has all the necessary translation utilities and tables, this still assumes a level of administrative intelligence that can determine what kind of system is sending you data. So all systems will need knowledge about the type of data they might potentially receive. This has now imposed the requirements of decrypting the received data, knowing what kind of system sent it, and executing a translation step after decryption to get the data into the format that the user expects. Another thing to consider is what happens if some systems do not have the capability to handle the new translation workload. Even if the systems could perform the translation, the requirement to know the format of the sending machine could force an administrative nightmare on everyone receiving files from another location. This chaos is a tremendous opportunity for the Enterprise Server. People with a mainframe background are used to making order of chaos. This order is already established in the ongoing running and management of the IBM Enterprise Server. Because the IBM Enterprise Server already has all kinds of translation tables (called code pages), the strategy would be to make this system the hub for collecting and distributing files outside of the corporate Intranet. This is sometimes called data exchanges by the establishing trading partners. There is a trend in government and private industry to focus all their data exchanges through one central point. Encryption makes this trend even more attractive in the future. As the focus changes from creating media (making a tape) to exchanging data electronically, encryption becomes a mandatory requirement. It makes business sense to establish a new Line of Business (LOB) for the Enterprise Server as the hub for all data exchanges. The IBM Enterprise Server has all the components needed to accomplish this with little work. The new System z9-BC or z9-EC can be configured with inexpensive crypto processors to do software encryption away from the billable processors. For example, two such processors can cost much less than $24,000 to purchase. Many installations already have these installed to support SSL. All of the code pages are standard in z/OS. Many are surprised to learn that z/OS supports UNIX file systems that appear similar to those that would be found on UNIX, Linux, and Windows. These can be used as store-and-forward repositories, with RACF or similar products ensuring the integrity. This new application would only need to have a small portion of the System z9 to function as the data exchange hub and be responsible for gathering files destined to go outside the corporate enterprise. It would receive the file internally, store the file, translate the file as needed by the receiving system, encrypt the file, and finally transmitted it off to its final destination. The reverse would be true for receipt of a file from a data exchange partner. The file would be received, decrypted, translated and forwarded to the correct Intranet connected system. Another benefit is that all the security concerns are focused on one system and key management would reside in one place - the IBM Enterprise Server. With its history of security, flexibility, automation, and its wide variety of tools, it is the most cost effective choice. In conclusion, encrypting data is not a huge challenge. But the real requirement in the enterprise will be to deliver the data, properly translated to the data exchange partner in a useable manner. The translation requirement is the lurking 'junkyard dog' of file encryption. The solution is to have the IBM Enterprise Server do what it does best and bring order at a very reasonable cost. -------------------------------------------------------------------- Today's Comments: As a follow-on to this one gets into the issues of what file formats can be used which can seemlessly go between systems. Indeed variable length record files can be challenging. Another complete topic is what products are available to do the transfers besides FTP. Hope this give folks a jumpstart of what I saw back in 2006 when encryption was very quickly imposed here and had to sort out all the implications of sending data to other mainframes, UNIX, and Windows kinds of system. jim ---------------------------------------------------------------------- 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
