Skip to content
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 name | Character positions | Description |
| GPBD_NAME | 6 to 13 | Group name |
| GPBD_INSTALL_DATA | 58 to 312 | Used 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 name | Character positions | Description |
| GPSGRP_NAME | 6 to 13 | Parent group name |
| GPSGRP_SUBGRP_ID | 15 to 22 | Child group name |
Record 0200: « User Basic Data »
This type defines the basic information associated with a user. A record corresponds to a user.
| Attribute name | Character positions | Description |
| USBD_NAME | 6 to 13 | User login |
| USBD_SPECIAL | 40 to 43 | Flag on account SPECIAL attribute |
| USBD_OPER | 45 to 48 | Flag on account OPERATIONS attribute |
| USBD_REVOKE | 50 to 53 | Flag on the revoked status of the account |
| USBD_PWD_INTERVAL | 60 to 62 | The number of days that the user’s password can be used |
| USBD_PWD_DATE | 64 to 73 | The date that the password was last changed |
| USBD_PROGRAMMER | 75 to 94 | The name associated with the user ID |
| USBD_DEFGRP_ID | 96 to 103 | The default group associated with the user |
| USBD_LASTJOB_TIME | 105 to 112 | Last recorded connexion time |
| USBD_LASTJOB_DATE | 114 to 123 | Last recorded connexion date |
| USBD_AUDITOR | 386 to 389 | Flag on account AUDITOR attribute |
| USBD_REVOKE_DATE | 458 to 467 | The 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 name | Character positions | Description |
| USGCON_NAME | 6 to 13 | User login |
| USGCON_GRP_ID | 15 to 22 | Group 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.
