Tracking Use On Critical Files/Objects

By Rich Loeber

Most shops have at least one, and probably more than one, mission critical information assets stored on the IBM i system. If you're doing your job as security officer, that asset is locked up tight to make sure that only authorized user profiles can get to it. But, do you know for a fact who is actually accessing that critical data?

Here is one way that you can review who is reading and even who is changing data on an individual object-by-object basis on your system. That is by using object auditing, a built-in feature of the IBM i OS.

For starters, you have to have to have Security Auditing active on your system. You can do a quick double check for this using the Display Security Auditing (DSPSECAUD) command. If security auditing is not active, you will need to get it up and active on your system. That is a process for a different tip. If you need help getting this started, send me an email (see below).

With security auditing active, you can set up access tracking on an object-by-object basis using the Change Object Auditing (CHGOBJAUD) command. Depending on what you're objective is, you can set the OBJAUD parameter to a number of values. Check the HELP text for more information. If you want to check everything, just set it to *ALL. If you are only tracking usage for a limited time period, be sure to change this value back to *NONE when you're finished as this will reduce some system overhead.

Once object auditing has been activated, the system will start adding entries to the system audit journal whenever any activity happens on the object you have activated.

To view the journal information, you use the Display Audit Journal Entries (DSPAUDJRNE) command. The first parameter, ENTTYP, selects the specific information that you want to see. Setting this value to 'ZC' will produce a listing of all of the times that the tracked object was changed. If any applications are deleting the object, using the report for value 'DO' will report those happenings. Using the value of 'ZR' will produce a larger listing showing all of the times that the tracked object was read. Depending on how your object is used, you might find that the ZR report is just too huge without filtering it down .... read on.

The generated reports are simple Query listings. The reports are generated from a file that the DSPAUDJRNE command creates in your QTEMP library. The database file is named QASYxxJ4 where "xx" is the value you used on the ENTTYP parameter. Once this database file has been created, you can use it to generate your own reports. This way, you can slice and dice the data for your own unique needs. For example, if you are looking for specific user profiles, you can add that as a selection criteria. Or, if you want to analyze access by time-of-day or day-of-the-week, you can do that too. The possibilities are quite open at this point.

I set this up on my test system to track accesses to an obscure data area that I was quite sure is only rarely used. I set the tracking and left it for a few hours, then went back to it. Even on this test system, I was surprised by the number of times the data area was used, and I'm the only user on the system! Who knows what surprises you will turn up.

If you have any questions about anything in this tip, just ask me and I'll give you my best shot. My email address is rich at kisco.com. All email will be answered.