Document revision date: 19 July 1999

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 note 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:

1. 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.

   $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD AUDIT_ARCHIVE /ACCESS=NETWORK /DEVICE=WORK2- _UAF> /DIRECTORY=[AUDIT_ARCHIVE]

2. 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:

   UAF> ADD/PROXY SMLNOD::AUDIT$SERVER AUDIT_ARCHIVE/DEFAULT UAF> EXIT

   
   See Section 12.3.2 for further information about setting up proxy accounts.

3. Log out from the remote node. On the local node, enable archiving of the log file to the node by entering the following command:

   $ SET AUDIT/ARCHIVE=ALL/DESTINATION=BIGNOD::WORK2:- _$ [AUDIT_ARCHIVE]SMLNOD_MAY_93.AUDIT$JOURNAL

   
   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 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.

9.4.3.2 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 format:

SET AUDIT/LISTENER=device-name

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 a listener device, enter the following command:

$ SET AUDIT/NOLISTENER

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.

9.5 Analyzing a Log File

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.

9.5.1 Recommended Procedure

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.

Step 1: Know What Is Normal

As a security administrator, you should be able to answer the following questions before analyzing an audit log file:

• What are the typical hours of operation for most users of the system?
• Are there specific users who normally operate with advanced privileges?
• Which images generate system security events as part of other applications?
• Are there any regular batch or network jobs that run at specific times of the day?

By knowing the answers to these questions, you can eliminate false alarms, which otherwise may cause you to wrongly suspect a security problem.

Step 2: Periodically Analyze the Audit Report

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 9.4.1.1].)

The following example shows the ANALYZE/AUDIT command line to generate this report:

$ ANALYZE/AUDIT/SINCE=TODAY/OUTPUT=31DEC1995.AUDIT - (1) _$ SYS$MANAGER:SECURITY.AUDIT$JOURNAL $ MAIL/SUBJECT="Security Events" 31DEC1995.AUDIT SYSTEM (2)

1. The first command in this example produces an audit report named 31DEC1995.AUDIT, which contains one-line descriptions of all the security event messages generated during the current day.
2. The second command mails the file to the security administrator for examination.

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.

Step 3: Scrutinize Suspicious Activity

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:

$ ANALYZE/AUDIT/FULL/SINCE=TODAY/OUTPUT=31DEC1995.AUDIT - _$ /EVENT_TYPE=(BREAKIN,RIGHTSDB,SYSUAF) $ MAIL/SUBJECT="Security Events" 31DEC1995.AUDIT SYSTEM

The audit report for December 31, 1995 contains information on all intrusion attempts and all modifications to the system user authorization file (SYSUAF.DAT) and the rights database (RIGHTSLIST.DAT).

9.5.2 Invoking the Audit Analysis Utility

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:

ANALYZE/AUDIT file-name

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 directory: SYS$MANAGER.

9.5.3 Providing Report Specifications

With the Audit Analysis utility, you are able to extract all or some of the security event messages from a single audit log and produce reports with various levels of detail.

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.

Table 9-6 Qualifiers for the Audit Analysis Utility

Type	Qualifier	Description
Content	/BEFORE	Extracts event messages logged before the specified time.
	/SINCE	Extracts event messages logged after the specified of time.
	/EVENT_TYPE	Extracts event messages of a specific event class (see Table 9-3).
	/SELECT	Extracts event messages based on data in the messages. (For example, /SELECT=USERNAME=JSNOOP lists only security event messages generated by user JSNOOP.)
	/IGNORE	Excludes event messages from the report based on data in the messages.
Format	/BRIEF	Produces a report with one line of information about each record in the audit log file, such as the type of event, when it occurred, and the terminal from which it originated (see Example 9-4). This is the default.
	/FULL	Provides all possible data for each record in the audit log file being processed (see Example 9-5). Appendix D provides sample alarm messages for each event class.
	/SUMMARY	Lists the total number of audit messages for each event class in the log file being analyzed (see Example 9-6). It can also plot the aggregate events per hour on each node.
	/BINARY	Produces a binary file so you can extract records for further analysis using your own data reduction tools. See the OpenVMS System Management Utilities Reference Manual for a description of the audit message record format.
Destination	/OUTPUT	Specifies the report destination. By default, it goes to SYS$OUTPUT.

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-4 Brief Audit Report

$ ANALYZE/AUDIT/BRIEF SYS$MANAGER:SECURITY.AUDIT$JOURNAL

Date / Time Type Subtype Node Username ID Term ------------------------------------------------------------------------------ 1-NOV-1995 16:00:03.37 ACCESS FILE_ACCESS HERE SYSTEM 5B600AE4 1-NOV-1995 16:00:59.66 LOGIN SUBPROCESS GONE ROBINSON 3BA011D4 1-NOV-1995 16:02:37.31 LOGIN SUBPROCESS GONE MILANT 000000D5 1-NOV-1995 16:06:36.40 LOGFAIL LOCAL SUPER MBILLS 000000E5 _TTA1: . . .

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-5 One Record from a Full Audit Report

$ ANALYZE/AUDIT/FULL SYS$MANAGER:SECURITY.AUDIT$JOURNAL

