By Rich Loeber
Your system is in use by your user community all day long. Depending on the size of your shop and the number of users, there could be hundreds or even thousands of security decisions being made by your security setup on a minute by minute, hour by hour, day by day basis. If you've done your homework well, those security arrangements will all work to protect your data from being used incorrectly.
But, how do you know when a security violation has been made?
One way is to keep security auditing active on your system and run regular reports from the security audit journal. In fact, that is a good practice to implement, but it is not going to give you quick feedback when a serious security violation occurs.
When a critical security violation happens, an error notice is posted to the system operator message queue (QSYSOPR). The problem, however, is that LOADS of messages in most shops go to the system operator message queue and it is easy to loose one in the haze of all that activity.
To address this problem of the security messages getting lost in the system operation message queue, the IBM i OS has an alternate message queue capability set up. Check your system to see of the QSYSMSG message queue exists in QSYS library. If you don't see one, just create using the CRTMSGQ command.
Once the QSYSMSG message queue is on your system, all critical security related messages will also be posted to this message queue along with your system operator queue. Now, all you need to do is make sure that you end up knowing when a message has been posted.
The quick and easy way is to log on to the system and run the following command:
CHGMSGQ MSGQ(QSYS/QSYSMSG) DLVRY(*BREAK)
Once this is done, whenever a message is posted to the QSYSMSG message queue, it will be displayed on your terminal session as a break message.
But, this could be a problem. First, it requires that you always be logged on and it limits the number of people who can monitor for security events to one. A different solution is to create a little CL program to "watch" the message queue for you and then forward the message on to your user profile (or a series of user profiles) when they happen.
This way, you and your security team can find out about security problems in real time and won't have to wait for audit journal analysis to see that serious security violations are happening.
I have put together a simple little message monitor CL program that works with a set of up to 5 user profiles stored in a simple data area. If you're interested in getting a copy of this code, or if you have any questions about this tip, send me an email (rich at kisco.com).
An even better solution is to implement a flexible message queue monitoring software tool such as Kisco Information Systems' iEventMonitor software. This will add email and text notification for you and you can implement many of the other features to monitor your system.
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.