Carol discusses the areas of IBM i security that, when ignored, may cause your system or data to be exposed.

Summer’s over (sad face), kids are going back to school, and your commute has increased because traffic has increased. All these signal that it’s time to get back into your normal routine. What does that mean for IBM i security, and what’s the danger of not following that routine? Let’s take a look.

Many of you have put a lot of work into getting your IBM i security configuration into a secure state. And, for some, it’s a work in progress. But unless you regularly review some of the settings, all of your hard work may be for naught. Unless you pay attention to them on a regular basis, configurations erode over time. So the data that you thought was secure isn’t, and users have more authority than what you intended. Below are real examples in which I’ve helped our clients put back configurations that have been ignored for a period of time.

Default Passwords

Most organizations have processes in place so that profiles are no longer created with a default password. But that’s assuming that all profiles are created by going through the proper process. What I see happening is an over-zealous administrator who wants to “help”—typically, a developer—and creates a profile on their own without using established procedures. What often occurs are default passwords. Worse, these profiles are often used for testing new technology or connections. And the tests are run with the profile having a default password. Then, when it’s time to move the process into production, no one wants to change the password and have to re-test. If you check for default passwords regularly, you should be able to catch the error and get the password changed before it’s moved into production.

Profiles with Non-Expiring Passwords

While it’s acceptable for service accounts to be configured so that their password doesn’t change (that is, a non-expiring password), it’s never appropriate for a person to have a non-expiring password. The list of profiles with non-expiring passwords needs to be reviewed regularly to catch any situation in which the profile creation process has gone a bit sideways and, instead of creating only service accounts with a non-expiring password, the same template is used for all user profile creation. In this real-world example, this situation wasn’t caught until we did a risk assessment for the client, which includes reviewing the list of profiles with non-expiring passwords. Imagine our client’s surprise when the list contained three times the number of profiles it should have.

Members of Group Profiles

I have so many examples of group profile membership not being reviewed regularly that it was hard to choose the best example! The primary reason group profiles should be reviewed regularly is to find the list of profiles that have moved to another part of the business. You receive requests to add users to a new group because of a new role, but how often do you receive a request to remove them from a group? Rarely, if ever. Unless you review group membership, you’ll be like our client who has one group with members from literally every department of the organization rather than only members of the one specific department for which it was created. This group profile owns data from all over the organization, and that data can be accessed by every member of the group. Untangling this quagmire is going to take significant time.

Users with Special Authorities

Most organizations have assigned more special authorities to users than is required for their role. That often occurs because profiles are copied from existing profiles that have been granted the special authority at some time in the past. I’m not talking about that scenario. I’m talking about the scenario where a profile is given a special authority—typically, *ALLOBJ—that’s supposed to be temporary. The scenario I see most often is one in which someone is given a temporary assignment—often a developer or engineer who is helping with a short-term project, such as an application or operating system upgrade. The intent is to give them the authority to do the job and then remove that authority when the project is complete. But unless the list of users who have been granted special authorities is reviewed periodically, it’s rare that the “temporary” authority is removed. Why? Because the administrator who granted it has forgotten and moved on to another project. Not reviewing the current list of users with special authorities caused an audit issue for one organization. They approved the assignments of special authorities but never reviewed the full list; therefore, they never caught the scenario I just described.

Inactive Profiles

Leaving profiles on a system when they’ve been inactive for a long time is a pet peeve of mine. To me, if a profile hasn’t been used in 180 days, it doesn’t need to be on the system. But I understand that there may be regulatory or other requirements one has to take into consideration that will cause inactive profiles to remain on a system. What I don’t understand, however, is when profiles remain on System A simply because they are active on System B. Let me explain. Some organizations have a “shotgun” approach to creating profiles. Rather than attempt to determine which partitions a user needs access to, a profile is created on all partitions. The delete policy then usually follows the create policy. If a profile is required on one partition, it’s left on all of them. This approach leads to profiles being able to access partitions for which they have no business requirement, and, to me, that’s an unnecessary risk to the data residing on those partitions. We’re helping one client clean up this exact situation and are about to delete 100 profiles that are on one partition but they either never had a requirement to access the partition or no longer have the requirement. Reviewing inactive profiles on each partition and removing them (or at least setting them to STATUS(*DISABLED) and PASSWORD(*NONE)) ensures that only users with a business requirement are accessing the system.

Authorities to Authorization Lists

When authorization lists are first configured, most administrators take great care to ensure the correct authorities are assigned—that is, only the users who need access are assigned and only with the authority required. What I find is that authorities are added or the *PUBLIC authority is changed. When investigating how/why this has occurred, it’s usually because someone is trying to debug a problem and assumes that security is the cause. I often find the end users’ group profile to the list with *ALL authority or *PUBLIC authority has been changed from *EXCLUDE to *ALL. Unfortunately, when they discover that security isn’t the issue, they forget (or don’t care) about setting the authority back to its original value. Once again, we often uncover these changes when we do a risk assessment, but most of our clients only do an annual risk assessment. That means their data has been potentially exposed for most of the past year.

Summary

I’ve written this article with the hope that you can learn from others’ experiences and will be motivated to review your own security configuration settings—better yet, that you’ll be motivated into a routine of regularly reviewing these settings to reduce the risk of exposing your system and its data.