Security audit (SECURITY) on FNORD, system id: 19728 Auditable event: Object access Event time: 6-AUG-1995 11:54:16.21 PID: 3D200117 Process name: Hobbit Username: PATTERSON Process owner: [ACCOUNTING,PATTERSON] Terminal name: RTA1: Object class name: LOGICAL_NAME_TABLE Object name: LNM$SYSTEM_DIRECTORY Access requested: WRITE Status: %SYSTEM-S-NORMAL, normal successful completion Privileges used: SYSPRV

Example 9-6 shows a summary report. In the ANALYZE/AUDIT command that generates the report, substitute the name of your audit log file.

Example 9-6 Summary of Events in an Audit Log File

$ ANALYZE/AUDIT/SUMMARY SYS$MANAGER:SECURITY.AUDIT$JOURNAL

Total records read: 9701 Records selected: 9701 Record buffer size: 1031 Successful logins: 542 Object creates: 1278 Successful logouts: 531 Object accesses: 3761 Login failures: 35 Object deaccesses: 2901 Breakin attempts: 2 Object deletes: 301 System UAF changes: 10 Volume (dis)mounts: 50 Rights db changes: 8 System time changes: 0 Netproxy changes: 5 Server messages: 0 Audit changes: 7 Connections: 0 Installed db changes: 50 Process control audits: 0 Sysgen changes: 9 Privilege audits: 91 NCP command lines: 120

9.5.4 Using the Audit Analysis Utility Interactively

When you send output to a terminal, you can analyze an audit log file interactively. At any time during the display of a listing, you can interrupt the report being displayed by pressing Ctrl/C. This automatically initiates a full listing and gives you the Command> prompt. In command mode, you can advance or return to earlier records in the report and study them in greater detail.

At the Command> prompt, you can enter any of the ANALYZE/AUDIT commands listed in the OpenVMS System Management Utilities Reference Manual to modify the analysis criteria, to change position within the audit report, or to toggle between full and brief displays. To return to an audit report listing, enter the CONTINUE command.

9.5.5 Examining the Report

When a routine analysis of an audit log file leads you to suspect that the security of your system has been compromised (through an actual or attempted intrusion, repeated login failures, or any other suspicious security events), you can investigate the source of the security event through a more detailed inspection of the security audit log file.

For example, assume that you see the security events shown in Example 9-7 during a routine inspection of the previous day's audit report.

Example 9-7 Identifying Suspicious Activity in the Audit Report

Date / Time Type Subtype Node Username ID Term ------------------------------------------------------------------------------ . . . 26-OCT-1995 16:06:09.17 LOGFAIL REMOTE BOSTON KOVACS 5BC002EA _RTA14: 26-OCT-1995 16:06:22.01 LOGFAIL REMOTE BOSTON KOVACS 5BC002EA _RTA14: 26-OCT-1995 16:06:34.17 LOGFAIL REMOTE BOSTON KOVACS 5BC002EA _RTA14: 26-OCT-1995 16:06:45.50 LOGFAIL REMOTE BOSTON KOVACS 5BC002EA _RTA14: 26-OCT-1995 16:07:12.39 LOGIN REMOTE BOSTON KOVACS 5BC002EA _RTA14: 26-OCT-1995 16:23:42.45 SYSUAF SYSUAF_ADD BOSTON KOVACS 5BC002EA _RTA14: . . .

The security events displayed in the report shown in Example 9-7 indicate that user Kovacs logged in to the system following four unsuccessful login attempts. Shortly after logging in, user Kovacs created a new account in the system user authorization file (SYSUAF.DAT).

At this point, you must determine whether this behavior is normal or abnormal. Is user Kovacs authorized to add new user accounts to the system? If you believe that the security of your system has been compromised, use the following command to generate a more detailed report from the security audit log file to determine if damage has been done to your system:

$ ANALYZE/AUDIT/FULL/SINCE=26-OCT-1995:16:06

The command in this example generates a full report of all security audit events written to the audit log file since user Kovacs first attempted to log in to the system. In a full format report, all the data for each record in the audit log file is displayed. Using the full report, you can determine the name of the remote user who logged in under the local KOVACS account and the node from which the login was made, as shown in Example 9-8.

Example 9-8 Scrutinizing a Suspicious Record

. . . Security alarm (SECURITY) and security audit (SECURITY) on BOSTON, system id: 19941 Auditable event: Remote interactive login failure Event time: 26-OCT-1995 16:06:09.17 PID: 5BC002EA Username: KOVACS Terminal name: _RTA14: Remote nodename: NACHWA Remote node id: 7300 Remote username: FOLLEN Status: %LOGIN-F-INVPWD, invalid password . . . Security alarm (SECURITY) and security audit (SECURITY) on BOSTON, system id: 19941 Auditable event: Remote interactive login Event time: 26-OCT-1995 16:07:12.39 PID: 5BC002EA Username: KOVACS Terminal name: _RTA14: Remote nodename: NACHWA Remote node id: 7300 Remote username: FOLLEN

The information displayed in Example 9-8 indicates that the login failures and subsequent successful login were made by user Follen from the remote node NACHWA. Your next step is to determine whether the security events were generated by user Follen or by someone who has broken into the remote node NACHWA through the FOLLEN account.

	privacy and legal statement
6346PRO_023.HTML