State of IBM i Security Study

Executive Summary

For the 21st year, this study provides compelling insight into the security posture of 148 IBM i server partitions – systems that are used to host business-critical applications, and that often house electronic personal health information (ePHI), financial data, and personally identifiable information (PII).

This is generally not a recurring study of the same systems each year, but overall trends are apparent. Cybersecurity is becoming a higher priority for participating organizations, and in recent years businesses have made gradual improvements with malware protection and password controls.

2024: A Potential IBM i Security Turning Point

As mentioned before, the 2024 IBM i Marketplace Survey revealed a record-setting level of cybersecurity concern. Based on the results from this year’s State of IBM i Security Study, it appears that this increased concern is resulting in organizations taking action to improve their security posture.

Looking Beyond 2024

Although the results from this year indicated an overall improved security posture across the pool of participants, there is still plenty of work to be done. Certain critical areas of security such as eliminating inactive profiles and addressing invalid sign-on attempts regressed while others hovered around their 2023 marks. Regardless, the results of this year’s study indicate that organizations are increasingly prioritizing IBM i security and are actively taking steps to improve their security posture – a trend that we hope to see continue in the years to come.

About This Study

Trends in IBM i Security

Cyberthreats grow more sophisticated every year, raising the importance of proper security controls. The 2024 State of IBM i Security Study proves that many organizations rely on system settings that leave data vulnerable.

But in recent years, Fortra has observed an encouraging trend: organizations large and small increasingly prioritize IBM i security.

A deeper understanding of the risks and the security controls built into the OS is currently driving a wave of interest in taking action on IBM i cybersecurity issues.

Why This Study Matters to You

The 21st annual State of IBM i Security Study strives to help you understand common IBM i security exposures and how to correct them quickly and effectively.

Your IBM i server likely runs mission-critical business applications. But because Windows and UNIX platforms often require more resources, it’s easy to let IBM i security projects take a back seat.

The weaknesses identified and documented in this study are caused by poor or missing configurations that can – and should – be corrected. This study illustrates the most common and dangerous IBM i security exposures and offers tips for improvement.

Methodology

The data shared in this study is collected by Fortra security experts reviewing IBM i systems using our proprietary Powertech Security Scan and Risk Assessor tools. The Powertech Security Scan is free software that runs directly from any network-attached PC without modifying systems settings, interrogating Power servers running IBM i (System i, iSeries, AS/400) across seven critical areas. The Powertech Risk Assessor tool evaluates these seven critical areas of IBM i security configurations as well as many others.

The areas of IBM i security covered in this study include:

• Server-level security controls
• Profile and password settings
• Administrative capabilities
• Network-initiated commands and data access
• Public accessibility to corporate data
• System event auditing
• Virus scanning

This year’s study includes 148 IBM i servers and partitions that were audited throughout 2023. The average system scanned for this study has 1,803 users and 509 libraries. Fifty-one percent of scanned servers are running on version 7.4 or 7.5 of IBM i, while 49% are running on unsupported versions of the OS (7.3 and below). It should be noted that IBM i 7.3 went out of support at the end of Q3 2023, leading to an increase in use of unsupported versions of the OS.

Security Enforcement Level: QSECURITY

IBM i security best practices start with the configuration of numerous system values, which regulate how easy or difficult it is for someone to use or abuse your system. Poorly configured or unmonitored system values are an unacceptable security risk.

QSECURITY Level

The system security level (QSECURITY) sets the overall tone, although it is often undermined by other settings. IBM recommends and ships security level 40 as the minimum, due to a documented vulnerability found in level 30 and below. It should be noted that, despite the revision of the default setting, a server migration will typically reload this to the same value as found on the previous generation of the server. In 7.5, IBM has restricted the use of security level 20 to an in-place upgrade only, and cannot be back leveled.

Figure 1 shows the distribution of security settings on the systems included in the 2024 dataset. Out of the 148 systems studied, 12% are running at system security level 30 and 4% are running at security level 20. Overall, 16% fall short of IBM’s recommended minimum level (Figure 1A). This is a significant improvement from the 30% of systems that fell short in 2023. Many running on a sub-par security level are doing so without deliberate intent after having migrated their system values from an older server. This major improvement offers an encouraging sign that those who are migrating servers are increasingly aware of their need to take corrective action.

