How well do we secure access to the system? This includes how users are identified and how these users are restricted from system access. We’ll skip considerations not unique to z/OS, such as physical access control. Here are some mainframe-specific considerations with recommendations for you to address them:
1. You need to know your security software (RACF, CA ACF2, or CA Top Secret) controls every path into your system. Paths include TSO, batch, started tasks, CICS, UNIX System Services (USS), TCP/IP, User Datagram Protocol (UDP), the various programs talking over TCP/IP and UDP, Remote Job Entry (RJE), Network Job Entry (NJE), Advanced Peer-to-Peer Networking (APPN), and other applids. (Think of an applid as any program that has a sign-on screen.)
If you have a path into your system that isn’t controlled by your security software, imagine this scenario: A knowledgeable programmer is fired for just cause. Your security staff revokes, suspends, or deletes the programmer’s userid in the security software. However, if there’s some path into your system that has its own hard-coded list of userids and passwords, you may now have a disgruntled, knowledgeable, former employee who’s working for your competitor and is able to access your system.
You will want to ask your security staff to ensure the security software completely controls every path into the system. Ask them to meet with the VTAM and JES systems programmers to identify all the paths into the system (starting with the aforementioned list) and discuss how each is controlled by the security software. Institute a policy requiring every applid to identify users by means of the security software (and not by hard-coded lists of userids and passwords).
2. Most online users sign on to a Windows Local Area Network (LAN) to log onto the mainframe. LANs carry the risk that someone is running a sniffer program on them to learn everyone’s userid and password, including mainframe userids and passwords. Encryption alone won’t protect against this. But Windows has a feature called Kerberos (the mainframe supports it, too) that protects against sniffer programs. You want to ensure that every Windows LAN has Active Directory implemented with Kerberos, both to prove users’ identities and to provide encryption of the session data. (This will affect PCI compliance, too, since if credit card numbers are entered into the mainframe from a Windows LAN, you will want to prevent sniffer programs from seeing the numbers.)
3. CICS regions have their own access control considerations. For example, each CICS region has a default userid it uses for all security questions when it doesn’t have a signed-on userid. If this userid is permitted to access some sensitive transaction (it shouldn’t be, and it shouldn’t have privileges in the security software), then anyone who can get his terminal to connect to that region can execute that transaction. You want to ensure the default userids are permitted only to trivial transactions such as your sign-on transaction. (Note that, depending on settings in VTAM and TCP/IP, people can connect their terminals to a CICS region from a dial-in modem in the data center and/or over the Internet from anywhere in the world.)
CICS transactions can generate batch job control language and cause CICS to submit it to JES for execution. If the JOB card doesn’t specify the userid with a USER= parameter, then the batch job will inherit the userid of the CICS region, which may have more access rights than the batch job should have. You will want to ask your security staff to minimize the access privileges of the CICS region userids. They should also consider features in the security software (such as PROPCNTL in RACF) that restrict such userid inheritance.
4. TCP/IP presents several security issues: FTP can be configured to permit anonymous connections. Note that FTP can also be configured to permit submission of batch jobs, access to printouts on the print queue, operator commands, and access to DB2. This is all controlled by the FTP configuration file. CICS, DB2, and WebSphere MQ can connect to TCP/IP in a variety of ways, some of which lose the identity of the user. TN3270 users can connect to applids unless you restrict them with an operand in the TCP/IP control file. (A more comprehensive discussion of TCP/IP security and the tools IBM gives us to secure TCP and UDP will be covered in a future column.) You will want to have formal change control over the configuration files, programs, and job control language for TCP/IP and all of its daemons and servers.
Future columns will describe additional system access control topics, including password management, VM machines with Linux guests, and network security, both TCP/IP and SNA.