iSeries Security Journal Receiver Management, Part 2

Published: March 15, 2006

by Steve Martinson

In the article, iSeries Security Journal Receiver Management, Part 1, I described how the OS/400 operating system logs security events that occur on your system in journal receivers associated with the QAUDJRN journal in library QSYS when iSeries security monitoring is activated. Also recall from Part 1 that you can set these 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 journal information can then 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

The key issue with all of this logging is that the journal receivers that are recording the activity can grow quickly, become numerous, and can easily be overlooked, since the system automatically manages the detachment of the "full" journal receiver (based on the size threshold you set) and automatically attaches the new journal receiver. Remember, the blame for disk capacity problems is frequently placed on the accumulation of these journal receivers. Unfortunately, the automatic cleanup function provided in OS/400, which you can access through the Operational Assistant menus, does not clean up the QAUDJRN receivers.

You're stuck between a rock and a hard place because you are the person responsible for security on your iSeries and you realize that the date ranges available for security reporting are dependent upon having that recorded security information online. As the number of detached security journal receivers on the system increases, the total disk space utilization for these receivers can begin to affect the available disk space for the rest of the system and its processes. Thus, it is very important to institute a process that addresses the security journal receivers on a regular basis in order to minimize operational impact, but you must also ensure that the system contains the files required for audit and security reporting.

Best practice recommendations are such that you back up security journal receivers at least on a monthly basis (a monthly system save). Depending upon your environment (system disk capacity, active user count, applications, auditing settings, etc.), you may want to ensure that security journal receivers are backed up weekly. (Perhaps you do a weekly system save?) However, if feasible, it is recommended to backup the security journal receivers with a special job, separate from the standard daily, weekly, or monthly system backup jobs that may occur in your environment. Having experienced the lengthy times that it sometimes takes to restore specific journal receivers from a weekly backup or system save, usually due to slow media seek time, I can assure you that you are more likely to remain sane if you implement separate security journal receiver backups as part of your weekend operations tasks.

In fact, I would actually have the operators perform the save twice, with one set of tapes is sent offsite and one set is kept in the vault for easy access should the need arise to restore security data for review or forensic reporting purposes. Why? Sometimes "Tape Vaults R Us" isn't all that quick to return a tape when you call and request a media delivery, not to mention that there have been incidents reported of backup tapes bouncing out of the truck never to be found again! (But that's a separate problem for another security tip.)

An example of a sound online security journal receiver availability schedule would be to always maintain the current and prior month's journal receivers online, even after they have been saved, to facilitate audit reporting requirements. For instance, if today is 03/15/2006, then my system would have online all security receivers for the month of February 2006 as well as the receivers that have been created so far in the month of March 2006. I call this the "trailing month" method of online receiver retention, since many of the regular security/audit report reviews are performed against the previous month's data. If the data is not there, you can't report on it.

The actual removal of saved security journal receivers would then be accomplished via the native OS/400 command interface and would be performed by security personnel, not operations staff. This is especially important for all of you "want something done right you have to do it yourself" types! I would recommend the following steps:

• At a command line, bring up a list of your security journal receivers. As I explained in Part 1 of this tip, the syntax would be WRKOBJ QGPL/ZAUDJR* *JRNRCV.
• Once the list of receivers is displayed, select the receivers using Option 8=Display description.
• This option displays the object description, which shows the creation date on the first screen, and paging down three times will show the Save/Restore information.
• Once you've determined which receivers can be deleted based on the combination of creation date and the fact they have been saved, select them with Option 4=Delete and press Enter.
• Other items to deal with:
  1. Delete only those created prior to your "trailing" month.
  2. If you don't verify that the receiver has been saved and you attempt to delete an unsaved receiver, the system will prompt you with message ID CPA7025 - Receiver &1 in & 2 never fully saved. (I C)
  3. Take a "C" to cancel processing of the delete and wait until it's been saved before attempting to delete it.

So, in general practice of this method, your operators would only generate a new journal receiver and save the existing journal receivers to tape, leaving the delete decisions to you, the expert!

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.

RELATED STORY

iSeries Security Journal Receiver Management, Part 1