State Of IBM i Security: Seven Areas That Demand Attention
April 24, 2017 Alex Woodie
The latest installment of the annual State of IBM i Security was released last week by HelpSystems, and the results were about what you would expect: most IBM i servers are basically wide open for abuse.
In a webinar last week, HelpSystems director of security technologies Robin Tatam discussed the findings of the report, which was based on security assessments conducted on 332 systems during 2016. He broke the findings down into seven core areas that should be addressed, including system security levels; administrative privileges; passwords and user profiles; data and program permissions; network access and exit programs; audit trails; and antivirus.
System Security Levels
We may as well get the good news out of the way, because there’s not much of it in this report. HelpSystems found that 81 percent of surveyed systems had a QSECURITY system value set to level 40 or higher (i.e. level 5). This is due to the fact that IBM started shipping new systems with a default setting of level 40.
QSECURITY level among IBM i shops. (source: HelpSystems)
So it’s all good, right? Not quite, Tatam says. “QSECURITY may come in shiny and new on level 40 on new system, but as soon as we load the tape from the old system, we’re back to level 20 or 30,” he says.
Even running at higher levels is no guarantee of security greatness. “I’ve seen systems running security level 50, at the highest level, but then when we interrogate the profiles we find they’re all running with ALLOBJ special authority, which is in essence the keys to the kingdom,” Tatam says. “So we want to make sure that not only these systems values are set correctly, but all the other moving parts and pieces are supporting our endeavors, not undermining them.”
Clearly, ALLOBJ isn’t just being used by administrators, as we learn in the next section.
Administrative Privileges
Another core element impacting security on IBM i systems are the administrative privileges granted to users, like ALLOBJ, SAVESYS, and SERVICE authorities. Administrators, programmers, and operators need these powers to execute tasks on the system, but all too often, regular end-users are being granted these rights as part of the normal course of business.
Special privileges among IBM i shops. (source: HelpSystems)
The average system evaluated by HelpSystems had an average of 200 user profiles with ALLOBJ authority, while 300 users had access to all spool files with SPLCTL authority. But those aren’t the worst, according to Tatam.
“The winner this year is JOBCT,” he says. “Almost 350 users on average on each system are operating with a permission that’s the primary control for bringing the server into a restricted state.”
Some people will argue that, since these users have to be authenticated anyway, that it alleviate some of the risk? “Any conversation about that user would not be complete with some consideration of the dreaded insider threat,” he says.
If an IBM i shop has strong authentication methods, it maybe wouldn’t be such a big issue. But clearly, most shops do not, as evidenced in the next section.
Passwords And User Profiles
The combination of a user name and a password is all you need to sign onto the IBM i server (until we’re all using 2FA, anyway). However, many IBM i shops do far too little to ensure the security of the passwords associated with the user profiles.
Minimum password length among IBM i shops. (source: HelpSystems)
One in 10 user profiles surveilled by HelpSystems uses the default password, which is the same as the user profile on IBM i. Nearly half of the systems had more than 30 user profiles with default passwords, while about a quarter had more than 100. “We’re ignoring the vulnerability that this poses,” Tatam says.
Other password controls are also going to the birds in IBM i-land. “Unbelievably, seven systems had a password minimum length of one,” Tatam says. “How do you justify that? One of the customers, when I asked that very question, I was told the CIO didn’t appreciate dealing with passwords.”
The IBM i OS also lets admins control whether a user profile (and optionally a workstation) is disabled after a certain number of incorrect sign-on attempts. “Most people are adhering to reasonable level, between three and five, or up to ten,” Tatam says. “It’s not considered best practices, but I’d rather have them be given more attempts rather than what 13 servers did, and say were not going to implement a threshold at all.”
Workstation disablement is another issue that should be considered. Nearly half of the systems surveyed would disable workstations (in addition to disabling user profiles) in response to a certain number of failed sign-on attempts. But 11 percent only chose to disable the workstation, not the user profile.
“The problem being, some interfaces don’t leverage the workstation concept,” Tatam says. “If it’s a script, or something along those lines, it continues on its merry way trying to connect to the server.”
Getting into the system is one thing, but what can you do once you’re in? Unfortunately, you can do a lot more than you may expect, as you’ll see in the next section.
Data and Program Permissions
On most computer systems, users must be specifically granted permission to access an object (i.e. data or a program). But that’s not the way it works in IBM i, which be default lets everybody access just about everything.
*PUBLIC Authority to data. (source: HelpSystems)
“When we look at public authority allocated to thousands of libraries in the study, we saw the most of them were sitting at PUBLIC*CHANGE,” Tatam says. “I can’t honestly say I’m surprised because that is the default permission that is set by IBM. Many of us are simply not aware, or take the time to change it.”
About 10 percent of surveyed shops have changed the public authority to *ALL, while another 25 percent restricted it to *USE. “But honestly there’s not that much difference between those three at a library level,” Tatam says. “In other words, we’re pretty much running at about 90 percent of libraries that are open to anybody with a user ID and a password.”
So if there’s no lock at the front gate, and none of the rooms are locked either, what’s to stop somebody from walking out with the goods? Not much, as you’ll see in the next section.
Network Access and Exit Programs
Today’s uber-connected world means the odds of somebody finding their way to an IBM i server through a network is very high. “We hope there’s a firewall in between,” Tatam says. “But ultimately the server is connected to the network, and the network is connected to other networks, potentially the Internet. There’s always a path through for someone.”
The percentage of IBM i shops with at least one exit program. (source: HelpSystems)
IBM provides various mechanisms to control network access, including exit points for common routes into the system, such as FTP and ODBC, against which IBM i shops are encouraged to buy or build exit programs to monitor activity. Unfortunately, few IBM i admins seems aware about this.
“Three-quarters of the systems we looked at don’t have a single exit programs deployed out of 28 or so exit points that can support them,” Tatam laments. “This is a pretty significant disconnect. In fact, this is an increase from last year. We’re not comparing year to year, but it does show that even with us beating the drum – and this being my own personal soapbox – many of us are not deploying these exit programs.”
Only about 9 percent of the shops surveyed have what HelpSystems considers adequate coverage of the exit points. That shows that they’re most likely trying to write their own exit programs (a difficult endeavor) as opposed to buying a vendor package (like *ahem* the various ones from HelpSystems).
“If the data leaves the system, you lose control,” Tatam says. “If you don’t have the necessary object level security or exit programs in place, you potently have a bit of a sieve where the data is just leaving the system. It’s happening under your nose, and you have no awareness of that taking place.”
IBM i has the facility to track data leaving the system, but as we’ll see in the next section, few are using it.
Audit Trails
The survey showed that 85 percent of surveyed IBM i shops have the QAUDCTL auditing function turned on. That’s the good news. The bad news is that just 17 percent of shops had an auditing tool to make sense of the data. And only 15 percent had an audit journal repository in place.
The disposition of the QAUDCTL setting among IBM i shops. (source: HelpSystems)
“There’s a big disconnect between the people who are collecting the data and the people who are using the data,” Tatam says. “In the IBM i world, we still have a tendency not to actually use the built-in flight recorder.”
One IBM i shop that did have QAUDCTL turned on found 6.9 million failed connection attempts against a single user profile. That should have sent up a giant red flag to the administrative staff, but only if they have the capability to understand what the log data actually means.
Here’s another fun fact about the IBM Security Audit Journal: HelpSystems detected that 18 percent of IBM i ships who turned logging on subsequently turned it off after being overwhelmed. “It was better they turned it off and pretended they never saw it,” Tatam says.
Understanding the log data is one area where a third-party tool can be very effective in bolstering security. So is the next area of focus.
Antivirus
While the IBM i is virus resistant, it’s not virus proof. The Windows-like IFS has long been identified as a repository for viruses, malware, ransomware, and other nasties developed for Windows.
The disposition of the QAUDCTL setting among IBM i shops.
(source: HelpSystems)
Tatam shared the story of one IBM i shop that had 248,000 infected files on the IFS. HelpSystems identified and corrected the problem with its Bytware antivirus software, which is co-developed with McAfee and is one of just a handful of antivirus products available for IBM i.
It’s been over a decade since this problem was first identified, but few IBM i shops are getting the message, according to Tatam. “Ninety-four percent of the servers we looked at do not scan IFS files prior to it being opened,” he warns.
‘Perfect Storm’
This combination of weaknesses in the security configuration of real-world IBM i servers poses a real hazard to the well-being of companies that rely on this workhorse to run their businesses. Just because a company hasn’t been victimized by hackers or disgruntled employees is no guarantee that they won’t be in the future.
“What we’re dealing with is a perfect storm that’s brewing,” Tatam says. “To be fair, based on [the history of IBM i security], we could argue that this storm has been briefing for years. It’s been brewed at this point. But we still have to keep fighting the good fight.”
Unfortunately, the odds are stacked against making progress. “First of all, security awareness in the IBM i community is generally pretty low in comparison to other platforms,” Tatam says. “Most of us know how to administer the system, to bring subsystems up and restore objects. We know that stuff inside and out. But when it comes to configuring public and private authority, we tend to glaze over and pretend that it doesn’t even exit.”
You can access a recording of Tatam’s webinar, Revealing the New State of IBM i Security, here. You can access a copy of the report, titled 2017 State of IBM i Security Study, here.
RELATED STORIES
Time To Get Your 2FA On, IBM i Admins
Assessing The Ransomware Threat On IBM i
Study Identifies Disturbing IBM i Security Weaknesses
State of IBM i Security? Still Horrible, After All These Years
