Remember when you were a kid and your mom asked you to clean your room? Didn’t it seem like a waste of time? After all, it was just going to get dirty again. Keeping it clean required effort; effort you could have used instead to play. As you got older, however, you began to understand why it was important to keep a clean room. It allowed you to organize your things better, move around your room with ease and find things more easily.
Now that you’re a security administrator, you have a similar responsibility to keep your security database clean and not “cluttered” with unnecessary information. As a starting point, ask yourself these questions:
• Do you remove user accounts that haven’t been accessed in more than a year?
• Do you have guidelines to remove unused entitlements from users?
• When users change job roles, do they lose their old entitlements or are you asked to have them certified for their new role?
• Do terminated employees have all their accounts removed as soon as their term date is entered into the Human Resources (HR) system?
If you answered no to any of these questions, then you may be a security database hoarder. Read on to see how to cure yourself of this aliment.
Here, when we talk about security databases, we’re mostly referring to the databases used by security products that secure the IBM z/OS mainframe. The reasoning and techniques described here can be used by any security database that controls authentication and entitlements. On the z/OS system, there are many advanced logging facilities and add-on software that allow for accurate usage tracking of user IDs and entitlements. This makes it the perfect system to implement an automated cleanup of your security database.
When you take on this project, you must first understand and believe in the benefits of having a clean security database. It goes without saying why it’s logical to remove all access from users who no longer are employed at the company. What many administrators and senior managers don’t understand is why you want to take access away from active employees. After all, they may need the access one day, right? In most cases, users who haven’t exercised their entitlements in 13 months don’t need these entitlements to conduct their job functions. If you have a proper workflow in place for entitlement requests, then it shouldn’t be an issue for the user to regain access if it’s needed again.
Implementing an automated solution for removing unused entitlements is the best security policy you can implement. This will allow you to pass audits with greater ease and confidence. In addition, there are many performance benefits you can gain by keeping a clean database. Not loading stale information every time the system wants to make a security check may not seem like it will save a lot of memory or CPU cycles, but when you consider that a busy system could make 1 billion security calls a week, those savings add up.
To successfully deploy an automated cleanup strategy, you must first prove that you can remove unused user IDs and entitlements without affecting the daily operations of the company. If successfully deployed, it should be transparent to all end users. There are three main z/OS security software solutions that z/OS users rely on: IBM RACF, CA ACF2 and CA Top Secret. All three have logging facilities that either use the z/OS SMF logs or the security product’s own logging data sets. While in theory this data could be used to create a database of security usage, it isn’t recommended for companies with a user base greater than 1,000 people. The data created would be enormous, the system resource usage would be high and it could be a big programming effort to sort though all that data. Most of the top vendors for z/OS offer a software solution that’s designed specifically for security cleanup. These products hook into the System Authorization Facility (SAF) and your Enterprise Security Manager (ESM) to monitor all security transactions being conducted. Because of the hooks these products have into the system, their resource usage is low, even in a heavily used system.
Once you have your data collection process in place, you will have to do one of the hardest things in this project ... wait. The biggest problem when you first turn on your data collection is that you won’t have any data. You have to wait and collect data as the system is used for its daily activities. The databases you’re using should be keeping track of every time a user is granted access via an entitlement on their ID. This will tell you what permissions, profiles and groups they’re using for their job. The rest are stale entitlements that should be cleaned up. In order to not make any mistakes, you want to ensure each user has had the opportunity to conduct all their job functions. Sometimes users will perform an activity on a quarterly or yearly basis, so you want to make sure you capture that activity. Having this database record for at least a year before taking any cleanup actions against your database can be extremely beneficial.
While you’re collecting the data, you will have plenty of work to keep you busy before you start doing the cleanup. You will need to set up the batch processes that will run each month to collect the list of users and entitlements that are now aged to the point of being eligible for cleanup. When you first deploy the cleanup, you could have years’ worth of unused entitlements to remove. After that first cleanup is complete, however, the number of items to clean up on the next run should be much smaller, as these are the users who didn’t meet the criteria last month but are now eligible after another month has passed.
The batch process you implement should contain a notification system that has been approved by your management. People can be given the opportunity to keep their IDs by using them. Exercising the ID on the system by logging on will remove them from the list. One suggestion is to send out an email at the beginning of the month, letting users know their IDs will expire at the end of the month. Then at the end of the month, unused IDs will be suspended in preparation for removal from the system. You should also have safeguards in place so you can quickly restore access in case something goes wrong. The reverse commands should be ready to be processed, and the support personnel should know where to find the commands if they need to execute them.
You will also want to put in place metrics that show how this cleanup process is controlling your company’s user population and entitlement access. Take a snapshot of your security database before you start the cleanup; this will be used as a baseline for your metrics. In addition, you should be working with your system performance people to gauge how the cleanup is affecting system response time. They should be able to look at your security manager software to see how much less CPU and memory are being used to perform tasks. They should also be able to look at CICS transactions, for example, to see how the response time is being affected. Then, every month as the cleanup runs, you can show the progress the system is making in keeping things clean. This makes great documentation for auditors as well.
One of the biggest hurdles you will have to overcome with this project is convincing non-security people that this project is worthwhile and won’t disrupt business activity. If your company has numerous regulatory obligations, it could be an easier sell to senior management. Most people won’t want to give up their access even if they haven’t used it in 10 years. This is why it’s imperative you get senior management buy-in for this project across all departments in your company.
Hopefully, this has inspired you to start your own entitlement cleanup strategy. It will take some time to fully implement this process, and it will take some convincing that this is a worthwhile effort. You will have to be patient as you collect data and test the accuracy of the reports and commands you’re executing. Once you’re done, however, you will find that the results were well worth the effort.