Our System Administrator did WHAT?
Accountability for your powerful users
By Robin Tatam
One of the greatest challenges that an organization faces when securing an IBM i environment is protecting the system from the very people who are also charged with its care: programmers, administrators, and security officers. While these power users often need access to restricted objects and commands, they rarely need that level of access 24 hours a day, and definitely not without accountability.
Fortunately, IBM i lets you audit events in a secure repository for forensic analysis and reporting. If you haven’t seen these controls, we offer a white paper about event auditing on our Web site at www.powertech.com, and we conduct frequent Webinars on auditing.
Setting Up Auditing
The first step to auditing in IBM i is to create a security audit journal to collect event information. Since the introduction of V5R3, IBM provides the Change Security Auditing (CHGSECAUD) CL command, which creates the security audit journal QAUDJRN, and creates and associates the first journal receiver. By prompting the command, you can override the default journal receiver name and location, and also specify the initial settings for two auditing system values. QAUDCTL acts as the auditing on/off switch; QAUDLVL designates which events will be recorded for all users.
The QAUDJRN journal must reside in the QSYS library, but I recommend that you create a secure library to contain the journal receiver. Since many receivers are generated by the system over time, a secure library allows for easier receiver management than the default library of QGPL. If auditing is currently active, you may create a fresh journal receiver in the new library, and then use the CHGSECAUD command to direct subsequent events to it. Previous audit journal receivers may be moved into the new library.
Once you have established an auditing infrastructure, you can begin to audit events, including:
- System events
- User activities.
- Object accesses
User Auditing
The focus of this article is on user activity auditing. You can view current audit settings using normal user profile commands, but changes to the configuration can only be made with the “Change User Auditing (CHGUSRAUD)” CL command. This supports the separation of duty between an auditor and an administrator. You must have *AUDIT special authority to use the CHGUSRAUD command.
PowerTech recommends that activities should be audited for any user with command line permission. Users have command line permission if their profile has a Limited Capabilities setting of *NO or *PARTIAL. Network interfaces, such as FTP and DDM, also permit commands to be executed and may not adhere to a limited capabilities restriction. These interfaces should always be controlled and audited using an exit point solution, such as PowerTech’s Network Security, as network data access is not normally an auditable event.
There are sixteen categories of events that can be audited for users in IBM i V6R1, including:
- *AUTFAIL (Authority Failures)
- *CMD (Commands)
- *CREATE (Object Creations)
- *DELETE (Object Deletions)
- *JOBDTA (Actions Affecting Jobs)
- *NETCMN (Network Communications)
- *OBJMGT (Object Management)
- *OPTICAL (Optical Drive Operations)
- *PGMADP (Program Adoptions)
- *PGMFAIL (Program Failure)
- *PRTDTA (Print Data)
- *SAVRST (Save and Restore Operations)
- *SECURITY (Security Operations)
- *SERVICE (Service Functions)
- *SPLFDTA (Spooled File Functions)
- *SYSMGT (System Management)
The QAUDLVL system value supports all but one of these categories to audit the associated activities for all users: The value of *CMD is unique to individual user auditing, and records the commands that a user runs via the command line, and through the execution of program code. The italicized categories support subset values to restrict the volume of events that may be generated.
The Operating System Challenge
So far I have discussed how to manually configure the IBM i to audit system events and user activities. While we normally only audit users who can enter system commands, this still leaves us with the issue of how to control administrators, as well as how to effectively report on the large volumes of audit data that is being generated.
Removing command line access from administrators or programmers is not a viable option, but you should audit all of their activities. In addition, restrict a profile to have only those special authorities and private authorities that are needed throughout the day, and remove unnecessary capabilities.
Solution 1: Adopting Authority
When a system activity, such as resetting a password, requires a special authority, consider the use of a custom program to perform this task. For example, a password reset program could adopt the authority of a profile that has Security Administrator (*SECADM) authority, as well as prevent access to other profile settings. This approach permits the restricted function to be performed without having security administrator rights. Of course, a program that adopts authority for sensitive activities should first verify that the user is eligible to perform the programmed function.
Authority adoption is always cumulative, meaning that the program owner’s authority is added to the run-time user’s own authority. The more programs in the call stack, the more authority the user may potentially receive. If the run-time user already has the necessary authority (perhaps through *ALLOBJ special authority), then there is no way to reduce the capabilities. It is also not very feasible to have a program for every function that a programmer or administrator might need to perform.
Solution 2: Profile Switching
Profile switching is another solution to the issue of temporary authority. IBM provides programming APIs to allow a job that was started under one profile to take on the authority of another profile mid-process. PowerTech Authority Broker is a powerful solution built around these APIs, and it is designed to address the issue of controlling powerful users. Authority Broker allows for you to be able to remove the special authorities and private authorities from a user’s normal profile, and then provide elevated access on demand when—and only when—it is required.
There are numerous advantages to profile switching using Authority Broker:
- The user does not have to manage yet another user profile and password
- Auditing is detailed, and points back to the user that started the job
- Notification events provide messaging of usage to interested parties
- Comprehensive reporting facilities are built in (including a .csv file export)
- A “Firecall” feature allows particular switch profiles to only be used after activation by an administrator
There are many other powerful application features, including the capability to leverage exit programs to perform custom processing as part of a switch, as well as the ability to use switch profiles within your own application programs. A popular use of this capability is to reduce a user’s capability prior to performing a function like STRSQL or Query.
While we will always need administrators and security officers, we have a responsibility to ensure that they do not become our biggest vulnerability. Overly-capable users are a common issue on IBM i, and one that you will want to address in your security remediation plans. Balance an auditor’s desire to strip these capabilities from base profiles, with the corporate requirement that users occasionally need alternate privileges to perform their job. Powerful auditing and notification functionality prevents a powerful user from running wild, and provides accountability where normally there is none.
To read more information on PowerTech Authority Broker, or to receive a free security assessment of your system (including a review of user capabilities), please visit www.powertech.com/powertech/PowerTech_Web_AuthorityBroker.asp.
Robin Tatam is the Director of Security Technologies for PowerTech, the leading provider of security solutions for the IBM i. Robin was co-author of the Redbook IBM System i Security: Protecting i5/OS Data with Encryption, and is a frequent speaker and writer on security topics. He can be reached by email at robin.tatam@powertech.com.