Carol provides suggestions for ways you can "spruce up" your security configuration.

I've been in my house for a while now, and I'm looking around and thinking that it's time for a little redecorating. I did a major renovation about three years ago, but now some walls need to be painted and I need to switch out some accessories. My problem is that I can never come up with the ideas myself. I always need to look through some home decorating magazines first. So just in case you're in the mood to redecorate your IBM i, here are some suggestions for freshening up the décor of your security configuration.

Suggestions for Auditing Values

If your system is at V7R2, there's a new value I suggest that you add to QAUDLVL—that's *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.

You can take advantage of this next suggestion even if your system isn't at V7R2. One action auditing value that I have come to appreciate more is *JOBDTA or the subsetted *JOBBAS. This auditing action logs the start, hold, release, and end of every job. Now 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 have 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 passwords. Some organizations still aren't using the QPWDRULES system value. This system value 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 that you change the value of your QPWDLVL (password level) system value. While my ultimate goal is to get all systems to be running at password level 3—which enables a maximum length of 128, 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 is 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 "facelift" 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 that users must wait 24 hours (one day) before they can use the CHGPWD command. Note: You can still use the Change User Profile (CHGUSRPRF) command to change the users' passwords, regardless of the setting of this system value.

Suggestions for User Profiles

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

My first suggestion is for those of you who have defined the group profiles on your system to represent roles, such as an administrator, operator, or programmer group. In this situation, I recommend that 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, when you are creating a profile, you know that the position is temporary, you can create the profile and 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 have secured but you have to, on occasion, grant access to a service account or process profile, this suggestion is for you. You have 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 getting new carpet, painting a couple of walls, and switching out some pictures, using some ideas I've gotten from HGTV. I hope that you've found these suggestions for switching up your security décor just as inspiring.