Most shops have at least one, and probably more than one, mission critical information assets stored on their iSeries-AS/400 system. If you're doing your job as a security officer, those assets are locked up tight to make sure that only authorized user profiles can get to them. 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. You can use object auditing, a built-in feature of OS/400.
For starters, you need 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 e-mail (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 your 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 tracking usage only 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.
The generated reports are simple Query/400 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 this tip, send me an e-mail and I'll do my best to answer. All e-mail messages will be responded to.
Rich Loeber is president of Kisco Information Systems Inc., in Saranac Lake, NY. The company is a provider of various security products for the iSeries market.
================================== MORE INFORMATION ON THIS TOPIC ==================================
Learning guide: Simple steps to a secure iSeries
If you're a systems manager, chances are security is your top priority. With new security issues emerging on a daily basis, it can seem like you're swimming against the tide when trying to secure your system from both intentional and unintentional security breaches and threats. We've gathered some good security information in this security Learning Guide to help you along your way. Consider it a security life preserver of sorts.
Time to review your *PUBLIC authority setups
OS/400's robust security architecture lets you specify security authorization at a variety of levels -- from the individual profile level to the group profile level and even supplemental group profile level. If, however, your system has default setups for *PUBLIC authority that are too broad in nature, all the little details at the other levels could easily be frustrated. It is important to understand how your *PUBLIC authorities are set and to review them periodically.
The importance of testing user profiles
If you're reading this, you're probably either a security officer or working in the security group in your iSeries shop. I'll bet, however, that you didn't start your career in the security area but worked your way into your current position, starting as a programmer or a database administrator or some other related field. In your earlier positions, I'm sure you learned a lot of principals about testing. Don't let this fall by the wayside in your current position. Security testing is just as important as application testing. In this tip we'll take a look at testing your user profiles.
Top ten security tips
There's no such thing as being too secure. Even if you run an iSeries, there are still a few things you must do to protect your system and your data. These tips can help you out.
This was first published in November 2004