Professional Documents
Culture Documents
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.
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
to more easily exchange data with connected personal computers (many auditors are working off checklists that have not been updated since this time). 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. However, a huge exposure was unleashed at the same time because of the shoddy way that OS/400 objects were secured up to that point. Prior to OS/400 release 3.1, users were typically connected to AS/400s through fixed function, nonprogrammable (dumb) terminals. During these times, the favored way of protecting data from end users was to limit their application access to a green screen menu system. This control was coupled with the limited capability parameter on the user ID, which prevented users from entering commands at a standard OS/400 menu. In this way users were easily prevented from wandering about the system and peering into places they should not. OS/400 Meets TCP/IP The introduction of the TCP/IP stack changed all of this dramatically. 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. Since the 1990s, IBM has shipped System i from the factory with all TCP/IP services enabled and ready to talk to the outside world. Few system administrators take the time to investigate what services are open and conversational, and even fewer understand networking well enough to understand which services should be turned off. 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. Direct access to System i (iSeries) data is possible through a Microsoft Excel Plug-in, for example, which is installed with every copy of IBM Client Access, the most widely distributed PC to the System i connectivity tool. At the time that IBM enabled the TCP/IP stack on OS/400, it also introduced exit points for various TCP/IP servers. 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, alter or even block these transaction requests. IBM did not provide the exit programs, but rather left it to its customers or third-party providers to provide these essential security services. With an exit program attached to, for example, the FTP servers exit point, the system administrator can now see information such as User JOHN connected to system XYZ from remote IP address 196.6.3.104 at 10:22 a.m. At 10:24 a.m., he sent a request to download the Payroll file, and at 10:31 a.m., he ran a remote command that attempted to delete his joblog. Armed with this level of information, the system administrator can create access rules (much like firewall rules) that will control which users can use which services,
2
what files may be accessed, and what level of logging and alerting is desired for these transactions. To determine if the system has exit programs attached, the WRKREGINF and the DSPNETA commands should be used and the servers listed in figure 2 examined. Services such as FTP, remote command and remote SQL should be monitored and controlled. The system administrator should be asked to produce logs of exit point traffic, and review the access rules that control the exit programs. Without exit programs in place, there are no logs or alerts of any data transfer activity or requests over FTP, remote command or ODBC. Figure 1 lists the most important remote access servers that can be protected by exit programs, along with a brief description of the function provided. Figure 1Remote 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 serverused when drives are mapped to integrated file system *FTPCLIENT FTP client on the iSeriesused 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, the WRKREGINF command is used and the list is scanned to find the exit point servers named in figure 1. If the Compliance Assessment tool can be used, then the display shown in figure 2 will provide the results.
OS/400 objects (files, programs, etc.) are for everyone (*PUBLIC) to have at least change (*CHANGE) rights to all parts of an application. *CHANGE access not only allows a user to read and change the contents of a file, 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). To see whether a particular system allows too much authority to important application objects, the object authority must be displayed. To do this, the OS/400 DSPOBJAUT command must be used. 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.
Who Is *PUBLIC?
It is important at this time to understand the concept of *PUBLIC. For every object on a system, there is an explicit authority assigned to *PUBLIC. Typical assignments are *ALL (complete rights to the object, including object deletion rights), *CHANGE (the rights to change the contents and outer shell of an object), *USE (the rights to use or read the object) and *EXCLUDE (no rights to the object). Assuming one has a system with 800 users and there is a file on that system called
JOURNALONLINE
PAYROLL, when the DSPOBJAUT command is issued on the PAYROLL file, the following list of users appears: JOHN: *ALL DAN: *USE SCOTT: *EXCLUDE *PUBLIC: *CHANGE In this case, John, Dan and Scott have explicit authority to the PAYROLL file, and the other 797 users on the system are members of the group *PUBLIC. On most OS/400-based systems, *PUBLIC has *CHANGE access to virtually every object on the system, and individually specified authorities are rare. This is for two reasons. First, the default setting (as shipped from the factory) for newly created objects is that *PUBLIC receives *CHANGE access. Although this authority is almost always too permissive, history and inertia have conspired to leave this setting in place. Additionally, there are few objects that detail individual access because setting individual object authorities is a far too cumbersome task for most system administrators. Studies have found that the average number of users on a system is approximately 800. Multiply that by an estimated 20,000 to 50,000 objects on the system, and it is quickly evident why system administrators do not typically secure individual objects to individual users. A well-secured System i either has all application objects and libraries secured against public access (*PUBLIC =
3
*EXCLUDE) or provides some mitigating control that prevents users from directly accessing those objects. It is recommended that IT auditors first check *PUBLICs access to production libraries. Access to libraries should be restricted to only users who have a demonstrated need. The IT auditor should check the object authorities of some items in the library and some of the critical applications on the system. Public access should be set to *EXCLUDE, and individual access should be granted where there is an appropriate business need. Group profiles that have broad access rights to database objects should be identifiedthis is a common back door. 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, or worse), then the system is at critical risk of having lost, damaged or stolen data. An exit program remediation would be essential to quickly safeguard the data.
User Security
As with other platforms, organizations should maintain adequate control over the creation and modification of user accounts or logon identities, which are called user profiles on i5/OS. As part of a comprehensive information systems review, the process for the creation of new user profiles on the system should be audited. There should be adequate controls in place to ensure that the level of privilege assigned to the new profile is consistent with the employees job responsibility.
4
By default, System i assigns to new user profiles a default password that is the same as the username. Controls should be in place to ensure that profiles are not created with default passwords. The audit should also review the procedures for when an employee is terminated or changes jobs. An enabled profile is an active profile that can be used to log on to the system. 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. On Microsoft systems, security policy often enforces strong passwords that require the use of at least one uppercase and one lowercase letter, a number, and a special character. Passwords are required to be changed on a regular basis. On OS/400, there is no way to force a special character without writing custom code in a password validation exit program. Most organizations run at password level 0 or 2, which restricts passwords to a maximum of 10 characters in length and uppercase letters only. Password level 3 is recommended and requires longer, mixed-case passwords. The full set of password-related settings (called system values on i5/OS) that need to be checked is outlined in figure 4, along with recommended values. The security system values can be viewed by typing DSPSYSVAL SYSVAL(QPWD*).
JOURNALONLINE
QPWDVLDPGM
powerful of special authorities) was 8210 percent of the user profiles on a typical system (see figure 6). Fully 20 percent of users had *SPLCTL special authority, and nearly 20 percent had *JOBCTL special authority. Of the eight special authorities available to end users, only *AUDIT was kept in any sort of check. One has to wonder if this is why all of the other settings are so out of control. Figure 6Special Authorities Observations From State of System i Security Study
180 160 140 120 100 80 60 40 20 0 Number of User Profiles
Full Report Hardware System Access Admin. Operator (*splctl) (*services) (*Jobctl)
Special Authorities
Copyright 2007 The Power Tech Group, Inc.
However, as the study data show, too many users are granted these powerful authorities, and too few managers and auditors can see and understand how this power is used. The 2007 study found that the average number of users on a machine was 825, 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. Contrary to popular complaints, no one needs these special authorities to run day-to-day business applications. To ensure appropriate segregation of duties,
5
programmers and development staff members should not have special authorities in their profiles. These authorities are important for system management, but one of the notable value propositions of System i is that it can typically be managed by fewer than a handful of administrators. Organizations can place far more restrictions on the use of special privileges by granting the power only on an as-needed basis. While the user has assumed privilege, all activity should be audited and reported on a regular basis.
System Security
Security on OS/400 begins with system values. These are the base configuration settings that are used to harden the system and prevent security breaches.
The most important of the system values is QSECURITY, which defines the overall security level of the operating system itself. Although it is still a quite common setting, a QSECURITY value of 30 indicates an unprotected operating system with suspect integrity. There are many well-known exposures at this QSECURITY level. IBM recommends that all systems should be set to security level 40 or higher, and all new systems ship with a default value of 40. To view the security-related system values, type in the i5/OS command: DSPSYSVAL *SEC. The checklist of OS/400 system values and their recommended settings is provided in figure 7.
JOURNALONLINE
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. The journal is a free feature of i5/OS, but it must be turned on and properly configured in order to do its job. 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. Simply stated, the QAUDCTL system value defines whether auditing is active on the system (see figure 8). Verify the type of activity that is configured to be logged to the system (QAUDLVL below). 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). Verify that a procedure exists to report against the audit logs on a regular basis. Determine how long the audit data are kept on the system. QAUDJRN data should be kept live on the system for a minimum of one month. Save the data to tape and store them for at least a year. A complete table of the audit-related system values is outlined in figure 8, along with recommended settings. The audit-related system values can be viewed using the command DSPSYSVAL SYSVAL(QAUD*). i5/OS also has a history log (QHST), but it is less reliable than the QAUDJRN because it is susceptible to tampering. Beginning with V2R3 of the operating system, all security-related events are written to the security audit journal, making it unnecessary to review the history log for these events. Log File Reporting The IT auditor should ensure that the organization reviews the log file report output on a regular basis. 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.
Conclusion
IBM System i is a powerful business platform, 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. Information security professionals are now becoming more aware of some of the more important security exposures on the system, such as the open doors through FTP and ODBC. The checklists outlined here form a basic IS audit program for AS/400.
Endnotes
PowerTech Compliance Assessment is a tool that information security professionals can download at no charge from www.powertech.com. It simplifies the task of gathering audit data from System i. The interactive graphical report includes references to Control Objectives for Information and related Technology (COBIT) objectives, along with hyperlinks to detailed explanations of OS/400 concepts. 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.powertech.com. 3 The State of System i Security is an annual study that reviews aggregate audit findings from approximately 200 systems each year. Copies are available at www.powertech.com.
1
John Earl is a an expert on OS/400 security. He has presented several hundred security sessions at System i and security conferences worldwide. In addition, he has educated thousands of IT auditors on methodologies to secure and audit the platform. Earl has more than 25 years of experience with IBM midrange systems and security. He has published numerous articles and columns for industry magazines, and served as a security subject matter expert for COMMON, the worlds largest community of IBM midrange users. He is a three-time winner of COMMONs Speaker Excellence Award.
QAUDLVL2
JOURNALONLINE
Authors 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, beyond the scope of this introductory article, is available in an Open Source i5/OS Security Policy available at www.powertech.com. A free copy of the OS/400 Compliance Assessment tool may be downloaded from www.powertech.com.
Information Systems Control Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the Information Systems Control Journal. Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute and their committees, and from opinions endorsed by authors employers, or the editors of this Journal. Information Systems Control Journal does not attest to the originality of authors' content. 2008 ISACA. All rights reserved. Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25 per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited. www.isaca.org
JOURNALONLINE