Document revision date: 30 March 2001

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, 1 Compaq DECwindows Motif for OpenVMS, 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.

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:

• Successful use of privileges with which an image is installed For example, the image SHOW.EXE is installed with WORLD privilege. When unprivileged users enter the SHOW SYSTEM command, SHOW.EXE uses WORLD privilege to perform wildcard $GETJPI system service calls. This use of WORLD privilege is not audited. However, if the same unprivileged users attempt to use the SHOW PROCESS command to display process attributes for a process that they do not have access to, the operation fails. This lack of WORLD privilege is audited even though SHOW.EXE is installed with WORLD privilege.
• Successful use of a lesser privilege than installed with the image When an image is installed with a greater privilege than used, the lesser privilege is not audited if the request is successful. For example, if an image installed with CMKRNL privilege successfully executes a $CMEXEC system service call, the use of the CMEXEC privilege is not audited. The following relationships exist:

  Greater Privilege	Privilege It Implies
  PRMMBX	TMPMBX
  CMKRNL	CMEXEC
  SYSNAM	GRPNAM
  WORLD	GROUP
  SYSPRV	GRPPRV
  BYPASS	SYSPRV, GRPPRV, READALL, DOWNGRADE, UPGRADE

• Any use of SETPRV privilege by an image installed with SETPRV Although the operating system does not audit use of SETPRV, it does audit the use of any privilege enabled with SETPRV. Compaq recommends that you install an image with the privileges that it actually needs and avoid installing images with SETPRV.
• With protected subsystems, successful access by using a subsystem identifier

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

• Server processes created with the DCL command RUN/TRUSTED or the Create Process system service ($CREPRC) with the PRC$M_TCB flag set Server applications that do need to audit information regarding their clients can set the auditing flags NSA$M_SERVER or CHP$M_SERVER, which override the process no-audit setting for the duration of the auditing call.
• Process control events inside your process's job tree that have the same UIC as the requestor You do not see any process control audits when granting or revoking identifiers to or from your own process. However, events related to the use of $CREPRC and $DELPRC are always audited.

Applications and system programs can contribute security event information by calling the following system services:

• $AUDIT_EVENT
• $CHECK_PRIVILEGE
• $CHKPRO and $CHECK_ACCESS

Audit Event ($AUDIT_EVENT) System Service

The operating system calls the $AUDIT_EVENT system service every time a security-relevant event occurs on the system. By looking at the SET AUDIT settings, the system service determines whether you enabled auditing for the event. When the event is enabled for alarms or audits, $AUDIT_EVENT generates an audit record that identifies the process (subject) involved and lists event information supplied by its caller.

Check Privilege ($CHECK_PRIVILEGE) System Service

The operating system calls the $CHECK_PRIVILEGE system service any time a user attempts to perform a privileged function. (The current set of OpenVMS privileges is listed in Appendix A.) The system service performs the privilege check and looks at the SET AUDIT settings to determine whether you enabled privilege auditing. When privilege auditing is enabled, $CHECK_PRIVILEGE generates an audit record. The audit record identifies the process (subject) and privilege involved, provides the result of the privilege check, and lists supplemental event information supplied by its caller. Privilege audit records usually contain the DCL command line or system service name associated with the privilege check.

Check Protection ($CHKPRO) and Check Access ($CHECK_ACCESS) System Services

The operating system calls the $CHKPRO system service any time a process (subject) attempts to access a protected object. The system service performs the access arbitration according to the rules described in Section 4.3. By looking at the SET AUDIT settings for the associated object class, the service also determines whether you enabled auditing for the associated object access event. When an alarm or an audit is required, $CHKPRO generates an audit record that identifies the process (subject) and object involved and includes the final outcome and any supplemental event information supplied by its caller.

Privileged server processes use the $CHECK_ACCESS system service to determine whether their clients should be allowed access to the protected objects being served. The $CHECK_ACCESS system service provides a calling interface appropriate for servers and is layered on top of the $CHKPRO service. As a result, it performs object access auditing in the same manner as $CHKPRO.

9.3 Developing an Auditing Plan

As system manager or site security administrator, you have to determine the level of security required at your site before you can understand which security events to audit.

9.3.1 Assessing Your Auditing Requirements

Assessing your auditing requirements is a two-step process:

1. Determine your site's general security requirements: are they high, moderate, or low? Table 1-1 provides some guidance on determining your security needs.
2. Once you know your site's needs, refer to Table 9-4 for a suggested list of event classes to enable.

After developing a general notion of your site requirements, you need to consider how much security reporting is realistic. Balance the suggestions in Table 9-4 with the following site factors:

• The sensitivity of the data at your site
• The amount of time you have to analyze log files
• The disk space you have available
• Your knowledge of a security threat: where is it coming from or likely to come from
• The tuning requirements of your system (See Section 9.3.3 for information about performance impact.)

Table 9-4 Events to Monitor Depending on a Site's Security Requirements

	Low	Medium	High
Goal	Monitor local events with high impact	Track changes to system definition	Monitor database changes; track use of process control system services Monitor network connections through DECnet Phase IV (VAX only)
Classes to Enable as Alarms	ACL, authorization, break-in (all types), logfailure (all types)	Same as low category plus use of SECURITY privilege	Same as medium category plus INSTALL, time, SYSGEN, unsuccessful privilege use
Classes to Enable as Audits	ACL, authorization, breakin (all types), logfailure (all types)	All of low category plus INSTALL; time; SYSGEN; privilege; logins (all types); logouts (all types); access of files through BYPASS, SYSPRV, and READALL privileges; unsuccessful access to files, devices, and volumes	All of medium category plus identifier, process, unsuccessful access to protected objects, NCP, connection (VAX only)

In Table 9-4, the event classes suggested for a low-security site are the default settings for the operating system. If these classes are not the current defaults on your system, you can enable them with the following command:

$ SET AUDIT/ALARM/AUDIT/ENABLE=(ACL,AUTHORIZATION,BREAKIN:ALL,LOGFAILURE:ALL)

In a site with moderate security requirements, you want to audit events that can redefine your system. You watch for changes to system files, system time, or system parameters. You also monitor image installations and the use of privilege. Example 9-3 shows the auditing setting for a site with moderate security requirements.

Example 9-3 Auditing Events for a Site with Moderate Security Requirements

System security alarms currently enabled for: Authorization Breakin: dialup,local,remote,network,detached System security audits currently enabled for: ACL Authorization INSTALL Time SYSGEN Breakin: dialup,local,remote,network,detached Login: batch,dialup,local,remote,network,subprocess,detached,server Logfailure: batch,dialup,local,remote,network,subprocess,detached,server Logout: batch,dialup,local,remote,network,subprocess,detached,server Privilege use: ACNT ALLSPOOL ALTPRI AUDIT BUG BYPASS CMEXEC CMKRNL DIAGNOSE DOWNGRADE EXQUOTA GROUP GRPNAM GRPPRV IMPORT IMPERSONATE LOG_IO MOUNT NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL PRMMBX PSWAPM READALL SECURITY SETPRV SHARE SHMEM SYSGBL SYSLCK SYSNAM SYSPRV TMPMBX UPGRADE VOLPRO WORLD Privilege failure: ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS CMEXEC CMKRNL DIAGNOSE DOWNGRADE EXQUOTA GROUP GRPNAM GRPPRV IMPORT IMPERSONATE LOG_IO MOUNT NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL PRMMBX PSWAPM READALL SECURITY SETPRV SHARE SHMEM SYSGBL SYSLCK SYSNAM SYSPRV TMPMBX UPGRADE VOLPRO WORLD FILE access: SYSPRV: read,write,execute,delete,control BYPASS: read,write,execute,delete,control READALL: read,write,execute,delete,control

To enable the settings for a moderate level of auditing, assuming the default events are already in effect, enter the following set of commands:

$ SET AUDIT/ALARM/AUDIT/ENABLE=PRIVILEGE=(SUCCESS:SECURITY,FAILURE:SECURITY) $ SET AUDIT/AUDIT/ENABLE=(INSTALL,SYSGEN,TIME,PRIVILEGE=(SUCCESS,FAILURE)) $ SET AUDIT/AUDIT/ENABLE=ACCESS=(BYPASS,SYSPRV,READALL)/CLASS=FILE $ SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=(FILE,DEVICE,VOLUME)

A site with high security requirements expands its auditing breadth to include network activity. It needs to monitor changes to the network database, network connections (VAX only), the use of identifiers as privileges, and privileged file access. Monitor all file access through SYSPRV, BYPASS, or READALL privilege, and watch both successful and unsuccessful file access through GRPPRV privilege. To enable the settings for a high level of auditing, assuming a medium level is in effect, enter the following set of commands:

$ SET AUDIT/ALARM/ENABLE=(INSTALL,SYSGEN,TIME,PRIVILEGE=(FAILURE:ALL)) $ SET AUDIT/AUDIT/ENABLE=(CONNECTION,IDENTIFIER,NCP,PROCESS:ALL) $ SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=*

To enable all auditing:

$ SET AUDIT/AUDIT/ENABLE=ALL/CLASS=*

To disable all auditing:

$ SET AUDIT/AUDIT/DISABLE=ALL/CLASS=*

See Section 10.3.2 for more suggestions of event classes to enable.

9.3.2 Selecting a Destination for the Event Message

The operating system can report a security event as either an alarm or an audit (see Section 9.2.1.1). Which form you select depends on the nature of the event. Real-time events or events that should be treated immediately, such as break-in attempts or changes to the system user authorization file (SYSUAF.DAT), are classes to enable as both alarms and audits. Less critical events can be enabled just as audits. Unless you have a hardcopy operator terminal, the alarm record is quickly superseded by other system messages. Audit event records, which are written to the system security audit log, are saved so you can study them in volume.

There is an advantage to studying event messages. Many times an isolated auditing message offers little insight, but numerous audit records reveal a pattern of activity that might indicate security violations. With auditing of object access, for example, a security administrator can see a pattern of time, types of objects being accessed, and other system information that, in total, paint a complete picture of system activity. Section 9.5 describes how to produce reports from audit log files.

9.3.3 Considering the Performance Impact

The default auditing performed by the operating system primarily tracks changes to the authorization databases. System events like changes to the system user authorization file (SYSUAF.DAT) or the installation of images do not occur too often and therefore are not a drain on system resources.

Auditing additional event classes, particularly access events and privilege events, can consume significant system resources if a site enables the event classes without understanding how their system is used and without evaluating the value of the audit information. In this respect, implementation of the audit reporting system is similar to system tuning: it takes a little while to reach the appropriate level of reporting that is free of spurious details. For this reason, Compaq recommends you turn auditing on in phases, not all at once, and gradually add or subtract event classes until you reach a satisfactory balance. Use the following guidelines:

• Evaluate your auditing requirements, as described in Section 9.3.1.
• Be selective in auditing object access events. Object access events occur all the time and therefore have the greatest impact on system performance. Audit file-access failures in most cases rather than successful file access, or put auditing ACEs on key files rather than enable auditing for the entire file class.
• Examine the layered products you are running so you understand which privileges they may use. Also become familiar with site-specific procedures, such as the use of the READALL privilege during a backup operation. Because privilege events occur frequently, they have a great impact on system performance.
• Enable a few event classes at a time and then add or subtract, if necessary, until you have sufficient event information. The more classes you enable, the more overhead you have and the fewer resources you have for useful work on the system.

Two commands in particular generate a large number of audit messages:

• The DCL 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).
• The UAF command MODIFY USER/FLAG=AUDIT generates a very large number of audit messages. It is not usually necessary to set this flag; if you have a particular AUDIT enabled, you do not need to have the user flag set as well.

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.

9.4.1 Using an Audit Log File

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. Table 9-5 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 Section 9.4.1.1), but this is not the recommended procedure.

Table 9-5 Characteristics of the Audit Log File

Characteristic	Advantage
Binary	A binary file requires the least amount of disk space.
Clusterwide	A clusterwide file, when processed by the Audit Analysis utility, results in one report of security-relevant events in the cluster.
Sequential record format	A sequential record format is easily analyzed by user-written programs. See the OpenVMS System Management Utilities Reference Manual for a description of the message format of the security audit log file.

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 Section 9.4.1.1).
• Routinely review the log file and scrutinize suspicious activity (see Section 9.5).

	privacy and legal statement
6346PRO_022.HTML