Audit Serve, Inc.

The Worldwide Connection for Audit, Security, Control and SOX Professionals

Security Approaches Used in the AS/400 Environment

By: Mitchell H. Levine, CISA
Audit Serve, Inc.

                                                             

Low Cost & Highly Skilled 
IT Audit and SOX Consulting Resources Available Immediately
Call Mitch Levine at (203) 972-3567 or 
email levinemh@auditserve.com for additional information

This article is intended to be an introduction to the security approaches used within IBM's AS/400 system which covers many but not all of the security components that are available. Since there are so many areas within AS/400 that impact security, articles will appear in future issues of Audit Vision which will probe into the AS/400 security at the individual component level.

AS/400 Version 2 Release 3, which contains extensive security changes, was not incorporated into this article since it will not be available until the end of the fourth quarter of 1993 and may not be installed within your environment until several months after the release date. Therefore, in order to avoid confusion with respect to ongoing security reviews based on the current operating environment, we chose to include only information that is available within the current release levels.

Introduction to AS/400 Security
AS/400 is the hardware platform and OS/400 is the actual operating system. However, it is generally accepted to refer to the entire environment as an AS/400.

AS/400 provides an installation with the ability to gradually install security on a system using 4 security levels. Security level 10 and 20 do not provide an acceptable level of security since neither level restricts users from obtaining access to resources and level 10 does not even provide sign-on security. Security level 30 is the first security level that provides a somewhat acceptable basis for system security which is further increased within security level 40. Security level 30 contained some security exposures which would allow a technical user to potentially bypass security. Some of these exposures are discussed in the Operating System Security Issues section of this article. Security level 50 is new a security level, which is provided with Version 2 Release 3, that will not be available until the end of the fourth quarter of 1993.

Each user is defined with a user profile which determines the Special Authorities to which they are assigned, object they own, and authorities they have to other objects. A user can also be assigned to group profiles, which is used to define users who share common access requirements to objects. User Profiles can also be established to restrict a user to a specific application which prevents them from accessing the system at the command level. To establish this level of control the user profile must have the Limited Capabilities parameter set to *YES, along with either the Initial Program or the Initial Menu parameter set to a valid program or menu name (note: initial menu could be set to *SIGNOFF). In addition, the Attention Program parameter (ATNPGM) in the user's profile must be set to *NONE to prevent the user from using the Attention keys to break out of the application into the command line where they are able to execute CL commands (i.e., CL commands are provided by the operating system to allow users to perform operation, programming, and normal system interface functions). This type of control is typically established for general users who only require access to a specific application while not requiring access at the system level. For most of the users that support the system, the Limited Capabilities function would not be used. Within AS/400 all resources are referred to as objects. There are several dozen types of objects AS/400 uses which provides a basis for securing resources, such as:

• CMD Command
• MENU Menu
• PGM Program
• LIB Library
• FILE Database file

The Security Administrator establishes authorities to each of these objects and grants access to individual user profiles, group profiles, and to all users (i.e., using the *PUBLIC authority). Refer to Figure 1 for an example of an object authority access listing.

Object authorities have system defined authorities that automatically preset the Object and Data values. This example provides the system defined value for each object authority.

Object Authority Sets:

• *ALL - complete access
  *CHANGE - alter
  *USE - read and execute (i.e., if object is a program)
  *EXCLUDE - specifically denies access
  

Object Authorities:

• *OBJOPR - access determined by user's data authority to object
  *OBJMGT - specify security for the object, add members to data base file, move or rename object
  *OBJEXIST - delete object or transfer ownership
  

Data Authorities:

• *READ - view entries within an object or run a program
  *ADD - add entries
  *UPD - change entries
  *DLT - remove entries
  

The meaning of the object and data authorities varies according to the type of object. If the object type is *FILE, then the data authorities determine whether a user can read, add, update, or delete records within the data file. For a program object, the data authorities have no meaning. However, for an object which is defined as a *LIB, then the data authorities determine the access which a user has to the programs that are defined in the library.

Authorization lists are optionally available to group objects which share the same access requirements to which a user can be granted access.

Privileged Userids
Users can be granted privileges which extend beyond the level of access that they are granted to individual objects through the assignment of Special Authorities within their User Profile. The two most privileged Special Authorities are *ALLOBJ (All Object Special Authority) and *SECADM (Security Administrator Special Authority). *ALLOBJ allows a user to perform all operations to all objects which includes complete unrestricted access. *SECADM allows a user to create and change user profiles. A user can also obtain the *ALLOBJ special authority and all other authorities if their user profile has *SECOFR specified in the User Class parameter.

Other Special Privileges can be assigned to user profiles which should be restricted to the appropriate users:

