Security

Any given computer is likely to be connected to some other computer, whether by Local Area Network (LAN), the Internet, cross-network connections, coupling facility, or simply wirelessly. Most security administrators learned security on one platform. As computers become more interconnected, they’re often charged with administering security for other types of platforms across various network types. Providing effective security across these connections is a challenge.

This and follow-up articles will examine common problems and approaches to cross-platform security, offer some basic underlying principles, and provide recommendations to make this security easy and effective. We cover a lot of material to simplify the problem and then reveal the most effective solution, which is currently available.

Configuration Examples

To illustrate the problems and solutions, let’s start with three example configurations. The first is a “programmer’s workbench,” a Windows computer that connects through a LAN to TSO and CICS on an IBM mainframe.

The second example is a retail cash register based on the UNIX operating system, connected to an iSeries midrange computer in a store, which connects to an IBM mainframe at the company’s headquarters.

The third example consists of IBM Connect:Direct software being used to exchange files between two mainframes over both SNA and TCP/IP networks.

Some immediate cross-platform security difficulties spring to mind, first with user identification, and then access control. User identification is complicated by the fact that different platforms have different length and content restrictions for both userids and passwords. Some platforms have a maximum length of eight characters while others are as long as 256 characters. Some use only uppercase; others use and often require both upper and lowercase. The pound character in the U.S. is different from the pound character in England.

With the programmer’s workbench configuration previously described, users may need to log on twice, first to Windows with a Windows userid and password, then to the mainframe with a mainframe userid and password. (To reduce the effort, many programmers hard code one of the userid/password combinations into a script or function key. This makes their lives easier, but weakens security.)

With our programmer’s workbench example, there’s also the risk of sniffer programs on the LAN exposing mainframe userids and passwords. A sniffer program executes on any computer on the LAN and can read message traffic for all the other computers on the subnet. If the LAN is used for mainframe logons, then the sniffer can read mainframe logon requests, including userids and passwords, unless some sort of protection is implemented. Note that encryption of the userids and passwords isn’t adequate protection. This is because the sniffer program doesn’t need to decrypt the logon request; it merely must record it and play it back over the network.

The difficulties of cross-platform user identification can’t be resolved with methods that seem easy to implement, but weaken security. For example, when a distributed computer such as a cash register connects to a different platform such as the iSeries, it’s tempting to simplify security problems by giving all users the same generic userid. This is easy to implement, but loses the identity of the user in log files and makes it impossible to distinguish between what one user can do vs. what other users can do.

Another common shortcut is to give one userid privileges that let it assume the identity of any other userid. Connect:Direct is often implemented in this fashion between mainframes. When Connect:Direct transfers files between mainframes, it often does this by submitting batch jobs that execute under the authority of some production userid. To make this happen, the userid for Connect:Direct is sometimes granted privileges that let it submit batch jobs for any userid without having to provide the password. Again, this approach seems easy to implement, but weakens security.

3 Pages