The Top 10 IBM i Security Exposures, Part 2
December 8, 2010 Wayne O. Evans
|
In Part 1 of this article, I mentioned the importance of being aware of common security exposures. I described five of the 10 most common security exposures and provided suggestions for minimizing risk. This article covers the remaining five security exposures. Exposure #6: Unrestricted use of IBM Navigator for i. IBM provides IBM Navigator for i (formerly called iSeries Navigator and Operations Navigator) as the graphical user interface for OS/400 functions. This powerful interface can be used in place of a command line to manage the security of objects, display data file content, and even delete objects. IBM Navigator, like command-line access, has the potential for great abuse. If unrestricted, the PC user operating through the Navigator has the capability to delete or change the authority of production data. Unfortunately, many installations are not aware of the security exposures introduced by IBM Navigator and do not restrict Navigator functions. Too frequently, the security officer relies on lack of user knowledge rather than adequately protecting the Navigator interfaces. Simply eliminating the support on the PC desktop will not restrict PC-literate users. A knowledgeable user can find a Client Access CD and add the missing programs to the PC. The traditional OS/400 controls of limiting user profiles and using exit programs have limited success in preventing unauthorized access through the Navigator.
Figure 1 shows the Application Administration graphical user interface the security officer uses to select what Navigator interfaces are allowed. The options can be allowed or restricted for all users, even those with *ALLOBJ special authority. The customized access is used to allow or restrict functions for individual users.
Figure 2 shows the Application Administration interface to control Client Access. Separate controls are defined for file upload, file download, remote commands, and functions. These controls of Application Administration do not replace the exit program function. Exit programs are more flexible because exit programs can allow selected files or files in specific libraries to be transferred, whereas the controls of Application Administration completely allow or restrict the function. RECOMMENDED ACTION: Use Application Administration to control IBM Navigator for i to control the options available to default and *ALLOBJ users. Application Administration blocks the function by hiding the icons shown in Navigator. Use Application Administration to limit end-users to the options to the Base Functions and to allow selected users access to individual functions. Exposure #7: Security Level set below 40. The recommended setting for the QSECURITY system value is 40. At lower security levels, preventing users from running batch jobs as other users can be difficult. Increasing the security level to 40 should be a high priority but you must first conduct an audit to determine if your system has any applications that would fail at a higher security level. Application programs that directly access objects or call internal modules of OS/400 will fail when security level 40 activates state/domain protection. You can determine if you have any programs that will cause problems by turning on audit of *PGMFAIL (program fail) events in the audit journal. You can visit www.WOEvans.net to download a document that gives a step-by-step process to safely increase the security level of your system. RECOMMENDED ACTION: If your system is not at security level 40, activate the audit journal to determine if you have any application programs that would fail at security level 40. If none are found you can increase the security level of your system. Exposure #8: Dormant and/or terminated accounts. When employees are terminated or change jobs, their system access should be revoked. Failure to remove dormant or terminated user profiles creates a potentially serious security exposure. A former user can be a greater threat than an external hacker because these users often possess knowledge about critical system files unknown to an outside hacker.
Use options 2, 3, and 4 of the Security Tools menu, shown in Figure 3, to scan for the last sign-on date for user profiles. You are allowed to specify the number of days of inactivity that determine when a user profile becomes dormant. Once a profile is dormant, it can be disabled and then removed from the system. However, the last sign-on date is not updated for user profiles that do not sign on, such as profiles used only for FTP, sending network mail, or ODBC-only access. The Security Tools menu option 2 allows you to specify the names of known user profiles that should be skipped during the check for inactivity. Then menu option 4 runs the job to find inactive profiles. Once this report is activated it can be scheduled to run daily to detect any new profiles that exceed the inactivity level you establish. In the case of terminated employees, every organization should have procedures in place to immediately disable the user profile upon termination. RECOMMENDED ACTION: Use existing security tool kit options to detect dormant or terminated user profiles. Eliminate these user profiles from your system and run periodic reports to detect profiles that fall within your inactivity parameters. Exposure #9: Inconsistent object ownership and authority. Most OS/400 installations fail to correctly define and manage object ownership and access, resulting in unnecessary security exposures. The machine will enforce access to objects, but all too often this protection is circumvented because of excessive *PUBLIC authority or group profile ownership of objects. One of the more difficult tasks for a security officer is to restrict object ownership. Unless there has been a careful policy to restrict object ownership, the programmers that create an application are the owners of programs and data files. When programming staff own production objects, deletion of user profiles for programmers that have left or are terminated can result in production applications not working. As a matter of policy, individuals should not own objects. Objects should be owned by user profiles whose sole purpose is to own production data. These production owner profiles should also not be used as group profiles. I recommend use of a security strategy called Application-Only Access, whereby users do not have access to data except when running approved applications. Application-only access uses OS/400 object authority to restrict access to production data files. When the user is running approved applications, the application will either adopt the production-owner user profile or swap the group profile to the production owner, allowing the user access within the application. The Application-Only Access security strategy is described in more detail in documents available at www.WOEvans.net. RECOMMENDED ACTION: Manage the authority to objects by establishing an object authority template and use third-party software to find and correct any deviations from the expected template. Use a third-party application to assist in the management of authorities. Rather than trying to change individual objects in a library to meet some standard, the security officer defines the desired security template of object owner and authorized users for an object type. Then the object management application retrieves and compares the ownership and authorized users for all objects in a library with the security template. Exposure #10: Incorrectly set authority to library on the library list. Many OS/400 installations customize IBM commands and objects by placing their modifications in a library in front of the IBM QSYS library on the library list. The authorities of this library and all libraries on the system portion of the library list need to be set correctly. The *PUBLIC should have *USE authority to the library. *USE authority allows access to objects in the library but the users cannot insert new objects into the library. If users are allowed *CHANGE authority to the library, this allows an intruder to put into the library an object that can be used to gain unauthorized access. For example, a SIGNOFF command could be inserted that would check to see if the user issuing the SIGNOFF command had powerful access. If that is the case, the intruder-inserted version of the command could perform some unauthorized activity before actual signoff of the user. RECOMMENDED ACTION: The *PUBLIC authority to libraries on the library list should be *USE to prevent the capability to insert objects that compromise security. In Conclusion My goal in writing this series of articles is to help you minimize the security risks to your OS/400 systems by identifying common exposures and suggesting ways to eliminate them. Having clearly defined security policies in place is essential to not only correct exposures, but to properly maintain and implement information security as an essential ongoing function. Involving users, as well as machine controls, in your security efforts is still the best way to assure more effective information security across the enterprise. Wayne O. Evans is an internationally recognized authority on OS/400 security. For more than 27 years, Evans served with IBM at its development laboratory in Rochester, Minnesota. For 16 of those years, he designed and implemented features for the IBM AS/400 and S/38 operating systems, and for six years before his retirement in 1991, he specialized in security. Today, Evans is an author, speaker, and instructor. He enjoys sharing his experience and expertise in OS/400 security. He has authored numerous articles on OS/400 Security and has written a book entitled “Wayne O. Evans on AS/400 Security,” published in 1997 (now out of print) that contains a collection of his writings on OS/400 security topics. Evans is a frequent speaker and instructor at technical conferences and OS/400 User Groups, including COMMON. Send your questions or comments for Wayne to Ted Holt via the IT Jungle Contact page. RELATED STORY The Top 10 IBM i Security Exposures, Part 1
|
