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.
Using an Audit Log File
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
Table 10-5 Characteristics of the Audit Log File
A binary file requires
the least amount of disk space.
A clusterwide file, when
processed by the Audit Analysis utility, results in one report of
security-relevant events in the cluster.
A sequential record
format is easily analyzed by user-written programs. See the HP OpenVMS System Management Utilities Reference Manual for a description of the message format of the security audit log
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.
The usefulness of the security audit log file
depends upon the procedures you adopt:
Maintain the log file
so events are recognized early and the file does not get too big (see “Maintaining the File”).
The security audit log file continues to grow
until action is taken, so you must devise a plan for maintaining it.
Typically, sites rename each day's log file
and create a new one. To open a new, clusterwide version of the security
audit log file, use the following command:
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).
Once you have opened the new log, rename the old
version with a name that incorporates a beginning or ending date for
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
Moving the File from the System Disk
To relocate the file from the SYS$COMMON:[SYSMGR] directory,
edit the command procedure SYSECURITY.COM. This procedure executes
each time the system is rebooted, before the audit server is started.
To relocate the file, perform the following steps:
Change the startup sequence
by adding a line to SYSECURITY.COM that directs the operating system
to mount the designated auditing disk before the
audit server process is started rather than after. For example:
$ IF .NOT. F$GETDVI("$1$DUA2","MNT") -
_$ THEN MOUNT/SYSTEM $1$DUA2 AUDIT AUDIT$ /NOREBUILD
The command in this example mounts a volume labeled
AUDIT on $1$DUA2 and makes it available systemwide. MOUNT also assigns
the logical name AUDIT$.
Move the audit server
database to the auditing disk, if you choose. The database remains
small and fairly stable so this step is not essential.
To move the database, add a second line to SYSECURITY.COM
to define the system logical name VMS$AUDIT_SERVER. (The line follows
the one that mounts the auditing disk.) In the command, define a system
logical name and assign it to the VMS$AUDIT_SERVER data file on the
disk with the logical name AUDIT$. For example:
This command redirects the audit server database
to the volume on $1$DUA2, which was mounted in step 1.
From the DCL level, redirect
the security audit log file to the volume mounted in SYSECURITY.COM
(see step 1). Use the SET AUDIT command to update the audit server
database with the new location of the security audit log file, and
instruct the audit server process on each node in the cluster to begin
using the file. For example:
Do not repeat this command on each system restart.
If you use a logical name in the specification
of the security audit log file, it must be defined as a /SYSTEM logical
name in SYSECURITY.COM.
Enabling a Terminal to Receive Alarms
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.
To set up a terminal to receive security class
alarms, enter the following DCL command from the designated terminal:
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.
Secondary Destinations for Event Messages
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.
Using a Remote Log File
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.
NOTE: Each node in a cluster must have its own archive
file. An archive file cannot be shared by multiple nodes in a cluster.
Use the following procedure to write security
audit messages to a remote security archive file:
Log in to the node where
the archive file is located, and create an account for the audit server.
To the account, assign a user name like AUDIT_ARCHIVE; make the account
unprivileged with only network access. Be sure the account has access
to the device and directory containing the security archive file.
Add a proxy account on
the remote node for AUDIT$SERVER. This allows the audit server process
to write data to its account on the remote node. For example, the
following commands grant the audit server process on node SMLNOD proxy
access to the AUDIT_ARCHIVE account on node BIGNOD:
You must supply a complete directory specification.
If you include any logical names, ensure the local audit server process
can translate them.
To create a new archive file, rename the current
file; the next time the system starts up, it creates a new one for
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.
Using a Listener Mailbox
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.
To enable the listener device to receive security-auditing
messages, execute the SET AUDIT/LISTENER command in the following
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.
To disable an audit listener device, enter the
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.