Secure my IBM i – Verify That System Values Haven’t Been Changed

Securing Your IBM i System with WRKSYSVAL SYSVAL(*SEC)

If you are like me, always tinkering with your Power Systems box to keep it locked down tight, then you need to get familiar with the WRKSYSVAL command. Specifically, using it with the SYSVAL(*SEC) parameter. This little gem is your gateway to tweaking the core security settings on your IBM i system.

Let’s spend a minute talking about what it does, how to use it, and why it is a must-have in my security toolkit.

What is WRKSYSVAL Anyway?

First off, WRKSYSVAL stands for Work with System Values. It is a command-line tool that lets you view, change, or even print out the various system values that control how your IBM i operates. System values are like the configuration knobs for your entire OS. They cover everything from date formats to performance tuning, but we are zeroing in on the security ones today.

When you run WRKSYSVAL SYSVAL(*SEC), it filters the list to show only the security-related system values. This makes it super handy because you do not have to scroll through hundreds of irrelevant settings. Just the stuff that matters for keeping bad actors out.

To fire it up, hop into your machine and type:

WRKSYSVAL SYSVAL(*SEC)

You will see a panel listing all the *SEC system values. From there, you can use option 5 to display details or option 2 to change them. Remember, changes to system values often require an IPL (Initial Program Load) to take effect, so plan accordingly.

Key Security System Values You Will See

Here is a rundown of some of the most important ones you will encounter with SYSVAL(*SEC). These are the heavy hitters for system security:

• QSECURITY: This sets the overall security level of your system. Levels range from 10 (minimal security) to 50 (maximum). At level 40 or 50, the system enforces object authority checks rigorously, which is great for production environments. If you are still at 30 or below, it is time to crank it up.
• QAUDCTL: Controls auditing. Want to log security events like failed sign-ons or object access attempts? Set this to *AUDLVL or *OBJAUD to enable journaling. Pair it with QAUDLVL for fine-grained control over what gets audited.
• QAUDLVL: Specifies the types of actions to audit. Values like *AUTFAIL for authority failures or *SECURITY for security changes help you track suspicious activity.
• QCRTAUT: Defines the default authority for newly created objects. Set it to *EXCLUDE or *USE to prevent public access by default. This stops users from stumbling into things they should not.
• QLMTDEVSSN: Limits the number of device sessions per user. Crank this down to 1 or 2 to prevent session hijacking or multiple logins.
• QPWDEXPITV: Password expiration interval. Set it to something reasonable like 60 days to force regular changes without annoying your users too much.
• QDSIGNON: Controls what happens after too many invalid sign-on attempts. Lock out profiles after 3 fails to thwart brute-force attacks.

There are more, like QPWDLVL for password complexity and QRMTSIGN for remote sign-on controls. The full list depends on your IBM i release, but *SEC pulls them all together neatly.

Using WRKSYSVAL SYSVAL(SEC)* provides a centralized and efficient way to review all IBM i security‑related system values, making it far easier to audit configurations, identify weak spots, and align settings with IBM’s recommended best practices. It supports stronger system hardening by allowing quick adjustments to critical values, such as raising QSECURITY or enabling comprehensive auditing and it helps companies demonstrate compliance with standards like PCI‑DSS, SOX, and GDPR through easily documented settings.

Regular reviews of these values keep security proactive, especially when new PTFs introduce updated recommendations, and the command integrates smoothly with CL or RPG automation through RTVSYSVAL and CHGSYSVAL, enabling security to fit naturally into DevOps workflows.

NOTE: Test changes in a non‑production environment first, since incorrect adjustments can inadvertently lock out administrators.

WRKSYSVAL SYSVAL(*SEC) is an essential command for anyone serious about IBM i security. It puts the power to review and tweak your system’s defenses right at your fingertips. Start using it today to lock down your setup, and you will sleep better knowing your data is protected.

Print System Security Attributes (PRTSYSSECA)

You can also run the Print System Security Attributes (PRTSYSSECA) command, which provides a comparison of the system’s current settings with IBM’s recommended settings. PRTSYSSECA produces a consolidated report of all security‑relevant system values and network attributes, giving administrators a single place to review the current security posture of the system. This eliminates guesswork and scattered manual checks.

