Brief: Changing your AS/400 security level is not as simple as changing the system value (QSECURITY) that controls it. You need to make sure that authorities are properly assigned before you switch to a higher security level. As a result, installations are often reluctant to increase the security level for fear of disrupting production users. This article recommends a step-by-step approach you can use to anticipate problems and minimize disruption.

The need for greater security can be the result of many factors: an increase in company size, a request from outside auditors or simply the recognition that too much access can be a dangerous thing. The first logical step in increasing security for your AS/400 is to change the QSECURITY system value which determines the overall security level for the system. But, as you will see, changing the security level without laying the proper groundwork is a bad plan. I'll walk through the preparations you should follow to change your security level in two parts: from Level 20 to Level 30, and from Level 30 to Level 40. With the approach outlined here you can provide a painless transition for your users.

Set Your Target

To help you determine your security goals, here's a review of the five levels of security available with V2R3 of OS/400.

 o Level 10: No system-enforced security. o Level 20: Sign-on security. o Level 30: Sign-on and resource security. o Level 40: Sign-on and resource security; integrity protection. o Level 50: Sign-on and resource security; enhanced integrity protection. 

The table shown in 1 illustrates the increase in protection at each security level.

The table shown in Figure 1 illustrates the increase in protection at each security level.

IBM ships systems at Level 10 to make installation easy. This does not mean that IBM recommends you run your AS/400 at Level 10. Every customer I have met recognizes the need for security and has changed the security level of his system beyond Level 10. To give you an idea of how AS/400 installations implement security, refer to the distribution of security levels shown in 2. If you have a new system, I recommend Level 40 since it is much easier to reduce the security level than to increase it after the system has production users.

IBM ships systems at Level 10 to make installation easy. This does not mean that IBM recommends you run your AS/400 at Level 10. Every customer I have met recognizes the need for security and has changed the security level of his system beyond Level 10. To give you an idea of how AS/400 installations implement security, refer to the distribution of security levels shown in Figure 2. If you have a new system, I recommend Level 40 since it is much easier to reduce the security level than to increase it after the system has production users.

Level 50, introduced in V2R3, is designed to meet the requirements defined by the U.S. Department of Defense for C2 security. It provides enhanced integrity protection for installations with strict security requirements. Level 50 is not recommended because the additional checking adds a 5-15 percent increase in CPU cycles. You'll find information on Level 50 in "Powerful Audit Functions Enhance V2R3 Security" (MC, February 1994).

Often, system owners find the menu security offered at Level 20 inadequate. Frequently, end users need access to a command line or need to use Query/400 to analyze the company's data. But, a user at Level 20 should not be given access to the command line or query facilities because his user profile's *ALLOBJ special authority gives him unrestricted access to all data on the system.

If your system is at Level 20, Level 30 offers a significant improvement in overall security but Level 40 will not cost you any additional performance or maintenance overhead. Level 40 security prevents potential integrity or security risks from programs that could circumvent security in special cases. The following summarizes the increased protection of Level 40.

Internal interfaces. The system prevents attempts to directly call system programs not documented as call-level interfaces (for example, directly calling the command-processing program for the SIGNOFF command). Other protection of internal interfaces at Level 40 and higher includes preventing access to internal system structures through the pointer capabilities of languages such as C, Pascal or MI.

Job submission. If a user profile name is used as the value for the USER field in a job description, any jobs submitted with the job description can be run with attributes taken from that user profile. An unauthorized user might violate security by submitting a job to run under the user profile specified in the job description.

At Level 30 security, the job runs if the submitter has *USE authority to the job description. At Level 40 and higher, the user submitting the job must have *USE authority to both the job description and the user profile specified in the job description. Otherwise, the job fails. This is the primary benefit of Level 40 over Level 30 for most AS/400 installations. The default authority for user profiles is *EXCLUDE, so users must be explicitly authorized to run jobs as other users.

Signing on without password. At Level 30 and below, signing on by pressing the Enter key without a user ID and password is possible with certain subsystem descriptions. At Level 40 and higher, the system stops any attempt to sign on without a user ID and password.

Validation of programs being restored. Beginning with V1R3 of OS/400, programs containing restricted instructions cannot be created. The execution of such programs created under previous releases is prevented at Level 40 and above. The system uses a technique called program validation to determine whether a program being restored to your system may contain restricted instructions, either because the program was created on an earlier release or because the object code has been changed.

