Auditing User Activity on IBM i

By Dan Riehl

In this second installment of the series dealing with forensic analysis by using the QAUDJRN journal, the focus is on the forensic analysis of user activity. I discuss how to audit and report on various activities performed by a particular user, and I also show how to audit and report on security-related events caused by all users. As examples, I examine how to audit and report on every time QSECOFR changes a system value, and I also discuss how to audit and report on every occurrence in which any user deletes any object.

Auditing Revisited

I encourage you to review the previous article in this series (" Auditing CL Command Usage" from the May 8, 2013 Issue of the SecureMyi Security Newsletter), which discusses the basics of auditing and reporting from the system security audit journal QAUDJRN.

In order to begin reporting on security related activities, you must first configure your system to perform the auditing functions you need. The system values QAUDCTL and QAUDLVL must be set for your desired level of auditing, and the QAUDJRN journal must have been created on your system.

Every security-related event that occurs on your system is tied to a particular user. In this article, the focus is on reporting on the activities performed by a user.

Usually, we want to report on the activities of our powerful users such as QSECOFR and system administrator users. Powerful IT users and other users with command-line access have the freedom to navigate the system outside of the constraints of a menu system that would otherwise confine their activities to those allowed by their menu options. Having said that, let me also say that you can audit and report on the activities of any user, regardless of the user's power or ability to navigate the system.

When you want to be able to audit and report on the activities of a particular user, you must first decide which events you're interested in collecting. If you don't care whether someone moves a spooled file report from one output queue to another, or if you don't care when a program adopts authority, it affects your choices when configuring auditing. If you want to be able to track each time a new library is created on the system or every time a file is deleted, it likewise affects your auditing configuration. The events that can be audited are described by a combination of the allowable values for the system values QAUDLVL and QAUDLVL2, and the allowable values for the AUDLVL attribute of each user profile.

If you decide that you want to audit and be able to report every time an object is created or deleted on the system, you add *CREATE and *DELETE to the system value QAUDLVL. If you want to know every time there's an authority failure on the system, you add *AUTFAIL to the QAUDLVL system value. But, as an option, if you want to know only when an object is created or deleted by a certain user, or if you want to know only when a certain user encounters an authority failure, you add the values *CREATE, *DELETE, and *AUTFAIL to the user's AUDLVL attribute by using this command:

CHGUSRAUD USRPRF(User-Profile-name) AUDLVL(*CREATE *DELETE *AUTFAIL)

The user profile's AUDLVL values determine what events are audited for this user. Events specified in the QAUDLVL system value are audited globally for all users.

When QSECOFR Changes a System Value

If you want to audit each time QSECOFR changes a system value, you need to include the value *SECURITY in the QAUDLVL system value or specify *SECURITY on the AUDLVL attribute of the QSECOFR user profile. Don't be concerned about changing the QSECOFR user profile to include auditing values in the CHGUSRAUD AUDLVL parameter. I generally advise that you shouldn't change IBM-supplied user profiles, but that advice doesn't apply to changing user auditing values.

Once you've changed the system value or the user profile to include *SECURITY auditing, any changes made to a System Value cause a special entry to be written to the QAUDJRN journal. Changes made to System Values are identified in QAUDJRN as an entry with the SV journal entry type. The SV journal entry type is also used when a system service attribute is changed or when the system clock is changed.

Extracting and Reporting on the System Value Change

As I discussed in the previous article in 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 output file for SV journal entries by using this command:

CRTDUPOBJ OBJ(QASYSVJ5) FROMLIB(QSYS) OBJTYPE(*FILE) TOLIB(MYLIB) NEWOBJ(SV_MODEL)

The model output file is always QASYxxJ5, where xx is the entry type, in this case SV.

Next, run the DSPJRN command, specifying that you want to extract the SV entries and that you want only the entries generated by QSECOFR, by using this command:

DSPJRN JRN(QAUDJRN) RCVRNG(*CURRENT) JRNCDE((T)) ENTTYP(SV) USRPRF(QSECOFR) OUTPUT(*OUTFILE) OUTFILFMT(*TYPE5) OUTFILE(MYLIB/SV_MODEL) OUTMBR(*FIRST *REPLACE)

NOTE: See the article "Alternative QAUDJRN Extraction Method" in the Security Shorts Column in the May 8, 2013 issue of this Newsletter.

Model Outfile for System Value Changes Audit Entries (Type SV) QASYSVJ5

Figure 1 above shows the layout of the model output file for system value changes. When you use the DSPJRN command as shown here, this will be the format of the data. Notice that the field SVSYSV contains the name of the system value that was changed, and the fields SVNVAL and SVOVAL contain the new and the old values, respectively. The field SVUSPF contains the name of the user who changed the system value. Once you have performed the DSPJRN command, you're ready to use SQL or Query on the file or download the file into Microsoft Excel or another spreadsheet or database program for further slicing and dicing. So now we have all the information we need on all system value changes performed by the specific user QSECOFR.

Auditing and Reporting Object Deletions by All Users

To report events in which an object is deleted for all users, the system value QAUDLVL must contain the value *DELETE. Once this is set, anytime a user deletes an object, a DO journal entry is written to the QAUDJRN journal. If an object in the library QTEMP is deleted, the event is not audited to QAUDJRN.

The DO journal entry is written whenever any object, Document Library Object (DLO), or IFS directory or stream file is deleted. If the deletion is performed under commitment control, additional DO entries are written to indicate a pending deletion.

Extracting and Reporting on the Delete Object Event

As in the previous example, you first create a duplicate of the IBM-supplied model output file, but this time for the DO journal type, using this command:

CRTDUPOBJ OBJ(QASYDOJ5) FROMLIB(QSYS) OBJTYPE(*FILE) TOLIB(MYLIB) NEWOBJ(DO_MODEL)

The model output file this time is QASYDOJ5. DO is used to indicate the Delete Object model output file.

Next, run the DSPJRN command, specifying that you want to extract the DO entries for ALL users, using this command:

DSPJRN JRN(QAUDJRN) RCVRNG(*CURRENT) JRNCDE((T)) ENTTYP(DO) USRPRF(*ALL) OUTPUT(*OUTFILE) OUTFILFMT(*TYPE5) OUTFILE(MYLIB/DO_MODEL) OUTMBR(*FIRST *REPLACE)

Model Outfile for Deleted Objects Audit Entries (Type DO) QASYDOJ5

Figure 2 above shows the layout of the model output file for object-deletion events. The field DOONAM identifies the object name deleted, and the field DOOLIB identifies the name of the object library. If the object is a DLO or a directory or stream file in the IFS, the other listed fields are used to identify the name of the file or directory and the path to the deleted object.

Auditing Other User actions

In addition to the examples shown here, there are many other options for auditing the actions of a user. For example, by including *CMD in the user's AUDLVL attribute, you can begin auditing every CL command executed by the user. You can also report object access by a user in order to answer questions such as, "What files did this user open?" In upcoming installments in this series, I'll provide more detail about object auditing. In part 1, I provide detailed discussion of auditing *CMD usage.

Consistency in Execution

As you can see, if you use the method of first creating a duplicate of the IBM-supplied model output file for each journal entry type you want to report on, you can then use the DSPJRN command to place the relevant journal entries into their correct format for queries and other audit reporting formats. Those reports in turn provide the information you need to correctly identify and manage the security-related events occurring on your system.

---

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