Tracking Access to Your Sensitive Files

By Dan Riehl

In this article on auditing using the QAUDJRN journal, the focus is on detecting access to sensitive files. In our heavily regulated environment, it's crucial that we keep prying eyes out of personal, private, and sensitive data. We also need to protect our files against unauthorized changes. The information I present here doesn't let you block unsanctioned access, but it can tell you when this access happens, after the fact. I once heard it said, "That which we cannot prevent, we must be able to detect."

I discuss how to audit and report on file access under everyday scenarios. I also discuss the various auditing options and how to configure the correct level of auditing you need to accomplish your reporting objectives. As examples, I examine how to audit and report on every event in which an IT staff member accesses the sensitive CREDITCARD file, whether for inquiry or for update. I also examine how to audit and report on every file accessed by using ODBC and whether the access was for inquiry or for update. The object-auditing methods I present here don't let you detect or report on database record updates; rather, I'm dealing with file level access only, and whether the file access was for inquiry only or for update. I cover detecting and reporting on database record-level update events in the September 24, 2014 issue of SecureMyi Newsletter.

Auditing Revisited

I encourage you to review the previous articles in this series Auditing and Reporting the Use of CL Commands and Auditing User Activity from the SecureMyi Security Newsletter.

Object Auditing

To audit and report on file access and access to other objects, the system value QAUDLVL must contain the value *OBJAUD. Once you've set the system value, you need to tell the system which objects you want to audit and the level of auditing you require. To begin auditing an object, you use the Change Object Auditing (CHGOBJAUD) command. Here's the command's format:

CHGOBJAUD   OBJ(Library-name/Object-name)   OBJTYPE(Object-Type)  +
                            OBJAUD(*ALL, *CHANGE, *USRPRF, *NONE)

To begin auditing ALL access to the sensitive file named CREDITCARD the command is:

CHGOBJAUD OBJ(PRODLIB/CREDITCARD) OBJTYPE(*FILE) OBJAUD(*ALL)

Once this command is run, every time the file is accessed, an journal entry is written to the QAUDJRN journal. If the file is accessed in a read-only operation, a journal entry type of ZR (object opened for read) will be written. If the file is accessed for an update operation, a journal entry type of ZC (object opened for change) will be written. The formats of the ZC and ZR journal entry types are virtually identical. The ZC format fields begin with the prefix ZC, and the ZR format has the same fields, but the field names have the prefix of ZR. Figure 1 shows the entire ZR journal entry format (as defined in the IBM-supplied model file QASYZRJ5).

Each journal entry identifies the access information such as job name, job user, current user, job number, program used to access the file, date, time, and so forth. The object name, library, and object type are also included, as is the object Access Type Code. The Access Type Code is a numeric code that indicates the exact access that has been performed (e.g., open, save, rename, copy). Figure 2 shows the Access Type Codes and their meanings.

The Access Type Codes list contain many operations that aren't used when file access is considered, but because object auditing can be active for any object type, most of these are irrelevant to file objects (e.g.,call and debug, which could be used when the object type is a program or service program). This is a good place to restate that object auditing can be in effect for any object type. If you want to know when a program object is used or changed or when a library object is changed, you can begin auditing access to the object by using the CHGOBJAUD command.

CHGOBJAUD OBJAUD Options

The CHGOBJAUD command allows you to specify whether access to an object is to be recorded in the QAUDJRN journal. As I mentioned, you specify the name of the object and the object type to be audited; you then select the OBJAUD value:

CHGOBJAUD . . OBJAUD(*ALL, *CHANGE, *USRPRF, *NONE)

The value *NONE specifies that access to the object is not audited. This is the state of all objects on the system unless you specify otherwise. If an object is being audited, you can turn off the auditing function for the object by specifying *NONE.

The value *CHANGE specifies that all access to the object for update operations is audited. File access, such as an RPG or COBOL Open for Input operation, isn't audited. But, if the file is opened for Update, that access is audited, because it is an Open in Update mode. It does not indicate that any change actually took place or that any records were updated. It indicates only that the file was opened in Update mode.

When it comes to other object types, (e.g. Program Objects) that are set to OBJAUD(*CHANGE), if the audited program is run, that access wouldn't be audited, because running a program isn't an update operation. If, however, the program is changed using the CHGPGM command, or other change access methods, that access would be audited because it's an update operation.

The value OBJAUD(*ALL) specifies that every access to the object is audited. An open of an audited file for input or for update is audited, as are changes made to the file using commands such as CHGPF and ADDPFM.

The OBJAUD value *USRPRF specifies that the object access is audited only if the user accessing the object has a User Auditing Value of *ALL or *CHANGE. For this, you use the Change User Audit (CHGUSRAUD) command and set the user's OBJAUD value to *ALL or *CHANGE. I consider the *USRPRF option to be ill conceived and recommend that you avoid using it.