My recommendation is that you run your AS/400 at Level 40 unless you have third-party software which cannot accommodate the Level 40 constraints. However, you should not plan on going directly from Level 10 or Level 20 to Level 40 if you have production active, so the preliminary steps needed to make a smooth transition to Level 40 are covered in two parts: Level 20 to Level 30 (this procedure will work for systems changing from Level 10 or Level 20 to Level 30) and Level 30 to Level 40. If you follow the procedures I've outlined, your management, users and auditors should be pleased and impressed with your new AS/400 security level.

Moving from Level 20 to Level 30

The change from Level 20 to Level 30 is done by changing the system value QSECURITY to 30. The activation of Level 30 does not take effect until the next IPL. When you change to Level 30 from Level 20, the system changes all user profiles the next time you perform an IPL. Special authorities are added to and removed from user profiles to match the default special authorities for the user class.

Unfortunately, conversion to Level 30 security is not that simple. If your system is running production applications at a lower security level, you should set up and test object-level security before changing to Level 30 security. If you change the system value without proper planning, your phone could begin to ring with end users frustrated because tasks they performed previously are now failing with "not-authorized..." messages. When you move to Level 30 security, *ALLOBJ authority is removed from all user profiles other than users in *SECOFR user class. Users who previously had *ALL access to all objects in the system must now have specific authorization to access the objects.

The following step-by-step process provides a smooth transition from Level 20 to Level 30.

1. Do not change the system value QSECURITY from 20 to 30 immediately. Continue to operate at Level 20 while you authorize users to objects.

2. Assign users to groups.

o Determine whether you have groups of users with similar job requirements who need access to the same information, such as users from the same department. Some users may not belong to such a group.

o As you create a group profile for users with similar requirements, specify the special authority of *NONE. The password for group profiles should be *NONE to prevent sign-on as the group profile. I recommend a naming convention for group profiles (such as GRPxxx) so that group profiles can easily be identified. An example of the command to create a group profile for the sales department is:

 CRTUSRPRF USRPRF(GRPSALES) + PASSWORD(*NONE) SPCAUT(*NONE) + TEXT('Sales dept group profile') 

o Use the Change User Profile (CHGUSRPRF) command to assign individual user profiles to a group.

When you assign users to a group profile, I recommend use of the parameter OWNER(*GRPPRF). This designates the group profile as the owner of new objects created by users of the group. The command to assign users to the group profile GRPSALES is:

 CHGUSRPRF USRPRF(user_profile) + GRPPRF(GRPSALES) OWNER(*GRPPRF) 

3. Create a test user profile. You can use the test user profile to detect any not-authorized conditions and correct the problems before production users are affected. When you create the test user profile, assign a special authority of *NONE and make the user profile a member of the group. The following command illustrates creation of the test profile for the sales group:

 CRTUSRPRF USRPRF(TESTSALES) PASSWORD(X) + USRCLS(*USER) INLPGM(--) INLMNU(--) + SPCAUT(*NONE) GRPPRF(GRPSALES) + TEXT('Test Profile for Sales Group') 

The parameter values indicated by '--' in the above command should be the same as those currently assigned to users in this group. An easy way to copy the parameters from an existing user profile is to use the Work with User Profiles (WRKUSRPRF) command and select the Copy option (option 3). This action returns a prompt for the new profile with the current values filled in. You only need to change the profile name, user class, special authority, group profile and text.

4. Find and correct "not authorized..." conditions using the test profile for the group.

o Sign on using the TESTSALES user profile and perform the tasks for a user from the sales group.

o When a task fails with a not-authorized message, use the Grant Object Authority (GRTOBJAUT) command to assign the required access to the group profile or make the access to the object *PUBLIC. An alternative to granting access is to use program adoption of authority.

o Continue using the TESTSALES user profile until you can perform all of the tasks for a member of the group.

5. Remove the *ALLOBJ authority from a single production user in the group.

o Inform this user that you are improving security. Instruct him to call you if he experiences any security-related application problems.

o Use the CHGUSRPRF command to remove the SPCAUT(*ALLOBJ) authority from that individual profile. If the production user gets not-authorized messages, grant the required access to *PUBLIC, the group profile or the individual profile. In most cases, objects should be authorized to *PUBLIC or the group profile, so other members of the group should not experience not-authorized messages.

