With the widespread use of mainframes today, it is absolutely necessary that they have excellent security. They are widely used by banks, credit card companies, government entities, government contractors, and nearly all other large organizations. Everyday millions of transactions pass through mainframes; with poor security, this can lead to the loss of massive amounts of money and data. Mainframe security is a must for business continuity and has continuously evolved over the years to where it is today. When the mainframe became more networked with other devices and connected to end users on computers other than the original “dumb terminal,” its security really broadened as the traditional physical security was no longer enough.

This article will introduce several security concepts in use on the mainframe. These topics will continue to be expanded upon along with new topics in future posts to come.

“Security Though Obscurity”

As defined by Wikipedia, the phrase, “security through obscurity”, is defined as, “a pejorative referring to a principle in security engineering, which attempts to use secrecy of design or implementation to provide security.” While the functionality and design of a mainframe are not kept secret, not many people are well versed in them. There is enough of a knowledge gap between typical Windows or Linux workstations/servers and System Z to consider this a minor form of security that exists in the world of mainframes. One must first learn an entirely new set of terminology (even a file is called a “dataset”). Next one has to become familiar with the architecture and operating system(s) unique to the mainframe to finally begin searching for vulnerabilities. And all of this typically must be done without much access to an actual mainframe, unless of course you happen to have a few hundred thousand dollars to spend on one.

Secure by Design

However, System Z certainly does not rely on obscurity as its main source of security. In fact, System Z holds the highest security rating/classification for any commercially available server – with the Common Criteria Evaluation Assurance Level 5 (EAL5) awarded by the International Standards Organization (ISO). Check out the Wikipedia page to read more on Evaluation Assurance Levels. As you will read in the rest of the article, and in future articles, System Z is certainly not lacking in security and has yet to have a major security breach.

Security Software – IBM Security Server and RACF

RACF, or Resource Access Control Facility, is one of several software add-on security products available for the mainframe’s base IBM Security Server component. The two other main competitors are ACF2 and Top Secret; these are both produced by CA Technologies, Inc. This article will focus on the base IBM Security Server, commonly referred to by its most well-known component, RACF.

The following is a list and brief description of the components that make up the IBM Security Server:

• DCE Security Server: Provides a fully functional OSF Distributed Computing Environment (DCE) that runs on z/OS. 
• Lightweight Directory Access Protocol (LDAP) Server: This server is based on a client/server model that provides client access to an LDAP server. This provides an easy way to maintain directory information in a central location for storage, update, retrieval, and exchange. 
• z/OS Firewall Technologies: This is an IPv4/IPv6 network security firewall program for z/OS. This allows the mainframe to be safely connected to the internet without any intervening hardware.
• Network Authentication Service for z/OS: This provides Kerberos security service without the need to purchase or use a middleware product such as a DCE. 
• Enterprise Identity Mapping (EIM): Provides a method to manage multiple user registries and user identities in an enterprise setting. 
• PKI Services: This service provides the ability to set up a public key infrastructure as well as serve as a certificate authority for both internal and external users. Using this, you can issue digital certificates using your company’s security policies. 

We will go into more detail on the final part of the security server, RACF.

RACF is an add-on software product that provides access control on the mainframe. It controls nearly everything security related on the mainframe and decides what users can use, change, or view. RACF stores all the information about users in its database. This information about users, resources, and access authorities is maintained in structures called profiles within this database. Additionally, RACF holds information on login times, password hashes, and password expirees.

RACF allows you to do the following in order to accomplish access control:

• Identify and authenticate users 
• Authorize users to access protected resources 
• Log and report various attempts of unauthorized access to protected resources 
• Control the means of access to resources 
• Allow applications to use the RACF macros 

Using RACF, administrators are able to set very specific rules on the password policy. This includes minimum length, lack of repeating characters, lack of adjacent characters on the keyboard, and the use of numeric or capital letters. It can even get as detailed as having a rule that requires, for example, the 5th character to be an uppercase letter. Passwords on the mainframe are able to contain upper/lowercase letters, numeric values, and the symbols #, $, and @. One thing you may find surprising about passwords on the mainframe is that they are typically limited to just 7 characters. However, what made this secure on the mainframe system I was learning on last spring was that RACF locked out the account after 3 failed login attempts – I learned this the hard way.

The following picture shows a RACF logon screen for a RACF defined user.

And here is an error message you would receive after entering an incorrect password.

Additionally, RACF will tell you if the user name you entered is not a valid RACF user. In the picture below I tried logging in with the user “ALEXB”, which does not exist. The security implication with this, as demonstrated in the video at the end of this post, is that it allows you enumerate all existing RACF users.

So where is all this RACF information stored? Well, it can be located anywhere on the mainframe. To find it, simply use the RVARY command.

On this system, the primary RACF database is stored in the SYS1.RACFPRM1 dataset and a backup is stored in SYS1.RACFBCK1. Changes to the RACF database are written to both these datasets simultaneously. Therefore, the backup is for hardware failure and not user error. Due to the contents of these files, permission to even read these datasets needs to be very limited.

If you are interested in how RACF progressed over the years since September 1976 when it first came out, check out the link to the history of RACF located in the resources section of this article.

Additionally, I would highly recommend checking out this video of a presentation by Phil Young given at BSides Las Vegas 2012. It includes a lot of the RACF information found in this article and points out that mainframe skills are very valuable in the security consulting industry. He also identifies several potential security vulnerabilities present on System Z. I talked with Phil briefly and one thing he pointed out is that not too many people are really looking for these kinds of vulnerabilities on mainframes. Typically, at many companies, the security staff is not poking around on the mainframe asking “can I do this” or “what will happen if I do this.” Usually, only the specific mainframe security staff is even allowed near the mainframe and the rest of the IT security staff do not have anything to do with it. However, one major reason for the lack of poking around is simply because the mainframe is usually the heart of the company’s IT infrastructure and they cannot afford any accidents to occur on the system. Though as more people begin to research into mainframe security and more tools begin to increase their support for mainframe systems, time will tell whether the security or the obscurity is a larger player in the lack of vulnerabilities on mainframes. But for the time being, it does not get much more secure than System Z.

Resources:

• Evaluation Assurance Levels: https://en.wikipedia.org/wiki/Evaluation_Assurance_Level
• RACF History: http://www-03.ibm.com/systems/z/os/zos/features/racf/racfhist.html
• RACF-L Mailing List: http://www.listserv.uga.edu/archives/racf-l.html
• IBM Introduction to the New Mainframe: Security Redbook: http://www.redbooks.ibm.com/abstracts/sg246776.html
• Mainframe Basics for Security Professionals: This is a mainframe security book mainly focused on RACF which I am planning to purchase and post about in future articles: http://www.amazon.com/Mainframe-Basics-Security-Professionals-Getting/dp/0131738569
• IBM Page on System Z Security Advantages: http://www-03.ibm.com/systems/z/advantages/security/index.html

About the Author

Alex Belcher

Alex is currently a student at the Rochester Institute of Technology pursuing a B.S. in Information Security and Forensics with a minor in Computer Science. He works with the school’s ITS Department with Network Communications as a Communications Specialist Assistant and with Distributed Support Services as a Lab Assistant. Additionally, he assists with his high school marching band during summers. During his first year at RIT, he took a Large Scale Computing Seminar; this was his first exposure to mainframe computing and he is interested in further research on the topic.