As a security officer, you work hard to develop and maintain policies. You slave to get things set up just right and then put practices in place that will make sure new applications are implemented with security that adheres to your established policies. However, sometimes you have to take the time to go back over old ground to make sure that what you set up is still working and in place.
The System Security Attributes report can be created on your system by running the Print System Security Attr (PRTSYSSECA) command. This will generate a small report that will collect security-related information from the system values and network attributes on your system. The report shows what your current settings are and how they compare to IBM's recommended settings.
With this report in hand, you should review all of the system values and network attributes to make sure that they are still set to the value that you expect based on your security policy. Then, for good measure, see how your settings compare to those that are recommended by IBM. For those settings where your implementation is stricter than IBM's recommendation, good for you. For those settings where your implementation is less strict, it would be good for you to review the reasons why you made that decision and document it. One day, a good security audit is going to see this difference and want an explanation.
The Print Private Authorities (PRTPVTAUT) command.prints a series of reports, depending on the object type you want to check. The reports generated can be used to quickly scan to make sure that the proper private authorities are in place. I find that a scan of the report will quickly reveal object authorities that are incongruous within a library. I recently ran this on our in-house system on a library where I am particularly concerned about security and I found several objects that had been changed by an *ALLOBJ user (namely me) in a way that was inconsistent with our security policy. After familiarizing myself with the report, I found that I could scan for specific values to locate anomalies that needed attention.
Using these two tools and others, you can do a complete review of your security implementation to make sure that what you initially set up is what is now in place. When you find situations where changes have been made, take the time to track down how things got changed and then take steps to make sure that it does not happen again. More often than not, I suspect that you will find that the *ALLOBJ authority user profiles on your system are to blame.
If you have any questions about anything included in this tip, you can reach me at firstname.lastname@example.org, All email messages will be answered as quickly as possible.
ABOUT THE AUTHOR: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.