o Continue until the production user is able to perform all tasks.

6. Remove *ALLOBJ from all other members of the group using the CHGUSRPRF command.

7. Delete the test user profile, TESTSALES, created in step 3 above. A common exposure found in many systems is excess profiles left over from testing or from users who have transferred jobs or left the installation. The best way to eliminate the problem is to delete the unused profiles immediately.

8. Repeat steps 3-7 for another group. Select one group at a time and complete that group before moving to the next group.

9. Process the users who are not members of group profiles. After you have given proper authorization to all production users who are members of a group, you will need to remove *ALLOBJ access from any remaining users who are not members of a group. The Display Authorized Users (DSPAUTUSR) command can list all of the user profiles and show their group membership. It can also list profiles that do not belong to a group profile. I recommend you process ungrouped users only after all groups are completed. This way, you reduce the number of calls you'll receive from users with not-authorized problems.

10. Authorize privileged users to workstations. If the QLMTSECOFR (limit security officer device access) system value is 1 (Yes), users with *ALLOBJ or *SERVICE special authority such as QSECOFR must be specifically authorized to devices at Level 30 security or higher. Give these users *CHANGE authority to the workstations they use.

11. Change the system value. When you have *ALLOBJ authority removed from all profiles except the users of the *SECOFR user class, you can change the system value QSECURITY from 20 to 30 without any disruption of the user community. When you change the system value from 20 to 30 and IPL, *ALLOBJ authority is removed from all user profiles. If you followed steps 1 through 10, the system does not have to add or remove special authorities to match Level 30 defaults.

Once the system value has been changed and the system IPLed, you should congratulate yourself. But be sure you don't overlook one final, important step. You have spent time getting the user profiles and groups properly authorized, so be sure to run a Save Security Data (SAVSECDTA) or a Save System (SAVSYS) command to back up the user profiles and authorities.

Moving from Level 30 to Level 40

The procedure for changing from Level 30 to Level 40 is similar to changing from Level 20 to 30, but your primary concern will be programs that violate the Level 40 constraints outlined previously.

1. Do not change the system value QSECURITY from 30 to 40 immediately. Continue to operate at Level 30 while you use auditing functions to determine if you can move to Level 40.

2. Create objects and activate auditing for potential Level 40 failures.

o Create a journal receiver to hold the audit data. This can have any user- assigned name and be placed in any library.

CRTJRNRCV JRNRCV(xxx/AUDIT0001) AUT(*EXCLUDE)

o Create the journal QAUDJRN in library QSYS, naming the journal receiver created previously.

 CRTJRN JRN(QSYS/QAUDJRN) JRNRCV(xxx/AUDIT0001) + AUT(*EXCLUDE) 

o Change the system value QAUDLVL to include *AUTFAIL and *PGMFAIL. The *PGMFAIL entry logs journal entries for any access attempts that violate the integrity protection at security Level 40. *AUTFAIL logs any access failures, including jobs submitted by users that would not have adequate authority at Level 40.

 CHGSYSVAL SYSVAL(QAUDLVL) + VALUE('*AUTFAIL *PGMFAIL') 

o If you are using V2R3, change the system value QAUDCTL to specify *AUDLVL. The command needed to activate auditing for V2R3 is:

CHGSYSVAL SYSVAL(QAUDCTL) VALUE('*AUDLVL')

3. Monitor the audit journal for *AUTFAIL and *PGMFAIL entries while running all your applications at Level 30 security. The Display Audit Log (DSPAUDLOG) tool supplied in QUSRTOOL provides a simple way to monitor the audit journal- sample output is shown in 3 on page 102. The domain failure message highlighted in the figure would cause the application to fail if the system value were set to 40. However, the DSPAUDLOG tool doesn't provide output to a database file. As a result, it does not allow you to select specific types of violations.

3. Monitor the audit journal for *AUTFAIL and *PGMFAIL entries while running all your applications at Level 30 security. The Display Audit Log (DSPAUDLOG) tool supplied in QUSRTOOL provides a simple way to monitor the audit journal- sample output is shown in Figure 3 on page 102. The domain failure message highlighted in the figure would cause the application to fail if the system value were set to 40. However, the DSPAUDLOG tool doesn't provide output to a database file. As a result, it does not allow you to select specific types of violations.

