Chapter 31: Exercises – COBOL and the z/OS Security Model

These exercises progress through five tiers of cognitive complexity. Detailed solutions are provided for exercises 1–3, and hints are given for exercises 4–5. All remaining exercises include only the problem statement so you can practice independently.

Tier 1 — Recall

Exercise 1: Security Product Identification

Problem: Match each z/OS security product with its vendor and a distinguishing characteristic.

Choose vendors from: IBM, Broadcom (formerly CA Technologies). Choose characteristics from: (A) Uses a rule-based access control model with rules stored in a flat structure, (B) IBM's native z/OS security facility using profiles in a hierarchical database, (C) Uses a top-down security model where access is denied by default and permissions are granted through facility-level security.

Exercise 2: RACF Access Levels

Problem: List the standard RACF access levels from lowest to highest and describe what each permits for a dataset resource.

Exercise 3: Dataset Security Profile Types

Problem: Explain the difference between a RACF discrete profile and a generic profile for dataset protection. Give an example of each and explain when you would use one over the other.

Exercise 4: CICS Security Components

Problem: Name the three primary resources that must be secured in a CICS environment and identify the RACF resource class used for each.

Exercise 5: Audit Trail Components

Problem: List the three types of records that RACF writes to the SMF (System Management Facilities) dataset for audit purposes, and explain what event each type captures.

Tier 2 — Understand

Exercise 6: Defense in Depth on z/OS

Explain the concept of "defense in depth" as it applies to z/OS security. Describe at least four distinct layers of security that a COBOL transaction must pass through when a CICS user retrieves a customer account record from a VSAM KSDS.

Exercise 7: RACF Groups and the Connect Command

A bank has the following departments that access COBOL applications: Retail Banking, Commercial Lending, Operations, and Audit. Explain how RACF groups should be structured to manage access to production datasets. Describe the role of the CONNECT command and the concept of a default group versus a connect group.

Exercise 8: Program Security and EXECUTE Authority

Explain how RACF's PROGRAM class can be used to control which users can execute which COBOL load modules. Why is program-level security important in a financial institution, and how does it complement dataset-level security?

Exercise 9: DB2 Security Integration with RACF

Describe how DB2 security works in conjunction with RACF. Explain the difference between DB2 internal authorization (GRANT/REVOKE) and external security (RACF). When a COBOL program executes an SQL SELECT statement, trace the security checks that occur.

Exercise 10: SOX Compliance Requirements for COBOL Applications

Explain how the Sarbanes-Oxley Act (SOX) Section 404 requirements affect COBOL application development and maintenance in a banking environment. Address:

1. Segregation of duties between developers and production support.
2. Change management controls for COBOL source code.
3. Access controls for production data.
4. Audit trail requirements.

Tier 3 — Apply

Exercise 11: Designing a RACF Security Scheme for a Banking Application

A new banking application called "LoanTrack" requires the following security setup:

Users and Roles: - Loan Officers (25 users) — read/update loan application data - Underwriters (10 users) — read loan data, update approval status - Managers (5 users) — read all data, run reports - System Administrators (3 users) — full access for maintenance

Resources to Protect: - VSAM datasets: BANK.PROD.LOANMSTR, BANK.PROD.LOANTRAN, BANK.PROD.LOANRPT - Batch programs: LOANUPD, LOANRPT, LOANPURG - CICS transactions: LKUP, LUPD, LRPT, LADM

Write all RACF commands to: 1. Create the necessary groups. 2. Connect users to appropriate groups. 3. Define dataset profiles with appropriate access levels. 4. Define program profiles. 5. Define CICS transaction profiles.

Exercise 12: Implementing Secure Coding Practices in COBOL

Rewrite the following insecure COBOL code to follow z/OS security best practices:

       PROCEDURE DIVISION.
           OPEN I-O ACCOUNT-MASTER.
           ACCEPT WS-ACCOUNT-NUM FROM CONSOLE.
           MOVE WS-ACCOUNT-NUM TO ACCT-KEY.
           READ ACCOUNT-MASTER
               INVALID KEY
                   DISPLAY "ACCOUNT NOT FOUND: " ACCT-KEY
               NOT INVALID KEY
                   DISPLAY "BALANCE: $" ACCT-BALANCE
                   DISPLAY "SSN: " ACCT-SSN
                   DISPLAY "ACCOUNT TYPE: " ACCT-TYPE
           END-READ.
           CLOSE ACCOUNT-MASTER.
           STOP RUN.

Address at least five security vulnerabilities in this code.

Exercise 13: Setting Up DB2 Security for COBOL Programs

A COBOL batch program ACCTUPD needs to: - SELECT from BANK.ACCOUNT_MASTER and BANK.TRANSACTION_LOG - UPDATE BANK.ACCOUNT_MASTER - INSERT into BANK.AUDIT_TRAIL

The program runs under batch user ID BATCHACT and a DB2 plan named ACCTPLAN. Write:

1. The DB2 GRANT statements needed.
2. The RACF commands to protect the DB2 plan.
3. The DBRM bind commands with security considerations.
4. The JCL to run the program with proper security context.

Exercise 14: PCI-DSS Compliance Implementation

A bank's credit card processing COBOL application must comply with PCI-DSS requirements. The application handles:

• Credit card numbers (PAN)
• Cardholder names
• Expiration dates
• CVV codes

Write COBOL code that implements the following PCI-DSS controls:

1. Mask the PAN when displaying to operators (show only last 4 digits).
2. Never store CVV data after authorization.
3. Log all access to cardholder data with timestamps and user IDs.
4. Encrypt sensitive fields before writing to the master file.

Provide the WORKING-STORAGE definitions and PROCEDURE DIVISION paragraphs.

Exercise 15: RACF Emergency Access Procedures

Design RACF commands and procedures for emergency access scenarios:

1. A critical batch job fails at 2 AM because the batch user ID's password has expired. Write the RACF commands to reset it and the safeguards to ensure the action is audited.
2. A security administrator's ID is revoked by mistake. Write the procedure to recover access.
3. A production dataset needs emergency access by a developer during a severity-1 incident. Write RACF commands that grant temporary access and automatically revoke it.

Exercise 16: Securing a CICS-DB2-COBOL Application Stack

A CICS online banking application allows customers to view account balances, transfer funds, and pay bills. Map out the complete security configuration:

1. CICS sign-on and user authentication setup.
2. Transaction-level security (which users can execute which transactions).
3. Program-level security within CICS.
4. DB2 authorization for the COBOL programs.
5. Dataset security for the underlying VSAM files.
6. Audit logging configuration for all financial transactions.

Write all RACF commands, CICS resource definitions, and DB2 GRANT statements.

Exercise 17: Secure File Transfer Configuration

A COBOL batch job produces a file of customer data that must be transmitted to a credit bureau. Design the security controls for this process:

1. RACF protection for the output dataset.
2. Encryption requirements for the file at rest and in transit.
3. A COBOL routine that validates the file's record count and hash total before release.
4. JCL that implements the secure transfer with Connect:Direct or FTP.
5. Audit trail entries documenting the transfer.

Write the COBOL validation code and the JCL for the secure transfer process.

Tier 4 — Analyze

Exercise 18: Security Breach Analysis

A bank's security team discovers that unauthorized balance adjustments were made to 15 customer accounts over the past week. The adjustments were made through the CICS transaction BADJ (Balance Adjustment), which calls COBOL program BALADJST. Analyze the situation:

1. What RACF/SMF records should be examined to identify who made the changes?
2. How can the DB2 audit tables be queried to trace the specific changes?
3. What security control failures allowed unauthorized access?
4. What RACF, CICS, and application-level changes should be implemented to prevent recurrence?
5. What regulatory reporting obligations does the bank have (SOX, PCI-DSS, banking regulators)?

