Information Systems Control Journal, Volume 2, 2002
A Beginner's Guide to Auditing the AS/400 Operating System
By Judith S. Bines, CISA, CPA, CFSA, CBM
Over the last few years, due to the demand for more information technology work, there has been a trend of operational and financial auditors transitioning to performing IT audit. This new brand of auditor is challenged with learning IT, yet often does not have all of the necessary resources available to assist in this process. When faced with this dilemma, one must remember that everyone was a novice at least once.
Most will think that auditing an operating system is a high-tech adventure. Well, sometimes it can be. Any audit can be made as technical as the auditor performing the task is creative.
The main purpose of this article is to help the novice auditor, IT or otherwise, perform an AS/400 operating system review. All the auditor will need is a little background, access to an AS/400 security administrator and/or an AS/400 user ID, and knowledge of a few commands.
First, an auditor must understand what an operating system is. The easiest way is to think of the operating system as the core or foundation of the computer environment. The operating system is the foundation upon which all other programs rely. For example, in a microcomputer environment, Windows 2000, Novell Netware or Windows NT would be the operating system or the foundation upon which the application programs such as Microsoft Office, Netscape Navigator, QuikCAM camera, QuickBooks or Turbo Tax would rely. In a midrange environment, the OS/400, AIX or UNIX operating systems would be the foundation upon which an installation's general ledger system, human resource system or warehouse processing system would rely. The same concept also applies for the mainframe environment.
So, the next question may be: what is an AS/400? IBM's Application System 400 (AS/400) was the successor to the former System 36 and System 38 midrange computers used primarily during the 1980s. The AS/400 is an object-oriented system that uses an operating system called the OS/400. Object-oriented means that everything related to the AS/400 platform is considered an object. Programs, files, printers, users and databases all are considered objects. If possible, it is a good idea to do background reading and a little research on the platform to be audited, if the documentation is available. This will help the auditor feel more comfortable about the tasks to be performed. AS/400 books can make this task much easier to manage.
When performing an AS/400 review, one should think of several key audit areas:
System configurations System authoritiesSensitive user profiles/default user IDs and Passwords
User profiles (individual and group)/ authorization lists Sensitive utilities/ commandsLibrary and program access (otherwise known as object access)
Job descriptionsAdopt authoritySystem key lock
Note: This is just a partial list of the areas that can be covered during a review of the AS/400 operating system.
System Configurations
System configurations (SYSCONFIGs) are the parameters (PARMs) used to define how the OS/400 operating system will function and how secure the operating system will be. When trying to think of what these configurations and parameters do in terms of the OS/400 operating system, think of them as the switches or settings that tell the operating system what to do. The security of the operating system is crucial in ensuring the reliability and integrity of the applications that work in conjunction with it, as well as the with the data on which the company relies. There are several configuration parameters that should be reviewed:
System security level--The AS/400 QSECURITY parameter should have the recommended minimum-security level of 30, although level 40 and 50 guarantee a much more effective security environment. A QSECURITY level of 10 or 20 should not be used if at all possible. These security levels provide the minimum amount of security and allow users to have the authority to edit and change all AS/400 objects (*ALLOBJ authority).
Password format options--The key AS/400 parameters are QPWDMINLEN (recommended value five or more), QPWDMAXLEN (recommended value no more than 10), QPWDRQDDIF (prevents new passwords from being the same as the previous XX passwords used, where XX represents the number of password reiterations that cannot be used), QPWDLMTREP (prevents a character from being used more than once in a password, e.g., a password of EEEEEEEE), QPWDLMTADJ (prevents passwords with numbers next to each other, e.g., a password of 12345678) and QPWDEXPITV (recommended value no more than 90 days).
Limit security officer--The best-case scenario is that the parameter QLMTSECOFR is set to one, which means that the security officer is limited to work at certain workstations that have been assigned. This may not be feasible in all installations due to the current networking environment.
Maximum sign-on attempts--The parameter QMAXSIGN should be set to disable a profile after a minimum of three to five attempts.
Create object authority--The parameter QCRTAUT should be set to either *USE or *EXCLUDE. This will prevent all newly created objects from being created with a DEFAULT level of authority that is too high (e.g., *ALL or *CHANGE). If set to *USE, sensitive utility programs should be considered and access adjusted where necessary.
Attention key program--The parameter QATNPGM is the parameter that defines what program is called when a user hits the ATTN key on a computer or uses a CTRL BREAK to exit an application program. If this is not properly defined, a user could potentially gain access to the AS/400 command line. If this occurs, and if security is NOT properly defined, the operating system, its data and its programs could be compromised. As the audit proceeds, make sure there is a program defined here so a general application user (e.g., an accounts payable clerk) cannot gain AS/400 command line access.
Auditing--The parameter QAUDCTL should be set to audit the areas deemed to be the highest risk for the organization. There are 14 systemwide parameters that can be used when auditing. One or all of the options can be audited.
System Authorities
(Logical Access Security)
The AS/400 operating system controls logical access. Logical access security is made up of seven special authorities including *ALLOBJ (allows a user to access and update all system resources), *SECADM (allows a user to perform security administration functions such as adding users), *SAVSYS (allows a user to perform save and restore functions/backups), *JOBCTL (allows a user to manage job and job queues), *SERVICE (allows a user to perform service functions), *SPLCTL (allows a user to perform print and spool functions) and *AUDIT (allows a user to change audit characteristics). Special authorities are associated with a specific user class. The DEFAULT access provided to that user class would vary depending upon the level of security defined (e.g., level 10, 20, 30, 40 or 50). The higher the security level, the more restrictive the access provided to the user classes becomes.
There also are four specific object authorities including *OPJOPR (allows a user to use an object), *OBJMGT (allows a user to move/rename an object and defined members to database files), *OBJEXIST (allows a user to control and manage an object), *AUTLMGT (allows a user to add and remove users and their authorities on an authorization list), and four specific data authorities, including *READ, *ADD, *UPD and *DLT, that can be assigned to a user.
A combination of the four specific object authorities and the four specific data authorities will grant a user either *ALL access to an object (i.e., similar to granting a user the QSECOFR or super user ability, effectively allowing this user to manipulate any AS/400 object), *CHANGE access to an object, *USE access to an object or *EXCLUDE access to an object.
There also is a public authority which grants access to any user not defined by special or specific authorities and *EXCLUDE authority, which specifically denies a user access to the object. It is important to be familiar with all of this information when reviewing and testing user profiles and when reviewing and testing AS/400 objects (e.g., programs, files).
Sensitive User Profiles
When testing user profiles, there are seven IBM-supplied user profiles that can easily be tested to ensure the default passwords have been changed from their username. The profiles and their passwords are:
User Profile Password User Profile Password
QSECOFR QSECOFR QSRVBAS QSRVBAS
QPGMR QPGMR QSRV QSRV
QUSER QUSER QDFTOWN QDFTOWN
QSYSOPR QSYSOPR
The easiest way to test these is to access the AS/400 sign-on screen. Type the user profile name listed above and the password at the AS/400 sign-on screen. If able to get in, exit by hitting the EXIT (PF3) key and write the exception. If not comfortable with this, request that the security administrator run the command ANALYZE DEFAULT PASSWORDS (ANZDFTPWD).
Note: Passwords for the IBM-supplied user ID, QSECOFR, should be changed and kept in a secure location. It also is recommended that procedures controlling and monitoring the access and usage of the QSECOFR user profile be developed by the installation under review. Passwords for the remaining user profiles should be changed and/or disabled from sign-on usage. If these passwords are not properly secured, the installation is subject to be compromised by internal and external hackers.
Default User IDs and Passwords
In a process similar to the IBM supplied user IDs, information technology professionals often will name user IDs for application systems, transmission devices and the like with a user name and a password that are the same. Understanding why this task is done is simple. It is definitely much easier to remember one item rather than two when setting up user IDs and passwords. This concept, however, can cause a control concern, especially when that user ID can be used either on the application system or on the operating system by persons not authorized to use them. All of these user IDs will not be sensitive, however, there are sure to be some that, if used by a hacker or a disgruntled employee, could potentially bring the system down. To test for these user IDs and also for the IBM-supplied user IDs listed previously have the security administrator run the command ANALYZE DEFAULT PASSWORDS (ANZDFTPWD). Once the list is obtained, the sensitivity and access allowed by the user IDs should be reviewed.
User/Group Profiles and Authorization Lists
User Profiles
Depending on the installation, user profiles can be defined in several different ways. There can be individual user profiles, group profiles or authorization lists used to define access to the AS/400 programs, files, data (e.g., objects). A user profile is used to define the user's ability to access and or manipulate AS/400 objects. Users can be information technology professionals working on the installation, IBM service representatives or contractors, and end users such as auditors, accountants or general ledger clerks. A user profile is defined by listing various attributes that will allow that user to access specific libraries, programs or menus, and any groups to which the user is assigned, along with other key information.
A sample of users should be tested when performing an AS/400 operating system review. The security administrator should print a list of all users. Once the listing is obtained, the command DISPLAY USER PROFILE BASIC INFORMATION can be used--DSPUSRPRF USRPRF (user profile name) TYPE(*BASIC) OUTPUT(*PRINT)--to see specific detailed information on a sample of users.
Group Profiles and Authorization Lists
Group profiles can be tested if they are used at the installation. A group profile is a user profile used to assign the same access rights to multiple individuals. Group profiles should be properly managed so individual accountability within the profile is retained. Group profiles also should have the password set to *NONE so they cannot be used as a sign-on ID and allowed to compromise accountability. Authorization lists can be tested if used by the installation. Authorization lists allow user profiles to have different authorities assigned that are independent of all other users. The authority assigned applies to all AS/400 objects that are secured by the list.
Sensitive Utilities/Commands
Several sensitive utilities should be reviewed when performing an AS/400 review. A utility is a program or set of programs that allows a particular task to be executed. The goal in the audit is to understand on a high level what the utility allows a user to do, how access should be defined for that utility and who should be able to use the utility. Within the AS/400 environment, several utilities should be reviewed. The utilities are:
Data file utility (DFU)--This utility can allow a user to manage and manipulate the contents of data files WITHOUT an audit trail.
Source entry utility (SEU)--This utility allows source code to be edited and manipulated online.
Screen design aid (SDA)--This utility allows a programmer to create screens and menus.
Interactive data definition utility (IDDU)--This utility allows a user to create and maintain record formats, data dictionaries (DDs) and file definitions (FDs).
Programming development manager (PDM)--This utility allows a user to select and manipulate objects. Typically, access to this tool should only be granted to programmers.
Sensitive commands such as the DELETE LIBRARY (DLTLIB), CREATE USER PROFILE (CRTUSRPRF), CLEAR LIBRARY (CLRLIB), CHANGE SYSTEM VALUE (CHGSYSVAL), CHANGE DST PASSWORD (CHGDSTPWD), CREATE LIBRARY (CRTLIB) and the DELETE DFU PROGRAM (DLTDFUPGM) should be reviewed along with other sensitive commands.
The utilities listed previously can be reviewed by entering the DISPLAY OBJECT AUTHORITY command and the utility name (e.g., DSPOBJAUT DFU) at the AS/400 command line. The auditor will want to review every user profile, group profile and/or authorization list that has access higher than *EXCLUDE and will want to determine the need for that user or group of users to have the access that is defined.
Dedicated Service Tools (DSTs)
DSTs are special utility programs used to manage the AS/400 system including installations and resetting the QSECOFR password. Three levels of DST tools are available to the installation. The levels are security, which allows a user to perform all functions including changing the DST passwords and resetting the QSECOFR password; full, which allows a user to perform service-related functions; and basic, which allows a user to perform functions that do not access sensitive data.
Each level has a default IBM password that should be changed and maintained in a secure location. The passwords for each level are as follows: QSECOFR (security), 22222222 (full) and 11111111 (basic). These passwords usually can be found in the IBM user manuals. It should be noted that to use the DSTs, the AS/400 needs to be brought down.
Some installations may feel that if the area is truly secured and if the AS/400 key is not left in the machine, the risk of a security breach is limited. (See system key lock section for additional information.) Auditors approached with this scenario will need to evaluate the environment and the ability to obtain access to the information. Otherwise, the best approach is to ensure these passwords are changed.
Library, File, Program and Print Queue Access
When performing the AS/400 operating system review, the auditor may wish to sample and evaluate access to key programs, files, libraries and print queues (otherwise known as AS/400 object access). The names of key objects can be obtained from the IT department, and/or the names of key objects can be obtained from workpapers maintained within the department for key application systems that may be used within the organization.
Print queues should be reviewed, especially if there is sensitive output assigned to those queues. If the print queues are not properly secured, unauthorized users can use the WORK SPOOL FILE command (WRKSPLF) to view and print the contents of the sensitive spooled print files in the queue. Users with the *SPLCTL authority should be reviewed when determining if there is sensitive output that should be secured within the output queues.
Another key factor to remember when reviewing object access is object ownership. Within the AS/400 environment, whomever creates an object OWNS that object and therefore retains all rights to that object. So, a programmer who creates a production object (e.g., utility, file, program) remains the owner of that object and retains all rights to that object unless the security administrator revokes the rights. It is important that installations begin the process of correcting data ownership immediately, since the impact of improper ownership could result in a system shutdown, unauthorized access or data manipulation and a cumbersome process of cleaning up each object once the error is realized.
Data ownership should be defined by a generic profile (e.g., QPGMR) that cannot be used to sign on.
Job Descriptions
Job descriptions are used when jobs are run on the AS/400. Job descriptions allow users who need the same output queue, job queue and library list to process the information without having to reestablish the same parameters each time the job is run.
Job descriptions pose a security risk if the installation is running at a level 30 and if a user profile such as QSECOFR is in the USER parameter field. This is because at a level 30 or lower security level, an AS/400 user needs only *USE access to the job description to obtain the access rights associated with the task performed by that job description. At a security level of 40 or higher, an AS/400 user would need access to both the job description and the user profile to obtain access and submit jobs under that user ID.
To obtain a printout of the job descriptions, the command DISPLAY OBJECT JOB DESCRIPTION can be used. Type DSPOBJ OBJ(*ALL/*ALL) OBJTYPE(*JOBD) OUTPUT(*PRINT) at the AS/400 command line. Once the job description list is obtained, use the command DSPOBJAUT(job description name) to find out who owns the job description and who has what access rights to that job description.
Adopt Authority
Adopt authority in the AS/400 is a feature that extends authority of one AS/400 user to another AS/400 user when a job is run. Many times installations will use QSECOFR authority as the ADOPT authority required when running a job, even when it is not necessary. During the audit, the command DISPLAY PROGRAMS THAT ADOPT or DSPPGMADP USRPRF(user profile name) OUTPUT(*PRINT) should be used to list all programs that adopt the IBM-supplied user profiles, specifically QSECOFR. The security administrator should be able to explain why each program requires the authority and why it needs to be set up under that particular user profile to execute.
System Key Lock
The system key lock is a means of physically securing the AS/400. It allows the system to be set on different modes: manual, normal, auto and secure.
The manual mode exposes the highest security threat to an operating system. This mode allows anyone with access to the system console to perform manually an initial program load (IPL), run dedicated service tools (DSTs) and turn off the system power. This mode is not recommended.
The normal, secure and auto modes are typically used at most installations, with auto and secure being the most restrictive from a security standpoint. In all cases, the key should not be left in the machine. The key should be removed and stored in a secure location.
References
IBM--AS/400 Advanced Series: Tips and Tools for Securing Your AS/400
Ernst & Young Technical Reference Series: Audit, Control and Security of the IBM AS/400
Author's Note
To obtain a printout of the parameters tested, use the WORK PRINT SPOOL FILE command to see and route the output to the proper network or local printer. Type WRKSPLF your user ID/name at the AS/400 command line to execute this printing task.
Judith S. Bines, CISA, CPA, CFSA, CBM
has more than 18 years' experience in the internal audit profession. She currently is pursuing an M.S. degree in taxation and has received an MBA in finance. She is an IT audit manager with the AmerisourceBergen Corporation and the co-owner of CoSource Partners, LLC, which specializes in accounting, audit and tax-related work.
|
