Plan auditing

Decide what data we need to audit, and how we will capture and process audit information. Consider how to check that the system is correctly configured.

There are several aspects to activity monitoring. The aspects we 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 we are interested only in exceptions or whether we are interested in all system behavior.

Some aspects of auditing can also be considered as operational monitoring; one distinction for auditing is that we are often looking at historic data, not just looking at real-time alerts. Monitoring is covered in the section Monitor and performance.

What data to audit

Consider what types of data or activity we 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, we must use tools running at the level of the operating system. Different tools are available and appropriate for different operating systems. We might also have logs created by associated tools such as sudo.

Operational control of IBM MQ

We 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 the system to issue authorization events. Channel events might also be useful to show activity, particularly if a channel ends unexpectedly.

Plan the capture, display, and archiving of audit data

Many of the elements we need are reported as IBM MQ event messages. We must choose tools that can read and format these messages. If we are interested in long-term storage and analysis we must move them to an auxiliary storage mechanism such as a database. If we do not process these messages, they remain on the event queue, possibly filling the queue. We 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.

Verify that the system is correctly configured

A set of tests are supplied with the IBM 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.

Parent topic: Plan for the security requirements