AccessibilitySkip to Top NavigationSkip to Main ContentHome  |  Contact IRS  |  About IRS  |  Site Map  |  Español  |  Help  

Part 10. Security, Privacy and Assurance

Chapter 8. Information Technology (IT) Security

Section 32. IBM Mainframe System Security Requirements

10.8.32  IBM Mainframe System Security Requirements

10.8.32.1  (09-01-2007)
Purpose

  1. This Internal Revenue Manual (IRM) establishes the minimum mandatory security settings for all IBM RACF mainframe operating systems within the Internal Revenue Service (IRS) running the z/OS.

10.8.32.1.1  (09-01-2007)
Overview

  1. This IRM establishes the information technology security requirements for the IBM mainframe systems running z/OS with RACF security software.

  2. The IRS uses the RACF IBM product, also referred to as SecureWay Security Server, to control and monitor access to data maintained on its mainframe computers. In order to maintain the integrity, confidentiality, and availability of data and information processed by IRS systems, the access control product, RACF, must be properly installed and configured. This document provides standards for the proper use and operation of this security software operating on IRS mainframe systems.

  3. This IRM is not predicated on definitions of General Support Systems (GSSs) or applications. The IRM is specific to the computer platforms and their operating systems regardless whether they are a GSS, part of a GSS, or part of a major application.

10.8.32.1.2  (09-01-2007)
Scope

  1. The provisions in this manual apply to all offices, business, operating and functional units within the IRS, external trading partners, as well as vendors with contractual arrangements with IRS, and are to be applied when IBM mainframe technology is used to accomplish the IRS mission.

  2. This manual also applies to individuals and organizations having contractual arrangements with the IRS, including employees, contractors, vendors, and outsourcing providers, which use or operate IBM mainframe information technology systems containing IRS data.

  3. This policy is binding on all IRS IBM mainframe computers running z/OS with RACF security software regardless of the user community.

  4. Contact Cybersecurity for additional information concerning requirements for IBM/RACF systems.

10.8.32.1.3  (09-01-2007)
IRM Section Topics

  1. This IRM contains information on the following subjects:

    • Authority

    • General Policy

    • Management Controls

    • Operational Controls

    • Technical Controls

    • Deviations

    • Appendix A: Required SETROPTS Specifications See Exhibit 10.8.32-1.

    • Appendix B: RACF Planning and Implementation See Exhibit 10.8.32-2.

    • Appendix C: UNIX System Services (USS) See Exhibit 10.8.32-3.

    • Appendix D: Network Communication Products See Exhibit 10.8.32-4.

    • Appendix E: Job Entry Subsystem 2 (JES2) See Exhibit 10.8.32-5.

    • Appendix F: Session Manager See Exhibit 10.8.32-6.

    • Appendix G: Terminal Programs, Transaction Processors, and Spool Software See Exhibit 10.8.32-7.

    • Appendix I: DASD Management Software See Exhibit 10.8.32-9.

    • Appendix K: Example of Controls for System Commands for Resources See Exhibit 10.8.32-11.

    • Appendix L: Minimum SMF Record Collection Requirements See Exhibit 10.8.32-12.

    • Glossary See Exhibit 10.8.32-13.

    • Acronyms See Exhibit 10.8.32-14.

    • List of References See Exhibit 10.8.32-15.

10.8.32.1.4  (09-01-2007)
Authority

  1. This document is assigned authority as a subsection of IRM 10.8, to describe Service policy as it relates to IBM/RACF security.

  2. FISMA requires Federal agencies to protect information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to ensure integrity, availability, and confidentiality of data and systems.

  3. The requirements and guidance identified in this IRM support comply with the requirements of IRM 10.8.1.

  4. This IRM is to neither contradict nor alter the meaning of requirements stated in IRM 10.8.1. In the event there is a discrepancy between this policy and IRM 10.8.1, IRM 10.8.1 has precedence unless specifically noted otherwise.

  5. This IRM shall be regularly evaluated and updated in accordance with IRM 10.8.1.

10.8.32.2  (09-01-2007)
General Policy

  1. The security standards identified within this IRM apply to all IRS systems and applications which currently use or plan to use IBM RACF. These standards – with the IBM RACF, Multiple Virtual Storage (MVS), Customer Information Control System (CICS), Time-Sharing Option (TSO), other technical manuals, and appropriate project office developed system documentation – provide the authorized minimum baseline configuration for IRS systems.

  2. Technical control settings shall be based on the capabilities of RACF to allow for the consistent implementation of RACF across all IBM mainframe platforms and applications.

  3. On systems running the z/OS where RACF is not the security package used, equivalent configuration and controls shall be implemented using the security software installed on the system.

10.8.32.2.1  (09-01-2007)
Roles and Responsibilities

  1. The IRS shall implement security roles in accordance with Federal laws and Information Technology (IT) security guidelines (e.g., Federal Information Security Management Act (FISMA), National Institute of Standards and Technology (NIST), Office of Management and Budget (OMB), Treasury, etc.) that are appropriate for their specific operations and missions.

  2. For further information, see IRM 10.8.2, Information Technology (IT) Security Roles and Responsibilities.

  3. In accordance with IRM 10.8.2, the RACF Security Administrator (RSA) shall be responsible for configuring system parameters in accordance with this IRM and system lifecycle documentation.

10.8.32.3  (09-01-2007)
Management Controls

  1. Management controls focus on the management of risk for an application or system and the management of computer security controls to mitigate that risk. See IRM 10.8.1 for general information and computer security management control requirements.

  2. Additional management controls specific to IBM/RACF mainframe systems are provided below in the following areas:

    1. Risk Assessment

    2. Planning

    3. System and Services Acquisition

    4. Certification, Accreditation, and Security Assessments

10.8.32.3.1  (09-01-2007)
Risk Assessment

  1. RACF mainframe systems shall not be used until they are compliant with this IRM and contain no high risk items, as listed below.

  2. Risk assessment activities for IBM mainframe systems shall include, at a minimum, an analysis of the compliance of the following high–risk items:

    1. Ensure proper minimum password length per IRM 10.8.1.

    2. Ensure proper password complexity requirements per IRM 10.8.

    3. Revoke or change passwords of IBMUSER and other privileged accounts provided by the vendor.

    4. Require at least 128–bit encryption for the operating system.

    5. Ensure telnet and other insecure services are not running.

    6. Ensure no unsupported operating systems or operating system versions are in use.

10.8.32.3.2  (09-01-2007)
Planning

  1. RSAs shall participate in contingency planning and contingency plan testing activities, as specified by IRM 10.8.1.

  2. RSAs shall participate in RACF security planning and implementation, as described in See Exhibit 10.8.32-2, RACF Planning and Implementation.

  3. RSAs shall participate in audit logging plan development, as described in IRM 10.8.3, Audit Logging Security Standards.

  4. System Owners shall plan for and schedule appropriate system maintenance activities necessary to bring systems into compliance with this IRM.

    1. System Owners shall apply vendor recommended security patches to operating systems at least monthly or more frequently, if possible.

    2. System Owners shall initiate planning, migration, and coordination activities to replace insecure system utilities, such as telnet and FTP, with utilities that provide session encryption.

    3. System Owners shall initiate necessary planning and coordination activities to remove privileged access from non–system administrators and replace such access with utilities that delegate limited privileges.

    4. System Owners shall upgrade applications having known security vulnerabilities to currently supported versions, no less than quarterly.

  5. System Owners shall be responsible for the development of standard enterprise–wide guidelines, standards, and procedures to support this policy.

10.8.32.3.3  (09-01-2007)
System and Services Acquisition

  1. Software products covered by this IRM shall be acquired, accounted for, and inventoried in accordance with IRM 10.8.1.

  2. Software products covered by this IRM shall adhere to IRS Enterprise Life Cycle (ELC) requirements, in accordance with IRM 10.8.1.

  3. The Designated Approving Authority (DAA) or designee shall ensure system documentation for each RACF protected system is maintained at the host site(s) and also at a secure off–site facility. Required system documentation is identified in TD P 84–01, Information Systems Life Cycle Manual.

10.8.32.3.4  (09-01-2007)
Certification, Accreditation, and Security Assessments

  1. All IBM mainframe systems shall obtain Certification and Accreditation (C&A) in accordance with IRM 10.8.1.

10.8.32.3.4.1  (09-01-2007)
Security Reviews

  1. The Cybersecurity, Certification, Testing, Evaluation and Assessment staff will perform quarterly compliance checks of IBM mainframe systems.

  2. Functional security reviews of the following system programs, libraries, load modules or tables shall be conducted quarterly for verification of authorized program changes:

    1. ICHRIN03 – shall assign USER= parameters to started tasks, and optionally gives them the TRUSTED attribute which causes them to be allowed to pass the security checks provided by RACHECK.

    2. ICHRRCDE – shall contain the names of any class descriptor entries the installation has added.

    3. ICHSECOP – shall not be used since this program is capable of being used to bypass RACF initialization processing, to indicate the number of resident index blocks, and to indicate whether there can be more than one dataset profile with the same dataset name.

    4. CHRDSNT – shall describe the RACF dataset, the number and type of buffers it uses, and whether updates will be reflected in the backup RACF dataset.

    5. ICHAUTAB – shall list authorized callers (users or programs/tasks that are allowed to issue RACLIST without a new password).

    6. ICHRRNG – shall be used to split the RACF dataset across more than one disk.

    7. ICHRMSFI – shall set options for the RACF report writer.

    8. RACF exits – shall not be active on a system.

    9. SYS1.PARMLIB – member list shall be reviewed for unauthorized configuration or changes.

    10. APF libraries – access privileges shall be verified.

  3. If the installation has customized the above program names, then the program serving this function shall be reviewed.

10.8.32.4  (09-01-2007)
Operational Controls

  1. Operational controls address security mechanisms that primarily are implemented and executed by individuals as opposed to systems. They often require technical or specialized expertise and rely on management activities as well as technical controls. See IRM 10.8.1 for general information and computer security operational control requirements.

  2. Additional operational controls specific to IBM/RACF mainframe are provided below in the following areas:

    1. Contingency Planning

    2. Configuration Management

    3. Maintenance

    4. System and Information Integrity

    5. Incident Response

10.8.32.4.1  (09-01-2007)
Contingency Planning

  1. RSAs shall participate in contingency planning and contingency plan testing activities, as specified by IRM 10.8.1.

  2. RSAs shall backup a baseline of each mainframe system (as defined in See IRM 10.8.32.4.2.1, Baseline Configuration) to write–protected media.

  3. Critical files shall not be co–located on the same physical device or access path. Specifically, the primary RACF dataset and the backup RACF dataset shall be marked "unmovable" , reside on different disk volumes, and accessible through different paths.

  4. The RACF and other critical datasets shall be backed–up at least weekly to removable media.

  5. Backup media shall be stored in a secure off–site facility.

10.8.32.4.2  (09-01-2007)
Configuration Management

  1. Configuration management (CM) requirements for all mainframe systems covered by this IRM follow below. The requirements below supplement the general CM requirements established by IRM 10.8.1.

  2. To ensure proper control and tracking of maintenance and changes made to system software, all software products with the capability for installation via IBM’s System Modification Program/Extended (SMP/E) process shall be installed and maintained using that process.

  3. RSAs shall regularly, at least monthly, check z/OS vendor websites for information on new security patches that are applicable to their environment. All applicable security patches shall be scheduled to be applied to the system. Patches shall be applied and tested in a test logical partition (LPAR) before being applied to the production LPARs and comply with all approved IRS CM processes and procedures.

10.8.32.4.2.1  (09-01-2007)
Baseline Configuration

  1. System owners shall be responsible for ensuring that a common minimum mainframe operating system baseline configuration is established and maintained for all hosts within the system owner’s boundary.

  2. RSAs shall ensure that the common minimum operating system baseline contains the minimum RACF settings as specified in See IRM 10.8.32.5.4.8, Required RACF Settings.

  3. RSAs shall ensure that the common minimum operating system baseline includes configuration restrictions as specified in See Exhibit 10.8.32-1, Required SETROPTS Specifications.

  4. All device files shall be located in the partitioned datasets as installed and designated by the operating system and/or application vendor.

10.8.32.4.3  (09-01-2007)
Maintenance

  1. System Owners shall schedule maintenance activities to bring mainframe systems into compliance with this IRM.

  2. The Information Systems Security Officer (ISSO) and the system owner shall ensure that unsupported system software is removed or upgraded prior to a vendor discontinuing support.

  3. Some equipment has the capability of automatically initiating communications to notify the vendor when the equipment detects a malfunction. (This feature is commonly known as "phone home" ). The handling of the notification and remote diagnostic procedures shall be documented by the system owner and approved by Mission Assurance.

10.8.32.4.4  (09-01-2007)
System and Information Integrity

  1. RSAs shall control and monitor mainframe components that can potentially bypass security features to prevent system integrity from being compromised. These components include system utilities, program library systems (such as Authorized Programs), and other file maintenance systems. There are also installation definable system components, such as System Management Facility (SMF) Exits and Supervisor Calls (SVCs) that are installed as part of the operating system.

  2. The security and integrity of the z/OS shall be validated using the Data Security Monitor (DSMON) facility of RACF to generate reports on the current status of the system.

    1. DSMON reports shall be reviewed by the RACF System Auditor at least weekly and compared with previous weekly reports or baseline reports to identify unauthorized changes and initiate corrective actions.

    2. The DSMON reports shall be available for review on demand by the RACF System Auditor for authorized and unauthorized changes.

  3. The following DSMON reports shall be generated weekly:

    1. System Report: This report provides the CPU–ID, Model Number, the Name, version, and release of the operating system, Resident volume, SMS–ID, and the RACF version and release. This report shall be used to identify any changes to the operating system.

    2. RACF Exits Report (RACEXT): This report provides "NO RACF EXITS ARE ACTIVE" . The presence of any RACF EXIT shall be reported immediately to the RSA to ensure that DES encryption is still active and the system has not been compromised.

    3. Selected User Attribute Report (RACUSR): This report provides the users with SPECIAL, OPERATIONS, or AUDITOR on a system–wide or group level.

    4. Selected Datasets Report:

      Link listed datasets (SYSLNK ): This report provides the datasets that are link listed, the volume serial number, whether it is RACF indicated and/or protected, and the UACC.

      APF authorized datasets (SYSAPF): This report provides the Authorized Program Facility (APF) datasets along with the volume serial number, whether RACF indicated and/or protected and the UACC.

      Cataloged datasets (SYSCAT): This report provides the datasets and where they are cataloged, long with the volume serial number, whether RACF indicated and/or protected and the UACC.

      Location of Primary/Backup RACF dataset (RACDST): This report provides the primary RACF database as well as the backup database. It shall also identify the volume serial number, whether RACF indicated and/or protected, and the UACC. The primary RACF database and backup shall be stored on different DASD.

      System Datasets Report (SYSSDS): This report provides the selected dataset name, volume serial number, selection criterion, if it is RACF indicated and protected and the UACC.

    5. Program Properties Table Report (SYSPPT): This report provides the program name, whether that program has the ability to bypass password protection, and whether it has a system key.

    6. RACF Authorized Caller Table Report (RACAUT): This report provides whether or not the system has an authorized caller table active with entries. The message shall be "NO ENTRIES IN RACF AUTHORIZED CALLER TABLE" .

    7. RACF Started Procedures Table Report (RACSPT):These reports provide all started procedures or the job name (if STARTED Class is active), associated users and groups, and if privileged or trusted.

      If the general resource class STARTED is active, there will be two reports: one that lists the profiles in the STARTED Class, and the other from the installation replaceable load module (ICHRIN03) associated with this command.

      If the STARTED Class is not active, only the report from the Started Procedures Table will be run. The z/OS platform will check the Class resources before checking the table when authorizing a started task. The started class profiles take precedence over the entries in the started procedures table.

      If the STARTED Class is not active, only the report from the Started Procedures Table will be run. The z/OS platform will check the Class resources before checking the table when authorizing a started task. The started class profiles take precedence over the entries in the started procedures table.

    8. RACF Class Descriptor Table Report (RACCDT): This report provides all the classes on the system, whether they are active or inactive, if audited, if statistics are kept, UACC and if operations is allowed.

    9. RACF Global Access Table Report (RACGAC):The report provides dataset profiles that are defined in the Global Access Table that have been selected because the datasets protected have a high volume of access by system users. This table is stored in memory and bypasses RACF profile checking if requested access is less than or equal to access indicated in the Global Access Table. Datasets with sensitive information shall be evaluated to ensure that such information does not reside in the Global Access Table.

    10. RACF Group Tree Report (RACGRP): This report provides the hierarchy of all the groups on the system. It also indicates group ownership if other than the superior group.

  4. To prevent a user from copying a sensitive program and executing it from a personal library, READ/UPDATE/ALTER access shall be restricted to the systems personnel responsible for the installation and maintenance of the software.

  5. Audit trail data (e.g., SMF data, TMON log data, SYSLOG) shall be protected by RACF according to the requirements stated in IRM 10.8.3.

  6. UPDATE and ALTER access shall be controlled from the point of log/dump datasets down to the point where the final repository is fed.

  7. UPDATE and ALTER access to RACF datasets shall be restricted to RACF security administrators and designated systems programmers only.

  8. All updates to the RACF security database shall be tracked by the utility program provided with RACF.

  9. All accesses to the RACF database shall be audited at all times.

  10. All datasets shall be cataloged either in the Master Catalog or in an appropriately defined and connected User Catalog.

  11. All catalog aliases shall be identified and defined in RACF and owned by the appropriate data owner.

  12. Systems programming personnel shall be authorized UPDATE and ALTER access to the System Master Catalog.

  13. System user catalogs shall be update-able by the users.

  14. All dataset access to the System Master Catalog and system user catalogs shall be logged.

  15. UPDATE and ALTER access privileges to all procedure libraries (proclibs) referenced in the JES2 procedure for started tasks (STCs) and TSO shall be restricted only to designated systems programming personnel.

10.8.32.4.5  (09-01-2007)
Incident Response

  1. If a RACF Group Administrator, designated official, the system RSA, or System or Group Auditor discovers any unauthorized update/modification activity which significantly impacts or could impact system integrity; these incidents shall be immediately reported to IRS’ Computer Security Incident Response Center (CSIRC) and first-line manager.

  2. CSIRC will work with local Area Security Managers and site management to determine the severity or significance of the security incident.

  3. Incidents shall be reported using any of the following methods:
    a. On-line reporting contact information

    • CSIRC Portal: http://www.csirc.web.irs.gov/

    • E-mail: csirc@csirc.irs.gov


    b. Telephonic reporting information

    • (866) 216-4809 (toll-free)

    • (202) 283-4809 (local)

    • (202) 283-0345 (FAX)

  4. Refer to Cybersecurity "Computer Security Incident Reporting Procedures" for more information.

10.8.32.5  (09-01-2007)
Technical Controls

  1. Technical controls focus on the security controls that the computer system executes. These controls provide automated protection from unauthorized access or misuse, facilitate detection of security violations, and support security requirements for the systems or applications. The implementation of technical controls shall be consistent with the management of security within the organization. See IRM 10.8.1 for general information and computer security technical control requirements.

  2. Additional technical controls specific to IBM/RACF mainframe are provided below in the following areas:

    1. Identification and Authentication

    2. Access Control

    3. Audit and Accountability

    4. System and Communications Protection

