Don’t assume default settings keep your IBM i safe—what you need to check.

By: Pauline Brazil Ayala

The IBM i platform continues to run the core business of many Fortune 500 and Global 2000 companies for three main reasons: high performance, high availability, and strong security capabilities.

Regarding availability, it is not uncommon for IBM i administrators to say they haven’t had to IPL their systems in months. It is also rare to hear of sudden performance issues occurring on well-managed IBM i servers. Similarly, IBM i can be configured to be an extremely secure platform.

However, a common myth believed by some IBM i users is that the system is automatically secure as soon as you power it on. This is a dangerous falsehood. It is the responsibility of the IBM i security administrator to ensure the server is configured correctly to take full advantage of the platform's security capabilities. Default settings provide broad access to the system, which also carries inherent risks that need to be managed.

IBM has made several security-related improvements in recent OS releases. Notably, the latest OS release, IBM i 7.6, includes enhancements to better secure core system objects in the main system library (QSYS). While these improvements help make systems safer out of the box, organizations must properly configure and continuously monitor their IBM i environments to ensure critical security settings remain unchanged. Misconfigurations or configuration drift can expose the system to cyberattacks and potential data breaches.

This article reviews several key IBM i security settings and provides recommendations for securely configuring them.

System Level Configuration

Perhaps the most important configuration setting to verify is the Security Level (QSECURITY) system value. This system value should be set to at least level 40, which enforces sign-on security, resource security, and integrity protection. For stronger protection, you can set the level to 50, which adds enhanced integrity protection. If your system is at level 30 or below, changing this system value should be done carefully with proper planning and testing, since adding integrity protection could cause some legacy applications to fail. Also note that an IPL is required for changes to the QSECURITY system value to take effect.

Audit Configuration

Another foundational security configuration is auditing. Unfortunately, I have seen IBM i shops that have experienced security breaches discover that auditing was never configured. Without auditing enabled, there is minimal to no forensic data available to help identify the root cause of a cyberattack or data breach.

The Auditing Control (QAUDCTL) system value should be set to *AUDLVL and *OBJAUD to enable auditing. The *AUDLVL value activates the audit settings configured in the Auditing Level system values, QAUDLVL and QAUDLVL2.

Once *AUDLVL is defined in QAUDCTL, the OS will begin creating journal entries in the system audit journal (QAUDJRN) for the types of events configured in the QAUDLVL and QAUDLVL2 system values. At a minimum, the following audit events should be enabled: *SECURITY, *NETCMN, *AUTFAIL, *PGMFAIL, and *PGMADP.

You should also enable object-level and IFS auditing for mission-critical libraries and IFS folders. Object-level auditing can be enabled with the CHGOBJAUD command, and IFS folder auditing with the CHGAUD command.

Network Configuration

Out of the box, many network protocols are automatically started during the IPL process. Some of these may be unnecessary or potentially vulnerable. It is best to change your startup program to disable autostart jobs for unused or insecure network protocols.

When an IPL is performed on the system, the program QSTRUP in library QSYS is executed. You can customize the startup process by retrieving the source code using the RTVCLSRC command and then creating your own startup program. (Ref: https://www.ibm.com/support/pages/changing-ipl-start-program)

After creating a custom startup program, you can change the system value QSTRUPPGM to point to the new program.

Another important check is whether you have a mechanism in place to monitor and block remote traffic for protocols such as ODBC or JDBC. You can verify this by running the WRKREGINF command to see whether you have exit programs (either custom or third-party) registered on your remote server exit points.

Encryption Configuration

It is strongly recommended to encrypt data transmission to and from your IBM i using a suitable Transport Layer Security (TLS) protocol. This can be configured using the QSSLPCL system value. It is imperative to select a protocol that is not vulnerable. At the time of writing this article, the recommended value is *TLSV1.3. However, as security standards evolve, stronger protocols will become available, so it is good practice to periodically review your TLS configuration to ensure the protocol you are using has not been compromised or deprecated, and to update it accordingly.

System TLS uses the sequence defined in the Transport Layer Security (TLS) cipher specification list (QSSLCSL) system value to determine the order of the System TLS default cipher specification list. Older ciphers that are now considered insecure should be removed. Only the following modern ciphers should typically be enabled:

• AES_128_GCM_SHA256
• AES_256_GCM_SHA384
• CHACHA20_POLY1305_SHA256

The Transport Layer Security cipher control (QSSLCSLCTL) system value should be set to the user-defined (*USRDFN) value when you want to customize and enable or disable required protocols.

Resource Configuration

Certain system values related to restoring objects are important to pay attention to and configure properly.

The Allow User Domain Objects, QALWUSRDMN, system value allows you to limit what libraries can contain user domain objects of type *USRSPC, *USRIDX, and *USRQ. It is best to limit this to a list of libraries you have approved to contain these object types. These objects can be accessed via the Machine Interface (MI) language, enabling direct data manipulation and potentially introducing security risks.

Set the Allow Object Restore (QALWOBJRST) system value to prevent anyone from restoring a system-state object or an object that adopts authority. This system value affects programs, service programs, modules, and Structured Query Language (SQL) packages. This is important because Adopt Authority is a powerful feature in the IBM i OS that can allow a program to run as the program owner. If the owner has elevated privileges and a backdoor exists in the program, it could become a serious security risk.

The Verify Object on Restore (QVFYOBJRST) system value allows you to control signature verification of objects during a restore operation. This can help prevent the restoration of objects that do not have valid signatures.

Password Configuration

Modern cybersecurity threats have increased the need to enforce complex passwords on your system. Outdated configurations with weak password policies do not leverage the strength and complexity available on the IBM i and significantly increase the risk of credentials being compromised. For example, passwords requiring only a single case and a maximum of 10 characters can be cracked quickly in a brute-force attack.

Ensure the Password Level (QPWDLVL) system value is set to level 3 or 4 (available at IBM i 7.5 and above). These password levels support longer, more complex passwords and have stronger encryption. Changing the password level requires careful planning to ensure users can still sign on afterward, and an IPL is required for the change to take effect.

There are also several additional password-related (QPWD*) system values that should be configured to add further complexity to your password. This article goes into further detail: Attackers Don’t Hack IBM i - They Log In.

Ongoing Monitoring is Critical

As you can see, many settings must be configured correctly to secure your IBM i. Changing some of these is quite straightforward, such as enabling auditing, while others require more concerted planning and execution, as in the case of a security or password level change. Either way, you don’t want to make the common mistake of treating security as a one-time project - hardening the system, then letting the configuration gradually drift back into a vulnerable state. It is important to regularly monitor your security configuration to ensure that critical settings have not changed.

Security on IBM i is extremely powerful - but only when it is configured and maintained correctly.