A better approach is to copy the data from the audit journal to a database file. Reports can then be generated using Query/400 or a user-written program. The steps to extract the data are:

o Use the Create Duplicate Object (CRTDUPOBJ) command to copy the system- supplied model file QASYAFJE in library QSYS to one of your user libraries.

 CRTDUPOBJ OBJ(QASYAFJE) FROMLIB(QSYS) + OBJTYPE(*FILE) TOLIB(xxx) 

o Use the Display Journal (DSPJRN) command to extract the AF type entries from the journal receiver into the newly created file.

 DSPJRN JRN(QAUDJRN) JRNCDE(T) ENTTYP(AF) + OUTPUT(*OUTFILE) OUTFILFMT(*TYPE2) + OUTFILE(xxx/QASYAFJE) 

o Create a query or program to print the file. Look for the following violation types in the AFVIOL field. Violation types B, C, D and R will usually prevent you from moving to Level 40 until you obtain or create a version of the software that supports Level 40. This should be a rare occurrence for most AS/400 shops since these violations are the result of direct calls to system programs usually initiated by C or MI programs. Contact your software vendor about support for Level 40 before you make the move.

 B: Restricted (blocked) instruction violation. C: Object validation failure. D: Unsupported interface (domain) violation. R: Attempt to access protected area of disk (enhanced hardware storage protection). 

o The following violation types can be corrected by authorizing users or changing your operational procedures.

J: Job-description and user-profile authorization failure. To run jobs at Level 30, users need authority to the job description (*JOBD). At Level 40, users must be authorized to both the *JOBD and the user profile name the job description used to submit the job. This problem can be corrected by giving the user *USE authority to the user profile specified in the job description.

S: Default sign-on attempt. At levels below 40, a subsystem can be built which allows a user to sign on without entering a user ID and password. You can correct this problem by having all users sign on using a user ID and password.

4. Use the Change Program (CHGPGM) command with the FRCCRT(*YES) parameter to create validation values for any programs that have not been created since V1R3. (A validation value is a checksum that validates the instruction stream of a program when it is restored.) At Level 40 security, the system translates any program that is restored without a validation value. This can add considerable time to the restore process. Save the programs using your normal backup procedures.

5. Change the QSECURITY system value to 40 and perform an IPL.

Don't Jump the Gun

Increasing the security level of your AS/400 can offer increased protection. But it is not as simple as just changing the system value QSECURITY. The potential disruption of production users can be eliminated if you follow the process described in this article.

Wayne O. Evans is an AS/400 security consultant and a frequent speaker on security topics. During his 27 years with IBM Corporation, he was involved with AS/400 security design issues. Direct your security-related questions to Wayne on MC-BBS or by fax at 507-252-9615.

A Guide to Changing QSECURITY

Figure 1 Levels of AS/400 Security

 UNABLE TO REPRODUCE GRAPHICS 
 
 A Guide to Changing QSECURITY
 
 Figure 2 Distribution of Security Level at AS/400 Installat
 
 UNABLE TO REPRODUCE GRAPHICS 
 
 A Guide to Changing QSECURITY
 
 Figure 3 Sample DSPAUDLOG Output
 
 OPTION - *CURRENT JRNLIB - *LIBL OUTTYP - *BASIC Start date - 3/28/93 End date - *LAST ENTTYP - *ALL Date Time Type Msg ID Message Text 3/29/93 8:00 SM CPI2256 System value QMCHPOOL changed by user QSECOFR. 3/29/93 8:17 CA CPI2253 Authority for object QTEMP/QNMACDQ type *DTAQ 3/29/93 8:18 CA CPI2253 Authority for object QSYS/QSWMSGRPY type *MSGQ 3/29/93 8:18 CO CPI2277 Object QSYS/QSWMSGRPY object type *MSGQ create 3/29/93 8:23 AF CPI2247 Domain violation by program QCACALL for object QSYS/QSCCPY type *PGM. 3/29/93 8:24 SM CPI2256 System value QIPLDATTIM changed by user QPGMR. 3/29/93 8:24 AF CPI2246 User QPGMR not authorized to object PAYROLL/WEEK02