This article is an excerpt from IBM Mainframe Security: Beyond the Basics  (MC Press, 2013).

Men are only as good as their technical development allows them to be.

—George Orwell

Mainframe security has been around for quite some time. Over the years, installations have realized that some practices, if implemented, will pay security dividends in the long run. In fact, it can be argued that not establishing best practices and not following them is detrimental to overall security and often results in increased security administration costs.

With this in mind, this article presents some of the best practices for IBM mainframe security.

Implement Role-Based Security

In simple terms, role-based security is one where you grant access to groups instead of to individuals. Generally, these groups represent specific job functions at the company.

The employees' access rights are determined not by their user IDs being in the access lists, but by virtue of their being members of certain groups. If a group is in the access list, then the employee automatically will have access because he or she is a member of the group, as shown in Figure 29.1.

To administer security, you simply add and remove people from groups. The only time you have to modify the access list is when a new group is formed or when one is no longer needed.

Figure 29.1: In role-based security, groups rather than individuals are in access lists.

There are several reasons why this model is appealing.

First, you will save on security administration costs. Under this scheme, groups, not individuals, will be in access lists. As people enter and leave various functional groups in your organization, you will not have to add and remove individuals from access lists.

Second, auditing will be easier. User IDs will be grouped according to their roles in the company, and the entire group, representing a role, will be granted access. To find out all users who have access to payroll data, for example, you simply list the group called "PAYROLL".

Last, it will help you in your user ID cloning efforts. Quite often, a request comes in to the security department such as "give the new employee Wayne the same access as that of Patricia." If you have implemented role-based security, all you have to do is list Patricia's user ID and find out what groups she is connected to. Then, you add Wayne to all these groups.

This simple cloning exercise would take much longer if you did not have role-based security. You would have to find out all profiles where Patricia has access and also the level of that access (such as read or update). There might be dozens, or even hundreds, of these profiles. You would then have to grant Wayne exactly the same level of access as Patricia to all these profiles.

Under role-based security, of course, a person is allowed to have more than one role. If that is the case, then that person simply belongs to more than one group.

So, under role-based security, are there any circumstances when you want to allow individual-level access? Yes, there are. Some access can rightly be granted at the individual level. This will happen when you have sensitive or critical data and you want to restrict it to just one or two individuals. In this case, granting access to entire groups would compromise the security of your important data.

When you adopt role-based security, one thing to keep in mind is group memberships. Since access is granted wholesale at the group level, it is assumed users are in the right groups. Otherwise, you are in a situation where the wrong people are getting access via incorrect group memberships.

Periodically De-Clutter Your Security Database

Database clutter is not very different from the physical clutter we collect in our basements and garages. It is an eyesore, gets in the way whenever we want to find something, and does not serve any useful function.

Security database clutter is bound to happen. Groups and user IDs become obsolete. Applications retire, requiring extensive cleanup of obsolete profiles. RACF groups become empty and might not be needed anymore. Employees transfer from one department to another. Departments get reorganized, and entire company divisions are bought and sold, not to mention mergers between companies.

You should regularly evaluate and make sure your security database is clutter-free. Otherwise, you will soon find that a lot of clutter has accumulated and is now unmanageable.

Inactive user IDs should be reviewed and deleted where appropriate. The DSMON Selected User Attribute report shows all user IDs that have been revoked. For more information about this report, refer to chapter 3, "The Data Security Monitor (DSMON)."

Handle Employee Transfers and Terminations as They Occur

In any organization, people come and go. In some organizations, however, when people leave the company, their user IDs remain.

The security database cleanup associated with users being terminated or transferring to new job functions is often neglected. This neglect might go unnoticed for a long time.

There should be a process in place whereby the security department gets notified of all employee transfers and terminations.

If an employee moves on to a new job function, he or she will, over time, request the new access necessary to do the new job function. However, if you do not have a process in place to clean up his or her old access, then that old access will still remain intact.

This situation, if allowed to persist, will not only create the security database clutter mentioned above but also cause security audit concerns, as the person does not need, and should not have, the old access any more. The problem is even worse in the case where the person held special security privileges in the old job.

In the case of employee terminations, make sure all access, and the user ID, is removed from the system. The concern here is that if the user ID inadvertently gets activated, then the access rights of that user ID are at risk of misuse.

Then there is the issue of what to do with the data sets owned by the person who has transferred or who has been terminated. These data sets cannot simply be deleted, as they might contain many years of work. In such cases, the best thing to do is to let the person's manager decide whether to reassign responsibility for the data or to delete it.

While cleanup activities such as these will not win you medals, or even recognition, they are a necessary evil. In the long run, it is in your best interest to keep things clean. Management should recognize this extra activity not as overhead, but as a job function within the security department.

Identify Your Important Data

There are two categories of data that can be designated as important:

• Critical operating system data (and its major components, such as DB2 and CICS)
• Your production data

While the first category is more or less standard across all companies and across all industries, the second category is installation-specific and therefore hard to identify. For example, for an automotive company, data sets containing auto part numbers and their specifications would be termed extremely critical to the business. There might well be legal reasons to guard this data from unauthorized access.

There are many benefits to identifying your important data:

• You can implement better security controls for this data.
• You can plan your disaster recovery exercises to include important data.
• The data owners and custodians will be better able to make access-approval decisions.
• During access reviews, the owners will be able to make intelligent decisions.
• Auditors will know where to focus their audit efforts.
• Security administrators will be able to implement tighter controls and loggings for this data.