Appendix E, "Object Operations and Auditing," of the IBM i Security Reference contains the operations audited for all the different object types and lists which operations are considered change (ZC) operations and which are considered read-only (ZR) operations. Some operations on files aren't audited. For example, the use of common display commands such as Display File Description (DSPFD), Display File Field Description (DSPFFD), and Display Object Description (DSPOBJD) doesn't generate an audit entry. Almost coincidentally, you can use the Display Object Description(DSPOBJD) command to view the current Object Auditing setting of an object.

The QCRTOBJAUD System Value

When new objects are created, you can specify that they should have their auditing value set to *ALL, *CHANGE, *USRPRF, or *NONE. The system value QCRTOBJAUD is used to specify the default auditing value for newly created objects. It's shipped from IBM with a value of *NONE, meaning that newly created objects will have their auditing value set to *NONE.

Each library on the system has a corresponding attribute named CRTOBJAUD. When you create or change a library, you can specify the CRTOBJAUD value. The default is *SYSVAL, which specifies to use the system default found in the system value QCRTOBJAUD. But you can override the system value by specifying *ALL, *CHANGE, *USRPRF, or *NONE on the CRTLIB or CHGLIB command as in the following:

CRTLIB LIB(MYLIB) CRTOBJAUD(*CHANGE)

In this case, newly created objects in library MYLIB will have the OBJAUD value set to *CHANGE. It's just as if you had specified the CHGOBJAUD . . . OBJAUD(*CHANGE) command for each new object.

When the IT Staff Accesses the Sensitive CREDITCARD File

It's a standard security practice that the IT staff has no access to production data, except in emergency situations. During those emergencies, the activity of the responding IT personnel should be audited and reported to ensure the proper controls have been maintained. However, in many cases, the IT staff isn't restricted from viewing or even updating critical production data. The controls are often not in place. In cases like this, it's important to know who looked at, or even changed, your sensitive files.

If you want to record each time an IT staff member accesses the CREDITCARD file, you first need to set the object auditing value for the CREDITCARD file to *ALL:

CHGOBJAUD OBJ(PRODLIB/CREDITCARD) OBJTYPE(*FILE) OBJAUD(*ALL)

This command causes all access to the CREDITCARD file to be recorded. Again, record-level access isn't collected by turning on object auditing. However, you'll record every time the file is opened for input or for update by anyone.

Once you've turned on *ALL auditing for the file, all access to the file will be written to the QAUDJRN journal, usually with a ZC (object opened for change) or a ZR (object opened for read) journal entry.

Since turning on *ALL auditing for an object will cause a journal entry to be written every time the object is accessed, you will not want to turn on auditing for objects haphazardly. Pick your most sensitive files, or files in which you want to be able to know who views or changes the file. If the file is heavily used by thousands of users, the number of journal entries can be quite large, so, be sure to account for this in your QAUDJRN journal receiver management plan. Also, keep in mind, if disk space for ZC and ZR journal entries is a problem, you can turn the auditing on and off for the file as needed using the command CHGOBJAUD.

High Availability Software

Many popular commercial high availability (HA) software solutions rely on OBJAUD(*CHANGE) being set for all production objects (e.g., files, programs, libraries, data areas). Typically the QCRTOBJAUD system value is set to *CHANGE, and the production libraries are set to CRTOBJAUD(*SYSVAL). This means that all newly created objects in production libraries will have the auditing value set to *CHANGE.

Extracting and Reporting on CREDITCARD File Access

IBM has provided the CL command CPYAUDJRNE(Copy Audit Journal Entries) to extract and format QAUDJRN journal entries. I highly recommend the use of this command. But, here is an alternative method that can provide additional filtering capabilities over the capabilities of the CPYAUDJRNE command.

As I discussed in the previous articles of this series, IBM has made it easy to extract the journal entries of interest from QAUDJRN. First, create a duplicate of the IBM-supplied model outfile for ZC and ZR journal entries:

CRTDUPOBJ OBJ(QASYZCJ5) FROMLIB(QSYS) OBJTYPE(*FILE) +
                TOLIB(MYLIB) NEWOBJ(ZC_MODEL)

CRTDUPOBJ OBJ(QASYZRJ5) FROMLIB(QSYS) OBJTYPE(*FILE) +
                TOLIB(MYLIB) NEWOBJ(ZR_MODEL)

The model outfile will always be QASYxxJ5, where xx is the journal entry type, in this case ZC and ZR.

Next, run the Display Journal (DSPJRN) command, specifying that you want to extract the ZC entries. This command extracts all ZC (object opened for change) entries and sends the formatted results to your file ZC_MODEL:

DSPJRN JRN(QAUDJRN) RCVRNG(*CURRENT) JRNCDE((T)) ENTTYP(ZC) OUTPUT(*OUTFILE) +
                 OUTFILFMT(*TYPE5) OUTFILE(MYLIB/ZC_MODEL) OUTMBR(*FIRST *REPLACE)

