I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please check the box if you want to proceed.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

When monitoring your security, the operating system can log security events that occur on your system. These events are recorded in special system objects called journal receivers. You can set up journal receivers to record different types of security events, such as changing 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) system value

The audit level (AUDLVL) value in user profiles

The object auditing (OBJAUD) value in user profiles

The object auditing (OBJAUD) value in objects.

The information in the audit journals is used:

To detect attempted security violations

To plan migration to a higher security level

To monitor the use of sensitive objects, such as confidential files.

Managing the Audit Journal and Journal Receivers

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.

Special locking protection is used to ensure that the system can write audit entries to the audit journal. When auditing is active (the QAUDCTL system value is not *NONE), the system arbitrator job (QSYSARB) holds a lock on the QSYS/QAUDJRN journal. You cannot perform certain operations on the audit journal when auditing is active, such as:

DLTJRN command

ENDJRNxxx (End Journaling) commands

APYJRNCHG command

RMVJRNCHG command

DMPOBJ or DMPSYSOBJ command

Moving the journal

Restoring the journal

Operations that work with authority, such as the GRTOBJAUT command

WRKJRN command

All security entries in the audit journal have a journal code of T. In addition to security entries, system entries also appear in the journal QAUDJRN. These are entries with a journal code of J, which relate to initial program load (IPL) and general operations performed on journal receivers (for example, saving the receiver). If damage occurs to the journal or to its current receiver so that the auditing entries cannot be journaled, the QAUDENDACN system value determines what action the system takes. Recovery from a damaged journal or journal receiver is the same as for other journals.

I recommend that you have the system manage the changing of journal receivers. Specify MNGRCV(*SYSTEM) when you create the QAUDJRN journal, or 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. The steps to verify that this occurs can be found in the accompanying document "System Managed Journal Receivers."

Attention: The automatic cleanup function provided using Operational Assistant menus does not clean up the QAUDJRN receivers. You should regularly detach, save, and delete QAUDJRN receivers to avoid problems with disk space.

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. It is very important to institute a process that addresses the security journal receivers on a regular basis in order to minimize operational impact as well as to ensure that the system contains the files required for audit and security reporting.

Best practice recommendations are that you back up security journal receivers at least on a monthly basis. Depending upon your environment (system DASD availability, active user count, applications, etc.), you may want to back them up on a weekly basis. If feasible, it is recommended to backup the security journal receivers with a special job, separate from the standard daily and/or weekly system backup jobs that may occur in your environment.

An example of a sound on-line security journal receiver availability schedule would be to always maintain the current and prior month's journal receivers on line after they have been saved to facilitate audit reporting requirements. For instance, if today is 12/12/2004, then my system would have on-line all security receivers for the month of November 2004 as well as the receivers that have been created so far in the month of December 2004.

The 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. So in general practice, your operators would only generate a new journal receiver and save the existing journal receivers to tape.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy