iSeries Security Journal Receiver Management, Part 1

We were recently subjected to an audit of our iSeries security practices under the auspices of Sarbanes-Oxley due to the fact that we are a publicly traded company. Believe it or not, it was the first time we had ever had any outside party review our iSeries security! Ignoring that glaring security exposure and getting right to the point, we were cited by the auditors for not having the security audit journaling function activated on our production iSeries system. (I know: an even worse security exposure!) We have been hesitant to activate the audit journal due to things we have heard from other installations, particularly about the impact security auditing has had on their disk utilization. Can you share some of the basics on security journal management according to your experiences and possibly alleviate our concerns about the receivers?

Thanks!

–Saleem

First of all, don’t feel bad about the ding on your audit for not having auditing turned on. Even in this age of über-logging where everything you can think of is being tracked, there are some iSeries shops that simply haven’t addressed this issue yet. Usually this is because the company is in an area of business that has not been subjected to any widespread IT security/auditing regulations like those in the financial or healthcare industries have. Additionally, I can’t tell you how many times I’ve heard the line, “We need to get rid of some of the security journals because we’re running out of disk space!” As it is with programmers thinking they need *ALLOBJ special authority, so it is with blaming disk space problems on security auditing. However, like it or not, as you just found out, the government’s desire to enforce the provisions of SOX is a real one. So, since you must comply with the requirement to implement controls for any data that may impact the company financials, as step one, you had better turn on iSeries security journaling and put together a plan for managing the resulting output!

Let’s start with some basics. When iSeries security monitoring is activated, the operating system logs security events that occur on your system. These events are recorded in special system objects called journal receivers, which are “attached to” or exclusively associated with the QAUDJRN journal in library QSYS. You can set up the audit journal receivers to record different types of security events, such as a change to a system value or user profile, or an unsuccessful attempt to access an object. The following values control which events are logged:

• The audit control (QAUDCTL) system value
• The audit level (QAUDLVL and QAUDLVL2) system values
• The audit level (AUDLVL) value specified in the user profiles
• The object auditing (OBJAUD) value of the user profile objects (and all other system objects as well)

As I’m sure you’ve read somewhere before, the information that is recorded in the audit journals can be used:

• To detect security errors and violations
• To plan migration to a higher security level, say from level 30 to level 40
• To monitor the use of sensitive objects, such as powerful commands and confidential files

Managing the Audit Journal and Journal Receivers

IBM clearly states that “the auditing journal, QSYS/QAUDJRN, is intended solely for security auditing. Objects should not be journaled to the audit journal. Commitment control should not use the audit journal. User entries should not be sent to this journal using the Send Journal Entry (SNDJRNE) command or the Send Journal Entry (QJOSJRNE) API.”

What this means is that the security audit journal should not be shared among other applications and processes looking for a place to journal their transaction data. Security journal information is very important and sensitive in its own right, so it must be treated accordingly. Just remember that if something happens to the journal or to the currently attached receiver such that the system cannot write auditing entries to the journal, the system value QAUDENDACN determines what the system will do about it–either turn off auditing and send a notification to the QSYSOPR and QSYSMSG message queues (*NOTIFY) OR turn off auditing and issue the power down system command (*PWRDWNSYS). Most sites use the former setting and, honestly, I have yet to see an installation that used the latter.

I always recommend that you have the system manage the changing of journal receivers. If it is set to user-managed, then it will require manual intervention to stay on top of the receivers. Specify MNGRCV(*SYSTEM) when you create the QAUDJRN journal or, if it’s already created, change the journal to that value so that the system automatically detaches the receiver when it reaches its threshold size and creates and attaches a new journal receiver. This is called system change-journal management.

Here is how to change a user-managed journal to be system-managed:

1.  On a command line, type WRKJRNA, press F4. Enter QAUDJRN for the Journal and leave *LIBL for the library. Your screen should look like the screen shown below:

Press Enter

After you press Enter you should see a screen similar to the one shown below. Please make note of the information on your screen that corresponds with the information in bold type in the screen shown below.

1 = Journal Name
2 = Library that journal resides in
3 = Name of the currently attached journal receiver
4 = Library that currently attached journal receiver resides in

After you have made note of all of the necessary information press F3 to exit the Work with Journal Attributes screen.

2.  On a command line, type CRTJRNRCV press F4. The journal receiver needs to be at least one number larger than the one noted above in Step 1. For example, if ZAUDJR0011 is attached, use ZAUDJR0012 here. The library needs to match the library for the journal receiver shown above (QGPL for example), Auxiliary storage pool ID is *LIBASP, Journal receiver threshold is variable (I suggest using the default of 1500000, which is 1.5GB per receiver). Text should be ‘Audit Journal Receiver’. Below is an example of what the screen should look like before you press Enter.

After you have verified the information is correct. Press Enter. This will create a new journal receiver on your system.

3.  On a command line, type CHGJRN, press F4. The journal to be changed is QAUDJRN and library is QSYS (unless otherwise displayed in Step 1). Press Enter.

The returned screen should be filled in as noted below. The Journal receiver number used is the one you created in Step 2 above. Also, make sure that the Manage receivers option is specified as *SYSTEM:

After you have made all of the changes shown above, press Enter. This will attach your newly created receiver, and tell the operating system to start managing the journal receivers.

Use the WRKJRNA command as in step 1 and press F15 from the screen where the attached journal number is displayed. This will show all associated receivers. Part II of this tip will discuss a strategy for on-line retention and management of the security audit journal receivers themselves.

Steve Martinson is a senior consultant and manager of the iSeries Security Practice for Servique, LLC. Martinson’s primary focus is on enterprise implementations of NetIQ Security Solutions for iSeries (NSSi) for key NetIQ accounts, starting at the planning stage and helping customers move through assessment, design and implementation.