[OpenVMS documentation]
[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
Updated: 11 December 1998

OpenVMS Guide to System Security


Previous Contents Index

8.9.7.3 Configuring Terminal Lines for Modems

When configuring terminal lines for modems, never set the /COMMSYNC qualifier to the DCL command SET TERMINAL (or the TT$M_COMMSYNC characteristic for the TTDRIVER interface) on a line with a modem hookup that is intended for interactive use.

The qualifier disables the modem terminal characteristic that disconnects a user process from the terminal line in case of a modem phone line failure. With the /COMMSYNCH qualifier enabled, the next call on the terminal line could be attached to the previous user's process. The /COMMSYNC qualifier is intended to allow connection of asynchronous printers and other devices to terminal ports by using modem signals as flow control.


Chapter 9
Security Auditing

This chapter describes how to use and manage the OpenVMS auditing system. It explains how you can monitor security-relevant activity on your system by recording events as they occur on the system and subsequently analyzing this audit log.

9.1 Overview of the Auditing Process

Auditing is the recording of security-relevant activity as it occurs on the system and the subsequent analysis of this audit log. With auditing, you can monitor users' activity on the system and, if necessary, reconstruct events leading up to attempts to compromise the security of your system. Thus, it is not as much a method of protecting the system and its data as a method of analyzing and recording system use.

Anything that has to do with a user's access to the system or to a protected object within the system is considered a security-relevant activity. Such activities are called events. Typical events include the following:

The operating system can record both successful and unsuccessful events. Sometimes the unsuccessful can be more revealing. For example, it is less important to record that a programmer displayed a file to which he had access than that the same programmer tried to but was prevented from displaying a protected file.

The event message itself can be written to two places: an audit log file or an operator terminal that is enabled to receive security class messages. As Example 9-1 shows, a message contains the following data:

  1. Date and time of the message
  2. Type of event
  3. Date and time the event occurred
  4. The process identification (PID) of the user who caused the event

Additional information in auditing messages is specific to the type of event. See Appendix D for examples of different messages.

Example 9-1 Sample Alarm Message

%%%%%%%%%%%  OPCOM  25-JUL-1995 16:07:09.20  %%%%%%%%%%%     (1)
Message from user AUDIT$SERVER on GILMORE 
Security alarm (SECURITY) on GILMORE, system id: 20300       
Auditable event:          Process suspended ($SUSPND)        (2)
Event time:               25-JUL-1995 16:07:08.77            (3)
PID:                      30C00119                           (4)
Process name:             Hobbit 
Username:                 HUBERT                            
Process owner:            [LEGAL,HUBERT]                    
Terminal name:            RTA1: 
Image name:               $99$DUA0:[SYS0.SYSCOMMON.][SYSEXE]SET.EXE 
Status:                   %SYSTEM-S-NORMAL, normal successful completion 
Target PID:               30C00126 
Target process name:      SMISERVER 
Target username:          SYSTEM 
Target process owner:     [SYSTEM] 

9.2 Reporting Security-Relevant Events

Beyond a certain set of default reporting (see Table 9-1), the kind of security event information you receive depends on the kind of information you select from a long list of possible events. This section explains how to enable the reporting of security event information. Specifically, it discusses the following topics:

9.2.1 Ways to Generate Audit Information

Whenever you install or upgrade your system, the OpenVMS operating system automatically audits a limited number of events. These event categories, which are shown in Table 9-1, represent major changes in the security of your system. Depending on your site's requirements, you may want to enable other forms of reporting.

You can have the operating system report on security-related activity in three different ways:

9.2.1.1 Auditing Categories of Activity

Security-relevant events are divided into a number of categories called event classes. The operating system audits several event classes by default (see Table 9-1). If the security requirements at your site justify additional auditing, you enable security auditing for additional event classes by using the DCL command SET AUDIT.

To enable auditing for different event classes, use the following command format:

SET AUDIT /ENABLE=event-class[,...] {/ALARM | /AUDIT} 

The command requires two qualifiers to enable events:

The operating system begins auditing the new events on all nodes of the cluster as soon as you enable them. It continues auditing until you explicitly disable the classes with the /DISABLE qualifier. The current auditing configuration is recorded in SYS$MANAGER:VMS$AUDIT_SERVER.DAT and so it is preserved across system boots.

For more information about the SET AUDIT command, see the OpenVMS DCL Dictionary.

Table 9-1 Event Classes Audited by Default
Class Description
ACL Access to any object holding a security-auditing ACE.
Audit All uses of the SET AUDIT command. This category cannot be disabled.
Authorization All changes to the authorization database:
  • System user authorization file (SYSUAF.DAT)
  • Network proxy authorization file (NETPROXY.DAT or NET$PROXY.DAT)
  • Rights database (RIGHTSLIST.DAT)
Break-in All intrusion attempts: batch, detached, dialup, local, network, remote.
Logfailure All login failures: batch, dialup, local, remote, network, subprocess, detached.

To see which event classes your site currently audits, enter the DCL command SHOW AUDIT. Example 9-3 displays the audit settings for a site with moderate security requirements.

Example of Enabling Event Classes

Although you can enable auditing for every possible class of security activity (/ENABLE=ALL), such an approach can result in an excessive number of auditing messages and generates too much information to analyze in a meaningful way. Therefore, Compaq suggests that you evaluate your needs, as described in Section 9.3.1, and selectively audit system activity.

You can enable auditing of event classes with different levels of granularity. You can use the following methods:

Example 9-2 Audit Generated by an Object Access Event

Message from user AUDIT$SERVER on BILBO 
Security alarm (SECURITY) and security audit (SECURITY) on BILBO, system id: 19662 
Auditable event:          Object deletion 
Event information:        file deletion request (IO$_DELETE) 
Event time:               24-APR-1992 13:17:24.59 
PID:                      47400085 
Process name:             Hobbit 
Username:                 ROBINSON 
Process owner:            [ACCOUNTING,ROBINSON] 
Terminal name:            OPA0: 
Image name:               DSA2264:[SYS51.SYSCOMMON.][SYSEXE]DELETE.EXE 
Object class name:        FILE 
Object owner:             [SYSTEM] 
Object protection:        SYSTEM:RWED, OWNER:RWED, GROUP:RE, WORLD:RE 
File name:                _DSA2200:[ROBINSON]FOO.BAR;1 
File ID:                  (17481,6299,1) 
Access requested:         DELETE 
Matching ACE:             (IDENTIFIER=MINDCRIME,ACCESS=NONE) 
Sequence key:             00008A41 
Status:                   %SYSTEM-F-NOPRIV, no privilege for attempted operation 

9.2.1.2 Attaching a Security-Auditing ACE

As Section 9.2.1.1 describes, auditing access to protected objects requires careful thought because this type of event occurs so frequently. Too many event messages can overwhelm you and possibly mask the unusual events that do require investigation.

A more selective method of auditing protected objects is to include an auditing ACE in an object's access control list (ACL) and enable the ACL event class. With this approach, only access to objects with security-auditing ACEs results in an event message, not all objects of a class.

You can use two different types of auditing ACEs, depending on where you want the event reported. Alarm ACEs direct event messages to the operator terminal, whereas Audit ACEs direct event messages to the audit log file. Table 9-2 summarizes the auditing ACEs, and the OpenVMS System Management Utilities Reference Manual provides a full description of them. See Table 10-1 for a list of system files benefiting from auditing ACEs.

Table 9-2 Access Control Entries (ACEs) for Security Auditing
ACE Type Description
Alarm ACE Writes an event message to the operator terminal whenever the object is accessed in the specified manner. It has the following syntax:
(ALARM=SECURITY[,OPTIONS=options],ACCESS=access-type[+access-type...])

Audit ACE Writes an event message to the security audit log file whenever the object is accessed in the specified manner. It has the following syntax:
(AUDIT=SECURITY 
[,OPTIONS=options],ACCESS=access-type[+access-type...])

You attach an ACE to sensitive objects by using the DCL command SET SECURITY/ACL or the access control list editor (ACL editor). Always include the SUCCESS or FAILURE keyword (or both) in the ACCESS statement of an auditing ACE.

It is a good idea to define auditing ACEs for critical system files that are not automatically audited, such as the automatic login file SYSALF.DAT, the operator log file OPERATOR.LOG, or the system accounting file ACCOUNTING.DAT. Do not monitor all access conditions, however, because such an approach can generate a large volume of messages, many of which are not useful. For example, tracking successful write operations to OPERATOR.LOG probably will not produce interesting information, but tracking unsuccessful attempts probably will.

You can add auditing ACEs to any protected object, although files are the most common objects to audit. You may want to add an auditing ACE to a print queue that is handing sensitive documents or add one to a terminal to catch attempted password grabbers (see Section 3.8).

Example of Adding an Auditing ACE

To establish an Alarm ACE for the file ACCOUNTING.DAT, enter the following command:


$ SET SECURITY/ACL=(ALARM=SECURITY,ACCESS=DELETE+CONTROL+SUCCESS+FAILURE)-
_$  SYS$MANAGER:ACCOUNTING.DAT

The ACL event class is enabled by default, but if it has been disabled at a site, you must enter the following command to reenable the use of auditing ACEs:


$ SET AUDIT/ALARM/AUDIT/ENABLE=ACL

9.2.1.3 Modifying a User Authorization Record

Sometimes you may see users acting in a suspicious way. Perhaps they are logging in from a number of terminals or logging in at unusual times of the day or the week. You can monitor users' actions by modifying the auditing attribute in their user authorization records. Run the AUTHORIZE utility and set the Audit flag.

Note that setting the AUDIT flag generates an extremely large number of audit messages. The following command sequence modifies the account of user Robin:


$ RUN SYS$SYSTEM:AUTHORIZE
UAF> MODIFY ROBIN/FLAGS=AUDIT
%UAF-I-MDFYMSG, user record(s) updated

With the Audit flag set, the operating system audits the user's process. The audit log file contains a report of any action the user performs that the operating system is capable of auditing (see Section 9.2.2). You can use the Audit Analysis utility to review the user's actions. For example, to get a report on the activities of user Robin, enter the following command:


$ ANALYZE/AUDIT/SELECT=(FLAGS=MANDATORY,USERNAME=ROBIN) -
_$ SECURITY.AUDIT$JOURNAL

See Section 9.5 for a full description of the Audit Analysis utility.

9.2.2 Kinds of System Activity the Operating System Can Report

With the DCL command SET AUDIT, you can enable auditing for one or more of the event classes shown in Table 9-3. Many of the events classes have keywords permitting you to define a subset of the event class.

Table 9-3 Kinds of Security Events the System Can Report
Event Class Description
Access Access requests to all objects in a class. You can audit selected types of access, both privileged and nonprivileged, to all protected objects of a particular class.
ACL Events requested by a security Audit or Alarm ACE in the ACL of an object.
Authorization Modification of any portion of SYSUAF.DAT, NETPROXY.DAT, NET$PROXY.DAT, or RIGHTSLIST.DAT.
Breakin Intrusion attempts.
Connection Logical link connections or terminations through SYSMAN, DECnet Phase IV,+ DECwindows, or an interprocess communication (IPC) call.
Create Creation of a protected object.
Deaccess Deaccess from a protected object.
Delete Deletion of a protected object.
Identifier Use of identifiers as privileges.
Install Modifications made to the known file list through the Install utility.
Logfailure Unsuccessful login attempts.
Login Successful login attempts.
Logout Logouts.
Mount Volume mounts and dismounts.
NCP Modification to the network configuration database, using the network control program (NCP).
Privilege Successful or unsuccessful use of privilege.
Process Use of one or more of the process control system services.
SYSGEN Modification of a system parameter with the System Generation utility (SYSGEN) or AUTOGEN.
Time Modification of system time.


+VAX specific

9.2.2.1 Suppression of Certain Privilege Audits

Although a site may enable the privilege event class, the operating system does not report every event in this class. It suppresses the following types of audits:


Previous Next Contents Index

[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
[OpenVMS documentation]

Copyright © Compaq Computer Corporation 1998. All rights reserved.

Legal
6346PRO_021.HTML