Related links

Protecting and Monitoring OpenVMS Systems

Michael Grinnell - Off-site Software Support Engineer

Gina Jones - Off-site Software Support Engineer

Overview

In
the work environments of today, the risk of computer breaches from outside
corporate or private firewalls are a constant threat. However, the threat to OpenVMS system
security can also come from inside of these same firewalls - threats that can
allow unwanted access to OpenVMS systems.
Even though OpenVMS was named "Cool and Virtually Unhackable"
at the 2001 DEFcon9 convention, lax security methods and irresponsible users
can leave OpenVMS systems to become vulnerable to unauthorized access.

Fortunately,
system administrators can enhance OpenVMS security by monitoring the integrity
of critical system files, applications, and utilities without incurring costs
for 3rd party products.

This
article discusses two mechanisms that OpenVMS provides which can help administrators
monitor file and utility access and prevent unauthorized access. OpenVMS Auditing and Access Control Entries
(ACEs) are standard with OpenVMS installations.
Using these utilities, system administrators can monitor and secure
critical system files and resources, operations that are vital to maintaining a
secure OpenVMS operating system.

User Access Security Issues in OpenVMS Environments

On
computer systems there are basically two types of users: authorized and
unauthorized. Authorized persons are given certain access to perform their
jobs/tasks and with that access a certain amount of responsibility. On the other hand, unauthorized users are not
intentionally given access to system resources and in general take no
responsibility for their actions while accessing the system. Security breaches usually result from one of
four types of user actions:

User
irresponsibility refers to situations where a user purposely or
accidentally causes noticeable damage.
A user accessing or copying a file or key to sell is an example of
this type of irresponsibility.

User
probing refers to users who are authorized to access computer resources
and exploit insufficiently protected parts of the system. Although some user's intentions may not
be malicious in nature, theft of services is a crime. Users with more serious intent may seek
confidential information, attempt embezzlement, or even destroy data by
probing.

User
penetration refers to a situation where a user breaches the security
controls to gain access to a system.
Although OpenVMS is virtually "hack proof," inadequate
security procedures can allow this most serious type of breach.

Social
engineering refers to intruders gaining access by deceiving legitimate
users of the system. They may
impersonate users by gaining access to their unsecured system/terminal
passwords or by having a user perform actions that may compromise the
security of the system.

Using Auditing to Monitor Access to Critical Files

Auditing
can be described as recording security-relevant activities as they occur on the
system and the review/analysis of the auditing log containing those activities.

Both
successful and unsuccessful events can be recorded in the audit log file,
SYS$COMMON:[SYSMGR]SECURITY.AUDIT$JOURNAL.
In addition, a terminal can be designated as a security operator
terminal where those same events can be displayed. Often, unsuccessful events are more useful in
revealing possible security concerns than monitoring successful access.

The
operating system audits the following security events by default and displays
those events to the SECURITY.AUDIT$JOURNAL file or to an operator enabled
terminal:

Authorization database changes

Intrusion attempts

Login failures

Use of DCL command SET AUDIT

Events triggered by Audit or Alarm ACEs

Example of Audit Settings

The following command displays the security
events currently enabled on an OpenVMS system.

Using Access Control Entries to Limit Access to Files

UIC
(User Identification Code) protection of files is often sufficient to deter
users from accessing areas of the system they should not be accessing. However, there are times when UIC protection
is not adequate. To provide individual
customized access protection to files and objects, Access Control Entries (ACE)
may be needed.

In addition to monitoring system events, such
as login failures, administrators can use an ACE to monitor individual objects,
such as files and print queues.

When users attempt to access a protected
object, the OpenVMS operating system compares the user profile of the user
process with the security profile of the object. The sequence of those checks is as follows:

1. Evaluate the Access Control List (ACL).

If the object has an ACL (Access Control
List) the system attempts to match an ACE entry from that ACL list with the
user's rights identifiers. If a match is
found, the user is granted or denied access and further checking of the ACL
ceases.

In the following example, the user TEST holds
the identifier named LARRY, which is also present on the PROJECT.TXT file. In this example, the user TEST would be
allowed full access to the file:

Note: When
you provide an ACE, do not forget to deny access via UIC protection; otherwise,
you are defeating the purpose of the ACE.

2. Evaluate the protection code.

If the ACE does not grant access, the
operating system then evaluates the protection code. The user is granted or
denied access based on the UIC protection mask.
The protection mask consists of the following categories: SYSTEM, OWNER,
GROUP and WORLD. Within those
categories, the granted access can be RWED (READ, WRITE, EXECUTE and DELETE) or
any combination.

In the following example note the access on
the following file:

LOGIN.COM;4 [SMITH] (RWED,RWED,RE,)

The SMITH account is the owner of the file.
SYSTEM has RWED. The Owner of the file is SMITH, who also has RWED. The group has RE. The world has no
access. Each access field is separated
by a comma.

3. Checking for special privileges.

If access was not granted by an ACE or the
UIC protection mask, privileges are then evaluated. Users with elevated system privileges may
have the ability to access objects regardless of protection offered by an ACE
or the UIC protection. The bypass
privilege (BYPASS), group privilege (GRPPRV), read all privilege (READALL), or
system privilege (SYSPRV) amplifies the holder's access to objects.

Note:
Administrators must be careful when granting elevated privileges that may allow
users access to critical objects. This can compromise system integrity.

Using Auditing to Monitor Queues and Logical Name Tables

For some object classes, such as queues and
logical name tables, a user may gain access based on alternate privileges. For example, the queue object allows full
access to all queues for users with the operator privilege (OPER), and the
logical name table object allows access to the system table for users with the
system name privilege (SYSNAM).

To monitor queues and logical name tables,
you can set an alarm ACE on those objects.

Example of Removing Security Alarm and Audit from Logical Name Table Object:

$ set audit/audit/alarm/disable=access=(success,failure)-/class=logical_name_table

Summary

You
can use the OpenVMS Auditing Utility and using Access Control Entries to
monitor access to files and objects.
There are other objects and system resources that can be monitored and
restricted by using these two utilities.
Please reference the OpenVMS Guide to System Security for additional
information on using OpenVMS auditing and Access Control Lists (ACL) to help
ensure the security of your OpenVMS system.

For more information

For more information about using these security methods, refer to
the HP OpenVMS Guide to System Security.