• JOBCTL (Job Control Special Authority) Allows a user to control subsystem batch jobs (e.g., cancel job) and printing on the system.
• SPLCTL (Spool Control Authority) Allows a user unrestricted control of output queues.
• SERVICE (Service Special Authority) Allows a user to utilize service tools on the system. This function should be limited to system programmers who are responsible for handling system problems which may require obtaining dumps of the system internals.
• SAVSYS Allows a user to save and restore objects regardless of whether they have been granted access to the objects that are being restored.

System Access
AS/400 provides many evasive action controls which are used to prevent unauthorized access to the system which are set by Security System Values. These evasive action controls which are set globally for all users include:

• Displaying sign-on information to the user which indicates the date and time of their last sign-on and any unauthorized sign-on attempts. This information should be analyzed by a user to determine whether their userid was used by someone else or if an attempt has been made to disclose their password.
• An installation-defined value can be specified for the number of minutes of terminal inactivity before either cancelling a job or disconnecting a terminal.
• Setting a limit to a user's ability to logon to multiple terminals with the same userid at the same time.
• An installation-defined value can be defined for the number of consecutive incorrect sign-on attempts before either the device and/or user profile is disabled.
• The ability to distinguish between local and remote sign-on in order to prevent remote access completely or require normal logon security for remote access.
• An installation can define the number of days before a password must be changed. This is a system-wide value that can be customized for individual users within their user profile.
• Password construction controls are provided which require hard to guess passwords to be used. This includes controls to ensure a minimum number of characters used in a password, preventing previous passwords from being used, restrict repeating characters, and the use of commonly defined passwords. Additionally, preventing the use of commonly defined password is accomplished by specifying a program name and library which contains an installation written program to perform additional interrogation of the password to be used.

Selected security events can be logged to the security audit journal. The QAUDLVL system value controls the events that are to be logged including:

• Authority failures (i.e., invalid logon attempts or unauthorized access attempts to objects)
• Objects created
• Objects deleted
• System integrity violations (refer to Operating System Security issues)
• Restore operations
• Security related functions (e.g., changing of a user's password by the security administrator, changing a user profile, change system wide values)

Security Administration
The *SECADM special authority (i.e., defined in the user profile) is required for a user to administer user profiles. There are three methods provided to administer security definitions for objects; the *ALLOBJ special authority, being assigned OBJMGT authority within a specific object, or being the owner of an object.

The *ALLOBJ authority allows for the administration of access entitlements to all objects. However, it also allows complete access (i.e., cannot be limited by the *EXCLUDE object authority) to all objects. Therefore, the use of this approach for security administration should not be used.

Object ownership would be the easiest method to control security administration but will give the owner complete access to the object. However, defining an *EXCLUDE object authority for the owner would restrict them from having any access to the object but would allow for the administration of access entitlements for the object. Although the security administrator can remove this *EXCLUDE object authority, there would be an audit trail of this occurrence which should be reviewed by an independent person.

Individual objects can also be administered by those individuals who have been assigned the *OBJMGT object authority to the object. However, this approach is not a preferred method for administering sensitive resources since a user with *OBJMGT authority can only grant or revoke the authority that they have themselves. Therefore, in order to properly administer security for the object the user would require complete access to the object.

The Security System Values that globally impact security on the system are administered by users that have both the *ALLOBJ and *SECADM special authorities. All security values are dynamically changed except for the security level which will not take effect until the next IPL. Since Security System Values are rarely changed, and the *ALLOBJ authority should be restricted, an emergency ID can be established with the authorities required to performed this function of changing Security System Values.

Operating System Security Issues
A program is defined to be executed as a user state program or a system state program. Users cannot generate system state programs since IBM does not provide the translators that are required to define user created system state programs.

Objects are stored in either user or system domain areas. All objects are created in system domain areas except for three object types (i.e., user space, user queue, and user index) and user created programs. Security level 40 prevents user state programs from accessing objects stored in a system domain area except through IBM provided facilities (i.e., API).

Controls also must be in place to prevent users from having access to AS/400 dedicated service tools (DST) which would allow an individual to potential modify the operating system components in order to bypass security. To gain access to DST, an individual needs to have Service Special Authority, the key to the CPU to switch the CPU mode, and the DST password.

This article was written more than one year ago. Events 
may have changed since this article was written.

Copyright  2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.

This article appeared in a past issue of the Audit Vision E-Mail Newsletter.

Technical Articles | Conferences | Audit Programs | Audit Serve Seminars | Consulting Services | Audit Vision Newsletter | What's New | Contact US

This website has been optimized for Netscape and Internet Explorer 4.0 and above.  Your comments and suggestions are always welcome, please email webmaster@auditserve.com.
Copyright © 2000  All rights reserved.  27 Pine Street, Suite 700, New Canaan, CT 06840 USA.