The Top 10 IBM i Security Exposures, Part 1
December 1, 2010 Wayne O. Evans
|
In today’s highly security-conscious network environment, it’s important that you be aware of some of the common security exposures that could lead to a security breach of your systems. Even though there are excellent security features built into IBM i, today’s network environments often open your systems to exposures not even dreamed of a few years ago. Based on numerous security reviews I have conducted across different industries, the same types of security exposures appear over and over again. In this series of articles, I describe the top 10 most common security exposures and provide suggestions for minimizing your risk. By using the security features that exist in OS/400 and, in some cases, utilizing software available to help automate the process, you can significantly reduce your risk and improve protection of your information assets. Exposure #1: No security policy or an ineffective security policy. Lack of a written security policy is the most frequent exposure that I find during a security audit. In my experience, more than 60 percent of OS/400 installations have no security policy. For those organizations that do have a written policy, the policy was often developed only because a regulatory agency required such a document. The security policy was created at some point to meet these requirements, but was not implemented effectively, and can only be found gathering dust on a shelf. Too often management assigns an individual as the security officer without any more specific direction than a general imperative to “secure the computer.” Management would never consider telling a programmer to simply “write a program” without giving the programmer detailed instructions that describe the expected input and output for a new application. Just as the programmer needs thorough program specifications, so the security officer needs a security policy to understand management expectations for system security. Comprehensive and effective security requires a coordinated plan to be sure that the security objectives are met. Effective computer security requires that both users and the operating system controls work together to protect system information. The best security system can easily be compromised if the human aspect of security is ignored. A comprehensive and effective security policy considers both the man and machine. A security policy plan consists of three components.
A security policy does not have to be written from scratch. Rather, it can be created by adapting content from other existing security policies. To help make creating security policies easier, I have posted example security policy documents that can be downloaded from my Web site at www.WOEvans.net. There is no cost to download these documents, but I request that you make a donation to the charity of your choice in return for the information. RECOMMENDED ACTION: Make creation of a security policy a top priority action item. Start by downloading the example security policy documents from www.WOEvans.net. There are also publications and third-party vendors that can help with the creation and automation of information security policies. Exposure #2: PC access creates security exposures. The workstation of choice today in most installations is a personal computer. Often the fixed-function display is replaced with a PC and iAccess for Windows (or as it is more commonly known, Client Access) is installed to give the users connectivity to the iSeries or AS/400. Unfortunately, the security exposures introduced by PC access are not always considered. Attaching a PC to the system creates potential security exposures by allowing users to interact with the system in ways not possible from a fixed-function display. PC users can quickly discover an icon that guides the user through file transfer operations. The user interface for file transfer makes it easy to perform the transfer by prompting the user with names of libraries, files, and members. Skilled PC users may learn of the RMTCMD function that is included as part of Client Access. RMTCMD can be used to issue CL commands, ignoring the LMTCPB restriction in the user profile that prevents use of commands from command lines. Experienced PC users can easily learn that FTP (File Transfer Protocol) will transfer iSeries or AS/400 files. The FTP session can also be used to issue commands to OS/400. The best way to control transactions like file transfer and remote commands with PC access is through exit programs. OS/400 provides the exit program capability but you must write and install the exit programs yourself. The details on how to write exit programs are quite complex and too lengthy to include in this article. Go to www.WOEvans.net for more information and sample exit point programs. Having written exit programs, I do not recommend that you try writing your own. The IBM documentation on exit points requires a significant investment in time and effort. The sample exit programs from my Web site may appear to be sufficient, but they do not address all of the special cases necessary to parse the SQL statements. These sample exit programs help get you started, but to implement a solution with a lot of flexibility will require many hours of work. Rather than spend time becoming an expert on exit programs, I recommend that you install the exit point support provided by an exit point vendor. Money spent to purchase an exit point solution from a third-party vendor is well worth it, rather than spending substantial resources in time and money to create and maintain your own exit programs. The following is list of suppliers of exit programs. This list may not be complete.
Exposure #3: Trivial passwords. The default behavior of the Create User Profile (CRTUSRPRF) command makes the password the same as the user profile. All too frequently, the security officer does not set the user password to expired status, which would require the user to change the password the first time the user signs on. Even when the password is set to expire, users that request a password sometimes neglect to sign on, and consequently the password and the user profile remain the same. Supplying the password equal to the user profile name is a common method for a hacker to gain access to an OS/400 system. I have personally signed on to systems in banks and other financial organizations using trivial passwords for IBM-shipped user profiles and even installation-created user profiles like TEST, PCUSER, FTP, and USER1. Often third-party application programs are installed with well-known profiles (such as JDEINSTAL, ALDONCMS, S2KOBJOWN) with matching passwords. Elimination of trivial passwords is a must in order to avoid giving hackers an easy way to get into your system. OS/400 has system values that a security officer can set to prevent trivial passwords for users. The security officer uses the Change System Value (CHGSYSVAL) command to manage the OS/400 password system values. I recommend the following password controls for all systems:
The Analyze Default Passwords (ANZDFTPWD) command finds user profiles that have a password the same as the user profile name. Change the password or delete these profiles to reduce the possibility that a hacker gains access to your system. RECOMMENDED ACTION: Use system values to set password rules that will eliminate trivial passwords. Run the ANZDFTPWD command to find user profiles that have a matching password. Change the password or delete these profiles to reduce the risk of a hacker gaining easy access to your system. Exposure #4: Unrestricted command line access and access to MAIN Menu. End users should run applications by selecting options from a menu, and should have no need for a command line. The user profile of the non-IT user should specify LMTCPB (limit capability) of *YES. Because end users are often authorized to access production data, restricting the command line keeps end users away from areas that could result in security exposures. The IBM default for the initial menu is MAIN. This menu is very powerful and allows menu options that can be used to delete production files. The MAIN menu is useful for power users but should not be assigned by default to end users. When users have an initial program specified, the initial menu should be INLMNU(*SIGNOFF), which signs off when the initial program terminate. RECOMMENDED ACTION: Specify LMTCPB(*YES) in the user profile. Use INLMNU(*SIGNOFF) to further restrict command line access when the initial program terminates. Exposure #5: Excessive special authority in User Profiles. Frequently User Profiles have special authority fields that have been specified during installation and programming that give these users extensive access to the system creating security exposures. Once granted, special authority can be difficult to eliminate without affecting functionality. Some of these special authority exposures include:
RECOMMENDED ACTION: Carefully restrict the number of users with powerful special authority. The Display User Profile (DSPUSRPRF) command can be directed to an OUTFILE and reports run to determine which users have special authority. 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.
|
