Chapter 31: Key Takeaways - COBOL and the z/OS Security Model

Chapter Summary

Security on the mainframe is not an afterthought bolted onto the system -- it is a deeply integrated, pervasive facility that controls every access to every resource. This chapter explored how the z/OS security model works and what COBOL developers must understand to write secure applications that comply with enterprise security policies and regulatory requirements. At the heart of z/OS security is RACF (Resource Access Control Facility), which authenticates users, authorizes access to resources through profiles and access lists, and logs security events for audit purposes. While RACF is the most widely deployed security product, compatible alternatives such as CA ACF2 and CA Top Secret provide equivalent functionality with different administrative interfaces.

The chapter examined the layers of security that protect mainframe resources. Dataset security controls who can read, write, create, and delete datasets through RACF dataset profiles that match on dataset name patterns. Program security restricts which load modules a user can execute, using program profiles and the RACF PROGRAM class. CICS security is multi-layered, controlling transaction invocation, program execution, file access, and queue operations through CICS resource security and surrogate user support. DB2 security uses its own authorization model of privileges and authorities, with RACF providing the authentication layer. We explored how each of these security domains applies to COBOL programs running in batch, CICS, and IMS environments.

The chapter also addressed secure coding practices for COBOL developers, including the avoidance of hardcoded credentials, proper handling of sensitive data in memory and files, audit trail generation, and defensive programming against injection-style attacks in CICS web-enabled applications. Compliance frameworks such as SOX (Sarbanes-Oxley) and PCI-DSS (Payment Card Industry Data Security Standard) impose specific requirements on mainframe applications, including segregation of duties, access logging, encryption of sensitive data, and change management controls. Understanding these requirements is increasingly important for COBOL developers because auditors examine not just infrastructure configurations but also application-level security practices.

Key Concepts

  • RACF (Resource Access Control Facility): IBM's security product for z/OS that provides user authentication, resource authorization, and security auditing. RACF uses profiles (user, group, dataset, and general resource) to define who can access what and at what level.
  • User Profiles and Groups: Every mainframe user has a RACF user profile defining their identity, default group, and attributes. Groups organize users and simplify access management. Access is granted by connecting users to groups, then authorizing groups to resources.
  • Access Levels: RACF defines standard access levels -- NONE, EXECUTE, READ, UPDATE, CONTROL, ALTER -- applied in a hierarchy. A user with UPDATE access can also READ the resource. These levels apply across dataset, program, and general resource classes.
  • Dataset Profiles (Discrete and Generic): Discrete profiles protect a single specific dataset. Generic profiles use pattern matching (% for single-character wildcard, * for single qualifier, ** for multiple qualifiers) to protect groups of datasets with a single rule.
  • CICS Resource Security: CICS uses RACF to authorize access to transactions (TCICSTRN class), programs (CCICSCMD class), files (FCICSFCT class), and other resources. The CICS region's security configuration determines which resource classes are active and how violations are handled.
  • DB2 Authorization: DB2 uses a privilege-based model where users are granted specific privileges (SELECT, INSERT, UPDATE, DELETE) on specific objects (tables, views, plans). Privileges can be granted directly or through DB2 roles, with RACF providing the underlying authentication.
  • Surrogate Users and Security Contexts: In CICS and IMS, transactions can execute under the security context of the signed-on user or a surrogate user. Understanding which identity is in effect when a COBOL program accesses resources is critical for correct security design.
  • Audit Trails and SMF Records: RACF generates System Management Facility (SMF) records for security events including successful access, access violations, and profile changes. Type 80 SMF records capture RACF events and feed into security monitoring and compliance reporting systems.
  • SOX Compliance: The Sarbanes-Oxley Act requires publicly traded companies to maintain internal controls over financial reporting. For mainframe COBOL applications processing financial data, this means enforced segregation of duties, change management controls, and comprehensive audit logging.
  • PCI-DSS Compliance: The Payment Card Industry Data Security Standard mandates specific protections for cardholder data, including encryption, access controls, network segmentation, and logging. COBOL programs that process credit card data must comply with PCI-DSS requirements at the application level.
  • Encryption and Data Protection: z/OS provides encryption at multiple levels -- dataset encryption through RACF profiles, network encryption through AT-TLS, and application-level encryption through callable services. COBOL programs can invoke ICSF (Integrated Cryptographic Service Facility) services for encryption, decryption, and hashing.
  • Program Control and APF Authorization: The Program Control facility restricts which programs can be executed, while APF (Authorized Program Facility) authorization controls access to sensitive system services. COBOL programs rarely need APF authorization, but understanding the concept helps when diagnosing S047 and S306 abends.

