Mainframe Security Best Practices
It’s worth the time and effort to develop security habits
4/8/2015 12:30:01 AM |
By Dinesh D. Dattani
Editor’s note: This article contains excerpts from the book “IBM Mainframe Security: Beyond the Basics—A Practical Guide from a z/OS and RACF Perspective” by Dinesh D. Dattani (MC Press, 2013).
Men are only as good as their technical development allows them to be.
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, the following presents some of the best practices for 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 1.
Figure 1: Employees Gain Security Access Via Groups
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.
There are several reasons why this model is appealing, including:
- 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.
- 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.”
- 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 free of clutter. Otherwise, you will soon find yourself with a very large clutter that has accumulated and is now unmanageable.
Inactive user IDs should be reviewed and deleted where appropriate. The Data Security Monitor Selected User Attribute report shows all user IDs that have been revoked.
Employee Transfers and Terminations
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 will 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 OS 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, including:
Assign Ownership to All 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.
All data, especially the company’s mission-critical data, must have an owner (or a custodian). Such a setup is useful in many ways, including:
Conduct Periodic Reviews
- 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.
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 earlier, 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.
At least once a year you should review the various pieces of information in the security database, which are:
Implement Change Management
- Special privileges granted to user IDs
- All access rights
- User IDs
- Group memberships
- RACF profiles
Production job control language (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 JCL:
Report and Monitor Security Activities
- Has been tested. Otherwise, unexpected failures will affect the timely production of your critical reports.
- Has been approved by management.
- Runs under a production batch ID, and not a test ID or a personal user ID. If a personal user ID runs production JCL, what happens when the person leaves?
- 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?
- Follows corporate standards and naming conventions.
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 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:
Implement Segregation of Duties
- 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. You should keep an eye on these access violations to see if a pattern is emerging.
- Access 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.
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.
A Better Job
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.
Dinesh D. Dattani is a mainframe security consultant residing in Toronto.