IBM i Security Best Practices

Q: With all of the security breaches in the news, how do I ensure I’m following secure practices with my IBM i?

For the most part, IBM i is secure out of the box. However, we often see that administrators, or worse, third-party products, make changes to the system that open it up to greater risk.

First and foremost, the company must have a well-defined security policy. This doesn’t mean that they have a Windows* policy that is then twisted to the IBM i. Rather, the security policy should be written in platform agnostic terms and include, either in-line or in an appendix, platform-specific implementation methods to meet those standards.

The heart of security on IBM i is our version of the “three-legged stool” or “fire triangle”—three parts where if any one fails, the entire model collapses. For IBM i, those three items are the user profiles, object authorities and system values.

The most common issue with user profiles is granting special authorities too frequently. Special authorities are meant to be special—restricted to the true system administrators. We often see job control and spool control granted to almost all of the users on a system.

In addition, profiles must have strong passwords. This means checking for and denying default passwords (where the profile and password match) and standard well-known passwords, enforcing long, mixed-case passwords, using a password change block rule, and ensuring all profiles follow these standards. (Admins: No cheating with CHGUSRPRF; use *ALLCRTCHG. Your profiles are often the most powerful and least protected.)

Object authorities, specifically libraries and profiles, must be tightly controlled. User profiles should never have *PUBLIC authority other than *EXCLUDE. If profiles have *PUBLIC authority, anyone on the system can use that profile’s authority (including special authorities) without knowing the password.

Libraries are the gateways to all other objects inside of them, so they too need to be locked down. Libraries should be *PUBLIC *EXCLUDE as well, but many people leave them as *PUBLIC *CHANGE. Remember, by default, objects created in a library inherit the library’s authority which underscores the library authority's importance.

System values control the overall security posture of your system. All system values should have an agreed upon, documented value and should be checked often to make sure they are not altered from their desired value. Don’t forget about the ability to lock the security related system values inside of system service tools (STRSST, Option 7). Review the memo to users at all new releases for new system values and settings.

So how can you determine if your system is at risk? Most standards recommend an annual security assessment from an outside consultant. IBM Systems Lab Services offers this type of assessment to give you an unbiased picture of your risk from the professionals that wrote the OS. You can find out more about getting your own system assessed and IBM’s other offerings by visiting ibm.biz/ibmisecurity.