Basic System Security: Key Values for Restoring Objects

Several other system values related to object restoration often remain at their shipped levels, reflecting a typical IBM i configuration of "load and go.”

The system values in question are designed to work together as a tri-pass filter that prevents restoration of malicious or tampered objects. But IBM i’s default values fail to provide this protection, which may leave the system vulnerable.

The system values below work consecutively to determine if an object should be restored, or if it is to be converted during the restore:

• Verify Object on Restore (QVFYOBJRST)—Sixty-four percent of servers are running below the recommended level of 3. This value, preset at level 1, controls whether a signature will be validated when a digitally signed object is restored.
• Force Conversion on Restore (QFRCCVNRST)—Eighty-four percent of servers are running below the recommended level of 3. This value, preset at level 1, controls whether some types of objects are converted during a restore.
• Allow Object Restore (QALWOBJRST)—Fifty-three percent of servers have altered this system value from its default *ALL setting to a more secure setting. This value controls whether programs with certain security attributes, such as system-state and authority adoption, can be restored.

System values set at the recommended level for Verify Object on Restore and Force Conversion on Restore both improved by approximately 8% while Allow Object Restore improved by a staggering 50%— demonstrating a strong, positive trend towards heightened security within restore processes. However, there is still plenty of room for improvement within this area of IBM i security.

Users with Powerful Authorities

IT professionals require special authorities to manage servers. These can also permit the ability to view or change financial applications, customer credit card data, and confidential employee files. In careless, misguided, or malicious hands, a user with special authorities can cause serious damage.

IBM i special authorities are administrative privileges and always pose a security risk, so auditors require you to limit the users who have these special authorities and carefully monitor and audit their use. Of the special authorities, *ALLOBJ is the one providing users with the unrestricted ability to view, change, and delete every file and program on the system. This is sometimes referred to as “root” authority. As shown in Figure 2, this authority is granted to users in unacceptably high numbers.

Only five systems have 10 or fewer users with *ALLOBJ authority. This year, 13% of users held *ALLOBJ, – an increase from 11% in 2023.

While *JOBCTL and *SPLCTL are the most frequently granted special authorities, (*IOSYSCFG) has been granted to 20% of users, marking a major increase from 6% in 2023.

Job Control provides the capability to change the priority of jobs and printing, or even terminate subsystems in some cases while I/O System Configuration allows users to add or remove communications configuration information, work with TCP/IP servers, and configure the internet connection server (ICS).

Password and Profile Security: Inactive Profiles

Inactive profiles are user profiles that have not been used in the last 30 days or more. They create a security exposure because these accounts are not actively maintained by their users, which make them prime targets for hijacking.

Many of these inactive profiles belong to former employees or contractors – people who might carry a grudge or who might find their former employer’s data useful in their new role at a competitor.

The threat persists even if ex-employees never attempt to utilize these profiles. Other users within the organization might know, for example, that the former IT director’s profile is still on the system. And whether an inactive profile is exploited by a former employee, a malicious insider, or a hacker, unusual use of the profile won’t be detected and reported by the profile owner.

Figure 3 shows an average of 851 profiles (47% of the total) have not signed on in the past 30 days or more. Of these, 494 of them remain enabled and ready to be used. Both categories have significantly worsened from their 2023 levels of 39% and 279 ready-tobe-used profiles. This is a serious drop-off in attentiveness to inactive profiles.

Password and Profile Security: Default Passwords

On IBM i, profiles that have a default password have a password that’s the same as the user name. Hackers – or even your own employees – can guess profile names like jsmith and try default passwords.

Regulatory and legislative standards typically mandate that users must utilize unique credentials known only to the user, ensuring that any actions can be tied to that specific individual. Organizations might struggle to prosecute illegal or unauthorized activity if it became evident that the credentials couldn’t unequivocally identify the culprit.

In this study, 7% of user profiles have default passwords (Figure 4). Thirty-six percent of the systems studied have more than 30 user profiles with default passwords. Eighteen percent are even worse off, with more than 100 users with default passwords. One system has a total of 3,941 user profiles with default passwords and nearly 81% of them were in an enabled state. Although there is still plenty of improvement to be made in this space, the percentage of user profiles with default passwords, systems with more than 30 user profiles with default passwords, and systems with more than 100 users with default passwords all decreased by nearly 50% from where they were in 2023.