Next, to collect all the ZR entries into the separate output file named ZR_MODEL, use the command:

DSPJRN JRN(QAUDJRN) RCVRNG(*CURRENT) JRNCDE((T)) ENTTYP(ZR) OUTPUT(*OUTFILE) +
                OUTFILFMT(*TYPE5) OUTFILE(MYLIB/ZR_MODEL) OUTMBR(*FIRST *REPLACE)

When using the DSPJRN command, you can limit your selection to a range of journal receivers or a date/time range. You cannot, however, use the OBJECT parameter in the DSPJRN command to limit the selection to only the CREDITCARD file. The OBJECT parameter is incompatible with the ZC and ZR journal entry types. Figure 1 shows the layout of the model output file for ZR entries extracted using the DSPJRN command.

Some of the main fields of interest in the output format are:

• ZRONAM - the object name that was accessed
• ZROLIB - the library name that contains the object accessed
• ZROTYP - the object type that was accessed
• ZROPGM - the program used to access the object
• ZROPGMLIB - the program library of the program used to access the object
• ZRJOB - the job name that accessed the object
• ZRUSPF - the current user profile used to access the object

In the example here, we want to focus on the entries in which the ZRONAM (object name) is CREDITCARD. We also want to focus on entries in which the ZRUSPF (current user) is a member of the IT staff. You might also be interested in the access type. You can use the table in Figure 2 to cross-reference the access type. Using a tool such as SQL, Query or Excel you can create a report that selects only the records of interest and presents them in a nice reporting format.

Auditing and Reporting All Files Accessed Using ODBC

In order to audit and report on all files that are accessed using ODBC, the files must have their auditing value set to *ALL or *CHANGE. This is a typical setup for some High Availability software, but is abnormal when H/A solutions are not in use. So if your files aren't currently set to OBJAUD(*ALL or *CHANGE), they will need to be set using the command CHGOBJAUD. Thankfully, the CHGOBJAUD command lets you perform bulk changes by using *ALL for the object name:

CHGOBJAUD OBJ(PAYROLL/*ALL) OBJTYPE(*FILE) OBJAUD(*ALL)

This command sets the OBJAUD value to *ALL for each file object in library PAYROLL. Once your files are set for *ALL object auditing, you're ready to start harvesting the ZC and ZR journal entries and select the entries generated by the main database server job named QZDASOINIT. Note: The job QZDAINIT for used for SNA ODBC connections and QZDASSINIT is used for ODBC secure-sockets connections.

Extracting and Reporting on the ODBC File Access Events

As in the preceding example, you first create a duplicate of the IBM-supplied model output file. If you've set the files to OBJAUD(*ALL), you can extract both ZC and ZR entries. If the OBJAUD(*CHANGE) value is used, only ZC records will be available. Here is the command to create the outfile for extraction of the ZC (object opened for change) entries:

CRTDUPOBJ OBJ(QASYZCJ5) FROMLIB(QSYS) OBJTYPE(*FILE) +
                TOLIB(MYLIB) NEWOBJ(ZC_MODEL)

If OBJAUD(*ALL) is used on the files, you can also extract ZR (object open for read) entries. So, you can create the model outfile for the ZR entries as well, as in the previous example.

Next, we run the DSPJRN command, specifying that we want to extract the ZC entries generated by the QZDASOINIT job (Database Server used by ODBC), using this command:

DSPJRN JRN(QAUDJRN) RCVRNG(*CURRENT) JRNCDE((T)) ENTTYP(ZC) JOB(QZDASOINIT) +
                OUTPUT(*OUTFILE) OUTFILFMT(*TYPE5) OUTFILE(MYLIB/ZC_MODEL) +
                OUTMBR(*FIRST *REPLACE)

Once the DSPJRN command has completed the extraction of the journal entries, use a query tool to select and format the data for viewing. In the previous example, we examined the important fields used in the ZR model output file. The fields in the ZC model outfile are virtually identical, but the field names are prefixed with ZC instead of ZR.

Here's a list of some of the important fields in the ZC model output file:

• ZCONAM - the object name accessed
• ZCOLIB - the name of the library that contains the object accessed
• ZCOTYP - the object type accessed
• ZCOPGM - the program used to access the object
• ZCOPGMLIB - the program library of the program used to access the object
• ZCJOB - the job name that accessed the object
• ZCUSPF - the current user profile used to access the object

Auditing with a Purpose

Set your OBJAUD auditing values as needed for your files and other objects. When you need to track file use and the use of other objects, you can use the principles I presented here. In the upcoming articles in this series, I cover more auditing options to help you get on top of your legal and regulatory requirements.

About the Author

Dan Riehl is the Editor of the SecureMyi Security Newsletter and a Security Specialist for
the IT Security and Compliance Group

Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients. He also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc.

Dan Riehl on LinkedIn