Securing Mainframe Communications Over the Internet

2 Pages

Mainframes are here to stay; they’ll continue to serve as the repositories and guardians of key corporate and governmental data. From a security perspective, their ability to efficiently process large amounts of data while protecting it from unauthorized access is unparalleled. Simultaneously, the growth of the Internet as a communications medium has placed new demands for immediate access to data stored on mainframe systems by ever larger audiences. This increased demand, coupled with the loss of mainframe technical skills among IT personnel, is threatening the mainframes’ ability to maintain the high level of data security they’ve traditionally provided.

One way many companies attempt to solve this problem is to isolate the mainframe—using Linux or Windows/ Intel servers as front-ends to handle the communications traffic. This sounds great in theory, but like all “Band-Aid” fixes, this approach has limitations. Using a front-end server increases costs and adds performance penalties. Worse, vulnerabilities in the less secure frontend servers might allow hackers to access the mainframe.

SSL Isn’t the Answer

Many people incorrectly assume incorporating Secure Sockets Layer (SSL) encryption into Web traffic will solve all security problems. Unfortunately, that isn’t the case, especially when working with critical data stored on mainframe systems. SSL was designed to provide data encryption over the Internet and to be easy to implement and use.

Unfortunately, achieving those objectives led to some compromises in other areas. The greatest of these is that SSL has no mechanism to authenticate the user. Presumably, the Web application using SSL encryption will be written to require a user ID and password, but these can be easily compromised in various ways. Here are a few examples:

  • Shared PCs: A user logs on to a public PC at an Internet café or on a borrowed laptop. This user’s ID and password are stored in the Web cache and can be easily discovered and accessed by subsequent users. In fact, if the user clicked “yes” to the prompt, asking to save the ID and password on the local machine, even the least comz puter-savvy user can get into the account.
  • The Wireless Access Protocol (WAP) gap: Using cell phones to access applications or to browse the Internet via cellular link or Bluetooth connection may not be secure. Security depends on the cellular provider, and networks not implementing WAP 2.0 require a gateway to decrypt the wireless protocol (WTLS) and re-crypt to SSL. If this gateway is compromised, the hacker can effortlessly gain access to transmitted data. In addition, Bluetooth links are easily eavesdropped and deciphered.
  • Spyware invasion: A user inadvertently downloads spyware from a Website. This spyware checks his Web cache for IDs and passwords, transmitting them back to a hacker for fraudulent use.
  • Host impersonator: A hacker impersonates the host computer (which also isn’t authenticated by SSL) and emulates the host to entice the user to provide a password and ID. This is similar to an e-mail “phishing” scheme.

So, the easily hackable Web cache, with its treasure trove of information, and the failure to authenticate the host and user machines can significantly compromise SSL encryption security. Moreover, SSL isn’t always enabled because enablement is entirely under the host’s control. When a user sees a message from a Web browser saying,

“The following pages contain both secure and non-secure items …” it means just that. The user doesn’t know which data he or she enters will be encrypted. For example, the user’s account, password, and credit card information may be encrypted but the name, address and other personal information may not be. This information could be valuable to a hacker, especially when combined with other information such as buying patterns, demographics, etc.

Another important issue, especially in this time of increasing government regulation and oversight of computer security practices, is the inability to audit and the lack of accountability when using SSL. Government regulations, such as the Health Insurance Portability and Accountability Act (HIPAA) and Gramm-Leach Bliley Act (GLBA), require data transactions be auditable and accurate logs be kept. Lacking the ability to know for certain the true identity and location of the user or even the host makes such tracking impossible. So, when security breaches do occur, SSL lacks the ability to determine precisely what happened and to identify the culprits.

Requirements for a Secure Solution

Mainframe operators are accustomed to having full control over the data in their machines, knowing precisely who has access to which data and having comprehensive logs to provide complete audit trails to track any access or transaction. The idea of allowing access by any computer, anywhere in the world, via an easily compromised ID and password, and not even having the ability to know where the access came from, is absolute heresy. It may be necessary to accept these security risks for simple business-to-consumer e-commerce transactions, but a higher standard must be adopted for more sensitive business-to-business and internal transactions, especially those involving financial, medical, governmental, and corporate data. The following guidelines form a minimum set of requirements for these more sensitive transactions:

2 Pages