Carol reflects on the things she’s learned in the past year.

When it comes to the end of a year, I like to look back and see how things have changed and what I’ve learned. This article describes the things I’ve learned about IBM i security this year—some from our clients and some from practical experience working on the system. My hope is that you’ll learn right along with me, making 2023 brighter and more IBM i systems secure.

I Need SQL!

No, Scott Forstie (DB2 for i Business Architect) didn’t pay me to say this! I’ve just found it to be true. This year I worked with a client to help them rework authorities in their IFS. Unfortunately, their system was still on IBM i 7.3 and very far behind on their Technology Refreshes (TRs). I desperately wanted to use the qsys2.ifs_object_privileges and qsys2.ifs_object_statistics IBM i Services, but they weren’t available. While I was able to complete the project, my analysis took significantly longer and one issue—specifically the analysis to find obsolete objects—will have to be re-addressed once they upgrade to IBM i 7.5 in 2023. This leads me to my next observation.

Organizations Need to Stay Current!

I can’t emphasize this enough. Not only are you missing out on the IBM i Services that will make your life as an administrator much easier, but not upgrading and not staying current with PTFs could likely mean leaving your system vulnerable. For example, I’m dismayed by the number of organizations that have not made the switch to New Navigator for i. Almost all functionality has been implemented in New Nav now. Why anyone would want to use the old and ugly interface of “Heritage” Navigator (as IBM calls it) is beyond me. Not to mention that it has security issues, which is why it was deprecated by IBM. If you’re one of those organizations that has not yet started to use New Nav, PLEASE… give it a try. Here’s how you launch it: http://your-system-name:2002/Navigator/login.

This leads me to my next observation.

People Don’t Like to Change

OK, I realize this is not news, and I get it. Change is hard. But when sitting on old technology affects the security of an organization, it makes me want to scream. For example, this year I ran into numerous organizations that continue to use the very ancient Client Access for Windows client. I get that people don’t want to change, but this client has now been out of support for almost four years. Who knows what kind of security issues might be in this client? I get that it can be a chore to roll out new software, but the excuse that end users don’t like change doesn’t fly in this case because end users should see very few if any changes to their user interface if they’re only using 5250 Telnet emulation. And I’ve found that most end users appreciate the usability features of the new client when they’ve been upgraded. I would hate to be an administrator who has not migrated their organization from Client Access to Access Client Solutions (ACS) when the inevitable Microsoft Patch Tuesday breaks Client Access and they’re left scrambling to upgrade their users’ client software. Stop using unsupported software and denying yourself use of the cool, new features of ACS. Put plans in place to upgrade in 2023!

Accidental Errors Occur

I don’t think organizations give enough credence to the fact that accidental errors occur that can affect your IBM i security posture. For example, I have a client that, by policy, creates group profiles with its password set to *NONE. But one day, the administrator was in a hurry and created two new group profiles and didn’t specify the password. Result? Two high-powered profiles with a default password. Fortunately, processes were in place to catch the mistake, but without these processes, they may have gone undetected for a very long time. Thankfully, IBM i 7.5 changes the password parameter on the Create User Profile (CRTUSRPRF) command to be *NONE (from *USRPRF), but my point is that checks need to be in place to make sure your IBM i security policies continue to be met and that your IBM i security policy doesn’t go sideways or take a huge step backward. I’ve had managers tell me they don’t need to take action or invest in IBM i security because “they trust their employees.” That’s great! I’m glad they trust their employees to not do anything malicious, but how do they account for their accidental errors? Obviously—and frighteningly—they don’t.

Misunderstanding of How the System Checks Authority

I still find organizations that don’t have a good understanding of how (in which order) the system checks authority. I was helping a client eliminate excess private authorities to speed up their Save Security Data (SAVSECDTA), and one of the issues I discovered was private authorities granted to profiles with *ALLOBJ special authority. *ALLOBJ is the first thing checked at the user level. It doesn’t matter what private authorities are granted to that user or its groups; *ALLOBJ provides them all authority to the object being accessed. If you’ve granted a private authority to a user with *ALLOBJ assigned to their profile, it will never be used.

IFS Continues to Confound

Even though the IFS has been around for well over 25 years, it continues to confound. I think the issue is twofold. First, organizations are realizing that their IFS is wide open and vulnerable but are frustrated because it’s not obvious to them where to start and/or what authority is required when they do determine where to start. I’d suggest starting with the directory containing the most critical information. Use Authority Collection to determine how much authority is required. Second, eliminate unused and unnecessary file shares since that’s the gateway malware uses to get to the system. And yet another reason to get current, IBM i 7.5 provides the capability to secure which profiles can use a file share. Prior to this, the damage malware could do was determined by the type of share (read-only or read-write) and the authority the profile has to the object being shared. Because the IFS remains such a mystery to most administrators, I included several examples of using Authority Collection and IBM i Services to secure and manage the IFS in my most recent book, Mastering IBM i Security.

Risk Assessment vs. Penetration (Pen) Tests

I’ve determined that a pen test provides more value to our clients than a detailed risk assessment. Why? I have performed more risk assessments than I can count over my career. But rather than take note and address each issue, many organizations dismissed the assertions made in the risk assessment, saying that they weren’t possible to exploit. The reason I like penetration testing is that you can’t argue with a screen shot showing how an IBM i security configuration setting or user profile with a default password was exploited or how a production file was accessed by an end user…all because the controls they thought were in place weren’t or the scenario they dismissed was actually exploitable. While risk assessments have a purpose (primarily for compliance requirements) pen tests provide proof that security controls are in place…or they aren’t. They also allow clients to prioritize their efforts on the areas that they know (based on the pen test results) need to be addressed.

Things I’m Thankful For

I’d be remiss if I also didn’t share my reflections on what’s been good about 2022 and what I’m thankful for. This year has been a year of many IBM i security enhancements, starting with the IBM i 7.5 release as well as the Technology Refreshes. I’m thankful that IBM continues to invest in making this the most securable system available. I’m thankful for all of the support I received that allowed me to publish my second book, Mastering IBM i Security. I’m thankful for my business partner, John Vanderwall, and all of our DXR Security clients. And, of course, I’m thankful for my faith and my family, especially my three great-nieces here in Seattle who bring such joy into my life. I can’t help but smile when I think about them.

My heart and my prayers go out to those of you who struggle this time of year. My prayer is that you can find peace and hope in 2023.