HP OpenVMS Systems Documentation
OpenVMS Guide to System Security
188.8.131.52 Maintaining the File
The security audit log file continues to grow until action is taken, so you must devise a plan for maintaining it.
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 the data.
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 Section 9.5.2). 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
9.4.2 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.
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 to a security administrator on a remote node 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.
Use the following procedure to write security audit messages to a remote security archive file:
To create a new archive file, rename the current file; the next time the system starts up, it creates a new one for you.
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
Section 9.5 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.
To enable the listener device to receive security-auditing messages, execute the SET AUDIT/LISTENER command in the following format:
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 following command:
On VAX systems, refer to 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.
Collecting security audit messages in the security audit log file is useless without periodically reviewing it for suspicious activity. You use the Audit Analysis utility (ANALYZE/AUDIT) to examine the data in the security audit log file.
ANALYZE/AUDIT generates a report from the log file so that you become
familiar with normal activity on your system and can easily spot
atypical activity. It summarizes events for you and plots where
activity is occurring on the cluster. The utility also helps you
analyze atypical activity because it is capable of selecting a subset
of information from an audit report and of providing fuller information
for your analysis. While the analysis of a single audit log file might
not be significant, audit records can, over time, reveal a pattern of
activity that indicates security violations.
This section describes how to analyze audit log files on your system. Although the way you use ANALYZE/AUDIT depends upon the security needs at your site, there are a number of common steps that you should follow, regardless of the extent to which you use the utility. Before you can recognize potential security problems, you need to become familiar with the normal operation of your system. Then you can develop a procedure for generating and reviewing audit reports on a periodic basis. Whenever your regular analysis of audit log files leads you to suspect a security problem, you should perform a detailed investigation of selected security events.
As a security administrator, you should be able to answer the following questions before analyzing an audit log file:
By knowing the answers to these questions, you can eliminate false alarms, which otherwise may cause you to wrongly suspect a security problem.
The most common type of report to generate is a brief, daily listing of events. You can create a command procedure that runs in a batch job every evening before midnight to generate a report of the day's security event messages. (You can use the same procedure to create a new version of the audit log [see Section 184.108.40.206].)
The following example shows the ANALYZE/AUDIT command line to generate this report:
Depending on the number of security events that you are auditing on your system, it can be impractical to review every audit record written to the audit log file. In this case, you can select a specific set of records from the log file, such as all audit records related to changes in the authorization database and break-in attempts, or all events occurring outside normal business hours.
Analyze any subprocess-related audits with the knowledge that a pipe subprocess (created by the DCL PIPE command) can generate the audits. The PIPE command can create a large number of subprocesses to execute a single PIPE command. This can mean a potential increase in auditing events that are related to subprocess activities (for example, process creation, process deletion, login, logfailure, and logout).
It is important that you review audit reports as soon as possible. The sooner you inspect the reports, the sooner you become aware of any possible breach of security on the system and can determine the extent of the problem. You can make the inspection of the previous day's audit report a regular part of your morning routine, or you can create a program that reviews the report and notifies you through the Mail utility (MAIL) when suspicious events appear.
If, during your review, you find any security events that appear suspicious or out of place, like login attempts outside normal business hours, then use the Audit Analysis utility to perform a more detailed inspection of the security audit log file. A full report can help you determine which security events logged to the audit log file warrant a more thorough investigation.
The following command generates a full report of selected security audit records:
The audit report for December 31, 2000 contains information on all
intrusion attempts and all modifications to the system user
authorization file (SYSUAF.DAT) and the rights database
The Audit Analysis utility is the tool you use to produce a meaningful report from a binary log file. This section and the sections that follow describe how to use the utility, but refer to the OpenVMS System Management Utilities Reference Manual for complete documentation of the utility's commands and qualifiers.
To invoke the Audit Analysis utility, use the following DCL command:
For the file-name parameter, substitute the name of the file
from which audit reports are to be generated. The default name of the
security audit log file is SECURITY.AUDIT$JOURNAL. You must specify the
The audit report reflects events from the set of event classes a site has enabled (see Section 9.2). You can tailor the report so only a subset of events are extracted. The selection criteria can be based on time, on event class, or on field of data within the event message. (See the documentation of the /SELECT qualifier in the OpenVMS System Management Utilities Reference Manual.) Table 9-6 summarizes the qualifiers that determine the content of the report.
ANALYZE/AUDIT produces audit reports in different formats (see Table 9-6). The utility produces a one-line summary of each record in the log file by default. Brief, one-line reports are most useful for routine analysis of a log file. The more detailed full reports provide the detail necessary for analyzing records of a suspicious nature. If you are interested in archiving portions of a log file, the binary listing lets you store a subset of an audit log file.
A summary report helps you identify potential security problems quickly. For each class of security event, a summary report can list the total number of audit messages extracted from the security audit log file being analyzed. A summary report can also display a plot of auditing activity, based on the system generating the event message, the time when it occurred, and the total number of events seen.
Example 9-4 shows a brief report of all the security audit events logged to the system security audit log file. In the ANALYZE/AUDIT command that generates the report, substitute the name of your audit log file.
Example 9-5 shows one record from a full format audit report. In the ANALYZE/AUDIT command that generates the report, substitute the name of your audit log file.
Example 9-6 shows a summary report. In the ANALYZE/AUDIT command that generates the report, substitute the name of your audit log file.