If you’ve ever heard me speak on the Fundamentals of IBM i Security, you’ve heard me describe its three core aspects: system values, user profiles, and object security.

Editor's Note: This article is excerpted from chapter 2 of the security book, Mastering IBM i Security, by Carol Woodbury.

It seems only appropriate then that the first part of this book excerpt series describes how to modernize monitoring and managing these three core aspects, starting with system values.

I’m starting with a discussion of accessing and managing the security-relevant system values because they set the tone of security on IBM i. In addition, two of the most important system values have major changes in IBM i 7.5. Let’s start with those changes.

QSECURITY

The QSECURITY system value sets the level of security on the system. There used to be five values that you could specify for QSECURITY: 10, 20, 30, 40, and 50. But when I was still leader of the IBM i (AS/400 at the time) security team, we removed the ability to specify security level 10. Upgrading the system would not change the value, and you could restore your system values and get to level 10, but you could not change it if it somehow got set to something other than 10. As of IBM i 7.5, level 20 is no longer available. Again, you can upgrade your system and stay at level 20; however, if you restore IBM i to a system in which the original value is something other than 20, attempting to restore the QSECURITY system value set to 20 will fail. The system will set QSECURITY to whatever the original value was.

I applaud IBM for removing this value. It’s truly irresponsible for any organization to be running at a level where all profiles are created with *ALLOBJ special authority! That said, I know that some organizations are still running at security level 20 (more than people realize, I believe). I’m hoping this change by IBM will cause these organizations to get a project in place to make this change. To aid in that process, I’m providing specific guidance on the process I’ve used to move organizations from security level 20 to 40 (as well as 30 to 40). For guidance and tips, see chapter 3, Moving to a Higher Security Level, and chapter 9, Successfully Securing Files Using Authority Collection, IBM i Services, and Auditing.

The second major change in IBM i 7.5 is to the QPWDLVL system value. A new password level (level 4) has been added, and the old LANMAN password, which was the one differentiator between password levels 0 and 1, has been removed from the system entirely (it has never been stored on levels 1 and 3). IBM i 7.5 removes it from levels 0 and 2. both level 0 and 2. The LANMAN password was used only when connecting to IBM i via a file share from a client running Windows 95, 98, or ME or Windows 2000 Server. Since none of those operating systems are supported (and haven’t been for ages), IBM has taken the step to remove the storage of that old and vulnerable password. Therefore, there is no longer a difference between password level 0 and 1.

Unlike the change to QSECURITY, you can still set QPWDLVL to a lower level. If your organization isn’t already at level 3, I encourage you to make that move. Then, after upgrading to IBM i 7.5, make the move to password level 4. I provide guidance for moving to a higher password level in chapter 4, Moving to a Higher Password Level.

Now let’s take a look at how you can access your security-relevant system value settings. Of course, there’s the tried-and-true Work with System Value (WRKSYSVAL) command.

In fact, you can narrow down what’s displayed by running the following to see only the security-related system values:

WRKSYSVAL *SEC

But what if you want to use New Navigator for i or SQL? In the section below called New Nav: System Values, we’ll look at New Nav. But first, let’s take a look at the two options SQL provides.

QSYS2.SYSTEM_VALUE_INFO

Run without any qualifying WHERE clause, this service lists all system values along with their current value. You can modify it to list all of the password system values since they all begin with ‘QPWD’ like this:

SELECT *

FROM QSYS2.SYSTEM_VALUE_INFO

WHERE system_value_name LIKE ‘QPWD%’;

But there’s no easy way to list just the security-related system values like there is with WRKSYSVAL. For this reason, I find this service to be of limited use. However, I think you’ll find this next service quite useful.

QSYS2.SECURITY_INFO

This service is similar to running the Display Security Attributes (DSPSECA) and Display Security Auditing (DSPSECAUD) CL commands along with the Retrieve Security Attributes API (QSYRTVSA). But instead of calling two CL commands that only go to display or write to an API, you can retrieve all security-related values (including security-relevant system values) in one easy select statement!

If you’ve ever run DSPSECA, you know that it displays somewhat random security configuration information, but if you need that information, it’s the only place you can discover it. For example, I find it useful to run DSPSECA to determine if a change to either QSECURITY or QPWDLVL has taken effect or is still pending. DSPSECA shows both the current and pending values. (Remember, it takes an IPL for changes to these system values to take effect.) Note: If the current and pending values are the same, only the current value is displayed. And I find running DSPSECAUD helpful to determine which audit journal receiver is currently attached. For more information about QSYS2. SECURITY_INFO, see https://www.ibm.com/support/pages/node/6442035

While this information is valuable, the format of the information returned is not that easy to consume. All of the information is returned on one line. You must endlessly scroll to the right of your Run SQL Scripts display to see all of them. Enter New Nav. What you’re going to realize once you’ve used IBM i Services and New Nav a few times is that they are very tightly connected. New Nav uses IBM i Services to present most of its information. Let’s see how New Nav displays this information.

New Nav: Security Information

To see the information provided by the QSYS2.SECURITY_INFO service in New Nav, log into New Nav, float your cursor over the padlock, and click on Security Configuration Info, as shown in Figure 2.1.

Figure 2.1: Click on the padlock icon and then Security Configuration Info to see the listing of security information, current and pending settings, and a description of the value.

What’s displayed is an aggregation of the system values returned when running WRKSYSVAL *SEC, the security attributes displayed when running DSPSECA, and the audit configuration settings displayed when running DSPSECAUD. A description of each system value, attribute, or configuration setting is provided, along with its list of possible values. One thing I appreciate about this view is that each possible value is explained, as shown in Figure 2.2. Under the covers, New Nav has called the QSYS2.SECURITY_ INFO IBM i Service but is displaying it in a much more consumable format than if you’d run the service in Run SQL Scripts.

Figure 2.2: An example of two values shown under the Security Configuration Info category.

I find this view quite helpful, and I think you will too, especially if you don’t work with IBM i security very often or you’re new to the topic.

New Nav: System Values

You can also get a listing of all system values, including the security-relevant system values, in New Nav. To access these values, float your cursor over what, to me, looks like a clipboard. See Figure 2.3.

Figure 2.3: Click on the clipboard then System Values to view and manage all system values.

The system values are grouped into categories. To display or change a value, click on (highlight) the category (the system values in each category are listed in the right column), and then right-click and choose Properties. Figure 2.4 shows an example of the properties for the Signon category.

Figure 2.4: Click on the Signon category to display/change the signon-related system values.

If you need a description of each security-relevant system value or recommendations for best-practice settings, see chapter 3 of IBM i Security Administration and Compliance, Third Edition.

Using the Audit Journal to Detect System Value Changes

I have many clients that require regular review of system value changes. The best way to do that is to review the changes using the SV audit journal entries. While you can use the method that’s been around for many, many releases (Copy Audit Journal Entry (CPYAUDJRNE)) and then run a query on the resulting file QTEMP/QAUDITSV, I prefer to use the method IBM is now providing for us: a one-step method to pull the entries out of the audit journal.

The following will produce a list of system value changes made in the last two weeks, omitting the changes made via the QNTC server.

SELECT entry_timestamp,

user_name,
system_value,
new_value,
old_value

FROM TABLE (

systools.audit_journal_sv(STARTING_TIMESTAMP => CURRENT TIMESTAMP - 14 DAYS)

)

WHERE system_value <> ‘ADJUTC’;

Want to learn more?  You can pick up Carol Woodbury's book, Mastering IBM i Security, at the MC Press Bookstore Today!