Feature Article

Auditing and Reporting the Use of CL Commands

By Dan Riehl - SecureMyi.com

When I discuss the topic of auditing, I'm referring to the IBM i auditing capability in which certain predefined activities or events cause an audit log record to be written as a formatted journal entry to the system's audit journal QAUDJRN. Auditing using QAUDJRN isn't automatically configured, so when you first start your system, you must configure the IBM i QAUDJRN auditing to meet your specific auditing requirements as defined by the system administrator, the security officer, the security policy, and your IT auditors.

Once you've configured your auditing environment, regular reporting of the QAUDJRN activities and events should be instituted to ensure adherence to policy. When audit journal entries are written to QAUDJRN, you have the sound basis needed to accurately analyze and report on current and historical events.

Even assuming a regular QAUDJRN reporting regimen, there will be occasions when you need to go back and dig out past events. These past events may have negatively affected your system, or you may want simply to check on who did what, when. For example, you may want to determine who changed Fred's user profile to assign him *ALLOBJ and *SECADM special authority. When did it occur, and how was it accomplished?

In cases like this, you can use forensic evaluation methods to extract the relevant audit entries from QAUDJRN to determine the culprit. In recent cases, I have been asked to use the QAUDJRN forensic reporting methods to solve some interesting mysteries, such as:

• A particular user profile keeps becoming disabled. Why?
• An RPG program ran correctly on Saturday but ended abnormally on Sunday. Did someone change the program between Saturday and Sunday?
• Who changed the System Value QCRTAUT from *CHANGE to *ALL, and when did the change occur?
• How did a new file end up in a library with incorrect private authorities, when the library's CRTAUT was specified correctly?
• Who has used the UPDDTA(DFU) command, and what files were they viewing and potentially editing?
• What CL commands were run from the command line by all *ALLOBJ users?
• Who has run compiler commands (e.g., CRTRPGPGM, CRTBNDRPG, CRTCLPGM, etc.) to create new programs on the production system?

All these mysteries were successfully solved by using the forensic analysis of the QAUDJRN journal. It is important to note that I was able to analyze the audit entries because the customers were auditing the particular events that comprised these incidents. For example, if the auditing setup did not include the QAUDLVL system value inclusion of *SECURITY, I wouldn't have been able to discover who changed the system value QCRTAUT. Changes to system values are audited only when QAUDLVL contains the value *SECURITY or the sub-value *SECCFG.

Is Your System Ready to Start Command Auditing?

If you're unsure about the auditing settings on your IBM i, you can use the Display Security Auditing Values (DSPSECAUD) command. Run the command to discover the current auditing settings on your system. If you see from the DSPSECAUD display that the journal QAUDJRN doesn't exist, you need to configure the system to start auditing. The easiest way to configure auditing is to use the Change Security Auditing Values (CHGSECAUD) command.

To audit command usage on the i, you must configure the QAUDCTL system value to allow auditing. In the case of auditing command usage, the system value QAUDCTL should be set to include the value *OBJAUD. However, in a standard auditing environment, you typically set the QAUDCTL system value to include the three values *AUDLVL, *OBJAUD, and *NOQTEMP.

Read More . .