With so much information in the IBM i audit journal, you have to know what you’re looking for. Otherwise, you may miss some important information.

Whether you’re using a product such as HelpSystems’ Compliance Monitor or getting information directly out of the audit journal yourself, this article will help you have a better understanding of what’s available.

I’m going to be referring to the IBM i Security Reference manual throughout this article. You may want to download and follow along.

Hint #1: Understand the Structure of the Entries

Numerous types of audit journal entries exist. One exists for each type of unique information that needs to be provided; for example, the CP entry that logs information about the creation or changes of user profiles contains different information from the authority failure (AF) entry, which is different from the audit journal entry that logs changes to system values (SV).

That said, each type of entry, while having unique information, also contains information that’s common to all entries. That’s called the “header” information. This common information is documented at the beginning of Appendix F in the Security Reference manual. Be sure to look at the *TYPE5 header information because it contains the most information and is the most current. The other *TYPEx entries are listed only for compatibility with older releases. The header contains information that can be quite helpful: the timestamp so you know when the audit journal entry was generated, the job information, the program and program library running at the time the entry was generated, and, when available, an IP address. The IP address is toward the end of the header in the Remote address field and is very useful when investigating the source of invalid sign-on attempts (PW) entries. Don’t look only at the fields that are specific for each type of entry; if you do, you’ll be missing quite a bit of information.

Hint #2: Know Which User Profile Name to Look For

Every audit journal entry contains at least two fields that refer to user profiles—sometimes more, depending on the entry type. The fields I want to focus on are in the header. The User name field is the name of the profile that makes up part of the job name, as in job number/job user/job name. This is the profile under which the job started. The User profile field is the profile under which the job was running when the audit journal entry was created. These fields may contain the same name, but when the job starts as one user and a profile swap occurs so that the job runs as a different profile, the names will be different. The best examples of this are the pre-start jobs that service ODBC connections. They start as QUSER, but when an ODBC request is made, the system swaps the job to run as the person making the ODBC connection. It’s rare that I examine the job user (the User name field.) My focus is generally on the profile that was running at the time the entry was generated: the User profile field. Using the User name field rather than the User profile field leads me down the wrong path when investigating issues.

Hint #3: Know Where to Look for IFS-Related Entries

I realize that the IFS is a bit of a mystery to some, but just as you can secure directories and objects in directories, you can audit them too. All actions that can be audited for libraries and objects in libraries can also be audited for directories and objects in directories—for example, authority failures, creation and deletion of objects, etc. You can also configure object auditing on IFS objects. The key to understanding the audit entries for IFS objects is knowing which field to look in. Your clue that the entry is for an IFS object is when the object name field is *N. That’s the sign to look near or at the end of the entry for the Path Name field, a character field that’s 5002 characters long.

Hint #4: Understand Object Auditing

To enable object auditing, you must include *OBJAUD in the QAUDCTL system value. Then use the Change Object Auditing (CHGOBJAUD) command to “turn on” auditing on specific objects. You can specify to audit the update of an object (*CHANGE) or to audit both updates and reads of an object (*ALL). (You don’t have the option to specify to audit only reads of an object.)

Once auditing has been enabled on an object, every time the object is read, an audit entry of type ZR will be generated. Examples include when a file is read or an SQL SELECT statement is run or it’s FTPed to another system or downloaded to a spreadsheet. Likewise, when the object is updated, an audit journal entry of type ZC is generated.

When do I use object auditing? When I’m trying to discover how and when an object is being used or when I’m trying to determine the processes using an object. For example, when the HelpSystems Professional Security Team is helping one of our clients change their security posture from one of wide-open access to restricted access, we need to determine what processes are accessing those objects—typically, physical and logical files. The best way to do that is to enable object auditing on those objects and then look at the ZR and ZC entries.

One thing I need to caution you on, however. When I’m trying to discover how an object is being used, I first look in Appendix E of the Security Reference manual. This appendix lists, by object type, the actions that cause a read (ZR) or update entry (ZC) to be generated. Some actions you might think should cause an entry don’t, so it’s best to check first.

Hint #5: Decipher the Two-Letter Audit Entry Types

I’ve been referring to these two-letter “codes” throughout this article. What if you don’t know what these are for or you don’t know which one to use? Several references exist for these two-letter codes. If you are using the Copy Audit Journal Entry (CPYAUDJRNE) command to get entries out of the audit journal, you specify these two-letter codes to “harvest” the information you’re looking for. CPYAUDJRNE then generates a file—QAUDITxx in library QTEMP—where xx is the two-letter code specified. If you’re unsure of the code, press F1=Help on the Audit journal types field. The help text provides a short description of each two-letter code. These descriptions are also available in Appendix F, after the description of the header fields. But if you’re still lost or need more detail, look in Chapter 9 of the Security Reference manual. Table 133 provides the mapping between what’s specified in the QAUDLVL (action auditing) system value and the codes that can be generated by specifying each. For example, the table shows that, if you specify *CREATE as one of the values for QAUDLVL, you could have AU, CO, DI, and XD entries.

Summary

So much information in the audit journal is never utilized. I hope this gives you a better understanding of what’s available so you can make full use of this information.