The AS/400 and IBM i Security Guide

Why Most IBM i Security Advice Is Ordered Wrong

Search for AS/400 security best practices and you get a list. Usually a long one, usually alphabetical or grouped by product category, and almost never sequenced by what is actually broken on real systems. That ordering problem matters more than it sounds, because IBM i security work is nearly always done in whatever time is left over after everything else. If the first three items on the list are low-yield, that is the whole budget gone.

So we ordered this differently. The sequence below follows what industry assessments keep finding, most consistently in Fortra's annual State of IBM i Security Study, rather than what makes for a tidy checklist. The finding that shows up on the most systems goes first.

The Order We Would Work In

Best Practices That Survive Contact With a Real System

A best practice is only worth the name if it changes an outcome. These are the ones we would defend.

Treat *PUBLIC authority as the setting that decides your blast radius. QCRTAUT is frequently still at *CHANGE, which quietly grants every new object to everyone. Set library-level defaults deliberately rather than inheriting them, and check what your application vendor ships with, because that is where a lot of *PUBLIC *CHANGE actually comes from.

Adopt authority rather than granting it. Adopted authority lets a program run with elevated rights without the user ever holding them, which keeps the profile itself unremarkable if it is compromised. It needs care around program-called-program chains, but it beats the alternative of permanent special authorities on human profiles.

Separate the people who administer security from the people who are audited by it. On a lot of IBM i shops the same two people do both, which is understandable and still a finding. If you cannot separate the duties, separate the review: have someone outside the team read the audit journal reports on a schedule.

Assume the network is the front door. The single biggest structural change on IBM i security in twenty years is that most access no longer arrives through a terminal session. If a control only applies to 5250 sign-on, treat it as a partial control and write down what it does not cover.

Tips That Are Really Just Postponed Problems

Some advice circulates because it is easy to give, not because it works. Restricting users to an initial menu with LMTCPB(*YES) is the clearest example: it looks like access control and it stops nothing that arrives over ODBC. Renaming QSECOFR is another. It is not harmful, but it is a speed bump presented as a control, and it can create false confidence that something structural was addressed.

Scheduling an annual security review is the third. Annual is better than never. It is also long enough for an authority change made in March to sit undetected until the following January. If the review is genuinely annual, at least make the authority and profile reports monthly and automated, so the annual review is reading a trend instead of taking a snapshot.