By Rich Loeber
In an era of steadily increasing computer security interest, it is inevitable that your shop will be audited by someone looking specifically at computer security arrangements. There are lots of aspects of a security audit, but one control all auditors seem to have in common is seeing proof that your IBM i program base is not tampered with. This tip will give you a simple method for providing this proof, plus it gives you a good opportunity to quickly review all changes to program objects by just scanning a few simple reports.
For your tracking to work, you will first have to set up a baseline of information about the programs on your system. I suggest that you dedicate a separate library on your system for this purpose and then make sure that access to the library is restricted to your security officers only. For purposes of this tip, I set up a library called KISPGMTRK and I’m going to track changes to *PGM objects only. In your implementation, you can expand the implementation to other program objects as you have need. To set up the baseline information about all programs on your system, just run the following command:
DSPOBJD OBJ(*ALLUSR/*ALL) OBJTYPE(*PGM) OUTPUT(*OUTFILE)
This will create a database file in your library named PGMMST which will become your baseline file. The file will contain information about all *PGM objects on your system from all user libraries. To expand your baseline to include all programs in the OS, just change the OBJ parameter to specify *ALL libraries, not just *ALLUSR libraries.
Once you have this baseline established, wait for some program change activity on your system. Then, repeat the above command only specify a different OUTFILE file. For my example, I have used a file name of CURMST. This will capture a second picture of all *PGM objects on your system taken at the second point in time.
Now, all that’s left is to compare the two files and produce your control listings. For my example, I used the IBM i Query tool (WRKQRY). This tool will let you run a query joining two files together dynamically. I joined them on library name and object name. If you are tracking more than just *PGM objects, then you will also have to join on object type.
For my tracking, I generate three different reports. A list of new programs added to the system, a list of programs deleted from the system and a list of programs that have changed. To get the new programs added, set up the current file first and the baseline file second, then specify a key join for unmatched records with the primary file. For deleted programs, set up the baseline file first and the current file second using the same unmatched records with primary file join (the opposite of your first report). Then for changed programs, process the two files using the matched records join option. To get just the changed programs, select records where the object size, create date or create time have changed.
When your reports have been created, you will then just need to replace your baseline database file with the most recent current file. In my example, I just do a copy/replace from the CURMST to the PGMMST file. Now you’re all set up for the next report cycle.
Once you have this set up and working, you could even work with it to keep a history database on file for all of the adds, deletes and changes over time. At a minimum, when your auditor shows up, you’ll have a nicely bound volume of reports showing all changes. And, you can review the program change activity for yourself to make sure there are no surprises along the way. After all, isn’t that the point of security checking?
If you’re interested, I’ll send you a save file of the library on my system where I developed my version of this process along with a simple CL program and CMD object to run it. If you have any questions about anything included in this tip, or you would like the sample, you can reach me at rich at kisco.com, All email messages will be answered as quickly as possible.