Time to Renovate Your IBM i Security?

Image

I did a major home renovation about three years ago, but now a few walls need painting and some accessories should be updated.

These small changes can have a major impact, and the same is true for your IBM i. Sprucing up your security configuration protects your system and your data, as well as making life easier for you and the rest of the IT team. Read on for some ways to freshen up your IBM i.

Suggestions for Auditing Values

If your system is at V7R2, there's a new value I suggest that you add to QAUDLVL: *PTFOPR. It logs the load, apply, and removal of PTFs. It's a handy way to prove to your auditors that you're following your patch (fix) strategy.

Here’s something you can implement even if your system isn't at V7R2. One action auditing value I’ve come to appreciate more is *JOBDTA or the subsetted *JOBBAS. This auditing action logs the start, hold, release, and end of every job.

Many people don't have this value specified in the QAUDLVL system value—for good reason. On a busy system, this value generates overwhelming volumes of entries. So why am I mentioning it? Because I’ve started to specify it at the user level, specifically to track the use of QSECOFR and other IBM-supplied profiles.

It also comes in handy when you're trying to determine how a profile is being used. I've been at clients where we see a "last used date" being updated for a profile, but we can't find the process that's using it. Specifying *JOBBAS for the user action auditing parameter on the change user auditing (CHGUSRAUD) command started logging the job information, and that allowed us to solve the mystery surrounding this particular profile. 

Suggestions for Passwords

Perhaps it's time to freshen up—that is, re-evaluate—the rules you're requiring for IBM i passwords. Some organizations still aren't using the QPWDRULES system value, the system value that consolidates your password rules into one system value.

It also adds many more options. For example, you can specify that, while you require a digit, it can't be the last character. Or that the user profile name can't be contained in the password. Note that once you specify one value for this system value, all of your rules must be defined here. The system starts ignoring the original password composition rule system values when QPWDRULES is changed from its default setting.

Here's a suggestion that might be a bit controversial, but please hear me out. I suggest you change the value of your QPWDLVL (password level) system value. While my ultimate goal is to get all systems running at password level 3—which enables a maximum length of 128 characters, uppercase and lowercase letters, all special characters, numbers, and punctuation—I realize that will probably not happen in my lifetime. So what may be more realistic is to get all systems to at least password level 1.

Password level 1 eliminates a version of the password that’s stored in a very weakly encrypted format. It's the format that had to be used when PCs connected to the NetServer via a file share using Windows 95, 98, or ME, or when a Windows 2000 server connected to the NetServer. Most organizations no longer use this software—or if it's in use, it's not used to connect to the NetServer.

Elimination of this password is the only difference between password level 0 and 1. The maximum length is still 10, and the passwords are limited to A-Z, 0-9, and special characters of #, @, _, and $. However, moving to this higher security level does provide a nice upgrade for your security scheme, eliminating the risk of these weakly encrypted passwords being abused.

Another password-related suggestion is to make use of the system value that became available in V6R1. That's the QPWDCHGBLK (password change block) system value. This system value allows you to specify—in hours—how long between password changes. In other words, it prevents users from repeatedly running the change password (CHGPWD) command to get back to their original password. I recommend a value of 24, meaning users must wait 24 hours (one day) before they can use the CHGPWD command. You can still use the change user profile (CHGUSRPRF) command to change the users' passwords, regardless of the setting of this system value.

I know that updating your password policy can create heavy burden on your IT team with never-ending password reset requests! Consider using a tool like Password Self Help for IBM i to relieve the administrative burden and securely put the control in the hands of your end users.

Suggestions for User Profiles

I have two suggestions for "spiffing up" your user profile configuration.

My first suggestion is for anyone who has defined the group profiles on your system to represent roles, such as administrator, operator, or programmer group. In this situation, I recommend you consider using the owner parameter that comes right after the group profile (GRPPRF) parameter. After you change this parameter to *GRPPRF, any object that one of the members creates (e.g., one of the administrators creates) is going to be owned by the administrator group, rather than the administrators themselves.

Using this strategy makes user profile cleanup significantly easier when one of these users leaves the organization, because they don't own system objects such as *DEVDs, *OUTQs, etc. Note that objects created into the IFS will continue to be owned by the individual.

Secondly, I want to bring your attention to two parameters that were added to the user profile in V7R1. These are user expiration date (USREXPDATE) and user expiration interval (USREXPITV). If you know the position is temporary when you’re creating a profile, you can specify a date or an interval when the system will automatically disable the profile.

This way, you don't have to wait for your process to set the profile to be disabled after the profile has been inactive for a period of time. The profile is disabled as soon as it's no longer used. 

Suggestion for Object Authority

If you have a file that you’ve secured but you have to, on occasion, grant access to a service account or process profile, this suggestion is for you. You’ve probably experienced times when you want to grant authority to the file but, because the file is in use (i.e., locked), your attempt timed out. My suggestion is to create an authorization list and attach it to the file during your next downtime. Once the authorization list is attached, you can always grant authority to the authorization list—even when the file is in use.

Final Thoughts

I'm excited about my upcoming home improvements, and I hope you've found these suggestions for switching up your security configuration just as inspiring.