Reporting Security-Relevant Events
» Table of Contents |  | | » Glossary | | | » Index | | |
| | |
| ||
| ||
Beyond a certain set of default reporting (see Table 9-1 “Event Classes Audited by Default”), 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:
Ways to generate event messages
Types of events the system can report
Sources of event 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 “Event Classes Audited by Default”, 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:
By enabling a category of events for auditing. For example, all login failures or all changes to system parameters can be reported.
By modifying a user's authorization record so the system audits all operations performed from the account.
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 /ENABLE qualifier defines the event classes you want audited. See Table 9-3 “Kinds of Security Events the System Can Report” for a list of event classes.
The /AUDIT qualifier or the /ALARM qualifier defines the destination for the event message.
The /AUDIT qualifier directs the message to the audit log file, whereas the /ALARM qualifier directs the message to an operator terminal that has been enabled to receive security event messages. Critical events should be reported as both audits and alarms; less critical events can be written to a log file for later examination. The default event classes listed in Table 9-1 “Event Classes Audited by Default” are audited as both alarms and audits.
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.
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:
|
Break-in | All intrusion attempts: batch, detached, dialup, local, network, remote. |
Logfailure | All login failures: batch, dialup, local, remote, network, subprocess, detached, server. |
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:
Enable a class
To enable auditing for all login failures, for example, you enable the logfailure class by entering the following command:
$ SET AUDIT/AUDIT/ENABLE=LOGFAILURE=ALLAs a result of this command, the audit server reports all login failures in the security audit log file.
Enable a subset of a class
With certain events, you may want to be more selective in the kinds of reporting you enable. For example, it makes more sense to enable network and remote login events rather than to enable all login events.
To enable auditing of only the network and remote logins, enter the following command:
$ SET AUDIT/AUDIT/ENABLE=LOGIN=(NETWORK,REMOTE)Enable successful, unsuccessful, or privileged events
Event messages that report on normal system use can easily be eliminated if you enable only unsuccessful event reports or reports for activity performed through a certain privilege.
When auditing access events to protected objects, in particular, you need to define your information requirements more finely than you would with event classes like logins or use of the Install utility. Files and certain other protected objects are accessed so often that full enabling of the related access event class can result in an overwhelming number of event messages---so many that they can possibly mask the unusual events that do require investigation. For this reason, it is recommended that you enable access auditing only for unusual conditions, such as unsuccessful or privileged access events.
To enable auditing of unsuccessful file access events, enter the following command:
$ SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=FILENotice that the previous command enables auditing for all failed file accesses, not just failed read or write access attempts. This is recommended because access operations can be quite involved: what appears to be a simple write operation can involve several types of access. (For example, before writing to the file, the operation requires access to the volume and read access to the directory as well as access to the file within it.)
Example 9-2 “Audit Generated by an Object Access Event” displays an event message from a file access failure. User Robinson tried to delete the file FOO.BAR, but an ACE on the file prevented it. Apparently, Robinson holds the identifier MINDCRIME, and an Identifier ACE on FOO.BAR denies access to those holding such an identifier. Furthermore, because the system owns the file, Robinson cannot gain delete access to the file through the protection code either.
Example 9-2 Audit Generated by an Object Access Event
|
|
|
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.
Table 9-2 Access Control Entries (ACEs) for Security Auditing
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:
|
|
|
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:
|
|
|
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:
|
|
|
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:
|
|
|
See “Analyzing a Log File” for a full description of the Audit Analysis utility.
With the DCL command SET AUDIT, you can enable auditing for one or more of the event classes shown in Table 9-3 “Kinds of Security Events the System Can Report”. Many of the events classes have keywords permitting you to define a subset of the event class. [3]
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,[5] HP 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. HP 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 “Assigning Privileges”.) 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 “How the System Determines If a User Can Access a Protected Object”“How the System Determines If a User Can Access a Protected Object” on page 74. 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.