Write sample RACF commands to pull the relevant audit data and SQL queries against the DB2 audit tables.

Exercise 19: Comparing Security Models — RACF vs. ACF2 vs. Top Secret

Your bank is considering migrating from ACF2 to RACF. Analyze the following aspects of the migration:

1. How do dataset protection models differ between ACF2 rules and RACF profiles?
2. What CICS security configuration changes are required?
3. How will the migration affect existing COBOL programs? Will source code changes be needed?
4. What are the risks of running both products in parallel during migration?
5. How should the migration be tested to ensure no security gaps?

Provide a comparison table and a migration checklist.

Exercise 20: Analyzing a RACF Security Report

Review the following RACF report extract and identify all security concerns:

DATASET PROFILE: BANK.PROD.**
  OWNER: SYSADM1
  UNIVERSAL ACCESS: READ
  WARNING MODE: ON
  AUDIT: NONE
  ACCESS LIST:
    BATCHGRP  - UPDATE
    DEVGROUP  - ALTER
    TESTUSER  - ALTER
    CICSRGN   - UPDATE
    AUDITORS  - READ

DATASET PROFILE: BANK.PROD.ACCTMSTR
  OWNER: BATCHUSR
  UNIVERSAL ACCESS: CONTROL
  WARNING MODE: OFF
  AUDIT: SUCCESS(UPDATE) FAILURES(READ)
  ACCESS LIST:
    (NONE DEFINED)

Identify at least seven security issues in these profiles and write the corrective RACF commands for each.

Exercise 21: Security Impact of Compiler Options

Analyze how the following COBOL compiler and link-edit options affect the security posture of a production COBOL program:

1. TEST (with debugging hooks) vs. NOTEST
2. LIST and MAP (producing assembly listings)
3. DYNAM (dynamic CALL) vs. NODYNAM (static CALL)
4. RENT (reentrant) vs. NORENT
5. Link-edit AC=1 (APF authorized) vs. AC=0

For each, explain the security risk and recommend the appropriate setting for production financial applications.

Exercise 22: Database Security Layering Analysis

A COBOL program accesses DB2 tables through the following chain:

User -> CICS -> COBOL Program -> DB2 Plan -> DB2 Package -> SQL -> Table

At each point in this chain, a security check can occur. Analyze:

1. Which security product (RACF, DB2, CICS) performs the check at each point?
2. What happens if security is properly configured at the table level but missing at the plan level?
3. How does the CICS user ID propagate to DB2 for authorization?
4. What is the risk of using a common CICS region user ID for all DB2 access instead of individual user IDs?

Exercise 23: Incident Response Procedure Analysis

A mainframe security incident has been detected: an authorized user appears to be exfiltrating customer data by running a COBOL program that writes account records to a personal dataset. Analyze the response:

1. What immediate containment actions should be taken?
2. What evidence must be preserved and how?
3. How should SMF records, RACF logs, and DB2 audit data be collected?
4. What chain-of-custody requirements apply to the evidence?
5. Write the RACF commands to immediately restrict the user's access without destroying audit evidence.

Tier 5 — Create

Exercise 24: Enterprise Security Architecture for a Banking COBOL System

Design a comprehensive security architecture for a bank's core COBOL processing environment that includes:

1. Authentication: RACF password policies, PassTicket configuration for batch jobs, digital certificate authentication for inter-system communication.
2. Authorization: A role-based access control model with RACF groups mapped to business roles across 10 departments.
3. Data Protection: Encryption strategy for sensitive data at rest (VSAM datasets) and in transit (MQ messages, file transfers).
4. Audit and Monitoring: SMF record collection, real-time alerting for security events, periodic access review procedures.
5. Compliance: Mapping of controls to SOX Section 404, PCI-DSS requirements, and banking regulations.

