Auditing Objects and Sensitive Files

Note: Some of this section is adapted from an iSeries NEWS Magazine, July 2004 article “Common Sense Security Auditing” By Dan Riehl.

We all have a small number of files that we consider sensitive and that need special protection, such as payroll data, health information, credit card numbers, sales, customer, and pricing and cost information. We can audit all access to these sensitive files using Object Auditing.

Before we discuss how to set up Object Auditing, we need to understand the impact. When we turn on Object Auditing for a database file, we potentially have a situation where an audit record can be written every time the file is opened.

If the sensitive file is seldom used, that's not a problem. But if it's used thousands of times a day, such activity will generate thousands of audit entries that will consume considerable amounts of disk space and certainly won't do much for system performance.

Let's take a common sense approach to Object Auditing:

If the file is heavily used, we'll use a technique to maximize performance and disk utilization. If the file is seldom used, we'll use another.

Auditing Specific Sensitive Objects

To audit specific sensitive objects, we use the CHGOBJAUD (Change Object Auditing) command as shown here:

CHGOBJAUD  OBJ(library-name/object-name)     +

OBJTYPE(object-type)     +

OBJAUD(*NONE, *CHANGE, *ALL,

or *USRPRF)

• With an OBJAUD (Object Auditing) value of *NONE, the system performs no object auditing for the object.

• A value of *CHANGE causes the system to audit all changes to the object.

• The value *ALL audits each change or use of the object.

• The value *USRPRF instructs the system to check the user profile's OBJAUD parameter to see what, if any, auditing it should perform. This is the value we'll use for heavily used files, which we'll discuss in a moment.

When the audited object is a database file, the system records any OPEN operation against the file.

• If *ALL is specified for OBJAUD, the system records all file OPEN operations.

• If *CHANGE is specified, the system records only OPEN for UPDATE operations. Security auditing doesn't care whether records are altered, so the OPEN for INPUT only or OPEN for UPDATE is the only thing recorded. To audit the contents of an IFS file, use commands CHGDLOAUD (Change Document Library Object Audit) and CHGAUD (Change Audit).

Auditing Seldom-Used Sensitive Files

For seldom-used sensitive files, turn on object auditing as follows (where myfile and mylibrary indicates your sensitive file):

CHGOBJAUD  OBJ(mylibrary/myfile)     +

OBJTYPE(*FILE)   +

OBJAUD(*ALL)

This will record every file OPEN operation, as well as the execution of CL commands that access or change the file object.

Auditing Heavily Used Files

For heavily used files, we have to use a different approach. Set the OBJAUD value of the object to *USRPRF. This means we'll record file accesses only if the user profile performing the access has its object auditing value set to indicate that object accesses for that user should be recorded.

Using this approach, we do not audit file access by the typical end users of the file, which filters out normal accesses we don't want to read about anyway. Who cares if the payroll clerk accesses the payroll file? To understand how we record file accesses only by certain users, we need to know the relationship between object auditing and user auditing.  See Auditing Powerful or Inquisitive Users.