Why Security?

Advances over the past few years in easy-to-use, high-level-inquiry languages, the use of small computers, and general familiarity with data processing have created a higher level of "computer literacy." Without a corresponding growth in awareness of good data-security practices, these advances could result in a higher likelihood of inadvertent (or deliberate) data exposure. (In this context, data exposure means unauthorized access, modification, or destruction of data.) In parallel, there are two additional trends: the continuing need for information to be on some sort of database that is easily accessible by authorized users, and the increase in critical assets stored on databases.

As these and other trends continue, and as the number of users and the ease-of-use of data systems increase, the need for data security takes on a new level of importance. An installation can no longer have minimal security simply because few people know how to access the data. Installations must actively pursue and demonstrate security and use a security mechanism to control any form of access to critical data.

Security Requirements

A security mechanism should:

• Identify users who wish to access the secured system. Ensure that a unique identifier can be associated with each potential user of the system when the user enters the system.
  
• Verify that the users are who they say they are. When a user enters the system, ensure that a further level of identification, such as a password, verifies that the user has the correct identifier.
  
• Allow only authorized users to access the protected resources. Provide users with an appropriate level of access authority for each protected resource.
  
• Allow a convenient way to administer security. Provide the ability to allow the installation to select the kind of security structure and administration that is needed.
  
• Record accesses to protected resources. Provide another level of accountability so the installation can see who is using what resources. Allow the installation to define the records it requires.
  
• Document violations, either immediately or as a user-requested periodic report.
  
• Be usable by those whose data is being protected. A security mechanism has to be easy to define and easy to use in order to help prevent circumventing the mechanism.
  

• List the key protected resources and indicate the level of protection that exists for each.

How RACF Meets Security Needs

RACF helps meet the needs for security by providing the ability to:

• Identify and verify users
  
• Authorize users to access the protected resources
  
• Control the means of access to resources
  
• Log and report various attempts of unauthorized access to protected resources
  
• Administer security to meet an installation's security goals

RACF provides these functions; the installation defines the users and the resources to be protected.

A specific RACF user, called the security administrator, has the responsibility to define users and resources to RACF. (Alternatively, the security administrator can assign other people to do some of this defining.) As well as defining what resources to protect (DASD data sets, minidisks, tape data sets, DASD volumes, tape volumes, terminals, and so on), the security administrator can define and grant the authorities by which users access the protected resources. Thus, the security administrator sets down the guidelines that RACF uses to decide the user-resource interaction within the installation.

RACF retains information about the users, resources, and access authorities in profiles on the RACF database and refers to the profiles when deciding which users should be permitted access to protected system resources.

Identifying and Verifying Users

RACF uses a user ID to identify the person who is trying to gain access to the system and a password to verify the authenticity of that identity. RACF uses the concept of only one person knowing a particular user ID-password combination to verify user identities and to ensure personal accountability. RACF allows some alternatives to password identification:

• RACF allows the use of an operator identification card (OIDCARD) in place of or in addition to the password during terminal processing. By requiring that a person not only know a password but also furnish an OIDCARD, an installation has increased assurance that the user ID has been entered by the proper user.
  

• RACF also allows workstations and client machines in a client-server environment to use a PassTicket in place of a password. A PassTicket can be generated by RACF or by another authorized function, and can be used only once on a given computer system, within ten minutes of generation,

OpenEdition users are also identified with numeric user identifiers (UIDs), and Open Edition groups are identified with numeric group identifiers (GIDs). Unlike user names or group names, these numeric Ids can be shared by more than one user or group, although sharing is not recommended.

RACF can help meet an installation's security needs because it allows the installation to define users who can access protected resources and, concurrently, to relate how users can access the protected resources.

Authorizing Users to Access Resources

Having identified and verified the user, RACF then controls interaction between the user and the system resources. RACF must authorize not only which users may access resources but also in what way the user may access them, such as for reading or for updating. RACF also can authorize when a user can access resources, by either time or day.

An OpenEdition user with a UID of 0 is a superuser. Because superusers pass all OpenEdition security checks, they can access all OpenEdition resources without restriction.

Logging and Reporting

Having identified and verified the user, and limited access to resources, RACF records the events where attempted user-resource interaction has occurred. An installation can use logging and reporting to alert management not only to anticipated user activities and system events but also to variances from the expected use of the system.

Administering Security

Because the security requirements at every data processing installation differ, RACF allows an installation to meet its own unique security objectives. RACF enables an installation to administer security in a number of ways:

• Flexible control of access to protected resources
  
• Protection of installation-defined resources
  
• Ability to store information for other products
  
• Choice of centralized or decentralized control of profiles
  
• Easy-to-use ISPF panels
  
