Top Five Failures In State of IBM i Security For 2022
April 18, 2022 Alex Woodie
HelpSystems last week officially unveiled its annual State of IBM i Security report, the 18th straight year for the series. Like with past reports, the 2022 version highlights some of the continuing challenges that IBM i customers face when trying to secure their systems. A few key areas stand out above the rest.
The IBM i server is a bit of an enigma when it comes to security. While it is widely perceived to be one of the most secure computing platforms on the planet – and “virus-proof” to boot – the reality is that a good number of IBM i systems in the wild are configured in a very unsecure manner. This mismatch between perception and reality provides fertile ground for cybercriminals and disgruntled insiders to do real damage.
The annual HelpSystems State of IBM i Security report is based on the accumulated results of hundreds of free security audits performed by HelpSystems on real-world IBM i machines over the previous year. This report, like the ones before it, provides a guidepost to help the IBM i community identify some of the most common security shortcomings, which is hopefully the first step in fixing them.
The goal is not to fix every single problem right out of the gate, but to tackle the biggest problems first, says Robin Tatam, director of security technologies for HelpSystems and one of the co-authors of the report.
“Most likely there is going to be some prioritization necessary in mitigation activities,” Tatam, said during a presentation of the report last week. “Most of us don’t have endless amounts of money and endless amounts of resources just sitting around twiddling their thumbs. So we need to prioritize and the study is useful in regards to pointing at the high risk items versus maybe low risk items.”
Here are the top five security issues identified by the report:
One of the top security issues on the IBM i server is susceptibility to attacks over TCP/IP. Since the midrange server’s architecture was developed before the Internet era, IBM created exit points to facilitate communication via various Internet protocols. It’s critical to monitor these exit points and exit programs to ensure nothing untoward is going on. But all too often, people don’t, much to Tatam’s chagrin.
“If you’ve ever heard me speak before, you will probably cringe when you see the word ‘exit program’ on the screen because you know this is my soapbox,” Tatam said. “I get very fired up about this topic because to me it is the easiest thing you can do to secure your system, and yet as we see, 90 percent of you have not taken this step.”
Only one out of 10 IBM i logical partitions audited by HelpSystems had exit programs in place to monitor data coming in or going out through 27 exit points, according to the State of Security report. However, 73 percent of the LPARs had at least one exit point in place, which is a little bit of cold comfort for Tatam. However, the lack of visibility into FTP, ODBC, and Telnet activity should be a giant red flag for admins.
“These PC tools running over TCP/IP are the interfaces we see attacked most commonly. And yet these are the ones that we put the least amount of protection around and that’s why this is an important mitigation step,” Tatam said. “And if you have limited resources, funds, etc. And you say I’m just going to do one thing, what’s the one thing I should do? This is going to be it for me. Hands down. This is the recommendation I would make.
The State of Security report found that 80 percent of IBM i environments are running at QSECURITY level 40 or 50, “which is fantastic,” Tatam said. However, that means there are 20 percent of shops running at less-than-optimal security levels, which is cause for alarm.
However, just because your system is set to security level 40, which has been the default from IBM for over 25 years, that doesn’t mean it’s fully protected, Tatam said. And on the flip side, there are things you can do to mitigate the risk when running at a lower security level, he said.
“For example, if you’re running on a level 40 system and you give all your users ALLOBJ special authority, then effectively your system is operating just as if it was on level 20,” Tatam said. “If you take ALLOBJ away from users from a system at level 20, then effectively you’re closer to a level 30 machine.”
Have a system running at security level 10? “Please call me,” Tatam said. “It’s one of those things that, I’ll be sad for you, but it will be exciting to see because I’ve never seen a system at that level. It is not supported by IBM.”
Powerful User Profiles
It’s critical to have some user profiles with special authorities, such as ALLOBJ, SECADM, and JOBCTL, because these authorities are needed to make important configuration changes to the operating system or to an application. However, they can also be abused, so IBM i shops should try to keep the bare minimum on hand, and track their usage closely.
The rule of thumb when it comes to user profiles with special authorities, according to HelpSystems, is that an IBM i shop should have no more than 10, or less than 3 percent of the user community. IBM i shops are exceeding that by miles, according to the State of the Security report, which found the average shop had more than 244 user profiles with ALLOBJ, and the average shop had more than 30 percent of user profiles with ALLOBJ.
It was the second straight year with an anomalously high number of user profiles with ALLOBJ, Tatam noted (last year, the number was over 300). Tatam was stumped as to why this was the case.
“I looked through the data. I couldn’t see a pattern,” he said. “There really was just no good explanation for why the systems were reviewed previously had so many ALLOBJ. So it did go down. It didn’t go down enough. Two hundred forty-four is still dramatically higher than most prior years. Typically, it’s around 100, 150.”
ALLOBJ is the “keys to the kingdom,” Tatam said. “You have access to every single file, every program, and even the entire operating system.”
All journal receivers, including those used to record system activities, individual user events, and attempts to access sensitive objects, are turned off by default on the IBM i, which means users must turn it on before they can start collecting this data.
According to the State of Security report, 78 percent of systems had IBM i journaling turned on. That number may initially look good when it comes to the IBM i security journal, QAUDJRN. However, Tatam said the percentage of IBM i shops actively collecting and storing security data is probably lower than that because the use of an IBM i high availability product will also activate the journal receivers.
“HA will help. It’ll get the data flowing and it looks good on the report because you get the check mark,” he said. “But in reality, it’s not doing any good and that’s a problem.”
A security-conscious administrator will have to do some digging to see if the QAUDJRN is collecting data in QSYS. The QUADJRN may be present because it was been activated at some point in the past, but is no longer collecting data. The admin may have to hunt through some system values to see if the system is properly set up to collect security events, but it’s worth the effort, Tatam said.
“The reason we’re so hot on this is you can’t detect a security violation if the auditing is not active,” he said. “You won’t know if somebody is trying to hammer their way through a brute force attack on your user profiles and such. You’re not going know if somebody is trying to access the payroll file outside of the payroll application.”
Passwords are a critical but often overlooked layer of security. Done well, they can help protect the IBM i server. Handled poorly, they can become a security liability themselves.
“Passwords are incredibly important to make sure that we control the user access,” Tatam said. “Passwords are required always in order to access a user account and inside that user account it defines what the user can do, what they see, where they go. So once the user is signed on, it’s game on.”
One of the biggest problems is default passwords, which on IBM i are the same as the user profile. There are tools in the operating system to help administrators enforce good user profile hygiene. Alas, too many are not using them.
According to the State of Security report, the average IBM i environment had 146 user profiles with default passwords. When you filter out the unused user profiles (which also pose their own risk to security), the number of user profiles with default passwords drops to 79. That is still way too high, Tatam said.
“I had a customer yesterday that I looked at that had over 1,000 profiles with default passwords,” Tatam said. “So if you are an IBM I shop and you have not looked to see if any of your profiles have a default password, this is something to jump on. Low-hanging fruit for sure. Easy to fix, but extremely detrimental when it’s found.”
These five items – exit points, security level, special authorities, the security journal, and passwords –contain some of the most glaring security problems, according to HelpSystems report. It’s not the first time that these problems have been highlighted by the State of Security report, and it’s undoubtedly not the last.
But these are not the biggest problem with IBM i security, Tatam said.
“What has been the main inhibitor to us having better security within IBM i?” Tatam said. “I break it down to one word: inaction, which is defined as a lack of action where we expect some or where some is appropriate. And that is us in the IBM i community.”
That’s also an area where some change – some action, some forward momentum – would be greatly appreciated.
You can download the State of Security 2022 report and view webinars at www.helpsystems.com/resources/guides/state-ibm-i-security-study.