For the past 16 years, IT firm HelpSystems has published a yearly “state of IBM i” security study. Year after year, the report uncovers consistent opportunities and conclusions that point to what is arguably a singular issue: IBM i is highly securable. What falls through the cracks is how and when those security features are adopted, monitored, and managed.

The company pulls data and insights from 244 of its clients in a range of industries: retail, finance, manufacturing, insurance, healthcare, government, and more

What the study found is consistent with what most studies reveal about security breaches within data centers. Security oversights are not caused by the systems themselves, but rather human behavior and company culture.

Without oversight of the IBM i systems within your data center, your systems may be vulnerable. IBM i itself not at issue. It’s company cultures and security settings that could lead to system-wide security breaches.

Study Methods

This study used a broad audience of companies and professionals that comprise a fair representation of IBM i’s global base. Analytics and methodologies aside, the results of the study all point to one critical issue: IBM i as a system is unimpeachable from a security standpoint. It’s where and how those baseline IBM i security features are not fully implemented by IT managers and teams that present the greatest security challenges.

The firms leverage an internal auditing system to analyze seven critical areas:

• Server-level security controls
• Settings at the passwords and profile levels
• Admin permissions
• Network commands and data permissions
• Accessibility to corporate data through public interfaces
• Virus scans
• Audits of system-wide events

Median system sizes were 477 users with 378 libraries, with averages of 1,228 and 555 respectively.

From a data perspective, it’s worth noting that of the systems tested, 27 percent  are running OS versions that IBM no longer supports (V7.1):

The Current State of the IBM i Business Landscape

There are well over 100,000 IBM i customers globally, and those systems often store a wide variety of sensitive data including financial information, payroll, CRMs and customer lists, personal information for both employees and customers, and various other types of crucial IP.

Even in a world of increasing security mandates from both state and federal authorities, those regulations do not encompass the common security holes that can impact IBM i data. Also, if your industry isn’t subject to those same regulations, your team may not be monitoring these security issues no matter how obvious they seem.

Critical Areas of IBM i Security: Main Problem Areas Were Analyzed

From level standpoint, these categories represent the main areas to target when you want to improve your IBM i deployment and management. These categories also provide a point to determine how best to analyze and discover opportunities to seal off data breaches and potential hacks.

Users with Special Authorities

Worth noting that of all the prominent vulnerabilities outlined, this is easily the most fixable. In many cases, too many user profiles with far too much authority existed. This is solely an IBM i management issue, but one that often goes undetected by IT teams.

Default Password Settings

Over a quarter of the systems studied had more than 100 users with system-assigned default passwords. Again: hardly something that is system related.

Network Back Doors

IBM has excellent exit point technology to control and monitor access to network data. Unfortunately, it can’t work properly if it isn’t implemented.

Public Access to Data

IBM i offers excellent data partitioning to prevent public access to data far in excess of what a user would need. The study found, in many cases, that partitioning wasn’t in place.

Ignoring Security Audits

Yes, most of the systems studied perform regular security audits. The security-related events found in those logs are often ignored. Put another way: audits are useless if there isn’t a strategy or a protocol in place to follow up on reported security breaches or events.

Vulnerability to Malware and Viruses

Only 11 percent of the servers studied are scanning files on open. That means the vast majority of the clients studied, or 89 percent, are at risk of importing internal objects that are infected.

Overall Study Objective: Identify The Holes

This report has useful findings meant to inform IBM i professionals about obvious, but perhaps unmonitored, security holes in their systems.

IBM i maintains a well-known set of security levels. Those levels, specifically as defined by IBM are:

Level 10: Password security

No security protection poses the greatest security risk. Not recommended.

Level 20: Password security

Users need a valid password and user ID. The sys-admin creates both for users. At this level, users have total authority to access all data. All users have *ALLJOB special authority. Security level 20 is not recommended.

Level 30: Password and resource security

Users have specific authority to use resources on the system. The system administrator defines a valid user ID and password. User access is limited by the defined security policies. Running security Level 30 is considered a security and integrity risk.

Level 40: Integrity protection

Resource security and integrity protection are enforced, and the system itself is protected against users. Integrity protection functions, such as the validation of parameters for interfaces to the operating system, help protect your system and the objects on it from tampering by experienced system users. For example, user-written programs cannot directly access internal control blocks through pointer manipulation.

Level 40 is the default security level for every new installation and is the recommended security level for most installations.

Level 50: Advanced integrity protection

Advanced integrity protection is added to the resource security and Level 40 integrity protection. This includes further restrictions, such as the restriction of message-handling between system state programs and user state programs. Not only is the system protected against user-written programs, but it ensures that users only have access to data on the system, rather than information about the system itself.

Level 50 is the recommended level of security for most businesses because it offers the highest level of security currently possible. Also, level 50 is the required level for C2, FIPS-140, and Common Criteria certifications.

Of the systems studied for this report:

• 170 were running at Level 40, with only 5 running at Level 50.
• Of those running at subpar levels (as defined by IBM), 10 were running at Level 20.
• A somewhat staggering 59 shops running at a very Swiss cheese-like and dangerous Level 30.

Solution: Increased Oversight and System Management

Teams often undergo staffing changes that lead to a lack of oversight of internal security audits. There may be other systems that pull or distract resources away from your IBM i servers. Perhaps the staffers who set up and implemented the system are long gone.

Those are organizational issues that often impact most companies. The weaknesses identified here are often simply caused by oversight. Knowing where those oversights fail could be key to securing your systems and limiting or eliminating data breaches and viral attacks. Setting authority levels as high as possible, for example, prevents users from gaining root access or access to data they don’t need.

While we use our own metrics here at Connectria, we can hardly argue with that logic. What we see regularly isn’t far from what was reported here. IBM i databases and servers isn’t the problem, resource allocation and oversight often is instead. It’s one of the reasons that we regularly conduct and manage security audits for our clients and partners.

We create responsive and tactical audit strategies, as well as oversee the implementation of security protocols to prevent ransomware and DoS attacks that remain a huge threat to global business. We’re here to help you strategize best practices to indemnify your systems against threats caused by a lack of security oversight.

Download this case study about Connectria’s successful hosting program we designed for Morton Technologies.