May 9, 2012 - Vol 2, Issue 8
Forensic Analysis - Tracing User Activity with QAUDJRN
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.
I encourage you to review the previous article in this series (" Forensic Analysis Using QAUDJRN, Part 1: CL Command Usage" from the February 1, 2012 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 "Option for Extracting Security related information from QAUDJRN using CPYAUDJRNE" in the Security Shorts Column in the May 9, 2012 issue of this Newsletter.