IT Management

This new column is targeted to security administrators and data security officers, but also will benefit CIOs, auditors, system programmers, and all IT staff. To lay the groundwork for this and future columns, and to help you focus on some of the top concerns in today’s data centers, I’ve listed several questions we may cover here, organized into six categories. I haven’t listed concepts common to all platforms (such as user security awareness), since they’re no different on the mainframe.

1. Access to the system. How do we verify all the paths into the system and know we’ve secured them? When do password syntax rules actually hurt security? Should password rules be the same or different on the mainframe and our desktops? What’s the best way to synchronize userids and passwords across platforms? If someone plugged the Ethernet cable in my office into a PC with a sniffer program, could I learn my neighbor’s mainframe password? How do UNIX System Services and TCP/IP get secured? Can we safely ignore LDAP? Kerberos? How do digital certificates really work and what do I need to do about them? Should I occasionally have lunch with the Active Directory administrator?

2. Access to data sets and resources. How should we protect data on tape, disk, the print queue, MQ queues, and UNIX System Services files? How do we know what resources we need to secure? How do we address residual data (left after a data set is erased) on tape? On disk? When someone downloads sensitive data to his laptop or USB drive, at what point are we no longer responsible for its security? What if we’re still mailing unencrypted tapes to other companies? How should we deal with hardware-encrypting tape drives and managing their encryption keys? Should we be using hardware or software encryption and how and where? What do we need to know about ICSF? About PKI?

3. Access to the network. How do we secure TCP/IP, UDP, and SNA? How do we integrate distributed security with mainframe security? What is System SSL and how do we make it happen? Should we trust the staff configuring TCP/IP daemons (such as FTP, telnet, httpd) not to introduce security holes? How do we secure our connections to other companies’ SNA networks, including Enterprise Extender? How do we protect against SQL injection? If someone connects DB2 and/or MQ to the Internet, who is responsible for making sure it’s secure? Should there be formal change control and security over use of port numbers? What should we do with the SERVAUTH SAF call in RACF, ACF2, and Top Secret?

4. Operating system protection. What does it mean, how does it affect RACF, ACF2, or Top Secret? What should we do about it? What do we need to do in RACF, ACF2, or Top Secret to secure the operating system? How will we know if the system programmers are keeping it secure?  Should system programmers have to use formal change control? Since IBM now makes it possible to sign programs digitally, what should we be doing to take advantage of this? What should we do if the Marketing VP insists on installing his favorite software package even though we have no way of knowing it’s safe? How do we secure started tasks?

5. Organizational issues. Who’s responsible for each of the aforementioned topics? How do we demonstrate the quality of mainframe security? Who really decides who can read the payroll data? Do we want to control who can see which payroll, accounts receivable, or accounts payable records by dollar value? How can we work together with UNIX, TCP/IP, firewall, and Windows staff? Since the regulations require a risk assessment for each application, how can we get a copy of it and benefit from it? How do we get the authority we need? If someone makes a system change (for example, adds new software with system privileges, connects to the Internet, or gives a UNIX System Services program UID 0) without informing the security staff in advance, what should we do?

6. Dealing with auditors. How can we benefit from them without wasting time on them? Why bother “reviewing the violations report”? Why should we listen to them if their comments don’t address the financial audit issues (reliability of the numbers, protection of assets, going concern, compliance)? How do each of these topics relate to the financial issues? How can we take advantage of their software tools?

Do you have a mainframe security topic not listed above that you would like to read about? Email amy@mainframezone.com to get it added to the list.