IBM i/AS400 Security Risks and Best Practices to Look Forward in 2025

According to the 2024 IBM i Marketplace Survey, approximately 79% of IBM i professionals consider cybersecurity their top concern this year. This focus on security is largely due to the increased emphasis on external threats, such as hackers and organized crime, compared to internal threats, which involve authorized users misusing organizational assets deliberately or accidentally. Internal threats can create significant security gaps, heightening vulnerability to cybercriminal attacks. As cybercrime continues to evolve, it is essential to remain aware of IBM i security risks and implement effective safeguards for your organization.

Top 14 IBM i Security Risks and Best Practices for 2025

This section will highlight IBM i security gaps and the ways you can bridge them for secure business operations in 2025.

1. Inadequate QSECURITY

IBM offers a system value known as QSECURITY that specifies the level of security to be enforced on IBM i systems. In total, IBM provides five levels of security (10, 20, 30, 40, and 50). IBM recommends maintaining a security level of 40 and above. Systems operating below IBM’s recommended security level are vulnerable to exploits.

Professional Recommendation: Try to maintain a security level of 40 and above for a fortified security baseline. IBM i/AS400 security professionals have in-depth knowledge of these systems and can accelerate the process using best practices.

2. Weak Object Restoration Filters

During object restoration, IBM i uses its system values that act like filters to protect your system from restoring harmful or tampered files. However, IBM i’s default values are not strong enough to detect and prevent the restoration of malicious files, leaving systems vulnerable.

The three primary system values that determine whether an object should be restored or converted include:

• Verify Object on Restore (QVFYOBJRST): This system value decides whether to validate a signature during the restoration of a digitally signed object. Originally set at level 1, IBM recommends running servers on level 3. However, most organizations fail to maintain the recommended level, increasing the chances of tampered signatures being restored.
• Force Conversion on Restore (QFRCCVNRST): This value determines whether to convert certain object types during restoration. Although the preset level is 1, IBM recommends servers to run on level 3. Major servers often run below this recommended level, risking the likelihood of converting malicious objects to support and operate on their current IBM i systems.
• Allow Object Restore (QALWOBJRST): This value regulates whether to restore programs with authority adoption and system-state security attributes. Although its default ALL setting helps with IBM i licensed program installation and system recovery, it can prove dangerous, as it allows any authorized user to restore any object (whether secure or malicious) on your system. Therefore, using more secure settings is essential to protect your system during restoration.

Professional Recommendation: Devise a security policy tailored to your system needs that ensures these values are set at the most secure levels.

3. Excessive User Permissions

For IBM i server management, organizations often grant special authorities to numerous IT professionals in their organizations. Authorities like the ‘root’ authority (ALLOBJ) provide the unrestricted ability to view, change, and delete sensitive data, files, and programs on IBM i systems.

Other special authorities that organizations grant to their users include Security Administrator (SECADM), Job Control (JOBCTL), Spool Control (SPLCTL), Save System (SAVSYS), Service (SERVICE), Audit (AUDIT), and System Configuration (IOSYSCFG). You can learn more about these special authorities and their functionalities from IBM’s official documentation.

Granting IBM special authorities to numerous IT employees can pose a security threat to your digital assets. Employees knowingly or unknowingly may remove, steal, or tamper with sensitive information that can prove fatal.

Professional Recommendation: It is wise to limit granting privileged authorities to less than 10 users or 3% of the user community. In addition, try to enforce separation of duties, avoid all-powerful users, monitor and report their actions, and be ready to justify their access to auditors and managers.

4. Inactive Profiles

Profiles that have not been used for over 30 days become a prime target for getting hijacked. Ex-employees can use these profiles to get authorized access to your company’s valuable data and misuse it without your knowledge. Even current employees and attackers can use these profiles to reach the core of your organization. The fun fact is that these profiles’ unusual activities often go undetected and reported since no active owner monitors their use.

Professional Recommendation: Try implementing a policy to disable or delete inactive profiles after a defined period. After setting a specific period, remove special authorities and ensure no active group profile assignments for inactive users. Once you verify the profile is inactive and is not required for any other audit process, remove it from the system.

5. Poor Passwords and Credentials

In many organizations, employees tend to use passwords similar to their usernames for IBM i profiles. These easy-to-guess passwords are susceptible to brute-force attacks. Moreover, when such profiles are compromised, organizations have a hard time identifying the actual culprit behind illegal and unauthorized activities.

Professional Recommendation: You must establish concrete password policies that guide employees on the importance of creating and using unique credentials for their IBM i profiles. In addition, implementing the QPWDRULES system value can restrict users from creating and using default profile passwords. It is also essential to regularly audit and update passwords to prevent profiles from being hacked.

6. Short Password Lengths

Although short passwords are easy to remember, they are easy to guess as well. Despite strengthening them using random characters, shorter passwords can be easily cracked compared to their longer versions. Many organizations fail to meet PCI DSS 4.0-recommended passwords having 12 or more characters, making their systems vulnerable to brute-force attacks.

Professional Recommendation: Implement a password policy that requires users to create passwords having over 12 characters. Additionally, educate users on transitioning from passwords to passphrases comprising 20 to 30 characters that fortify profiles against brute-force attacks.

7. Ineffective Password Controls

Major organizations use basic password policies that often lead users to create guessable passwords. This often poses risks of user profiles being compromised containing IBM i core system’s special authorities or sensitive information.

Professional Recommendation: Try adopting advanced password policy systems like QPWDRULES that govern whether a password is correctly formed or not. QPWDRULES requires users to form passwords using digits, lowercase letters, special characters, and uppercase letters.

Additionally, implementing multi-factor authentication (MFA) can save systems from unauthorized access. IBM i built-in techniques like single sign-on (SSO) act as a great alternative to using passwords entirely.

8. Allowance of Innumerable Sign-On Attempts

Forgotten or mistyped passwords while signing into an account are common. However, repeated failed logins, especially against powerful profiles, could be a signal for intrusion.

Often organizations leave profiles enabled even after multiple failed sign-in attempts. It’s easy to disable the device description for explicitly named devices used to sign-in to the profile. However, virtual devices pose a risk since the system creates new ones when users reconnect. Additionally, some connection types, like ODBC and REXEC, do not follow these rules, leaving potential gaps in protection. Therefore, users can connect to a service that does not require a work device to sign in to the profile again.

Organizations also do not put a limit on invalid attempts that allow guessing password combinations as many times as they want.

Professional Recommendation: Set a maximum number of allowed sign-on attempts and disable profiles after this limit is exceeded. Additionally, consider using self-service password reset tools that can help users who forgot their passwords to rest them as required.

9. Public Data Access

The PUBLIC access right in IBM i allows non-named users without any authority to read, change, or delete critical data from numerous files and libraries. This right has several levels of access that allow unauthorized users to access and use library objects (using USE), change objects in a library (using CHANGE), and manage, rename, specify security, and delete libraries (using ALL).

Many systems still leave too many libraries open to average users by keeping PUBLIC access unrestricted, leading to unauthorized program changes, database alterations, and data breaches.

Professional Recommendation: Use resource-level security or exit programs to restrict the access of unauthorized users. Furthermore, set PUBLIC permissions to EXCLUDE where possible.

10. Public New File and Program Access

The Default Create Authority (CRTAUT) parameter of IBM i libraries provides unauthorized users PUBLIC access to newly created files and objects. The PUBLIC access provides a green signal to add, change, copy, delete, and read data and change object characteristics from files. This leaves new files and programs of a system vulnerable to exploitation.

Additionally, when a newly created user profile provides access to PUBLIC permissions that exceed the strongly recommended EXCLUDE setting, it creates security gaps even in IBM i systems having a QSECURITY level of 40 and 50. Unauthorized users can easily exploit these profiles without triggering security violations that organizations may find difficult to track and address.

Professional Recommendation: Implement security tools that enable secure, smooth data access to authorized users. You must also monitor changes made in your database information to meet regulatory compliance.

11. Lack of Network Access Control

IBM i services like FTP, ODBC, and JDBC allow users to send or retrieve data over the network using simple tools, including pre-installed software like Windows FTP. Some services even allow running powerful commands, like deleting libraries, without needing command line access. Without proper controls, this creates significant vulnerabilities.

Professional Recommendation: You must implement a custom IBM i exit program or commercial exit software to track user activities originating through FTP, ODBC, and other network access tools.

12. Insufficient Command Line Restrictions

Traditional methods like revoking command line access and using menu-based controls, are no longer enough to restrict sensitive data access. One reason is IBM’s open new interfaces that allow remote commands and data access. Unauthorized users can leverage network interfaces to bypass command-line restrictions set by administrators, execute commands, and access sensitive data remotely.

Professional Recommendation: Review network data access for risky activity, set clear file-sharing guidelines, and remove default DB2 access in tools like Access  Client Solutions, IBM i Client Access, and Microsoft Excel.

13. Improper Security Event Auditing

The IBM i Security Audit Journal is a powerful tool for logging critical security activities and events like file deletions, user authority changes, and more. However, the journal contains a large volume of cryptic data that can be difficult to monitor and interpret.

Some organizations disable the auditing journal systems in their systems leaving key events unlogged. On the other hand, many organizations lack the tools to process, analyze, and generate meaningful insights from these data.

Professional Recommendation: Activate the Security Audit Journal and use auditing tools for automated raw data analysis and reduced compliance reporting costs.

14. Malware Vulnerabilities

The IBM i traditional library and object infrastructure is highly virus-resistant. However, many file systems within the Integrated File System (IFS) are vulnerable to hosting and spreading infected files.

Due to this risk, IBM supported native virus scanning through registry exit points and system values. However, major organizations do not have proper antivirus controls, leaving them at risk of infection or spreading malware to other servers.

Professional Recommendation: Follow these steps to prevent malware from spreading in the current and other environments.

• Implement an exit program to the ‘QIBM_QP0L_SCAN_OPEN’ exit point. This will obstruct attempts to open files from the network and scan files before opening them, preventing viruses from spreading outside the environment.
• Integrate an IBM i native antivirus software. This software will identify and address infections as well as prevent the spread of malware outside the current environment.
• Incorporate an exit program at the ‘QIBM_QPWFS_FILE_SERV’ exit point. This program will limit remote virus actions on the network servers.

Conclusion

Cyberattacks are expected to cost around $10.5 trillion annually by 2025, leading to identity theft, extortion, data loss, business outages, and closures. While IBM i provides strong security tools, effective protection relies on proper configurations, procedures, and policies. Ensuring IBM i security is an ongoing process that requires the right strategies and approaches. If you’re not familiar with best practices, consider consulting with experienced IBM i security professionals who can help you raise your guards most effectively.