Forensic Analysis Part 3 - Tracking Access to Sensitive Files

By Dan Riehl

In this third installment of the series dealing with forensic analysis 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 does 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 access only, and whether the access was for inquiry only or for update. I cover detecting and reporting on database-update events in an upcoming installment of this Forensic Analysis series.

Auditing Revisited

I encourage you to review the previous articles in this series Forensic Analysis Using QAUDJRN, Part 1: CL Command Usage and Forensic Analysis Using QAUDJRN, Part 2: User Acitivity 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 file named CREDITCARD the command is:

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

Once this command is run, each time the file is accessed, an 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 start with ZC, and the ZR format has the same fields, but they begin with the letters ZR. Figure 1 shows the entire ZR journal entry format (as defined in the IBM-supplied 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. The access type is identified by 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 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 would 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 need to start auditing the object by using the CHGOBJAUD command.

CHGOBJAUD OBJAUD Options

The CHGOBJAUD command lets you specify that access to an object 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 be audited. File access, such as an RPG open for input operation, isn't audited. But, if the file is opened for update, that access is audited, because it is an open for update operation. It doesn't 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 that are set to OBJAUD(*CHANGE), if a 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, that access would be audited because it's an update operation. The value *ALL specifies that all access to the object be audited. An open of the 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 terribly ill conceived and recommend that you avoid 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 DSPOBJD command to view the current Object Auditing setting 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 is 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 at will. The controls aren't in place. In cases like this, it's important to know who looked at, or even changed, your sensitive files.

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

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

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

Once you've turned on 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 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 *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 journal entries. Here is an alternative that can provide additional filtering capabilities over CPYAUDJRNE.

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 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 the 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 a separate output file, use this 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 Query, 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 specify *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 harvest the ZC and ZR journal entries and select the entries generated by the main database server job named QZDASOINIT.

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 present 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