Security: User Auditing Example

It was a dark and stormy day. Suddenly the boss walked in.

"Got a job for you," he said. "Security."

"That is what I am here for."

Seems there is a programmer with a lot of authority. But something happened recently, and he has come under suspicion. They want to know what he does on the IBM System i system. I took the job. After all, he is my boss.

Because the boss did not confide in me what incident brought this user to their attention, I was working in the dark. I could monitor him so closely that I would be drowned in data. What I wanted was information. I would activate User Auditing on his user profile.

User Auditing is a subclass of Action Auditing, where certain actions of a user cause a journal record to be written to the Security Audit journal. These records tell what the user did. They could be viewed on a screen with the DSPJRN command or the DSPJRN command could write them to a file, and Query (or some other tool) could use that file as a database, and generate reports from it.

I decided to monitor the commands he used, any objects he deleted from our production library, and any spooled file activity. I hoped this would be enough, but not too much.

The Setup

First, I set the auditing system value to allow action auditing:
 

WRKSYSVAL QAUDCTL

I selected Option 2 and added *AUDLVL.

Then I turned on user auditing on the user profile:
 

CHGUSRAUD USRPRF(NOLDOR) AUDLVL(*CMD *DELETE *SPLFDTA)

Then I waited.

Note: The changes made by the CHGUSRAUD command take effect the next time a job is started for this user. Therefore, the user you are auditing must start a new job for the new auditing values to be picked up.

The Data

After a couple of days, I checked to see what sort of activity he had done. I checked my Security Reference manual, Chapter 9 to see what type of records I should be looking at. In table 9-2, Security Auditing Journal Entries, I saw that *CMD generates CD records, *DELETE generates DO records and *SPLFDTA generates SF records. I created copies of those files so I could run queries against the audit records and have the field names available.
 

CPYAUDJRNE ENTTYP(CD DO SF) OUTFILE(QGPL/QAUDIT)

This command will create three files named QAUDITCD, QAUDITDO and QAUDITSF in the QGPL library, you can change the name of the destination library on the previous command if needed.

Then, I created some queries and generated a report on each of these activities. Go into the Query menus, WRKQRY, and create a query for the Command audit records:

Then, select the parts of the query we will work with, the input file, the fields, and the sort order:

At the file selection screen, choose the command file:
 

After selecting the file, select the fields to display.  I chose the timestamp, job identification, the command (of course), and a few other fields:

I set it to sort by timestamp and job name:

This is the report that was generated: 

Note: Some blank columns have been removed to make the report fit the fax width. In addition, the command line field includes the complete command, even though it is not shown here. Shifting the screen to the right (F20) will show the rest of the command line.

I created a similar report for the delete entries (file QAUDITDO). The fields chosen this time are date, time, job, object, library, type and path name.  If the object type is *N, the object deleted was an IFS object so the 'Path name' field will have the path to the object:

The report generated was this:

Following is the report I generated:
 

The 'TYPE' field tells what the user did.  According to the Security Reference manual, C means spooled file creation, and D means spooled file deletion.

Analysis

Looking over the three reports, I can see that during this time the only activity was some program development in SEU. I checked what program TEST1 does, and it is just some code to do some testing on how to use an API. There is nothing suspicious in this data at all.

I presented my findings to the Boss and he exonerated Noldor. He did not want to pursue the original problem. Case closed.

Other Options

I used query to quickly generate three reports. The early steps to generate the three files, QAUDITCD, QAUDITDO, and QAUDITSF, are merely databases, and a program could have been written to read all three and interweave the records from the three files into a single report. In this simple case, it was not necessary. However, in a more complicated situation (where the user was doing more than a few edits and compiles), this might make it easier to follow what he was actually doing. Any High Level Language works. However, RPG or COBOL are best for this.


Because this user turned out to not be the trouble-maker, perhaps setting up Object Auditing on the library in question might find what is going on. For more information on Object Auditing, refer to document: