Mainframe & RACF: security in the time of dinosaurs

Kleverware Mainframe

In the 1950’s, computers appeared in companies. The processing capabilities of mainframes could not be matched. These systems and their thousands of transactions per day brought speed to the existing processes. Today we are going to focus on the security systems of these computers and more particularly on RACF.

History

Resource Access Control Facility (RACF) appeared on MVS, the operating system supplied by IBM with its mainframes from the mid-1970s. It is responsible for ensuring the security and control of operations performed in the system. It is based on three principles:

  • User identification and verification
  • Authorization of access to resources
  • Recording and reporting of accesses made

Despite its age, this system has evolved with IBM machines and OS. Today, after almost 50 years of service, it still provides security for z/OS systems, descendants of MVS in 64 bits.

How does it work?

The RACF system provides the tools to manage user access to critical resources. RACF keeps information about users, resources and access permissions in special structures called “profiles” in its database and refers to these profiles when deciding which users should be allowed access to protected resources in the system.

To help protect critical resources, RACF can:

  • Identify and authenticate users
  • Allow users to access protected resources
  • Record and report on various attempts to gain unauthorised access to protected resources.
  • Control the means of access to resources

Export and audit:

The principle is to process each data item as a record. Depending on the type of record, the different attributes change.

There are three categories that group these types of records:

  • Groups
  • Users
  • Resources

The most common record types are, for example, « 0100 – Group basic data » or « 0200 – User basic data ».

In a RACF extraction, we will therefore find all the records in a single file, and the first four characters identify the type of record.

Each type is also well defined. Each attribute is defined over a range of characters, e.g. type 0200:

  • Character 6 to 13: User login
  • Character 50 to 53: Account status (Revoked)

What about the IAG?

Despite the age of IBM mainframes, they are still very present, especially in bank and insurance IT. The review of RACF accounts is therefore an important subject in their identity and access governance. Kleverware can audit and analyse these “dinosaurs”, highlight anomalies and allow the recertification of this data.

The first step in the process is to render RACF records in a more readable way, without reviewers having to wade through 20 pages of documentation to find out if an account is assigned the SPECIAL attribute.

As we saw in the previous chapter, RACF extractions are formatted according to the type of RECORD. Once the type is known, the data can be transformed into a more readable form, Excel, or CSV for the braver ones. Only records that are useful for the review of accounts are kept.

From experience, here is the list of attributes that Kleverware systematically audits for its customers:

Record 0100: « Group Basic Data »

This type defines the basic information associated with a group. A record corresponds to a group.

Attribute nameCharacter positionsDescription
GPBD_NAME6 to 13Group name
GPBD_INSTALL_DATA58 to 312Used as a description of the group

Record 0101: « Group subgroups »

This type defines the relationships between the different groups. A record corresponds to a relationship between two groups.

Attribute nameCharacter positionsDescription
GPSGRP_NAME6 to 13Parent group name
GPSGRP_SUBGRP_ID15 to 22Child group name

Record 0200: « User Basic Data »

This type defines the basic information associated with a user. A record corresponds to a user.

Attribute nameCharacter positionsDescription
USBD_NAME6 to 13User login
USBD_SPECIAL40 to 43Flag on account SPECIAL attribute
USBD_OPER45 to 48Flag on account OPERATIONS attribute
USBD_REVOKE50 to 53Flag on the revoked status of the account
USBD_PWD_INTERVAL60 to 62The number of days that the user’s password can be used
USBD_PWD_DATE64 to 73The date that the password was last changed
USBD_PROGRAMMER75 to 94The name associated with the user ID
USBD_DEFGRP_ID96 to 103The default group associated with the user
USBD_LASTJOB_TIME105 to 112Last recorded connexion time
USBD_LASTJOB_DATE114 to 123Last recorded connexion date
USBD_AUDITOR386 to 389Flag on account AUDITOR attribute
USBD_REVOKE_DATE458 to 467The date that the user is revoked

Record 0203: « Group subgroups »

This type defines the relationships between users and groups. A record is a relationship between a user and a group.

Attribute nameCharacter positionsDescription
USGCON_NAME6 to 13User login
USGCON_GRP_ID15 to 22Group name

In addition to this information, Kleverware IAG integrates data required by the customer for their review. For this purpose, other record types can also be extracted, such as record 0205 “User Connect” for TSO related information.

Once the necessary information has been extracted and transformed, it can be returned to the reviewers through the application and integrated with the rest of the IS that has been modelled to establish the legitimacy of the users, groups and accesses linked to RACF.

Did you like this post ?

Share on twitter
Twitter
Share on linkedin
LinkedIn