Write all RACF commands, COBOL security routines, JCL for audit processing, and compliance mapping documentation.

Exercise 25: Secure COBOL Coding Standards Manual

Create a secure coding standards document for COBOL developers at a financial institution. The document should cover:

1. Input validation standards (field-level checks, range validation, format validation).
2. Error handling standards (no sensitive data in error messages, proper file status checking).
3. Data protection standards (masking PII, handling encryption keys, secure file operations).
4. Logging standards (what to log, what never to log, log format, retention).
5. DB2 security standards (parameterized queries, minimum privilege, plan binding).
6. CICS security standards (transaction security, commarea protection, BMS map security).

For each standard, provide a "bad example" showing the security vulnerability, a "good example" showing the secure approach, and the COBOL code for both.

Exercise 26: Automated Security Compliance Monitoring System

Design and write a COBOL-based security compliance monitoring system that:

1. Reads RACF database extracts (IRRDBU00 unload records) to identify: - User IDs not used in 90 days (candidates for revocation) - Datasets with UACC greater than NONE - Users with excessive ALTER access - Groups with no members
2. Reads SMF Type 80 records to detect: - Repeated authentication failures (potential brute-force attacks) - After-hours access to sensitive datasets - Unusual data access patterns
3. Produces: - A compliance dashboard report - Exception reports for immediate action - Trend analysis showing security posture changes over time

Write the COBOL program, record layouts for RACF unload and SMF records, JCL to run the system, and DFSORT pre-processing steps.

Exercise 27: Zero-Trust Security Implementation for Mainframe COBOL

Design a zero-trust security model for a mainframe COBOL environment. Traditional mainframe security assumes trust within the network perimeter. A zero-trust model requires verification at every access point. Your design should address:

1. How to implement identity verification at every COBOL program entry point.
2. How to enforce least-privilege access for every DB2 query.
3. How to implement micro-segmentation for CICS regions.
4. How to validate data integrity between COBOL programs in a batch chain.
5. How to implement continuous monitoring and risk-based authentication.

Provide architectural diagrams (described textually), RACF configurations, COBOL security routines, and CICS configuration changes.

Exercise 28: Security Migration from Batch to API-Enabled COBOL

A bank is exposing its COBOL business logic through APIs (via z/OS Connect or CICS Web Services). Design the security model for this transition:

1. Map existing RACF batch security to API-level OAuth 2.0 tokens.
2. Implement API rate limiting and throttling using CICS policies.
3. Add input validation to COBOL programs to protect against injection attacks from API callers.
4. Configure mutual TLS for API communication.
5. Design an audit trail that correlates API calls with COBOL program execution.

Write the COBOL validation routines, CICS pipeline configuration, and RACF commands for the API security model.

Exercise 29: Disaster Recovery Security Considerations

Design the security aspects of a disaster recovery plan for a bank's COBOL processing environment:

1. How are RACF databases replicated to the DR site?
2. How are encryption keys managed across sites?
3. What security validations must pass before DR processing can begin?
4. How are temporary elevated access rights managed during a disaster?
5. How is the security posture restored when returning to the primary site?

Write the RACF commands for DR activation, the COBOL security validation program, and the JCL for the DR security initialization process.

Exercise 30: Multi-Factor Authentication Integration for COBOL Transactions

Design and implement a multi-factor authentication (MFA) system for high-value COBOL transactions in a banking environment:

1. Define threshold criteria for transactions requiring MFA (amount, account type, time of day).
2. Design the CICS transaction flow for MFA challenge/response.
3. Write the COBOL code that interfaces with an external MFA provider via a web service call.
4. Implement fallback procedures when the MFA service is unavailable.
5. Design the audit logging for MFA events.
6. Write RACF commands to enforce MFA requirements through RACF MFA policies.

Provide the complete COBOL program, CICS BMS maps for the MFA screens, and all configuration commands.