Planning auditing
Decide what data you need to audit, and how you will capture and process audit information. Consider how to check that your system is correctly configured.
There are several aspects to activity monitoring. The aspects you must consider are often defined by auditor requirements, and these requirements are often driven by regulatory standards such as HIPAA (Health Insurance Portability and Accountability Act) or SOX (Sarbanes-Oxley). IBM® MQ provides features intended to help with compliance to such standards.
Consider whether you are interested only in exceptions or whether you are interested in all system behavior.
Some aspects of auditing can also be considered as operational monitoring; one distinction for auditing is that you are often looking at historic data, not just looking at real-time alerts. Monitoring is covered in the section Monitoring and performance.
What data to audit
Consider what types of data or activity you need to audit, as described in the following sections:- Changes made to IBM MQ using the IBM MQ interfaces
- Configure IBM MQ to issue instrumentation events, specifically command events and configuration events.
- Changes made to IBM MQ outside its control
- Some changes can affect how IBM MQ behaves, but cannot be directly monitored by IBM MQ. Examples of such changes include changes to the configuration files mqs.ini, qm.ini, and mqclient.ini, the creation and deletion of queue managers, installation of binary files such as user exit programs, and changes to file permissions. To monitor these activities, you must use tools running at the level of the operating system. Different tools are available and appropriate for different operating systems. You might also have logs created by associated tools such as sudo.
- Operational control of IBM MQ
- You might have to use operating system tools to audit activities such as the starting and stopping of queue managers. In some cases, IBM MQ can be configured to issue instrumentation events.
- Application activity within IBM MQ
- To audit the actions of applications, for example opening of queues and putting and getting of messages, configure IBM MQ to issue appropriate events.
- Intruder alerts
- To audit attempted breaches of security, configure your system to issue authorization events. Channel events might also be useful to show activity, particularly if a channel ends unexpectedly.
Planning the capture, display, and archiving of audit data
Many of the elements you need are reported as IBM MQ event messages. You must choose tools that can read and format these messages. If you are interested in long-term storage and analysis you must move them to an auxiliary storage mechanism such as a database. If you do not process these messages, they remain on the event queue, possibly filling the queue. You might decide to implement a tool that automatically takes action based on some events; for example, to issue an alert when a security failure happens.
Verifying that your system is correctly configured
A set of tests are supplied with the MQ Explorer. Use these to check your object definitions for problems.
Also, check periodically that the system configuration is as you expect. Although command and configuration events can report when something is changed, it is also useful to dump the configuration and compare it to a known good copy.