Auditing of Sensitive Users and Objects

Published: April 26, 2006

Hey, Steve:

My shop keeps running up against the process and data control requirements surrounding the Sarbanes-Oxley Act. We are continually told that we should be actively monitoring all accesses to the critical financial data that reside on our i5 system, as well as the powerful users that may be accessing the data. Of course, the first hurdle to compliance in this area is identifying which files are critical and then managing the users with powerful authorities. However, since there's already someone in the IT security group breathing down my neck and our company already has a well-defined data classification scheme (rare, I know!), I don't need to worry about identifying the critical stuff. My problem is to decide the best way to track the usage of the sensitive objects. What audit methodology would you recommend for monitoring access to our critical objects and the powerful users that may be accessing them?

Thanks!

--Doug

A comprehensive auditing strategy for a production i5 (iSeries) system or systems requires a little bit of planning and a whole lot of ongoing management. Your plan should answer questions like:

• Which profiles do I audit, regardless of what objects they touch?
• What objects do I audit, regardless of which profiles access them?
• How do I balance my need to audit with the impact that it may have on my system?

As I mentioned in a previous tip, you can use the QAUDCTL, QAUDLVL, and QAUDLVL2 system values to set up the audit journal receivers to record different types of security events. However, there are two important components of auditing that are often overlooked, or should I say, mismanaged: the audit level (AUDLVL) value specified in the user profile and the object auditing (OBJAUD) value of the objects themselves.

Having been in your shoes at a number of different financial institutions, here is what I have found to be a good balance between auditing as much as you can without causing your system to choke on all of the monitoring you are required to perform.

User Profiles

In i5/OS (OS/400), user profiles have a parameter called the "object auditing value" (OBJAUD) that specifies the object auditing value for the user. This value takes effect only if the object auditing value for the object being accessed has the value *USRPRF, so they are dependent upon each other. The possible values for the user profile OBJAUD parameter are:

• *NONE: The auditing value for the object itself determines when auditing is performed
• *CHANGE: All change accesses by this user on all objects with the *USRPRF audit value are logged
• *ALL: All change and read accesses by this user on all objects with the *USRPRF audit value are logged

Thus, the *ALL setting for the user profile(s) in question will generate read accesses for those objects that have the *USRPRF audit value set. You can change the user profile by executing the following command:

CHGUSRAUD USRPRF(ANYUSER) OBJAUD(*ALL)

Replace ANYUSER with the profile name of the user whose object accesses you want to monitor.

System Objects

In i5/OS , all objects have an object auditing value parameter (OBJAUD), which specifies the object auditing value for the object. (User profiles are objects too). This is a required parameter for every object and may be set as follows:

• *NONE: Using or changing this object does not cause an audit entry to be sent to the security journal
• *USRPRF: The user profile of the user accessing this object is used to determine if an audit record is to be sent for this access; as stated above, the OBJAUD keyword of the CHGUSRAUD command is used to turn auditing on for a specific user
• *CHANGE: All change accesses to this object by all users are logged
• *ALL: All change or read accesses to this object by all users are logged

Thus, the *USRPRF setting for the objects in question will generate read accesses for user profiles that have had object auditing turned on via the CHGUSRAUD command. You can change the object auditing values by executing the following command:

CHGOBJAUD OBJ(ANYLIB/*ALL) OBJTYPE(*ALL) OBJAUD(*USRPRF)

Replace ANYLIB with the name of the library containing the object that needs to be audited. You can select *ALL objects or execute the command multiple times for specific objects.

I recommend that you set *USRPRF as the object auditing value. If you were to select *ALL for the object auditing value of the objects themselves, the system would likely produce a very large amount of audit data in a relatively short period of time. This would cause everyone and their brother to come looking for you, since the security audit journal would start cranking out journal receivers and eat into your valuable DASD storage space! You don't want to validate their already false opinion that all of the space issues are security's fault anyway, now do you? So, set the QCRTOBJAUD system value (auditing value for newly created objects) to *USRPRF. This ensures that auditing entries are sent for these objects when they are used or changed by a user who is currently being audited. Then, change the auditing value of your existing objects to *USRPRF (at a minimum) and leave the auditing value of your sensitive objects set to *CHANGE or *ALL (I hope they're not set to *NONE!) so that all accesses to those objects are logged.

This combination of object and user profile auditing settings effectively enables the use of "spot auditing," where you turn up auditing for specific users using the CHGUSRAUD command instead of attempting to turn on all auditing for all of your objects. Reports can then be created using the Display Audit Journal Entries (DSPAUDJRNE) command in tandem with standard query tools, or you can use a third-party audit reporting tool. Knowing who and what you need to audit and how to do so effectively is the key to minimizing the security audit journal and system load requirements--and to keeping the auditors happy. Just remember, it is better to log as much as you can and have the data if you need it then it is to need the data and not have it!

RELATED STORIES

iSeries Security Journal Receiver Management, Part 1

iSeries Security Journal Receiver Management, Part 2

Steve Martinson is a senior consultant and manager of the iSeries Security Practice for Servique, LLC. Martinson's primary focus is on enterprise implementations of NetIQ Security Solutions for iSeries (NSSi) for key NetIQ accounts, starting at the planning stage and helping customers move through assessment, design and implementation.