10.8.32.5.1  (09-01-2007)
Identification and Authentication

  1. IBM z/OS systems shall be able to identify and differentiate among users so that activities on the system can be linked to specific individuals.

  2. All UserIDs in IBM z/OS system environments must consist of alphabetic, numeric, and national (#, $, @) characters.

    1. The first character shall be alphabetic or national.

    2. Each UserID shall be unique and be between 1 to 8 characters in length (7 is preferable due to current job naming conventions).

  3. The RSA for each system will work with the System Programming staff for that system to define the syntax of UserID based on IRM 10.8.1 requirements.

10.8.32.5.1.1  (09-01-2007)
Password Management

  1. Passwords shall be protected using a FIPS–approved hashing or encryption mechanism.

  2. Passwords shall have the minimum requirements in accordance with IRM 10.8.1.

  3. Password syntax (defined in RACF SETROPTS) shall be A=Alpha and N=Numeric combination, or L=Alphanum. This allows for the largest possible number of permutations.

  4. The first character shall be alphabetic to support integration with large database machines and UNIX systems. The SETROPTS parameter of *=Anything shall not be used for all characters in the password, as this would allow the use of real words or proper names and render the system vulnerable to a password cracker program.

  5. The lifetime for a password shall not exceed the number of days specified in IRM 10.8.1, unless specifically documented by the RSA and approved by Mission Assurance. Exceptions, such as those for STC, shall be documented by the RSA and approved by ACIO, Cybersecurity.

  6. Password history for all UserIDs shall be maintained systemically through RACF SETROPTS parameter and meet the minimum number of previous passwords generation specified in IRM 10.8.1.

  7. Users shall be notified by the system in advance that their passwords will expire. See Exhibit 10.8.32-1 of this document for the minimum of days to specify in RACF SETROPTS PASSWORD (WARNING) field.

  8. Passwords shall not be automated through use of function keys, scripts, or other methods where logons/passwords may be stored on systems except in the case of pass–through communications.

  9. Password distribution shall be made in a secure manner. Employee UserID, name and initial passwords shall be distributed to the user via the OL5081 system or in a sealed "CONFIDENTIAL INFORMATION To Be Opened by Addressee Only" envelope addressed to the appropriate user. They shall be labeled "To Be Opened by Addressee Only" or via secure (encrypted) e–mail.

  10. When the RSA must change a user’s password, the change user panel or TSO command shall be used to ensure the password confidentiality. The password shall NEVER be reset to a user’s default groupname, UserID, or generic password.

  11. The RVARY passwords for the Switch and Status functions shall be set to "Installation Defined" in the SETROPTS. The same rules shall be used as set forth in See IRM 10.8.32.5.1.2, FIRECALL Account, which contains guidance for using and protecting FIRECALL (emergency and/or special use) UserIDs.

10.8.32.5.1.2  (09-01-2007)
FireCall Account

  1. Each implementation of RACF at each mainframe shall establish and maintain at least three (3) FIRECALL UserIDs for emergency or special use purposes.

  2. The FIRECALL UserIDs shall be used only in accordance with locally developed standard operating procedures that meet the requirements stated in IRM 10.8.1and this document.

  3. FIRECALL UserIDs shall be created, one with system–level SPECIAL attribute, one with system–level OPERATIONS attribute, and one for Disaster Recovery with system–level SPECIAL and/or AUDITOR attribute(s).

  4. Passwords for FIRECALL UserIDs shall be replaced after each use.

  5. When a FIRECALL UserID is used, a report shall be prepared by the individual(s) handling the event. The report shall describe the problem, the solution, and the user involved. A copy of this documentation shall be sent to the local RSA by the next business day.

  6. The RSA must be notified no later than the next working day when a FIRECALL UserID has been used. The RSA shall delete the FIRECALL, recreate the UserID(s), and create a new password as soon as the event is over, and place the new password along with the UserID in a sealed envelope in the locked container and/or send to the disaster recovery site, as appropriate.

  7. The contents of the SYS1.UADS shall be reviewed by the RSA in conjunction with the quarterly user validation to ensure only valid users are contained therein.

    1. Only IBMUSER, the FIRECALL "SPECIAL" , a Disaster Recovery FIRECALL "SPECIAL" , the UserID of the RSA, and the UserID of the System Software RACF Specialist shall be in this dataset.

    2. Any additional UserIDs placed in SYS1.UADS must be documented in writing and approved by management. The account approval documentation shall be retained by the RSA.

10.8.32.5.1.3  (09-01-2007)
System Operator UserIDs

  1. Each user of a system–defined operator console shall be defined to RACF as a unique UserID.

10.8.32.5.2  (09-01-2007)
Access Control

  1. An access matrix shall be used to document critical system and resource (including data) access levels for users and groups.

  2. The approved method for adding, updating, and removing users and/or privileges shall be the Information System User Registration/Change Request via the OL5081 or its successor. If supplemental information is required, that information shall be provided in the special instructions of the OL5081.

  3. When a new or previous system user needs a UserID, the user shall submit an OL5081 request through his/her Functional Manager or their designee.

  4. Upon receipt of the properly completed OL5081, the RSA or User Administrator will assign the UserID, initial password, and add the user to the RACF database.

  5. Each entry of OL5081 or its successor must contain the required management approval authorizing the action to the employee account. An OL5081, or its successor, is also required under the following circumstances:

    1. When management requests to add or delete an employee to the RACF database;

    2. When an employee has a name change;

    3. When an employee functional position changes and access requirements change (i.e., CSA to DBA or access is no longer required);

    4. For a NDM authorization file;

    5. When a modification is required to an existing user’s profile (i.e., temporary access request, OMVS segment, etc.).

10.8.32.5.2.1  (09-01-2007)
Access Revocation and Termination

  1. After the number of days of inactivity stated in IRM 10.8.1, UserIDs shall be REVOKED by the system, but will not be physically removed from the system at that time. To be reactivated, the user will be required to request re–activation through the OL5081 system.

  2. After the number of days of inactivity stated in IRM 10.8.1, the UserID shall be purged from the system, along with all accesses, privileges and datasets rights. To be reactivated, the user will be required to submit a new Information System User Registration/Change Request Form 5081 or its successor at https://OL5081.enterprise.irs.gov) through their manager requesting reassignment of a UserID and a new password.

10.8.32.5.2.2  (09-01-2007)
Group Identification

  1. The RACF group concept shall be used to facilitate role–based access control.

  2. Users with similar access requirements shall be collected in a RACF group.

  3. The group structure shall be determined by functional role and corresponding access requirements. Procedures for setting up the RACF group tree structure are contained in See Exhibit 10.8.32-2 RACF Privilege Management.

  4. Standard groups shall include at a minimum:

    1. Security

    2. RACF Group Security Administrator

    3. Application programmers

    4. System programmers

    5. Computer operators

    6. Operating system administrators

    7. Database administrators

    8. Auditors

    9. Batch jobs

    10. Started tasks

    11. CICS regions

    12. Consoles

    13. CPE, NJE and RJE ports of entry

    14. Users with OPERATIONS attribute

    15. DB2 subsystems

  5. The Group ID shall be 8 characters or less and be consist of alphabetic, numeric, and national (#, $, @) characters. The first character shall be alphabetic or national.

  6. The RSA and/or the system programmer for each system shall develop unique Group IDs based on the functionality of the group.

  7. No user shall be allowed to own a group (with the exception of the IBMUSER, which owns SYS1) as this would give that user the power to alter or delete the group based on that person’s identity rather than his/her role.

  8. All group profiles must utilize the INSTALLATION DATA field to describe the purpose of the group, and all data set profiles utilizing a group name as the High Level Qualifier (HLQ) must likewise utilize the INSTALLATION DATA field to describe the data sets being protected.

10.8.32.5.2.3  (09-01-2007)
z/OS System Command Controls

  1. System commands shall be controlled by selectively granting access to resources in the OPERCMDS class, with names such as MVS.command.qualifier or MVS.command.qualifier object.

  2. To restrict general access, the MVS.** resource shall be defined in the OPERCMDS class with a default access of NONE.

  3. An enterprise–wide system owner procedural document shall be developed to control z/OS system commands that provides a granular indication of roles as well as the type of access for each role. See Exhibit 10.8.32-9 contains a sample table that may be used to control z/OS system commands.

  4. Commands shall be defined to the OPERCMDS resource class.

  5. System command control accesses shall be limited to a minimum number of personnel required for normal business operations.

10.8.32.5.2.4  (09-01-2007)
Resource Access Control

  1. Two families of RACF profiles shall be used to control all system resources:

    • the DATASET profiles are used to protect datasets

    • the general resource profile is used to protect everything else.


    General resources shall be all the resources that are defined in the class descriptor table and include among others, DASD volumes, tape volumes, terminals, and load modules (programs).

  2. No installation defined system started procedures, tasks, or programs shall be allowed to bypass RACF security checks or call the RACINIT macro, unless specifically authorized in writing by the RSA, approved by ACIO, Cybersecurity, and issued within the authorized transmittal process. No such authorization shall compromise the system, an application, or sensitive information which results in an unacceptable risk.

10.8.32.5.2.5  (09-01-2007)
System–Level Privileges

  1. The primary and backup RSA(s) on each system shall be the only individuals that may be granted more than one system–level attribute (SPECIAL and AUDITOR) on a full–time basis.

  2. System Operators, System Managers, Computer System Analysts, and System Programmers shall be assigned only group–level access to the appropriate datasets or resource classes to perform normal day–to–day work.

  3. The actions of privileged users shall be monitored by their management and/or by a designated system auditor through review of audit trails and SUCCESS reports.

  4. All activities at the system–level by anyone granted access through privileged attributes shall be audited by the system at all times, through the UAUDIT attribute which must be set for all users with system–level privileges.

  5. The AUDITOR attribute should be assigned only to personnel within the organization specifically assigned audit functions. It provides the ability to list any RACF rule and to modify any auditing options including turning auditing off. The Group–level AUDITOR attribute allows all of the above privileges within the scope of the group only.

10.8.32.5.2.6  (09-01-2007)
User Dataset and Resource Controls

  1. Controls shall be implemented to provide assurance that:

    1. No access is allowed unless explicitly granted.

    2. The least level of access has been granted.

    3. Access is granted only on a need–to–know basis.

  2. No user shall ever be defined to the system or given access to resources with the assumption that they might need access at sometime in the future.

  3. Temporary accounts for access to resources for specific work assignments shall be revoked upon completion of the assignment by the RSA.

  4. In order to establish and maintain the greatest level of control over system resources, the following rules shall apply when establishing or maintaining discretionary access controls at user, group, and dataset levels.

    1. No single user shall have more than one system–level attribute (SPECIAL, OPERATIONS, and AUDITOR). Exception: RACF Security Administrators may possess both the System–level SPECIAL and AUDITOR attributes.

    2. A single user shall have more than one group–level attribute within a given group or scope of groups (SPECIAL, OPERATIONS, AUDITOR) only when required to perform normal business operations.

    3. The WHEN field in the user record is optional, but may be used to specify the day of the week and hours of the day in which the user is allowed to logon. This time window is based on the employee(s) tour of duty as indicated in the OL5081.

    4. All groups shall be owned by another group (SUPGROUP).

    5. No UserID shall be the owner of a group. Exception: SYS1 owned by IBMUSER.

    6. Decisions to grant Universal Access (UACC) of ALTER, CONTROL, or UPDATE for datasets and resources shall be documented to include the authorizing individual's name and the security impact analysis. A copy of this documentation shall be sent to the RACF Security Administrator for each system at field sites.

    7. Any dataset or spool output containing sensitive but unclassified (SBU) data shall have a UACC of NONE.

    8. Decisions to assign UACC higher than NONE, EXECUTE, or READ to datasets on the Selected Datasets Table shall be documented to include the authorizing individual's name and the security impact analysis. A copy of this documentation shall be sent to the RACF Security Administrator for each system at field sites.

    9. Access requirements shall be explicitly defined for users and groups using the STANDARD ACCESS LIST in the dataset or resource records containing taxpayer data, instead of using UACC higher than NONE.

    10. RACF shall be set to require that every Dataset Profile is either a UserID or group name as the high–level–qualifier.

10.8.32.5.2.7  (09-01-2007)
RACF Records (Profiles)

  1. User records, group records, dataset records, and resource records can be extended by the addition of segments which hold additional related data and shall be used to further control user access to resources.

  2. RACF profiles shall be set in accordance with Exhibit 10.8.32–2.


More Internal Revenue Manual