Password and Profile Security: Password Length

Shorter passwords may be easier to remember, but they’re also easier for others to guess. Although short passwords can be strengthened by using random characters, the odds of correctly guessing a four-character password are greater than a longer password.

NIST now recommends using eight-character passwords, up from their previous recommendation of six characters.

Figure 5 shows the setting for the minimum password value on the systems reviewed. Only 7% of systems studied met the PCI DSS 4.0’s requirement of a 12-character minimum – a stark difference from the 48% that met the PCI’s eight-character minimum in 2023. Although largely falling short of PCI compliance, the number of systems studied that surpassed eight characters or more increased to 60% in 2024.

Shockingly, 11% of systems permit users to select a password that is less than six characters long and two servers permitted the use of single character passwords.

Password and Profile Security: Other Password Settings

IBM i allows system administrators to define password policy at a granular level. Password settings include length, character restrictions, digit requirements, expiration interval, and how soon a password can be reused.

These settings help make passwords harder to guess and increase the protection of your system, since simple, easy-to-guess passwords like “123456” and “password” remain disturbingly common. Imagine what could happen if your users with simple passwords have special authorities or access to sensitive data.

The latest data shows that older, more basic password controls have become widely utilized. For example, 66% of systems require a digit in passwords and 87% require passwords to differ from previous versions of the password, as opposed to 49% and 60% in 2023, respectively.

However, a more advanced system for password controls, known as QPWDRULES, is only being used by 35% of systems. QPWDRULES specifies a list of rules used to control whether a password is formed correctly, such as *REQANY3 which states that the password must contain characters from at least three of the following four types of characters: uppercase letters, lowercase letters, digits, and special characters. Adoption of QPWDULES thereby enforces the widespread use of password best practices among users.

Although the increase in use of basic password controls is a positive trend, QPWDRULES should serve as the standard for healthy password policy going forward.

Password and Profile Security: Invalid Sign-On Attempts

Passwords are forgotten, mistyped, or simply mixed up with other passwords. Help desk personnel charged with resetting these passwords often work with the same users over and over. How do you track which users have multiple invalid sign-on attempts? What if your powerful profiles are targeted? Larger numbers could indicate an intrusion attempt, while single-digit attempts are probably the sign of a frustrated user.

Fifty-three percent of systems have a profile that experienced more than 100 denied attempts. Twenty-six percent have more than 1,000 invalid sign-on attempts against a single profile. Six systems had more than a million attempts against a single profile, one of which had upwards of four million attempts.

Figure 6 shows the action taken when the maximum number of allowed sign-on attempts is exceeded. In 85% of cases, the profile is disabled and this is always recommended. When using explicitly named devices (as opposed to virtual device names) the recommendation is expanded to include disablement of the device description. It is not recommended to disable virtual devices, as the system typically creates a new device when the user reconnects. The device setting does not apply to all connections, such as ODBC and REXEC services.

The other 15% of servers disable the device, but leave the profile enabled. This creates risk if the user re-establishes a connection, or perhaps connects to a service that does not require a workstation device.

Shockingly, 2% of systems evaluated don’t have a maximum number of invalid sign-on attempts defined, allowing an unlimited number of guesses at users’ passwords.

*PUBLIC Access to Data

On most servers, users typically have no authority to an object or task unless they’re expressly granted permission. With IBM i, every object has a default permission that applies to non-named users, known collectively as *PUBLIC. This default permission is initially set by IBM with enough authority to read, change, even delete data from a file. Unless the user is granted a specific authority (granted or denied access), the user can leverage the object’s default permission. When *PUBLIC access rights are left unrestricted, there is a risk for unauthorized program changes and database alterations—red flags for auditors.

This study uses the *PUBLIC access rights to libraries as a simple measurement indicating how accessible IBM i data is to the average end user. Figure 7 shows the level of access that *PUBLIC has to libraries on the systems in our study.

*USE: *PUBLIC can get a catalog of all objects in that library, and attempt to use or access any object in the library

*CHANGE: *PUBLIC can place new objects in the library and to change some of the library characteristics

*ALL: *PUBLIC can manage, rename, specify security for, or even delete a library (if they have delete authority to the objects in the library)

