Managing Privileged Users on the IBM AS/400 (System i)

WHITEPAPER
Managing Privileged Users on the
System i for Regulatory Compliance
Abstract:
This whitepaper from PowerTech discusses best practices in managing,limiting, and auditing privileged or powerful user accounts on the System i and AS/400. What are the security exposures from powerful user accounts and special authorities such as *ALLOBJ? What are your auditors looking for? How do Information Technology frameworks such as COBIT and ISO 17799 affect your business, and how can you configure your system to comply with them? Discover the answers to these questions and learn best practices for reducing your securityexposures from powerful users on the System i.
The PowerTech Group, Inc. T: 253.872.7788 Copyright 2007, The PowerTech Group, Inc. PowerTech is a registered trademark ofwww.powertech.com The PowerTech Group, Inc. AS/400 is a registered trademark of IBM. All otherF: 253.872.7904 product and company names are trademarks of their respective holders.Introduction
In the past few years, there has been an increased emphasis on the security and control of critical corporate Information Technology (IT) assets in companies large and small. This new emphasis is driven largely by U.S. legislation such as Sarbanes-Oxley, the California Privacy Act (SB1386), HIPAA, and the federal Gramm-Leach-Bliley Act (GLBA). Many other countries and jurisdictions are also emphasizing the need for IT organizations to monitor and protect valuable data assets. In response, companies are scrambling to implement IT security plans against which they can demonstrate their adherence to best practices and thus their compliance with regulations. One of the top concerns of auditors on the System i and other platforms is the proliferation of unregulated and unmonitored users with powerful privileges. On the System i, we define powerful accounts as any account with special authorities or simply those with direct rights to production data.
In this whitepaper, we look at some of the most common exposures that result from such powerful profiles. We relate these vulnerabilities to the relevant COBIT and ISO 17799 controls, and we suggest best practices for managing and reducing the number of powerful profiles. We also recommend techniques for dealing with programming staff who need to have emergency access to production data.
The Risks and Exposures of Special Authorities in OS/400
Let's start by reviewing some of the potential exposure on the System i system. Special authorities are rights granted to a user that specifically exempt that user from the restrictions normally enforced by traditional OS/400 security. The reason special authorities exist is to provide a select number of highly trusted users with the ability to circumvent security controls when business conditions require it. These "security bypass" rights are very powerful and should be reserved only for trusted and knowledgeable IT professionals. And because of their power, security frameworks such as COBIT and ISO 17799 require that the use of these special authorities should be subject to monitoring and management review.
In OS/400, when you create or change a user profile, you implicitly or explicitly assign special authorities to the user profile. When you assign a user class (e.g., *SECOFR, *SYSOPR, *USER, *PGMR) to a user profile, you are also assigning a set of default special authorities to the user. The table below shows the default special authorities that are assigned to each user class:
User Class Default Special Authorities*SECOFR All special authorities *SECADM *SECADM*PGMR None*SYSOPR *JOBCTL and *SAVSYS*USER None
Copyright ©2007 PowerTech Group, Inc. All rights reserved.There are eight types of special authority in OS/400. It is vitally important to monitor and manage the dissemination and use of these rights.
Total Access (*ALLOBJ)*ALLOBJ authority is the most powerful authority on any System i or AS/400 system. This authority, which is roughly equivalent to root on a UNIX system, grants the user complete access to all libraries, data, and programs on the system. A user with All-Object authority cannot be controlled. An employee with access to this special authority, and who is either careless or has malicious intent, would have very little difficulty in exploiting his or her autho... [download for more]