jopdf0801-auditing-ibm.pdf

Copyright © 2008 ISACA. All rights reserved. www.isaca.org.Auditing IBM AS/400 and System i By John Earl any information security professionals know what to look for when auditing a Windows machine, as they are quite practiced at it and there are a lot of resources that help them stay current. Although IBM System i (the IBM midrange platform formerly known as the AS/400 and the iSeries) architecture has been around for more than 25 years, the amount of information available about how to audit the system is scarce—and not because the system is unimportant. System i is found in just about every industry vertical and contains some of the most critical data an organization must protect. Credit card numbers, bank accounts, healthcare histories, customer lists and payroll records are all processed and stored on System i. More than 400,000 systems are estimated in production use in the loyal install base throughout the world, and 16,000 banks run core banking and financial applications on System i. Some of the better-known software vendors that provide applications are Oracle (JD Edwards ERP), Lawson/Intentia (Financials), Jack Henry and FiServ (Core Banking), SSA (BPICS, MAPICS, Infinium and Infor ERP applications), and Manhattan Associates (Supply Chain). Given the mission-critical data that are kept on the system, maintaining a secure configuration should be a top priority. However, many of these systems are poorly configured and poorly managed, but are given a clean bill of health by IT auditors. In working with companies that run System i, some errors/problems this author has found include: • IT auditors working from old and outdated checklists, and seeming to be unaware that a full Transmission Control Protocol/Internet Protocol (TCP/IP) networking capability was introduced to the system back in 1993 • IT auditors unaware of new capabilities (and risks) that have been introduced in recent versions of the operating system • IT auditors not looking for issues that are specific to System i • IT auditors mistakenly assuming that limiting command-line access (using the limit capabilities [LMTCPB] option on user profiles) is adequate to control access to sensitive data (It is not.) This article outlines the key set of controls and configuration settings that need to be checked in any basic review of System i and its i5/OS operating system. In many places, a reference is provided to the relevant i5/OS command required to retrieve the data, or alternatively the Compliance Assessment1 tool, which gathers all of the relevant data into one convenient report. M enterprise-class relational database, DB2/400. Thus, auditing the System i environment is similar to auditing the combination of Microsoft SQL Server running on Windows Server, or Oracle running on a UNIX system. It is not possible to have a System i that does not have DB2/400 running. One of the strengths of i5/OS is that it is an object-based (not object-oriented) architecture, which makes it extremely resistant to viruses. In fact, viruses that can plague Windows or UNIX operating environments have no affect on a System i because (among other reasons) the object-based architecture can distinguish between files and programs and refuses to execute files. The most common control deficiencies on the System i occur because of the incredibly loose authority structure under which most shops run. On the typical System i, applications have been configured such that every user has complete access to every object on the system (equivalent to read/write/execute). For example, in many of the banks that run on System i, every teller can read and modify every account. At thousands of retail giants, every one of the users on System i can read and use credit card numbers stored in database tables. In healthcare environments, no one can definitively say who has looked at or changed various pieces of data. And, in all of these environments, although the operating system provides basic tools to do so, no one can produce logs that describe what has happened on the machine. Six Keys to Security This article outlines six key areas that need to be checked in an i5/OS environment. It explains how to spot the common exposures, why they pose a threat and how best to remediate those problems.2 The areas that need to be investigated are: • Network access • Program, file and library security • User security • Powerful administrator (root level) privileges • System values • Logging and auditing Network Access Perhaps the greatest area of risk on OS/400 systems is the unprotected access that most end users have to the system from their desktops, laptops and mobile devices. The Big Risk: User Access Through the Network When version 3.1 of OS/400 was released in 1994, IBM not only introduced a robust TCP/IP stack to the AS/400, but also enhanced its host servers’ capability to allow the system 1 A Unique Operating System First, the basic principles of the operating system should be reviewed. i5/OS (FKA OS/400) includes an integrated JOURNALONLINE remote command and remote SQL should be monitored and controlled. File and Library Security Next the object-level security assigned to programs. he ran a remote command that attempted to delete his joblog. which is installed with every copy of IBM Client Access. the system administrator can now see information such as “User JOHN connected to system XYZ from remote IP address 196.m. To determine if the system has exit programs attached. which prevented users from entering commands at a standard OS/400 menu. However. Services such as FTP. This control was coupled with the limited capability parameter on the user ID. These exit point application programming interfaces (APIs) allow a system administrator to attach a program to the TCP/IP servers that will see inbound and outbound data requests and have the ability to record. Users now have complete access to all of the data because they continue to carry *CHANGE authority (equivalent to rwx) to the data and because they can use simple tools such as File Transfer Protocol (FTP) or Microsoft Excel (using Open Database Connectivity [ODBC] connections) to download or upload data between their personal computing devices and System i. Program. and at 10:31 a. OS/400 Meets TCP/IP The introduction of the TCP/IP stack changed all of this dramatically. it also introduced exit points for various TCP/IP servers. During these times. this is not a problem. for example. remote command or ODBC. 2 what files may be accessed. and even fewer understand networking well enough to understand which services should be turned off. the favored way of protecting data from end users was to limit their application access to a green screen menu system.1. users were typically connected to AS/400s through fixed function. IBM has shipped System i from the factory with all TCP/IP services enabled and ready to talk to the outside world. and what level of logging and alerting is desired for these transactions. Without exit programs in place. he sent a request to download the Payroll file. If the Compliance Assessment tool can be used.3. the most widely distributed PC to the System i connectivity tool. If the individual objects in the database are well secured.m. alter or even block these transaction requests. The system administrator should be asked to produce logs of exit point traffic. an integrated database also means that every user who has a valid user ID and password to the operating system can access the database system. Prior to OS/400 release 3. The result is that nearly every i5/OS-based machine that sits on a network is at risk of having every piece of confidential data on that system disclosed or corrupted by any user with a valid user ID and password.104 at 10:22 a. Figure 1—Remote Access Servers That Can Be Protected by Exit Programs Exit Point Server Description *DDM Alternate ODBC server *DQSRV Client data queue server *FILESRV Remote file server—used when drives are mapped to integrated file system *FTPCLIENT FTP client on the iSeries—used for requests originating from the System i server *FTPSERVER FTP server on the iSeries *NDB ODBC and JDBC native database *RMTSRV Remote command server *RTVOBJINF ODBC and JDBC retrieve object info *SQL ODBC and JDBC sign-on (logon) *SQLSRV 1 ODBC and JDBC server *SQLSRV 2 ODBC and JDBC server *TELNET TCP/IP terminal emulation *DATAQSRV Remote data queue server *FTPREXEC Remote command through FTP *REXEC_SO Remote command sign-on (logon) *TFRFCL Client file transfer server To inspect whether exit programs are deployed on a system. data files and libraries (database collections) should be reviewed. Figure 1 lists the most important remote access servers that can be protected by exit programs. This was widely received as a great leap forward by all users of the machine because it simplified the task of transferring data to and from personal computers. In this way users were easily prevented from wandering about the system and peering into places they should not. Few system administrators take the time to investigate what services are open and conversational...” On the downside. At the time that IBM enabled the TCP/IP stack on OS/400. there are no logs or alerts of any data transfer activity or requests over FTP.6. a huge exposure was unleashed at the same time because of the shoddy way that OS/400 objects were secured up to that point. the FTP server’s exit point. This is one of the reasons the system earns the suffix “i” for “integrated. the WRKREGINF command is used and the list is scanned to find the exit point servers named in figure 1.to more easily exchange data with connected personal computers (many auditors are working off checklists that have not been updated since this time). nonprogrammable (dumb) terminals. At 10:24 a. Public Authority to Objects One of the benefits of i5/OS is that it has an integrated database (DB2/400) contained within the operating system. IBM did not provide the exit programs. along with a brief description of the function provided. With an exit program attached to. the system administrator can create access rules (much like firewall rules) that will control which users can use which services. the usual authority settings for JOURNALONLINE . Unfortunately. the WRKREGINF and the DSPNETA commands should be used and the servers listed in figure 2 examined.m. for example. and review the access rules that control the exit programs.” Armed with this level of information. Direct access to System i (iSeries) data is possible through a Microsoft Excel Plug-in. then the display shown in figure 2 will provide the results. Since the 1990s. but rather left it to its customers or third-party providers to provide these essential security services. the default setting (as shipped from the factory) for newly created objects is that *PUBLIC receives *CHANGE access. Additionally. First. the object authority must be displayed. and individually specified authorities are rare. history and inertia have conspired to leave this setting in place.Figure 2—Exit Program Display OS/400 objects (files. the following list of users appears: • JOHN: *ALL • DAN: *USE • SCOTT: *EXCLUDE • *PUBLIC: *CHANGE In this case. etc. To see whether a particular system allows too much authority to important application objects. A well-secured System i either has all application objects and libraries secured against public access (*PUBLIC = 3 . This is for two reasons. when the DSPOBJAUT command is issued on the PAYROLL file. *PUBLIC has *CHANGE access to virtually every object on the system. Who Is *PUBLIC? It is important at this time to understand the concept of *PUBLIC. and it is quickly evident why system administrators do not typically secure individual objects to individual users.000 objects on the system. including object deletion rights). John. *CHANGE access not only allows a user to read and change the contents of a file. and the other 797 users on the system are members of the group *PUBLIC. Typical assignments are *ALL (complete rights to the object. Studies have found that the average number of users on a system is approximately 800. Typical syntax for this command is: • DSPOBJAUT OBJ(Library_Name /File_Name) OBJTYPE(*FILE) • DSPOBJAUT OBJ(Library_Name) OBJTYPE(*LIB) The Compliance Assessment display is shown in figure 3.000 to 50. To do this. there are few objects that detail individual access because setting individual object authorities is a far too cumbersome task for most system administrators. *CHANGE (the rights to change the contents and outer shell of an object). Dan and Scott have explicit authority to the PAYROLL file. there is an explicit authority assigned to *PUBLIC. Multiply that by an estimated 20. but also to add or delete entries in the file and to change some of the external properties of a file (*CHANGE is roughly equivalent to rwx on a UNIX system).) are for everyone (*PUBLIC) to have at least change (*CHANGE) rights to all parts of an application. Although this authority is almost always too permissive. *USE (the rights to use or read the object) and *EXCLUDE (no rights to the object). programs. For every object on a system. On most OS/400-based systems. the OS/400 DSPOBJAUT command must be used. Assuming one has a system with 800 users and there is a file on that system called JOURNALONLINE PAYROLL. The audit should also review the procedures for when an employee is terminated or changes jobs. On Microsoft systems. The IT auditor should check the object authorities of some items in the library and some of the critical applications on the system. System i assigns to new user profiles a default password that is the same as the username. There should be adequate controls in place to ensure that the level of privilege assigned to the new profile is consistent with the employee’s job responsibility. Passwords are required to be changed on a regular basis. An exit program remediation would be essential to quickly safeguard the data. damaged or stolen data. Password level 3 is recommended and requires longer. JOURNALONLINE . along with recommended values. A disabled profile is essentially in a suspended state since it cannot be used to log on to the system even if the password is known. This is where the previous two items come together with potentially disastrous results. If the auditor finds that there are no exit programs protecting network access points from client tools such as FTP and ODBC and *PUBLIC has broad access (*CHANGE. 4 By default. then the system is at critical risk of having lost. Controls should be in place to ensure that profiles are not created with default passwords. which restricts passwords to a maximum of 10 characters in length and uppercase letters only. User Security As with other platforms. Access to libraries should be restricted to only users who have a demonstrated need. Group profiles that have broad access rights to database objects should be identified—this is a common back door. and a special character. On OS/400. The security system values can be viewed by typing DSPSYSVAL SYSVAL(QPWD*). a number. which are called user profiles on i5/OS. An enabled profile is an active profile that can be used to log on to the system. the process for the creation of new user profiles on the system should be audited.Figure 3—Compliance Assessment Display *EXCLUDE) or provides some mitigating control that prevents users from directly accessing those objects. mixed-case passwords. organizations should maintain adequate control over the creation and modification of user accounts or logon identities. and individual access should be granted where there is an appropriate business need. It is recommended that IT auditors first check *PUBLIC’s access to production libraries. there is no way to force a special character without writing custom code in a password validation exit program. As part of a comprehensive information systems review. The full set of password-related settings (called system values on i5/OS) that need to be checked is outlined in figure 4. security policy often enforces strong passwords that require the use of at least one uppercase and one lowercase letter. Public access should be set to *EXCLUDE. or worse). Most organizations run at password level 0 or 2. The nonintuitive values are: 0=Any password can be used 1=Cannot be the same as last 32 2=Cannot be the same as last 24 3=Cannot be the same as last 18 4=Cannot be the same as last 12 5=Cannot be the same as last 10 6=Cannot be the same as last 8 7=Cannot be the same as last 6 8=Cannot be the same as last 4 A system exit program that sees and controls password changes. Operator (*splctl) (*services) (*Jobctl) Backup Operator (*Savsys) Special Authorities Copyright 2007 The Power Tech Group. One has to wonder if this is why all of the other settings are so out of control.Figure 4—Compliance Assessment User Security Tab System Value QPWDEXPITV QPWDLMTAJC QPWDLMTCHR QPWDLMTREP QPWDLVL QPWDMAXLEN QPWDMINLEN QPWDPOSDIF QPWDRQDDGT QPWDRQDDIF Recommended Setting 90 1 *NONE 2 3 128 6 0 1 A number less than or equal to 5 Explanation Number of days before a password expires Limits adjacent digits in password. Of the eight special authorities available to end users. Level 2 allows repeated characters. Characters listed here would not be valid for use in a password. Services (*Secadm) (*losyscfg) Audit Rights (*audit) Full Report Hardware System Access Admin. or even root-level. Prevents the listed characters in a password. QPWDVLDPGM *NONE. but they cannot be consecutive. and the average number of users wielding *ALLOBJ (the most JOURNALONLINE Often programmers try to justify their need for a powerful profile on a production system because of occasional emergencies. Limits repeating characters in a password. and too few managers and auditors can see and understand how this power is used.” the same character cannot be in the relative position in a new password.or administrator-level access (very powerful) Security administrator (can create new user profiles) Network services configuration Configuration of audit and logging settings Full access to reports and printer spool files Hardware administration System operator controls Backup and restore operations powerful of special authorities) was 82—10 percent of the user profiles on a typical system (see figure 6). Inc. Contrary to popular complaints. To ensure appropriate segregation of duties. Any program registered here should be treated as very sensitive due to its ability to see and disclose passwords. However. and nearly 20 percent had *JOBCTL special authority. Special authorities grant user profiles system administrator. no one needs these special authorities to run day-to-day business applications. allowing for separation of duties and a fine level of granularity when it comes to assigning powerful authorities. There are eight special authorities on i5/OS (see figure 5). as the study data show. only *AUDIT was kept in any sort of check. *REGFAC or a program name Administrative Rights (Powerful Profiles) The most striking finding from the “State of System i Security Study 2007”3 is the large number of users that wield special authority on the typical OS/400 system. too many users are granted these powerful authorities. Figure 5—Special Authorities on i5/OS Special Authority Name *ALLOBJ *SECADM *IOSYSCFG *AUDIT *SPLCTL *SERVICE *JOBCTL *SAVSYS Special Authority Description Root. 10-character. Level 1 limits to a single digit. Requires a digit in the password Number of new passwords that must be used before a previous password can be recycled. 5 . Fully 20 percent of users had *SPLCTL special authority. A program may be registered that prevents the creation of weak passwords or dictionary words. uppercase passwords Maximum length of password Minimum length of password Limits password character positions. privilege and essentially provide a free pass around the usual authority restrictions. The 2007 study found that the average number of users on a machine was 825. Figure 6—Special Authorities Observations From State of System i Security Study 180 160 140 120 100 80 60 40 20 0 Number of User Profiles Root Access (*Allobj) Security Network Admin. Supports the more complex 128-byte upper-/lowercase pass phrases rather than the shorter. If “1. depending on specific circumstances. To view the security-related system values. While the *ALWPGMADP and ALWPTF values may be acceptable from time to time. The most important of the system values is QSECURITY. Although it is still a quite common setting. A setting of three (disable user and device) is both counterproductive and ineffective in a TCP/IP environment. QINACTITV No more than 30 The number of minutes before an inactive Telnet session times out QINACTMSGQ *DSCJOB After a Telnet session has timed out. This value should be turned off (0) until there is a specific need to use it. QAUTOVRT 0 Controls the automatic configuration of new virtual devices as soon as they are connected to the system. the job resumes where it left off. These are the base configuration settings that are used to harden the system and prevent security breaches. the default value should be the more stringent *NONE. This value should be turned off (0) until there is a specific need to use it. There are many well-known exposures at this QSECURITY level. and all new systems ship with a default value of 40. Two indicates that the user ID should be disabled. QALWUSRDMN Shall not contain the Certain sensitive objects can facilitate breaches if they are allowed in all libraries on a system. ships as *CHANGE QCRTOBJAUD *ALL Controls default auditing levels for all users and objects. System Security Security on OS/400 begins with system values. a QSECURITY value of 30 indicates an unprotected operating system with suspect integrity. If values *ALL or *DIR these objects are required on a system. identifies what action should be taken. QALWOBJRST *NONE Controls the kinds of programs that can be restored to the system. If the same user signs onto the same device within the QDSCJOBITV value. QMAXSIGN No more than 5 Maximum number of invalid sign-on attempts before a user is subjected to the action described in system value QMAXSGNACN QRMTIPL 0 Level one allows the system to be IPL’d (booted) remotely via a modem. and turned off after use. which defines the overall security level of the operating system itself. This value should be turned off (0) until there is a specific need to use it. Should be set to zero unless a specific contrary reason exists. IBM recommends that all systems should be set to security level 40 or higher. The checklist of OS/400 system values and their recommended settings is provided in figure 7. Forty is the absolute minimum acceptable level. all activity should be audited and reported on a regular basis. QAUTOCFG 0 Controls the automatic configuration of new physical devices as soon as they are connected to the system. Set to at least three. QVFYOBJRST 3 or 5 Verifies object signatures when objects are restored to the system Note: Specific system values related to auditing of the system and password control settings are covered elsewhere in this article. the applications and libraries that require these objects should be known and documented here. and turned off after use. allows login after verification has occurred QUSEADPAUT A named authority list Names an authority list that names the system users who are allowed to create a program that adopts another user’s authority. QAUTORMT 0 Controls the automatic configuration of remote device controllers as soon as they are connected to the system.programmers and development staff members should not have special authorities in their profiles. This setting instructs the system to disconnect the job but leave it active in suspended animation for the amount of time described in system value QDSCJOBITV. should be set to the widest setting possible QDSCJOBITV No more than 240 After an inactive Telnet session times out. type in the i5/OS command: DSPSYSVAL *SEC. Thirty has numerous well-known exploits. System Value QSECURITY Recommended Value 40 or 50 6 JOURNALONLINE . Twenty and 10 indicate that every user has root-level privileges. This list of users should be small and well managed. but one of the notable value propositions of System i is that it can typically be managed by fewer than a handful of administrators. QDSPSGNINF 1 Requests that information about the last successful and unsuccessful sign-on attempts be displayed to the user as he/she signs on QFRCCVNRST Set to 3-7 Forces program conversion on restore. These authorities are important for system management. Figure 7—OS/400 System Values and Their Recommended Settings Explanation Controls the level of operating system integrity. QMAXSGNACN 2 After (QMAXSIGN) number of invalid sign-on attempts. Organizations can place far more restrictions on the use of special privileges by granting the power only on an as-needed basis. QRMTSIGN *VERIFY When a known user attempts to log in from a remote computer. identifies what action should be taken. While the user has assumed privilege. A longer time frame is tolerable if the QINACTITV and QINACTIVMSGQ values are set properly. and turned off after use. determines how long (in minutes) to wait before the job is ended. QCRTAUT *EXCLUDE Controls what access the general public (*PUBLIC) should automatically receive to newly created objects (files and programs). Conclusion IBM System i is a powerful business platform. *NOQTEMP *NOTIFY *SYS *AUTFAIL. • Verify that a procedure exists to report against the audit logs on a regular basis. *PGMFAIL Use QAUDLVL system value to set auditing Explanation Specifies what type of auditing is allowed on the system. making it unnecessary to review the history log for these events. the world’s largest community of IBM midrange users.powertech. could contain some additional values QAUDLVL2 JOURNALONLINE 7 . i5/OS also has a history log (QHST). 1 John Earl is a an expert on OS/400 security. *OBJAUD. He has published numerous articles and columns for industry magazines. 3 The “State of System i Security” is an annual study that reviews aggregate audit findings from approximately 200 systems each year. The audit-related system values can be viewed using the command DSPSYSVAL SYSVAL(QAUD*).Auditing The security audit journal QAUDJRN is a tamperproof log that cannot be altered or changed once an event has been written to the journal. Simply stated. but data are secure only if the IT department configures the system correctly and maintains adequate controls over the management of the system and its applications. Specifies the action to take if journal entries cannot be recorded. but it must be turned on and properly configured in order to do its job.com. He has presented several hundred security sessions at System i and security conferences worldwide. The journal is a free feature of i5/OS. but will also provide a fuller picture of system activity. he has educated thousands of IT auditors on methodologies to secure and audit the platform.powertech. Configuring the Audit Journal The following is a checklist for the audit journal: • Verify that the security audit journal exists on the system and that the auditing is active. *SECURITY.powertech. but it is less reliable than the QAUDJRN because it is susceptible to tampering. He is a three-time winner of COMMON’s Speaker Excellence Award. In addition. Earl has more than 25 years of experience with IBM midrange systems and security. *DELETE. The checklists outlined here form a basic IS audit program for AS/400. • Verify the type of activity that is configured to be logged to the system (QAUDLVL below). Some of the most important reports to review are: • Changes to user profiles • Changes to system values • Invalid sign-on attempts • Authority failures • Command usage by privileged users • Auditing changes • Attempts to violate OS integrity It is most practical to conduct regular reviews using a commercial reporting product since the format of the audit journal makes it difficult to read. QAUDLVL defines what type of events to write to the audit log once the auditing has been turned on by specifying *AUDLVL in the QAUDCTL setting (figure 8). Beginning with V2R3 of the operating system. the QAUDCTL system value defines whether auditing is active on the system (see figure 8). Value *NOQTEMP is permitted but not required. The interactive graphical report includes references to Control Objectives for Information and related Technology (COBIT) objectives. Information security professionals are now becoming more aware of some of the more important security exposures on the system. This recommended group represents a minimum standard for best practices. • Save the data to tape and store them for at least a year. Log File Reporting The IT auditor should ensure that the organization reviews the log file report output on a regular basis. along with hyperlinks to detailed explanations of OS/400 concepts. all security-related events are written to the security audit journal. • Determine how long the audit data are kept on the system. Specifies what types of security events should be audited. Figure 8—Audit-related System Values and Recommended Settings System Value QAUDCTL QAUDENDACN QAUDFRCLVL QAUDLVL Recommended Value *AUDLVL. QAUDJRN data should be kept live on the system for a minimum of one month. *OBJMGT. More settings will require more data storage. Controls the buffering ration of records written to the security auditing journal. such as the open doors through FTP and ODBC.com.com. *SERVICE.” which may be too harsh for most environments. An extension of the QAUDLVL system value. *SYSMGT. It simplifies the task of gathering audit data from System i. Copies are available at www. A complete table of the audit-related system values is outlined in figure 8. along with recommended settings. 2 IT professionals who are looking for a more advanced and/or automated audit program for i5/OS and System i can find more detailed information at www. Allowable values are “Notify” and “Power Down System Immediately. *SYS (system regulated buffering) is sufficient. and served as a security subject matter expert for COMMON. Endnotes PowerTech Compliance Assessment is a tool that information security professionals can download at no charge from www. *SAVRST. permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC).org 8 JOURNALONLINE . or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited. © 2008 ISACA. Salem.. beyond the scope of this introductory article. entitles one to receive an annual subscription to the Information Systems Control Journal. date. to photocopy articles owned by ISACA.com. reprint or republication. 27 Congress St. 01970.powertech. Copying for other than personal use or internal reference. or the editors of this Journal. www.isaca.50 per article plus 25¢ per page. permission must be obtained in writing from the association. is available in an Open Source i5/OS Security Policy available at www. a voluntary organization serving IT governance professionals. Mass. for a flat fee of US $2. Send payment to the CCC stating the ISSN (1526-7407). Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. All rights reserved. Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. Membership in the association. They may differ from policies and official statements of ISACA and/or the IT Governance Institute® and their committees. A free copy of the OS/400 Compliance Assessment tool may be downloaded from www. and from opinions endorsed by authors’ employers. Information Systems Control Journal does not attest to the originality of authors' content. For other copying. Information Systems Control Journal is published by ISACA. volume. Where necessary.powertech.com.Author’s Note Some of the more advanced topics that were not covered in this article because of space limitations are: • Adopted authority • Sign-on screen messages • Dedicated service tools (DST) profiles and passwords • Network attribute settings • Library lists • Printer output queues More detailed information. and first and last page number of each article.