Making Sense of the IBM i Security Audit Journals

By Rich Loeber

To track security events on your IBM i, the i/OS has quite nicely provided an extensive security audit journal function to help you. When you have security auditing active on your system, all sorts of relevant security information is regularly stored in your system security audit journal that will help you to know what's going on with your system. This is a great feature for the IBM i OS, but capturing the audit information and then using it in a meaningful way are two different things.

This tip will just scratch the surface of how you can start to make some sense out of all the information that is stored with your system security audit journal.

The secret that starts the process of unlocking the system audit journal is the Display Journal (DSPJRN) command. To work with the system audit journal, run this command for the journal named QAUDJRN.

The command defaults to displaying information to your terminal screen. This is a hard way to wade through the information, although there are any number of filters that you can use to limit the information displayed.

A better way to work with this information is to run the Display Journal command using one of the options that transfers the journal information into a normalized database file. This is done by selecting the option OUTPUT(*OUTFILE). When you do this, you will have to specify the format for the output file. There are five different formats offered, from *TYPE1 through *TYPE5. You can use the HELP function to see the difference. Each higher number format builds on the information in the base *TYPE1 format. If you're just starting, the *TYPE1 format should be sufficient.

Once you have your database built, then it is time to start analyzing it to see just what you have recorded in your security audit journal. For starters, I recommend that you run summary reports on fields like the Entry Type, Job Name, User Profile and so on to see how many records you have in your current journal with various values. On our test system here, I do this with the old "Query Two Step" of summarizing the information to a file and then reporting that file. I have some Query definitions that I've created for this purpose that I would be happy to share with you in a save file that you can restore to your system. If you'd like a copy, just let me know by email (rich at kisco.com) and I'll send them to you.

As you work with the databases that you've created and the various analysis reports that you work with, you will also need to have a copy of the IBM i Security Manual handy. There are at least 100 pages in the Appendix (on ours, it is Appendix F) that describe all of the information in the various database formats, not to mention the codes that can be contained and what they mean. On our system, I've even found codes in the security audit journal that are not documented in the Security Manual. In that case, the next stop is IBM support.

If the tasks seems too daunting for you, I'm certain that you will not be the first security officer who has thrown in the towel on analyzing this audit journal. There are a number of third party software solutions that have taken the time to do all of the necessary investigation and one of them might just fill the bill for you, not to mention lowering your blood pressure.