Carol discusses the characteristics she’s observed over the years that are indications an organization isn’t taking IBM i security as seriously as it should.

I’ve seen the entire range of IBM i organizations when it comes to implementing security. There are organizations that have implemented “deny by default” and “least privilege access” postures such that, when I do a penetration test, I have little to no success in attaining access when I shouldn’t. Then there are organizations that are still running at QSECURITY level 20, where all profiles have *ALLOBJ—but at least they’re asking for help and are moving in the right direction. Unfortunately, and to put it bluntly, not all organizations care about IBM i security. Here are the characteristics I’ve observed over the years that indicate to me that an organization isn’t serious about attaining a secure IBM i.

#1:   Not realizing the value of the data residing on IBM i

By far, one indication that an organization isn’t taking IBM i seriously is that they fail to recognize the value of the data running on IBM i. Without this recognition, insufficient time and funds are allocated to protecting it. Many organizations think that, just because they don’t have data that falls under some law or regulation, they don’t have to worry about security. Nothing could be further from the truth. I talked to someone at a conference recently who was claiming that his company had “too much” security and he couldn’t understand why, given that they had no compliance requirements. I posed this question to him: If the data on your IBM i became unavailable, what would happen to your company? His response? “The manufacturing line would shut down.” “And who would that affect?” I asked. “The entire company,” was his response. He suddenly realized my point. It doesn’t matter if your organization falls under compliance requirements or not; if your data can be stolen, accidentally deleted or modified, or become unavailable due to ransomware, the very essence of the business is in danger. It’s unfortunate, but many organizations have drunk the Kool-Aid that IBM i is secure (rather than secureable) and ignore the fact that they need to apply resources to protect it.

#2: Not staying current

The next indication to me that an organization doesn’t care about IBM i security is that they don’t stay current. Several ways of not being current exist. First is the operating system (OS) itself. I’m shocked at how many organizations are running their operating systems at version 7.2 and earlier with no upgrade plans in sight! I also see organizations running IBM i 7.3 with no plans to upgrade even though end of support is September 30, 2023 (that’s slightly more than a month after this article is originally published). In addition to missing out on new features and enhancements of the current releases (many of which are security-related, especially in IBM i 7.5), the biggest issue of not staying current is the lack of support when security issues arise. Which brings me to my next point.

The operating system may be running at a supported release, but the PTF level may not be current. More than ever before, it’s incredibly important that you keep your PTFs up to date. Like it or not, open source is now used for many of the latest IBM i enhancements and features. Open-source code used in IBM i is used by other platforms and in many software packages literally around the world. Bad actors are constantly attempting to find and exploit vulnerabilities. As such, when a vulnerability is discovered, the IBM i team must incorporate the fix, just like all other operating systems and applications using this code. To reduce your organization’s risk of being exploited by a known vulnerability, your system must stay current with PTFs. The easiest way to keep your PTF levels current is to use the following service, which does a “phone home” to IBM to find the most recent PTFs and then compares that list to what’s installed.

SELECT *

   FROM SYSTOOLS.GROUP_PTF_CURRENCY

   ORDER BY PTF_GROUP_LEVEL_AVAILABLE - PTF_GROUP_LEVEL_INSTALLED DESC;

Unfortunately, there is an occasional defective PTF, so another service has been created that looks at defective PTFs and shows whether the replacement PTF is installed.

SELECT *

 FROM SYSTOOLS.DEFECTIVE_PTF_CURRENCY;

The final way organizations can be out of date is by not learning about and taking advantage of the new features and technologies IBM has provided us. If you’re reading this article, it’s doubtful that this applies to you. I get that everyone’s plate is full, so there’s a temptation to not change something if it’s not broken. But what if that old process could be made better—for example, fewer resources could be required, or the output could be made more readable or accessible, or data could be aggregated so that a human visual comparison between two reports could be eliminated? This refusal by IBM i administrators/programmers/security administrators to leave processes “as is” is what’s made some organizations assert that the system is “old.” The system isn’t old, but processes running on it sure can be! We are doing ourselves a huge disservice by not modernizing our processes. Also, not upgrading technology can put your organization at risk. Again, you may be running the latest OS level and be current on PTFs, but using old technology or old software could put your system at risk. For example, if you are still using the old (IBM calls it “Heritage,” but I call it like it is…old) Navigator for i, you’re putting your system at a security risk. Or, if you are still running the ancient Client Access for Windows, you’re using technology that’s been out of service for over four years (April 30, 2019) and, yes, I still see it in use. Not only does it have security issues, but you run the risk of a Microsoft Patch Tuesday breaking it and having to scramble to replace it across your entire organization with the current technology, Access Client Solutions (ACS). Rest assured, IBM is not going to put out a fix to resolve the issue; it will be your problem to resolve.

#3: Not monitoring for changes or not periodically reviewing security configurations

Another issue I see is not taking the time to monitor for security changes or review security configurations. Again, I understand that no one has extra time, but unless you are periodically (at a minimum quarterly) looking for changes or reviewing settings, I guarantee they are not what you expect them to be. How can settings change, you ask? Let me give you a few examples that I’ve seen over the years:

• In the heat of trying to debug an application issue in the middle of the night, the *PUBLIC authority of an authorization list is changed from *PUBLIC *EXCLUDE to *ALL because, obviously, the issue was being caused by security (which it rarely is and wasn’t in this case), and the *PUBLIC authority was never changed back when admin realized that didn’t solve the problem.
• Two user profiles are created with a default password because the administrator was in hurry and didn’t follow policy.
• Users changed jobs within the organization and retained their original group profile assignments for training purposes. Now those users are members of a group representing an area of the business they haven’t worked for in for five years but still have access.
• A developer was asked to work on a short-term project that required elevated authority. *ALLOBJ was assigned to their profile on a “temporary” basis. Two years later and 18 months after the project was completed, the developer still has *ALLOBJ.

Do any of these sound familiar?

#4: Not taking advantage of the features provided by IBM to secure the system

As a reader of my articles, you know I love to help people understand how to use the latest features IBM provides us either in a full OS release or in the periodic Technology Refreshes (TRs). Authority Collection has taken the mystery out of securing objects and demystified how much authority a user requires by telling us exactly how much authority is required. (New) Navigator for i has made security accessible to the novice user—including getting information out of the audit journal. And I can’t say enough about how much this non-SQL user loves SQL Services and has made administering IBM i security soooo much easier! But even if organizations don’t like these up-to-date features, there’s the old (but still working!) SECTOOLS that at least gives a basic view of security. Unfortunately, many organizations choose to ignore these integrated security features.

#5: Not using the software they’ve purchased

Many organizations have purchased one of the security vendor’s software packages to add another layer of security one top of what’s provided by the operating system. Unfortunately, I often see those software packages underutilized or, worse, not used at all! What a waste! Sometimes the administrator who was originally in place when the software was purchased has moved into another job or insufficient resources were never allocated when the software was purchased. Regardless, if you have this software, USE IT!

Summary

If you are reading this article and none of these issues applies to you, huzzah! You get a gold star! If one of these characteristics hits home, I encourage you to work with your management to get it resolved. Many of these characteristics manifest themselves because personnel—especially management—is uninformed about IBM i. Resources abound to help anyone in the organization gain a better understanding of IBM i. Perhaps you know of colleagues in the industry to which one or more of these characteristics applies; if so, I encourage you to talk with them. Many times peer-to-peer conversations can reach the unconvinced. I truly believe that, as a community, we can convince organizations to take IBM i security seriously.

 

Carol Woodbury is President and CTO of DXR Security and has over 30 years’ experience with IBM i Security. She started her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies – SkyView Partners and DXR Security. Her current company - DXR Security - specializes in penetration testing for IBM i. Her practical experience together with her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known world-wide as an author and award-winning speaker on security technology, specializing in IBM i Security topics. She has written seven books on IBM i Security. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

 

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		IBM i Security Administration and Compliance: Second Edition Get the must-have guide by the industry’s #1 security authority. List Price $71.95 Now On Sale
		IBM i Security Administration and Compliance For beginners to veterans, this is the definitive security resource. List Price $69.95 Now On Sale

Also Read

Securing IBM i: A Dual Responsibility

Top IBM i Security Issues of 2024

Why Cleaning Up Is an Important Part of Your IBM i Security Practice