2. Ensure that each APPLID calls your security software to verify userids and passwords. Make sure no APPLID uses hard-coded lists of userids and passwords, especially vendor-supplied ones.
3. For each path in your network that carries sensitive data, ensure there’s effective encryption, either from the hardware or software.
4. For each possible connection you want to restrict, ensure that needed restrictions are in place. These will often be provided by your VTAM systems programmer; for example, by deactivating cross-domain definitions or by using USSTABs (a VTAM method that can control binds).
5. Use your security software to restrict which users can bind to any sensitive APPLIDs. RACF uses the APPL resource class; ACF2 uses SOURCE definitions, and TopSecret uses FACILITY definitions.
6. Use your security software to prevent any program from spoofing an APPLID. This could allow the program to put up a fake logon screen on someone’s terminal and use it to harvest userids and passwords. VTAM calls the security software in the VTAMAPPL resource class to prevent this, but it provides protection only if the security software has rules in place.
7. Identify the networks your network is connected to; for example, your partners’ networks. These will be called “adjacent networks” and are identified in SYS1.VTAMLST. Identify what networks they’re connected to. Determine what your contract with your partner says about who is liable in the event of security breaches. Ask your VTAM systems programmer what VTAM options and software tools can prevent spoofing of networks. For more information, see “An Often Overlooked Security Hole in SNA Networks” in the April/May 2008 issue of z/Journal.
8. Review protection on the Windows LANs used to sign onto the mainframe. Determine what would prevent someone from installing a sniffer program to learn other users’ mainframe userids and passwords. Encryption isn’t sufficient protection since someone executing a sniffer program could record and play back the logon message without needing to decrypt it. Implementing Kerberos in Windows Active Directory can provide protection over the LAN. Physical protection of the link between the LAN and the OSA would provide further protection.
9. Determine whether the OSA that connects LANs to the mainframe is shared between MVS images. This could permit a user on the test system to access the production system, bypassing any firewall you think is isolating test from production. You will need to review your Hardware Configuration Definition (HCD) and Input/Output Control Program (IOCP) hardware configuration data sets to determine this. (Thanks to David Hayes and Kevin Metcalfe of the U.S. Government Accountability Office for identifying and researching this possible exposure.)
10. Summarize your findings, including any uncontrolled security risks and recommended further protections. Review this with your VTAM systems programmer.
How to Evaluate TCP/IP Security
We’ll show you how to evaluate TCP/IP security first on a single mainframe (MVS image). Our approach is to:
• Identify all the MVS images
• For each MVS image, identify all the TCP/IP stacks
• For each stack, identify the IP addresses and ports that can be used
• Evaluate all related risks and tools available to provide security, including some tools unique to mainframe TCP/IP.
On z/OS, you may have several “stacks” or copies of TCP/IP on each MVS image. To develop a big picture of all the TCP/IP activity, you need to identify all the stacks, and then for each stack, identify the security and control options.
Once you’ve identified the stacks, for each stack you need to review the TCP/IP control file, often called PROFILE.TCPIP. This control file will list the IP addresses, port numbers, hardware devices called OSA that link LANs to VTAM, daemons (started tasks) that are automatically started when TCP/IP starts, and the names of APPLIDs to which Telnet users can request a bind.
In summary, here are the steps to evaluate the TCP/IP part of your network:
1. Map your MVS images, and for each, the IP addresses, port numbers, daemons, and physical connections it uses. You may need your TCP/IP administrator’s assistance in interpreting and verifying this information.
2. Determine what firewalls protect your mainframe TCP/IP network and what techniques they use, such as packet filtering, network address translation, and intrusion detection systems. Include both external firewalls and the policy agent software that provides firewall-like functionality and comes free with mainframe TCP/IP.
3. Summarize the IP addresses used on your mainframe and their names. For example, you might call the IP addresses inside your firewall by one name and the addresses outside your firewall by a different name. Determine whether you need to define these names to the security software to control who can use which IP addresses. Use the SERVAUTH resource class with the security software to accomplish this. The use of RACF, ACF2, or Top Secret to protect IP addresses, ports, and other resources is one advantage that mainframe TCP/IP has over other platforms.
4. Identify what ports are protected and what daemon (application program) is associated with each port. In the PROFILE.TCPIP control file, the RESTRICTLOWPORTS operand can prevent unauthorized programs from opening any of the ports numbered 1-1023. On the PORT and PORTRANGE statements, the RESERVED, DENY, and SAF keywords can prevent use of other ports, or restrict who can use them by means of the security software. Evaluate the risk if an unauthorized program executing on the mainframe were to open a port and start reading and writing over your TCP/IP network. Unless every port is restricted or protected, this may be a risk you want to minimize. You may decide to implement formal change control, only permitting a program to open a port to which the program has been approved.
5. Evaluate each daemon (a program dedicated to one application and usually to one port number). Each daemon is an MVS started task. Each is assigned a userid and may have privileges in the security software or superuser privilege in UNIX System Services. Each will have its own JCL and often its own control file specifying security options. Most daemons will be defined in the PROFILE.TCPIP control file, but a few, such as Telnet, will be defined in the /etc/inetd.conf control file for UNIX System Services. Ensure that daemons don’t have security software privileges nor root privilege in UNIX System Services unless there’s a clear reason (such as IBM documentation) to do so.
6. For each daemon, determine whether it needs encryption to protect sensitive data over the network. Most daemons can easily activate system Secure Sockets Layer (SSL) or Kerberos on MVS if directed by control options.
7. For each daemon, determine how it establishes users’ identities. Many will rely on userids and passwords, some on other means. Some may permit anonymous logins. Some (such as the httpd daemon) will assign userids on the basis of matching filenames to directives in their control file. A few, which should seldom be used, such as Trivial File Transport Protocol (TFTP), always permit anonymous logins.
8. For Telnet (remote login) connections, determine which APPLIDs Telnet users can bind to. This is a little-understood gray area between VTAM and TCP/IP. The ALLOWAPPL operand of the PROFILE.TCPIP control file specifies which APPLIDs a user can bind to by connecting through Telnet. The default value is *, which means any APPLID, which could make it possible for anyone on the Internet to bind to any APPLID on your system. This risk is greatly reduced if every APPLID calls the security software to verify userids and passwords. It’s also greatly reduced if firewalls or the security software can restrict who can connect to the Telnet port.
9. Note that the FTP daemon supports functions beyond uploading and downloading both UNIX System Services and MVS data sets. Depending on control file options, it can permit submission of batch jobs, operator commands, access to print files on the print queue, and access to DB2 data. Most of these functions can be secured with security software.
10. Ensure that the files and data sets containing programs, JCL, and control information are protected with security software and reasonable change control.
11. Summarize your findings, including any uncontrolled security risks and recommended further protections. Review this with your TCP/IP administrator and VTAM systems programmer.
Mainframe computers with z/OS will continue to use both SNA and TCP/IP for telecommunications. The tools are easily available to make them both secure. To keep them secure, managers will need to be sure that all security exposures are evaluated and that reasonable, practical protection is implemented as needed.