Our findings demonstrate that IBM i shops still have far too many libraries accessible to the average user—libraries that often include critical corporate information. With virtually every system user having access to data far beyond their demonstrated need, administrators need better processes to control access to IBM i data.

*PUBLIC Access to New Files, Programs, and User Profiles

When new files and programs are created on most systems, the average user automatically has change rights to the vast majority of those new objects. Nonnamed users (*PUBLIC) have the authority to read, add, change, and delete data from the file. These users can copy data from, or upload data to, the file, and even change some of the object characteristics of the file.

This is because *PUBLIC’s authority to newly created files and programs typically comes from the library’s Default Create Authority (CRTAUT) parameter. Figure 8 shows that 19% of libraries have Default Create Authority set to *USE, *CHANGE, or *ALL. However, 76% of libraries defer the setting to the QCRTAUT system value (*SYSVAL). Figure 8A extends the library level assignment of *SYSVAL and reflects that the system value typically remains at the shipped default of *CHANGE. Just 7% of servers are configured to use the deny-by-default requirement of common regulatory standards such as PCI DSS.

Another issue occurs when a user profile is created with permissions granted to the general user population (*PUBLIC). When *PUBLIC permissions exceed the strongly recommended setting of *EXCLUDE, this is known as an “unsecured profile.” It is possible for an alternate user to run a job that leverages the privileges of the unsecured profile. This activity will not be logged by the operating system as a security violation, since it is deemed permissible at all security levels. Sixty percent of systems have at least one unsecured profile and 7% of systems have 10 or more profiles that are publicly accessible – showing an improvement from 14% in 2023. Publicly accessible and unsecured profiles have the potential to create a loophole around a QSECURITY setting of level 40 or 50.

Network Access

Services such as FTP, ODBC, JDBC, and DDM can send IBM i data across the network as soon as the machine is powered on. All end users need is a free tool from the internet or even tools pre-loaded onto a PC. For example, Windows comes with FTP client software that easily sends or retrieves data from an IBM i server.

Some TCP services even permit the execution of server commands. The easily accessed FTP service enables commands like Delete Library (DLTLIB) to be run by all users – even those without command line permission on their profile.

Firewall protection leads some IBM i pros to question whether systems are ever actually accessed in this way. However, the Fortra team witnessed an attack in progress where an intruder had successfully penetrated the perimeter and repeatedly tried to access a client’s system via FTP using several different user profiles, including ADMINISTRA and ROOT.

To reduce this exposure, IBM provides interfaces known as exit points that allow administrators to secure their systems. An exit program attached to an exit point can monitor and restrict network access to the system. An exit program should have two main functions: to audit access requests and to provide access control that augments IBM i object-level security.

Fortra reviewed 27 different network exit point interfaces on each system to check whether an exit program was registered. Forty percent of the systems have no exit programs in place to allow them to log and control network access (Figure 9). Although 40% is not ideal, it is a major improvement from 65% just a year ago. However, even on the systems with exit programs, coverage is often incomplete. Just 7% of systems have all 27 exit points covered. Adoption of exit programs has grown steadily in recent years, but many companies are still unaware of this wide-open network access problem.

Command Line Access

The traditional way to control access to sensitive data and powerful commands was to limit command line access for end users. And in the past, this method was effective.

In addition to configuring the user profile with limited capabilities, application menus controlled how users accessed data and when they had access to a command line. However, as IBM opens new interfaces that provide access to data and the opportunity to run remote commands, this approach isn’t as sound as it used to be.

Seventy-six percent of users have had their command line access revoked, leaving them unable to run most commands through traditional menu-based interfaces. Nine percent of users studied have both command line access and an enabled profile, which presents a very clear risk.

Several network interfaces do not acknowledge the command line limitations configured in a user profile and must be controlled in other ways. This means that users can run commands remotely, even when system administrators have purposely taken precautions to restrict them from using a command line.

Security Event Auditing

IBM i can log important security-related events into a tamperproof repository – the Security Audit Journal. This feature allows organizations to determine the source of critical security events, such as “who deleted this file?” or “who gave this user *ALLOBJ authority?” This information can make the difference between responding promptly to a security event and discovering a breach after significant damage has occurred. The challenge is that the volume of data contained in the Security Audit Journal is large and the contents are cryptic. Most IT staff have trouble monitoring and making sense of the logged activity.

