HP OpenVMS Systems Documentation

OpenVMS Guide to System Security

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

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.

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.

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.

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.

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.

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

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=*

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.

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:

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.

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.

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