Easy Comparison Against Best Practices
The PRTSYSSECA report includes both the current value and the IBM‑recommended value for each attribute. This makes it simple to spot misconfigurations, weak settings, or deviations from baseline security standards.

Identifying Security Exposures
Because PRTSYSSECA highlights differences between your system’s configuration and IBM’s recommended settings, it becomes a powerful tool for identifying potential vulnerabilities.

Strengthening Your IBM i Security Baseline

Before you start tightening individual system values, it helps to understand why these particular settings matter so much. A handful of IBM i security attributes carry far more weight than the rest they influence authentication strength, password hygiene, intrusion resistance, and overall system integrity. Getting them right forms the backbone of a hardened IBM i environment. The following sidebar highlights the key values every administrator should review, along with practical best‑practice recommendations to keep your system aligned with modern security expectations.

If you are new to IBM-i Security and want a shortlist of essential system values to check, then have a look at these:

QSECURITY : Set my IBM-i Overall Security Posture

QSECURITY defines how strictly the system enforces object authority, authentication, and integrity protections. Best practice:

• QSECURITY 40 for most environments
• QSECURITY 50 for regulated, audited, or highly sensitive systems

Level 40 blocks unsupported interfaces from bypassing object security, while level 50 adds additional integrity protections that prevent user‑controlled code from manipulating system objects. Anything below 40 is considered insecure by modern standards.

QPWDLVL : Longer more secure passwords

If you’re still on older password levels, upgrade:

CHGSYSVAL SYSVAL(QPWDLVL) VALUE('3')

• Level 3 supports long passwords and mixed-case
• Requires an IPL to take effect
• All systems running modern IBM i releases should be using level 3 or 4

Once long passwords are enabled, users can create passphrases like:

“CorrectHorseBatteryStaple2024” “MyFavoriteCoffeeIsEspresso!”

These are easier to remember and far harder to crack.

QPWDRULES : Enforce Modern Password Strength

QPWDRULES consolidates all password‑related controls into a single, flexible rule set. It supports passphrases, character classes, reuse prevention, and more.

Best‑practice recommendations include:

• MINLEN(12) or higher
• MAXLEN(128) to allow passphrases
• CHGPGM(NONE)* to prevent programmatic password changes
• REQDGT(1) and REQUPPER(1) for complexity
• HSTPWD(12) or more to prevent reuse
• DGTMIN(1) and LCASE(YES)* for mixed‑case enforcement
• PWDPOSITION(ANY)* to avoid predictable patterns

The goal is to encourage long, strong passphrases rather than short, complex passwords.

QPWDEXPITV : Control Password Expiration

QPWDEXPITV sets how long a password remains valid before the user must change it.

Best practice:

• 60–90 days for traditional password environments
• 180+ days if using strong passphrases and MFA
• 0 (no expiration) ONLY when MFA and passphrases are enforced and the risk model supports it

Short expiration intervals are outdated unless passwords are weak. Modern guidance favors long‑life passphrases combined with strong complexity rules.

QMAXSIGN : Limit Brute‑Force Attempts

QMAXSIGN determines how many failed sign‑on attempts are allowed before the system disables the profile.

Best practice:

• 3–5 attempts before disabling the profile
• Pair with QMAXSGNACN(DISABLE)* to lock the profile rather than disconnect the session
• Combine with QINACTITV and QINACTMSGQ to manage idle sessions

A low threshold stops automated guessing attacks quickly while still giving legitimate users a reasonable margin for error.

Wrapping Up

Securing an IBM i isn’t about one big change, it’s about consistently tightening the fundamentals. When you understand the system values that shape your security posture, you’re no longer reacting to problems; you’re preventing them. Review these settings regularly, document your baselines, and treat security as an ongoing discipline rather than a one‑time project. Your future self and your auditors will thank you for it.

If you’re following along with the rest of this “Secure My IBM i” series, keep going. Each small improvement builds toward a stronger, more resilient system. And if you’ve got questions, ideas, or war stories that I can write about – I’d love to hear them.