This article is an excerpt from IBM Mainframe Security: Beyond the Basics.

"Security Best Practices, Part 1" presented several best practices for IBM mainframe security, including implementing role-based security, de-cluttering your security database, handling employee transitions appropriately, and identifying your important data. In this article, we continue the discussion with a look at some additional best practices for IBM mainframe security.

Assign Ownership to All Data

All data, especially the company's mission-critical data, must have an owner (or a custodian). Such a setup is useful in many ways:

• For access approval purposes, the security department knows where to go for approvals. The owners can make informed decisions, as they know their data the best.
• If there are discrepancies in access rights, then you can go to the owner for clarification purposes.
• The owner can make appropriate decisions about data backup requirements for recovery and disaster recovery purposes.

Various compliance legislations require the company to have ownership of at least the production data.

Keep All Security Within RACF

Chapter 25, "Security Architecture," discussed the benefits of having external security. In our case, this is RACF. It is recommended that, as far as possible, RACF be utilized as the security repository.

Some products provide the choice to implement either internal security or external security. Whenever there is a choice, it should be company policy to always select the latter.

There might be a few exceptions. Some applications, developed in-house or purchased from outside vendors, might offer only internal security. The application security requirements might be at the field level, and the whole process might be so customized that it makes sense to leave it up to the application group to manage their own security. This should be an exception rather than the rule, however.

Log Accesses to Important Data

The best practice of identifying all your important data was mentioned earlier in this chapter. If that is done, then implementing logging for important data is easy. These logs are invaluable for a number of reasons, among them the need to comply with corporate and regulatory standards.

Conduct Periodic Reviews of All Access Rights

A periodic review of all security definitions is essential to verify their continued applicability. This will give you a greater comfort level about your mainframe security.

For example, in the role-based security model discussed in Part 1, members of a group automatically get certain access rights. It follows that if group membership is not periodically reviewed, then it is possible that wrong individuals have access to some data.

This activity is often overlooked, for the simple reason that it is not urgent and the staff is busy doing daily security administration. To alleviate the workload on the security department, it is suggested that the review occur on a staggered basis.

Periodically—at least once a year—you should review the various pieces of information in the security database:

• Special privileges granted to user IDs
• All access rights
• User IDs
• Group memberships
• RACF profiles

Implement Change Management for Production JCL

Production JCL is what ultimately generates all those reports that are critical to the survival of corporations. Any changes, additions, or deletions to production JCL must go through a change-management process whereby the JCL is examined before being put into production.

This JCL resides in one or more designated procedure libraries at the installation. Before it goes into production, make sure the following is true:

• The JCL has been tested. Otherwise, unexpected failures will affect the timely production of your critical reports.
• The JCL has been approved by management.
• The JCL runs under a production batch ID, not a test ID or a personal user ID. If a personal user ID runs production JCL, what happens when the person leaves?
• The JCL does not reference any personal data sets. If it does, then changes made to the personal data sets can cause integrity issues. Also, what happens if the person leaves?
• The JCL follows corporate standards and naming conventions.

Report and Monitor Security Activities

In chapter 4, "Security Event Logging and Auditing," we saw the various logging capabilities that RACF provides and learned the importance of such logging. This logging is meaningless, however, unless you produce meaningful reports and monitor the security activities. (Of course, some logging is done for posterity, in case the need arises to find out what happened in the past.)

With regular monitoring, the security department becomes familiar with access patterns and is better able to fine-tune the security definitions that are in place. Also, if the user community is aware that monitoring is being done regularly, then there is less likelihood that someone will engage in fraudulent activity. It is like those traffic cameras randomly installed at key city intersections; just knowing that there might be one at the next intersection reduces the chances of motorists running red lights.

On a regular basis, you should produce reports and monitor the following:

• Activities carried out by means of special privileges—This includes all RACF security definition changes. This monitoring will ensure special powers are not abused.
• Invalid logon attempts—These are mostly a result of invalid passwords having been entered at logon time. You are looking for patterns that might tell you, for example, if someone is trying to use (or guess) someone else's password.
• Security violations—Inevitably, users try to access data they are not supposed to be accessing, and RACF fails the attempt. Even though the access attempt has failed, you should still keep an eye on these access violations to see if a pattern is emerging. For example, if you notice that a user ID is consistently failing on access attempts to your payroll master file, this should raise a red flag.
• Accesses to important data—In rare cases, for very important data, you might have set up logging even for successful accesses. These accesses need to be monitored to ensure the access was in line with the person's job function.

Implement Segregation of Duties

The principle of segregation of duties means that no individual should have multiple special privileges, such that the individual is able to carry out unauthorized activities and later cover his or her tracks by using special privileges.

In terms of job functions, segregation of duties implies that multiple sensitive functions should not be carried out by the same individual. For example, the person administering security by means of the RACF special privilege should not also be the one to review the report on special privilege activities. These two functions should be segregated.

Require Approval Before Granting Access

When there is a request to grant access, the security department is in no position to make a judgment call as to whether the request is in line with company policy. Security administrators are the ones who should be granting the access, but only after the owner (or custodian) of that piece of data has approved the request. The owners are in the best position to make judgment calls on data they own.

Summary

If you adopt and implement security best practices at your organization, then the whole task of securing your company's business data becomes much easier. You will also be better prepared to meet with auditors and compliance monitors.