• Transparency to end users
  
• Exits for installation-written routines
  
• Data security monitor
  
• RACF report writer

Flexible Control

RACF allows the installation to set its own rules for controlling access to its resources by defining what is protected at what level and who can access protected resources. Because of RACF's flexible design, any installation can tailor RACF to interact with its present operating environment. Because the installation establishes the controls--while RACF merely enforces them--each installation can also adapt RACF implementation to changes in its security needs.

Protection of Installation-Defined Resources

In addition to the predefined resources, such as data sets, minidisks, terminals, and transactions defined to IMS/ESA and CICS/ESA*, RACF permits an installation to protect its own installation-defined resources. Installation-defined resources provide a great deal of flexibility in defining what resources an installation can protect.

In a system-managed storage environment, RACF allows a storage administrator to control the use of data, management, and storage classes.

RACF Report Writer

The RACF report writer permits the auditor or security administrator to assess the implementation of RACF and the use of the resources it protects. The RACF report writer provides a wide range of reports that enable an installation to monitor and verify the use of the system and resources.

The RACF report writer lists the contents of system management facility (SMF) records in a format that is easy to read. The RACF report writer can also generate reports based on the information in the SMF records, such as:

• Reports that describe attempts to access a particular RACF-protected resource in terms of user identity, number and type of successful accesses, and number and type of attempted security violations
  
• Reports that describe user and group activity
  
• Reports that summarize system use and resource use.

The RACF report writer is not enhanced in RACF 2.1. Its function is stabilized at the RACF 1.9.2 level. Except as detailed below, it is not able to report on any new RACF 2.1 function. For example, report writer does not report on:

• New events, such as OpenEdition MVS support
  
• New audit data, such as the sysplex data sharing mode

Certain RACF 2.1 enhancements automatically handled by the report writer are still reported. For example:

• SETROPTS options that affect new RACF 2.1 classes
  

• Access successes or failures for resources in new RACF 2.1 classes

Installations using the RACF report writer have to change to another reporting package if they want to obtain full reports from RACF SMF records. Some alternatives are:

• Service Level Reporter (SLR)
  
• An independent vendor's reporting program
  
• Your own reporting program

Users

RACF allows an installation to define the users who can access the protected resources, records information about the users in the user profiles, and maintains this information in the RACF database (along with all other profiles). The user profile includes (but is not limited to):

• The user's name and identifier.
  
• The user's password.
  
• The profile owner.
  

• The user's responsibilities, authorities, or restrictions while defined to the system. These are called the user attributes.
  

• The user's security classification. This classification determines the user's ability to access sensitive resources.

The user attributes define authorities or limits that a specific user has while on the protected system. (Not every user on a protected system has one of the user attributes.) The system-level user attributes include:

• SPECIAL, which gives the user full, system-wide control over all the profiles in the RACF database.
  

• AUDITOR, which gives the user full system-wide responsibility for auditing the security controls and the use of the system resources.
  

• OPERATIONS, which allows the user to perform any maintenance operations, such as copying, reorganizing, cataloging, and scratching, on RACF-protected system resources.
  

• CLAUTH (class authorization), which allows the user to define profiles to RACF for classes of predefined or installation-defined resources. (A class is a collection of RACF entities with similar characteristics. For example, DASDVOL is the predefined class for DASD volumes.)
  

• REVOKE, which prohibits the RACF-defined user from entering the system.

Before RACF 1.9, a security classification consisted of a security level or a set of categories or both. A security level is an installation-defined name that corresponds to a numerical security level (the higher the number, the higher the security level). For example, a user might have a security level of confidential. The installation has defined the security level of confidential to be equal to 150. A category is an installation-defined name corresponding to a department or area within an organization with similar security quirements. For example, all of the people who work on the accounting program could be in a category called "accounting."

When a user requests access to a sensitive resource, RACF checks the user's categories and security level to determine whether the user has an adequate security classification for that resource.

RACF 1.9 or later provides an additional security-classification concept, a security label, which is a combination of a security level and zero or more categories. See "B1 Security Level" in topic 2.3.1.2 for more information. To access a resource protected by a security label, a user has to have a security label whose contents encompass the contents of the resource's security label.

Groups

With RACF, all defined users belong to at least one group, known as their default group. A group is a collection of RACF users who share common access requirements to protected resources or who have similar attributes within the system. Groups associate similar jobs or projects together for administrative convenience. You can think of the groups as forming a hierarchical or "tree" structure, where each group is "owned" by a superior group. Groups can also "own" resources, as well as users and other groups. Figure 4 illustrates a tree structure of users associated to a group. (Note that subgroups or resources could be associated with groups in a similar tree structure.)

---