Five percent of the systems reviewed do not have an audit journal repository – marking a significant positive change from 19% in 2023. Meanwhile, 6% of systems – compared to 28% in 2023 – are operating with the QAUDCTL system value setting at its shipped value of *NONE (Figure 10). This is the master on/off switch for auditing and globally blocks any system or object level events from being logged, regardless of the existence of the system audit journal. Setting QAUDCTL to *NONE suggests that administrators fired up the auditing function but subsequently turned it back off or perhaps were unaware of the necessity for additional configuration.

When organizations have activated the Security Audit Journal, it’s unclear how much insight the extensive data is providing them. A few software vendors provide auditing tools that report on and review the system data written to the Security Audit Journal. This year, 66% of systems have a recognizable tool installed. Considering this number was at just 25% in 2023, organizations are demonstrating an increased willingness to invest in security event auditing.

Protection from Ransomware, Viruses, and Other Malware

The traditional IBM i library and object infrastructure is considered highly virus-resistant, but other file structures within the Integrated File System (IFS) are susceptible to hosting infected files, which can then be propagated throughout the network. Recognizing this reality, IBM created system values and registry exit points to support native virus scanning.

Results from the 2024 IBM i Marketplace Survey indicate that 34% of IBM i professionals regard ransomware as one of their greatest IBM i cybersecurity challenges. Administrators are also starting to recognize that IBM i contains file systems that are not immune to infection and, under certain circumstances, native applications and even IBM i itself can be impacted.

When the servers in this study were reviewed for antivirus controls, 41% were scanning on file open, which is a massive increase from just 13% in 2023. This still means the other 59% are at risk of having internal objects impacted or of spreading an infection to another server in their network (Figure 11).

Conclusion

IBM i has a reputation as one of the most securable platforms available. One of IBM i’s great advantages is that sophisticated tools for securing, monitoring, and logging are built into the OS. But experts agree that IBM i security is only as effective as the policies, procedures, and configurations put in place to manage it.

This study highlighted a number of common security exposures and configuration management practices that must be addressed to protect the data on IBM i systems. No system became vulnerable overnight, nor is it possible to fix every security problem in a single day. What’s important is starting somewhere and making continued progress toward a stronger security profile.

If you’re unsure how to proceed, start with top priorities for IBM i security:

• System Security: Check the QSECURITY level and make sure it’s 40 or higher
• Security Auditing: Enable QAUDJRN and find a tool to help interpret it
• Network Access: Register the most common exit points like FTP and ODBC first
• User Permission: Reduce unnecessary user privileges

Most experts recommend starting with an assessment of vulnerabilities to understand where your system security stands today and how it could be improved. Security professionals with IBM i expertise and user-friendly software solutions are available to make this project faster and easier. Fortra offers a range of options, from a very thorough Risk Assessment to a quick, no-charge Security Scan.

Once you have all the information, you can begin formulating a plan that addresses your organization’s security vulnerabilities. And from there, security will become business as usual—not a moment of panic after a failed audit or a data breach.

About the Authors

Sandi Moore

Sandi has been working with Fortra customers for over 20 years, helping them to effectively address systems monitoring and cybersecurity challenges on IBM i. Organizations throughout the public and private sector rely on Sandi’s expertise, whether they’re looking to proactively protect their systems or improve security controls after a malware attack.

Amy Williams

Amy is a Senior Security Services Consultant who joined Fortra in 2015. She holds CISSP, CISA, and PCI-P certifications. Amy first began working on the IBM i platform in 1994 and her experience includes application testing, system installation, system administration, and architecture.

Our Security Solutions

Fortra is the leading expert in automated security solutions for IBM Power Systems servers, helping users manage today’s compliance regulations and data privacy threats. Our security solutions and services save your valuable IT resources, giving you ongoing protection and peace of mind.

Because IBM Power servers often host sensitive corporate data, organizations need to practice proactive compliance security. As an IBM Advanced Business Partner with an expansive worldwide customer base, Fortra understands corporate vulnerability and the risks associated with data privacy and access control.

Fortra security solutions and services are the corporate standard for IBM i security at many major international financial institutions. Fortra has demonstrated a proven commitment to the security and compliance market and leads the industry in raising awareness of IBM i security issues and solutions, leveraging the experience of some of the world's foremost IBM i security experts.