Carol Woodbury's IBM i Security Tip - MAR 2009

I agree that it's significantly more convenient to do your job when you don't have to worry about authority issues. Often by habit we sign on with a profile that has all special authorities (such as QSECOFR) rather than signing on with our own or a less-powerful profile. We're also the ones that couldn't be bothered with changing our passwords to something new so we set the password expiration parameter in our user profiles to *NOMAX. Why do we do this? Because it makes our life easier. Or does it?

Vendors signing to their clients' systems to administer their application almost always insist on having *ALLOBJ. They usually don't need *ALLOBJ but they insist on it because - altogether now - it's more convenient.

For all of you with *ALLOBJ - which one of you hasn't scrambled to clean up after yourself after accidentally deleting a program, clearing the wrong file, ending TCP/IP or powering down the system? Accidents are one thing - breaches are another. What will be the recourse if the unthinkable happens and the organization experiences a breach? Do you want to be one of those who insisted on having *ALLOBJ or never disciplined yourself to use your own profile instead of QSECOFR and now are in a position of having to prove that you weren't the one that changed the configuration that let the disgruntled employee download the HR master file?

While we may think we're saving ourselves time by using an all-powerful profile and by never changing our passwords, in the long run we could easily be bringing upon ourselves significantly more grief than getting rid of *ALLOBJ or changing our password regularly has ever caused us. In a recent study from the Ponemon Institute, insider threats are rising. Other studies link the rise in insider threats to the downturn in the economy. Now is not the time to insist on convenience. Now is the time to insist on being compliant with all security policies and requirements.

Here are some of ways to reduce your exposure.

I Need the Power
I wish I had a $1.00 for every time someone said to me, "But I have to have *ALLOBJ to do my job." Now it's true that some functions in i5/OS do require *ALLOBJ. But those functions are typically performed by security or system administrators - not by operators or programmers. On the rare occasion that an operator runs a task requiring *ALLOBJ (such as to specify the Allow object differences attribute on a restore) a CL program can be written that accomplishes the task and is owned by a profile that has *ALLOBJ and that adopts this owner's authority. While the Help Desk needs to re-enable profiles and re-set passwords they, too, can use a CL program that is owned by a profile with *ALLOBJ and *SECADM and adopts this authority to work with these profiles. Finally, in working with programmers, it's usually a matter of granting authority to some restricted commands (such as the Start Debug (STRDBG) command) rather than actually performing functions that (literally) require *ALLOBJ.

But I really do need the Power - Monitoring Ourselves
If you are an Administrator or Security Officer, there are many tasks that require *ALLOBJ to be assigned to your profile. Much of the time, when I'm assisting our clients, the tasks I'm completing require that my profile have *ALLOBJ special authority. When this happens, if they don't already have a policy that requires it, I request that auditing be turned on for my profile. Why? So that there's an undisputable log of all of the activities that I have performed. If there's ever a question, we can go back to the audit journal to see exactly what occurred.

Turning on auditing for profiles that have *ALLOBJ special authority is a good practice. You may also want to enable auditing on other profiles such as those with *SECADM or *SERVICE special authorities To enable auditing for an individual, run the Change User Auditing (CHGUSRAUD) command, specifying (at least) *CMD for the User action auditing parameter. This causes all commands typed from a command line or run from a CL program to be logged in the audit journal.

As an administrator, regardless of the organization's security policy, I'd enable auditing on my own profile as well as any other profile that has *ALLOBJ. I'd also change my password expiration interval to be no more than 30 days.