Compliance and the AS/400

Communications News, Feb, 2008 by John Earl

The IBM System i (as the AS/400 is now known) carries some of the most critical and sensitive data in the organization. While industry and government compliance initiatives require the protection of personal and confidential data, the average System i may have a litany of security configuration violations that indicate the data is not being protected. Some of the most glaring deficiencies include:

Group ownership of data. Many System i applications were secured with an authority scheme that designates a single ID as the owner of all files and programs. That same owner profile is also the group ID for all application users. This means that every application user will operate with application owner rights by virtue of their membership in the group. This vulnerability presents an unacceptable level of risk.

To discover whether a system has this problem, start by looking at the most important files on the system--the payroll or credit card file--and ask the system administrator to show who has authority to read it or change it. If the list of users includes group IDs with large membership lists (or worse, the system group "public"), proceed with the assumption that individual files are not well secured.

Unmanaged access control. With the adoption of TCP/IP networking protocols, users may now have access to the System i using PC-based tools such as open database connectivity, which allows dynamic data exchange through common tools such as Word and Excel. Users with tools that can access the data, coupled with the legacy of group profile ownership, present the perfect storm of vulnerability.

To see whether the system has this worst-case scenario, select a user ID without any administrative rights and attempt to launch an FTP session against the System i. If logon is successful, attempt to download data from the system using the FTP command: get qgpl/qddssrc.qdsignon c:\myfile.txt. If the file can be downloaded, access control on this machine is not closely managed.

Too many chiefs. One of the more surprising findings on the System i is the large number of security officers, or root-level users, on each system. An average of 8 to 10 percent of all system users may be operating with root-level authority.

Check the system by having the system administrator list all users with "allobj" (essentially root) special authority. This list should be small and each user should have an obvious need for special authority. Additionally, powerful profiles should all be audited, and their logs regularly reviewed.

The most-effective solution for the first two issues is to implement server exit programs, which perform host-based firewall functions, inspecting the incoming traffic and applying business rules to determine if traffic is permitted or not. These programs also log all incoming requests, providing an audit trail that can be invaluable in an emergency.

Too many users with too much power is a problem that, while common to many platforms, seems to be a larger concern on the System i. Because these powerful user IDs have complete run of the system, staff should monitor and control the use of high-powered IDs and have a review process that determines that each use was appropriate. The essentials of any solution should include the ability for IT staff to temporarily check high-powered profiles, the ability to audit and monitor the actions of these users, and an emergency process for fixing production problems with a minimum of red tape.

For more information: rsleads.com/802cn-258

John Earl is vice president and chief technology officer for The PowerTech Group, Kent, Wash.