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:
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:
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.
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:
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:
Selected security events can be logged to the security audit journal. The QAUDLVL system value controls the events that are to be logged including:
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.
For a free proposal to perform an audit of your organization or provide SOX support & testing services, contact Mitchell Levine of Audit Serve at (203) 972-3567 or via e-mail at Levinemh@auditserve.com.
Copyright 2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.
Join 3,500 other subscribers
Advertise with Us