Carol describes 10 things that she wishes were different when it comes to IBM i security.

It’s the time of year when all children are making their Christmas wish list, hoping Santa will deliver on Christmas morning. While I’m a few years beyond believing in Santa Claus (!), I’ve created my list, just in case.

Wish #1: V7R3

I wish all IBM i customers would upgrade to V7R3. The Authority Collection feature added in V7R3 alone justifies the upgrade. This feature helps administrators to stop over-authorizing and enables them to remove *ALLOBJ from profiles that don’t really need it. If you are considering upgrading to V7R2, skip that thought and move right to V7R3!

Wish #2: QSECURITY Level 40

If all IBM i partitions were running at QSECURITY level 40 or 50, it would make my day. Simply put, systems at the lower security levels cannot be secured. And yes, there are still systems running at security level 20 and 30. Fortunately, in the last couple of years I’ve seen more interest in moving to the higher security levels, and we’re helping more clients make the move from both 20 and 30 to security level 40.

Wish #3: Abandon QCRTAUT = *ALL

When QCRTAUT = *ALL, with a few exceptions, every object you create has *PUBLIC authority *ALL. That, of course, causes tremendous data integrity and confidentiality issues. When changing the system value back to the default of *CHANGE or something even more restrictive, it’s very difficult to know what will break. For some operations, such as adding a physical file member, *CHANGE to the physical file isn’t sufficient; the operating system requires *CHANGE plus *OBJMGT. So unless you are very familiar with your application, it’s just a guess whether something will break when changing the system value to something other than *ALL. My wish is that IBM would take away the ability to set QCRTAUT to *ALL. They could grandfather in any system with the value already set but prevent it from occurring going forward…much the same as we did when I was the iSeries Security team leader and we removed level 10 from QSECURITY.

Wish #4: Limited Authority for Senior Management and Company Owners

When senior management or company owners have a sign-on to IBM i, they often take liberties with their access. I’ve found that they frequently have more authority than is required, set their password to never expire, and often have a default password. My wish is that they would realize that their profiles are targets. That is, their profile will be one of the first a hacker will attempt to exploit; therefore, they should not have a profile if they don’t need one, and if they do, use a very strong password and limit the access of their profile to only what is required to perform the tasks they have responsibility for on IBM i.

Wish #5: Work with Me

The good news is that more organizations are starting to understand the need to appropriately secure their data. The bad news is that some users are still very defiant of the need to secure data and get very defensive when you try to reduce their access, especially on production systems. My wish is that these groups would stop being so defensive and understand that they will still be able to do their job but be willing to use appropriate tools and processes to accomplish their daily tasks. My wish is that you’d work with me. I’ll make sure you can still do your job, but don’t get defiant and refuse to work with me to reduce access to appropriate levels.

Wish #6: QSECOFR *DISABLED

Unlike all other IBM-supplied user profiles, QSECOFR has to have a password. (The system prevents you from setting it to PASSWORD(*NONE)). However, you can set the profile to be STATUS(*DISABLED). If you need to sign on with QSECOFR, you can either re-enable the profile or sign on to the console—even if the profile is *DISABLED. My wish is that everyone would set QSECOFR to *DISABLED to help prevent the profile from being exploited.

.

Wish #7: Understand the Authority Check Algorithm

I wish more people understood the way that the system checks authority. In general, the system checks the user, then the group(s), then *PUBLIC authority. *ALLOBJ is the first thing checked at a user profile level, so if a user has *ALLOBJ, no amount of private authorities will stop them from accessing every object on the system. Also, if any authority is found at the user level—sufficient or not—the algorithm stops and the user gets that authority. When authority is found at the user level, the group(s) are never checked.

Wish #8: Use the QPWDRULES System Value

This wish is actually two wishes in one! I wish that administrators would start to use the QPWDRULES system value to define their password composition rules. That’s because of the additional options and combinations you have over using the original password composition rule system values. The second wish is that administrators would use the combination of *LMTPRFNAME and *ALLCRTCHG (new in V7R2) to prevent the use of default passwords. What better way to eliminate the exposure presented by default passwords than to prevent them from ever occurring!

Wish #9: Plan to Be Hacked

Ok, this wish might sound a bit harsh, but I wish that everyone would assume that they’re going to be hacked. I’ve found that organizations that assume they’re going to be hacked have plans and processes that are much more sound than simply hoping they’ll never be hacked. You should form the appropriate response teams, contract with an organization that will come in and do the forensic investigation to determine what happened and how to recover, and more. It’s a much more healthy attitude to have, and I encourage you to get to that place.

Wish #10: Recognize the Value of the Data on Your IBM i Systems

This might be my last wish, but it’s the one I most wish would come true. I wish that businesses would understand the value of the data that resides on their IBM i. If that happens, organizations will be willing to invest in securing their data to ensure data integrity and confidentiality. Without recognition of the value of the data, IBM i security administrators are constantly fighting to implement sound security measures. An understanding of the value produces a partnership between the business and IT and will result in the appropriate layers of defense to be put in place to protect the organization’s data.

Carol’s Wish List

Perhaps some of these items are on your wish list too. If not, I hope that you’ll consider the merits of my wishes and consider adding them to your wish list in the future.