Common Pitfalls

  1. Hardcoding user IDs, passwords, or security tokens in COBOL source code. This is a critical security violation that exposes credentials to anyone who can read the source library. Credentials should be managed through RACF, keystores, or external security facilities -- never embedded in application code.
  2. Leaving sensitive data in working storage after use. COBOL working storage persists for the life of the program (or run unit in CICS). Credit card numbers, social security numbers, and passwords should be overwritten with spaces or zeros immediately after use to minimize exposure in memory dumps.
  3. Not validating input data in CICS web-enabled applications. COBOL programs that process data from web interfaces (through CICS Web Services or Channels and Containers) must validate all input for length, format, and content to prevent buffer overflows and injection attacks.
  4. Assuming that batch job security is sufficient without application-level checks. While RACF controls who can submit a job and what datasets it can access, the COBOL program itself should validate that the processing being performed is consistent with business rules and authorization levels.
  5. Granting excessive RACF access for convenience during development. Developers often request ALTER access to datasets or CONTROL authority during testing, then forget to reduce these permissions for production. Access should always follow the principle of least privilege.
  6. Not logging security-relevant application events. Even when RACF logs resource access, the application should log business-level events such as account modifications, large transactions, and override actions. These application audit trails are essential for SOX and PCI-DSS compliance.
  7. Ignoring the security implications of CICS transaction routing. When transactions are routed across CICS regions, the user's security context may or may not propagate depending on configuration. COBOL programs should not assume a specific security identity without verifying it through EXEC CICS ASSIGN.
  8. Failing to protect temporary datasets containing sensitive data. Batch jobs often create temporary datasets (&&TEMP) that contain intermediate results including sensitive data. These datasets should be allocated with appropriate RACF protection or kept as truly temporary so they are deleted at job completion.

Quick Reference

RACF ACCESS LEVELS (HIERARCHY):
  NONE    - No access permitted
  EXECUTE - Execute programs only
  READ    - Read access
  UPDATE  - Read and write access
  CONTROL - VSAM control password equivalent
  ALTER   - Full control including delete

RACF DATASET PROFILE PATTERNS:
  HLQ.EXACT.MATCH        - Discrete profile
  HLQ.PAYROLL.*          - Generic: one qualifier
  HLQ.PAYROLL.**         - Generic: multiple qualifiers
  HLQ.PAYROLL.%ASTER     - % matches single character

CICS SECURITY CLASSES:
  TCICSTRN  - Transaction security
  CCICSCMD  - Command security
  FCICSFCT  - File security
  DCICSDCT  - Destination security
  JCICSJCT  - Journal security
  SCICSTST  - Temporary storage security

DB2 PRIVILEGES:
  SELECT, INSERT, UPDATE, DELETE  - Table level
  EXECUTE                         - Package/plan level
  BINDADD, CREATETAB, CREATEIN   - Administrative
  SYSADM, DBADM, SQLADM          - Authority levels

SMF RECORD TYPES FOR SECURITY:
  Type 80  - RACF security events
  Type 30  - Job/step resource usage
  Type 83  - RACF data set access

      * SECURE DATA HANDLING IN COBOL
       01  WS-CREDIT-CARD    PIC X(16).
       01  WS-MASKED-CARD    PIC X(16).

      * AFTER PROCESSING, CLEAR SENSITIVE DATA
           MOVE SPACES TO WS-CREDIT-CARD.

      * MASK CARD NUMBER FOR DISPLAY/LOGGING
           STRING '************' DELIMITED SIZE
                  WS-CREDIT-CARD(13:4) DELIMITED SIZE
                  INTO WS-MASKED-CARD.

      * CICS: CHECK CURRENT USER IDENTITY
           EXEC CICS ASSIGN
                USERID(WS-CURRENT-USER)
           END-EXEC.

What's Next

Chapter 32 turns to performance tuning -- the art and science of making COBOL programs run faster and use fewer resources. You will learn about compiler options that affect performance, I/O optimization strategies, DB2 and CICS tuning techniques, memory layout considerations, and batch optimization approaches. Performance tuning brings together knowledge from every previous chapter, as optimization requires understanding the program's interaction with the operating system, database, transaction manager, and storage subsystem.