Admin Alert: Locking Down i5/OS System Security Values

This week, I’m demonstrating a technique for protecting your system security setup from unauthorized changes by other i5/OS administrative users. Introduced in i5/OS V5R2 and located inside System Service Tools (SST), there is an operating system configuration that lets you lock down security settings so that no users can change your preset i5/OS security scheme. Here’s how it works.

Why Lock Down Security Changes?

The main reason for shutting down your security scheme is for. . . well, security. Your iSeries, System i, or Power i box may reside in a regulated environment where only one or two security officer users are authorized to make system security changes. By using the Allow System Value Security Change function inside SST, you can ensure that only one security officer user and a backup (if desired) can change your security setup. This can prevent a corrupted insider with the proper authority from manipulating security values to allow unauthorized access. To lock down system security settings, perform the following steps.

1. Since the QSECOFR User ID inside SST can change all SST settings, change the QSECOFR user’s SST password so that no one can use that profile to turn the Allow System Security Change function back on after you turn it off. For information about changing SST user ID passwords, see the Service Tools User IDs and Passwords entry on the i5/OS Information Center, Version 5, Release 4 Web site. Don’t worry about someone using the Change IBM Service Tools Pwd (CHGDSTPWD) command to reset the SST QSECOFR user ID to its default password. CHGDSTPWD can only be run when you are signed on as the QSECOFR user profile. If you’ve locked down the QSECOFR user profile and the ability to change its password, no one will be able to reset the QSECOFR SST user ID to its default value.
2. Create one or more security officer-based SST user IDs for your designated security officer and a security officer backup, if desired. These user IDs should have all the same service tools privileges that the QSECOFR SST user ID has. Again, see the Service Tools User IDs and Passwords entry in the Information Center for details on how to set up these SST user IDs.
3. Lock down your system security values using the technique outlined in the rest of this article.

By performing this configuration, you can reasonably be assured that your system security values are locked down and only the designated security officers can change them.

How To Lock Down i5/OS System Security Values

Go into SST by executing the Start System Service Tools (STRSST) command. Enter your SST User ID and password when prompted. This brings you to the SST main screen.

Take option 7, Work with System Security. SST will then take you to the Work with System Security screen.

Although this screen contains three options for locking down i5/OS security configurations, today I’m focusing on option 1, Allow System Value Security changes. This value is set to “1=Yes” by default, which allows users with proper authority to change all i5/OS system values dealing with security. You can view and work with these values on the green-screen by running the Work with System Values (WRKSYSVAL) command with the following parameter.

WRKSYSVAL SYSVAL(*SEC)

You can also view these values in iSeries Navigator (OpsNav). Unlike the green-screen, the security system values are not grouped in one place in OpsNav. They are located under different grouping names inside the Configuration and Service→System Values node. To view any individual security values, you first have to open up the system value group they belong to. For example, to view your system’s password security policies, click on the Configuration and Service→System Values→Password node and you will see the following screen.

It’s a simple matter to lock down system security values in SST by using the Work with System Security screen shown above. To prevent anyone from changing security settings, all you have to do is change the Allow System Security Values Changes setting from “1=Yes” to “2=No” on the Work with System Security screen.

After this change, all security values will be locked down and no one will be able to change them. If someone tries to change a security value on the green screen, they will get the following message.

Locking down security values also protects changes made through OpsNav. If I try to make the same password security change on the OpsNav Password System Values→Expiration screen, I’ll get the following message.

By locking down security, I can protect my security scheme from accidental or intentional security changes. When I need to make an actual security change, I can simply go back into SST and turn the Allow System Value Security Changes value back on again.

What Security Values Are Locked Down?

When you lock down system security value changes, no user will be able to change system values in the following categories.

• Auditing system values–System values that activate and control auditing settings for system objects.
• Device system values–Values that control device configurations, the number of automatically created QPADEV* devices for telnet sessions, and the actions to take when a device error occurs.
• Jobs system values–Define the time-out interval and the action to take when a job times out.
• Password system values–System password composition rules, password expiration parameters, password validation program, and the password reuse cycle.
• Message and service system values–Defines whether the system can be serviced remotely.
• Restore system values–Specifies whether a signed object can be restored, and whether to force object conversion on a restore.
• Security system values–Define the basic security level of the system and other security settings on the system.
• Sign-on system values–Affect where security officer users can sign on, how many sessions a telnet user can start on the system, and what happens when a user performs too many invalid sign-on attempts.

Determining Whether Security Values Are Locked Down

If you are unable to change a system security value and you are not sure whether the Allow System Value Security Changes function is turned on or off in SST, IBM offers an easy way to check. Simply type in the Display Security Attributes (DSPSECA) command from a green-screen command line, and the operating system will show you the following display that lists out all the partition’s relevant security values.

This way, you can easily tell whether or not the security settings have been locked down.

About Our Testing Environment

All configurations described in this article were tested on an i5 box running i5/OS V5R4. We also used the iSeries Navigator product that comes with iSeries Access for Windows V5R4. This article has not been tested with the i 6.x operating system, but these techniques may also work with that operating system. The SST Allow System Value Security Change function is only available in i5/OS V5R2 and above.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot