Reporting Security-Relevant Events

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 “Event Classes Audited by Default”). 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 HP OpenVMS DCL Dictionary.

To see the event classes your site currently audits, enter the DCL command SHOW AUDIT. Example 9-3 “Auditing Events for a Site with Moderate Security Requirements” 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, HP suggests that you evaluate your needs, as described in “Assessing Your Auditing Requirements”, 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-2001 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

As “Auditing Categories of Activity” 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 “Access Control Entries (ACEs) for Security Auditing” summarizes the auditing ACEs, and the HP OpenVMS System Management Utilities Reference Manual provides a full description of them. See Table 10-1 “System Files Benefiting from ACL-Based Auditing” for a list of system files benefiting from auditing ACEs.

(ALARM=SECURITY[,OPTIONS=options],ACCESS=access-type[+access-type...])

(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 either a print queue that is handling sensitive documents or to a terminal to catch attempted password grabbers (see “Guidelines for Protecting Your Password”“Guidelines for Protecting Your Password” on page 53).

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

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 “Kinds of System Activity the Operating System Can Report”). 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 “Analyzing a Log File” for a full description of the Audit Analysis utility.

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:

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: