Jan 15 ’13
Cross-Platform Security: Recommended Solutions for Common Problems
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.
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.
Turning from user identification to access control, we see similar difficulties in cross-platform security.
Access control is complicated by the fact the names of files and resources that require protection can also have different standards for length, content, and organization. File names with z/OS are all uppercase and are subdivided into pieces called qualifiers, using a period as the separator character. The qualifiers are used to organize files together (e.g., all data sets whose high-level [left-most] qualifier is SYS1…). UNIX and Windows filenames are separated by slashes, often lower- or mixed-case, and organized into directories and sub-directories.
There can be types of resources on one platform that don’t exist on others (e.g., UNIX pipes or mainframe JESSPOOL and TSOPROC).
A final problem results from the different software approaches to user identification and access control. With z/OS, these are provided by one of three security software packages—IBM’s RACF, CA-ACF2, or CA-Top Secret—each with its own logic and architecture. On Windows computers, these functions are built into the operating system using a different architecture. These functions are also built into the UNIX and iSeries operating systems but with yet different architectures.
Each security software has its own set of privileges that seldom neatly match other security software’s privileges.
As we examine some of the possible solutions, here are some basic, simplifying, principles to keep in mind:
• Assume each platform is responsible for protecting the files and resources that live on that platform. Any other approach is impractical.
• A user’s identity can only be validated by the platform where the user is defined.
• Platforms will need a means of trusting each other.
• The only widely used communication protocol all platforms support is TCP/IP. This set of rules and formats to let different types of computers communicate with each other started out in UNIX and spread to the Internet. Microsoft adopted it for Windows when its proprietary protocols were found incapable of effective security. IBM adopted TCP/IP and supports it fully on mainframes, iSeries, and AIX. Any cross-platform security solution will likely rely on TCP/IP.
The several different cross-platform solutions developed typically use one or more of the following approaches:
• Userid coordination, maintaining a list on each platform of its userids and their corresponding userids on other platforms
• Agent software on each platform that handles userid administration and communicates with the agent software on other platforms and also with the security software on its own platform
• Role-Based Access Control (RBAC) using groups of users, each of which represents a role such as all the users who need to be Accounts Receivable clerks
• Upside-down trees with examples you know already, including the directory tree on your hard drive and the organization chart for your company
• Cross-platform security standards supported on all platforms.
Each of these approaches has pros and cons. The first two involve adding hardware resource usage, administrative overhead, and control information. The last three involve using tools already on your computers.
Userid coordination can add significantly to hardware and network resource usage, encryption requirements, and administrative effort needed. An example of this approach is the RACF mainframe security software feature called RACF Remote Sharing Feature (RRSF).
Imagine a bank acquires another bank and merges the two IT departments. Each bank has a user whose userid is CHARLIE on all of that bank’s computers. Merging the two banks’ information security will need a method to distinguish between the two CHARLIEs.
Installing and maintaining agent software on each platform requires administrative overhead and relies on the software staying current and executing properly on each platform. Some platforms’ security software doesn’t lend itself easily to interaction with agent software.
RBAC simplifies security administration. Administrators grant whole collections of privileges by making a user a member of a group that has already been granted exactly the privileges needed. This is simpler than trying to grant a new user all the various privileges needed.
Upside-down trees, such as the directory tree on your hard drive, permit extensions on the bottom, and don’t require those on the top to know all the details of what those on the bottom are doing. Such trees provide command and control up and down the chain. For example, in UNIX or Windows directory trees, you can add new files and sub-directories to a directory, and the directories at the top don’t need to be aware of details in the directories at the bottom. You can also limit access for certain users to just specified parts of the tree.
Upside-down trees also provide uniqueness for names. Instead of two files named paydata, you can have a file named /prod/payroll/October/paydata and /test/payroll/October/paydata.
Observing standards supported on all platforms requires vendors to work together to agree on a standard and then support it. With one exception, getting vendors to agree on such a standard might seem impossible.
The one standard that all the vendors support is called Distributed Computing Environment (DCE). This includes both Lightweight Directory Access Protocol (LDAP) and Kerberos. DCE was developed back when the major computer vendors were IBM and the BUNCH (Burroughs, Univac, NCR, Control Data, and Honeywell). It uses TCP/IP for communication, LDAP to manage information about users, and Kerberos to authenticate users.
LDAP identifies users via a directory or database of user definitions. LDAP servers are organized into an upside-down tree that extends across platforms and provides unique naming of users and files. A well-known example of an LDAP directory is Active Directory on Windows computers. An LDAP server on any platform can interact intelligently with LDAP servers on other platforms within an upside-down tree to provide practical security administration for userids.
Kerberos is the means of proving each user’s identity and for providing one-time session keys for encryption between platforms. It’s built into Active Directory, provides protection against sniffer programs, and all major platforms support it.
Use of LDAP and Kerberos, universally accepted and implemented standard protocols, is a superior solution. They were first developed on UNIX, and spread to the Internet. Active Directory on Windows is LDAP and supports Kerberos. On the mainframe, z/OS gives you LDAP and Kerberos for free, and they both work with RACF, ACF2, and TopSecret.
Future articles will explain how LDAP and Kerberos work, and practical implementation suggestions for whichever approach you use.