HP OpenVMS Guide to System Security: OpenVMS Version 8.4 > Chapter 10 Security Auditing
The operating system can send event messages to an audit log file or to an operator terminal. If a site wants additional copies, it can send duplicate messages to a remote log file or an application listener mailbox.
The operating system writes all security event messages to the latest version of the security audit log file. This log file is created by default during system startup in the SYS$COMMON:[SYSMGR] directory and named SECURITY.AUDIT$JOURNAL. “Characteristics of the Audit Log File” describes some of its more notable characteristics.
Ordinarily, all cluster events are written to a single audit log file. The use of one security audit log file in a cluster results in a single record of all security-relevant events on the system. For this reason, one clusterwide log file is preferable to node-specific audit logs, which lose the interrelationship of events across the cluster, thus producing an incomplete analysis of security events. You can, if you wish, create node-specific audit logs (see “Maintaining the File”), but this is not the recommended procedure.
To create a new, node-specific log, precede the SET AUDIT/SERVER=NEW_LOG command with the command SET AUDIT/DESTINATION=filespec where the file specification includes a logical name that resolves to a node-specific file (for example, SYS$SPECIFIC:[SYSMGR]SECURITY).
To save space on the system disk, you may want to copy the file to another disk and delete the log from the system disk. Even sites with a dedicated auditing disk, which is common to environments with high security requirements, may want to relocate the old version to make space for future messages.
Once you archive the file, run the Audit Analysis utility on the old log (see “Invoking the Audit Analysis Utility”). By archiving this file, you maintain a clusterwide history of auditing messages. If you ever discover a security threat on the system, you can analyze the archived log files for a trail of suspicious user activity during a specified period of time.
The operating system sends alarm messages to terminals enabled for security class messages. In most cases, these security alarms appear on the system console by default. Because messages scroll quickly off the screen, it is a good practice to enable a separate terminal for security class messages and disable message delivery to the system console. Choose either a terminal in a secure location that provides hardcopy output or have dedicated staff monitor the security operator terminal. Any number of terminals can be enabled as security operators.
For long-term use of a specific terminal, you can modify your site-specific startup command procedure to automatically enable the terminal. For example, the following command lines in a startup command procedure disable the delivery of security alarms to the system console and enable alarms on terminal TTA3:
The authorization and SYSGEN event classes occasionally produce such lengthy alarm messages that the messages get truncated. For this reason, it is best to enable these classes for both alarms and audits. When an alarm message is truncated, the text indicates it is incomplete. As long as you have enabled the classes for audit messages, you can use ANALYZE/AUDIT to display the complete message.
The operator terminal and the audit log file are the primary destinations for security event messages. A site can choose to send copies of audit messages to a remote log file (called an archive file) or a listener mailbox.
The operating system allows workstations and other users with limited management resources to duplicate their audit log file on another node. This secondary log, the security archive file, is then available on a remote node to a security administrator who has the skills to analyze the file. In some situations, the archive file can also provide insurance should the local audit log file be tampered with in some way. One node can direct auditing messages to an archive file. Once enabled, the audit server writes a copy of each auditing message to the security archive file as well as to the security audit log file.
If the network goes down, messages intended for the security archive file are lost. Security operator terminals receive notice of the lost connection and the number of lost messages. Once the network is up, the audit server reestablishes connection to the original archive file and continues writing event messages.
Analyzing the security archive file is identical, in most respects, to analysis of the security audit log file. You can analyze a remote security archive file at any time, even while the file is open. See “Analyzing a Log File” for more information.
As an additional feature of the security auditing facility, you can create a listener device to receive a binary copy of all security-auditing messages. (A listener device is a permanent or temporary mailbox that you create with the Create Mailbox [$CREMBX] system service.) You can set up an application to receive and process auditing information and react to events as they occur on the system. Each system can have one listener device, and it can receive only events that are occurring on the local node.
For the device-name parameter, supply either the logical name specified when you created the mailbox or the equivalence name of the mailbox, in the form of MBAn, where n represents the unit number of the mailbox. If you create the device as a temporary mailbox, you must use the Get Device and Volume Information ($GETDVI) system service to return the mailbox device name.
On VAX systems, see the files AUDSRV_LISTENER.B32 (a VAX BLISS program) and AUDSRV_LISTENER.MAR (a VAX MACRO program) in the SYS$EXAMPLES directory for examples of a program that processes audit-event messages sent to a listener mailbox on a DECtalk device.