"Everybody wants to add security at the end. Then they discover that 'the end' is six months of rework because the data model has no audit columns, the CICS transactions have no surrogate user design, and the batch jobs run under a generic userid that can read every dataset on the LPAR. Security is not a coat of paint. It's the foundation." — Kwame Mensah, Chief Architect, Continental National Bank

Chapter Overview

At 3:22 PM on a Thursday in October 2022, a PCI-DSS auditor sat down in the CNB conference room, opened his laptop, and asked Kwame Mensah a question that would consume the next four months of his life: "Show me how you prevent a CICS application programmer from reading cardholder data outside their authorized transaction flow."

Kwame had a good answer. CNB's security architecture was sound — RACF profiles on datasets, DB2 column-level access controls, CICS transaction security, MQ channel authentication. But "good" and "auditor-ready" are different things. The auditor wanted documentation. Traceability. Evidence that every control was tested, that every exception was logged, that the audit trail was tamper-proof. Four months later, CNB passed the audit — but Kwame swore he would never again treat security documentation as something you produce after the architecture is built.

That experience informs this entire chapter. We are going to cover z/OS security from the ground up: RACF internals, encryption mechanisms, secure COBOL coding patterns, and compliance mapping for PCI-DSS and HIPAA. But the real lesson is the threshold concept for this chapter: security is an architecture decision, not a bolt-on. Once you internalize that — once you understand that security permeates every layer from the network edge to the DB2 column to the COBOL MOVE statement — you stop treating it as an afterthought and start designing it in from day one.

What you will learn in this chapter:

1. Why mainframe security is architecturally different from distributed security — and why that difference matters for compliance
2. How to design RACF profiles for datasets, DB2 objects, CICS resources, and MQ queues
3. How z/OS encryption works at the hardware, software, and network layers
4. How to write COBOL code that resists SQL injection, prevents buffer overflows, and maintains audit trails
5. How to map PCI-DSS's 12 requirements and HIPAA's security rule to specific z/OS controls
6. How to design the complete security architecture for the HA banking progressive project

Learning Path Annotations:

• :runner: Fast Track: If you're already RACF-proficient, skim Section 28.2 and focus on Sections 28.4 (secure COBOL coding) and 28.5-28.6 (compliance mapping). The compliance sections are where architects separate from system programmers.
• :microscope: Deep Dive: If you're new to z/OS security, read every section sequentially. Section 28.1 establishes the mental model; Section 28.2 gives you the hands-on RACF knowledge; everything else builds on those foundations.

Spaced Review — Connecting to Prior Chapters:

:link: From Chapter 4 (Dataset Management): You learned that SMS classes control dataset placement and performance characteristics. In this chapter, you'll see how RACF dataset profiles add the security layer — who can read, write, alter, and delete those datasets. The SMS STORCLAS determines where the data lives; the RACF profile determines who touches it.

:link: From Chapter 16 (CICS Security): You implemented CICS transaction-level and resource-level security using RACF and the CICS security domains. This chapter extends that foundation to the entire application stack — datasets behind the CICS programs, DB2 tables those programs access, MQ queues those programs write to. Chapter 16 gave you the CICS layer; this chapter gives you every other layer.

:link: From Chapter 19 (IBM MQ): You configured MQ queue managers and channel authentication records. This chapter deepens that into MQ security profiles — RESLEVEL, MQQUEUE, MQPROC resource classes — and shows how MQ security integrates with the broader RACF architecture.

28.1 The Security Landscape: Why Mainframe Security Is Different — and Better

Let me say something that will annoy your distributed-systems colleagues: z/OS is the most secure general-purpose computing platform ever built. That is not marketing. It is an architectural fact rooted in hardware design decisions made in the 1970s that have been continuously refined for fifty years.

Here is why.

28.1.1 Hardware-Enforced Isolation

Every address space on z/OS runs in its own hardware-protected memory region. The System/370 architecture — and its z/Architecture successor — enforces address space isolation through the Dynamic Address Translation (DAT) hardware. A program in address space A literally cannot reference memory in address space B. Not through pointer arithmetic. Not through buffer overflows. Not through any clever trick. The hardware page tables are different, and there is no user-mode instruction that can alter them.

Compare this to Linux or Windows, where a kernel vulnerability can give an attacker access to any process's memory. On z/OS, even a kernel vulnerability in one address space doesn't compromise another, because the isolation boundary is in the hardware, not the software.

:bulb: Key Insight: This is why mainframe security certifications (Common Criteria EAL5+) exceed what any distributed platform has achieved. The security boundary is not a software abstraction — it is a hardware gate.

28.1.2 The System Authorization Facility (SAF)

SAF is the z/OS security router. Every security decision on z/OS — every dataset open, every CICS transaction attach, every DB2 object access, every MQ queue operation — goes through SAF. SAF routes the request to the installed External Security Manager (ESM), which in most shops is RACF (Resource Access Control Facility). ACF2 and Top Secret are the alternatives, but RACF holds roughly 90% market share, so this chapter focuses on RACF.

The critical architectural point: SAF is pervasive. It is not optional. It is not something you enable. Every z/OS subsystem calls SAF before granting access to any protected resource. There is one security checkpoint that everything passes through — not a patchwork of application-level security modules that might or might not be configured correctly.

USER REQUEST                     SAF                    RACF
    |                             |                       |
    +--- OPEN dataset ----------->+--- Route to ESM ----->+--- Check profile
    +--- EXEC CICS transaction -->+--- Route to ESM ----->+--- Check profile
    +--- EXEC SQL SELECT -------->+--- Route to ESM ----->+--- Check profile
    +--- MQOPEN queue ----------->+--- Route to ESM ----->+--- Check profile
    |                             |                       |
    |                     (single checkpoint)      (single database)

28.1.3 The Security Posture Hierarchy

z/OS security operates on a layered model. Each layer adds controls, and an attacker must defeat every layer to access protected data:

At CNB, Kwame calls this the "seven gates." An attacker who gets past the network still faces system authentication. Past system authentication, they face dataset profiles. Past dataset profiles, they face DB2 authorization. And so on. Each gate is independently configured, independently audited, and independently logged.

:warning: Common Pitfall: Many shops configure the outer gates (network, system) and neglect the inner gates (DB2, application). This creates a "hard shell, soft center" — if an insider or a compromised application bypasses the outer layers, there is nothing stopping them from accessing any data. Defense in depth means every gate is locked.

28.1.4 Auditing: SMF and the Immutable Record

z/OS generates System Management Facilities (SMF) records for virtually every security-relevant event. RACF produces SMF type 80 records for every access decision — both successful and failed. These records include the userid, the resource, the access level requested, the access level granted or denied, the timestamp, and the job or transaction name.

SMF records are written to SMF datasets that are protected by RACF. You cannot delete or modify them without a separate audit trail recording that deletion or modification. This creates an immutable audit chain that satisfies even the most demanding compliance frameworks.

At Federal Benefits Administration, Sandra Chen's team processes over 2 million SMF type 80 records per day. They feed these into a SIEM (Security Information and Event Management) system that correlates security events across all four LPARs. When an auditor asks "Who accessed Sandra's personal benefits record in the last 90 days?" — the answer takes fifteen seconds.

28.2 RACF Deep Dive: Profiles, Classes, Groups, and Access Control

RACF is the security database. Everything in z/OS security ultimately resolves to a RACF profile that says "this user (or group) has this level of access to this resource." Understanding how profiles work is non-negotiable for any COBOL architect.

28.2.1 User and Group Architecture

RACF organizes security principals into users and groups. A user represents a person or a started task (batch job, CICS region, DB2 address space). A group represents a collection of users with a common security need.

Production group hierarchy at CNB:

SYS1                          (system-level group, no human members)
  +-- CNBPROD                 (all production userids)
  |     +-- CNBATCH           (batch started task userids)
  |     +-- CNBCICS           (CICS region userids)
  |     +-- CNBDB2            (DB2 started task userids)
  |     +-- CNBMQ             (MQ queue manager userids)
  |     +-- CNBOPER           (operations staff)
  |     +-- CNBDBA            (database administrators)
  +-- CNBDEV                  (development userids)
  |     +-- CNBDEVL           (developers — limited access)
  |     +-- CNBTST            (test region userids)
  +-- CNBSEC                  (security administration)
  +-- CNBAUD                  (auditors — read-only access)

:bulb: Key Insight: Notice that batch started tasks, CICS regions, and DB2 address spaces have their own userids in their own groups. They are not running under a generic "PROD" userid. This is fundamental to least-privilege design — the CICS region userid has different authorities than the batch userid, which has different authorities than the DB2 started task userid.

28.2.2 Dataset Profiles

Dataset profiles control access to z/OS datasets (files). There are two types:

Discrete profiles protect a single, specific dataset:

ADDSD 'CNB.PROD.ACCTMSTR' UACC(NONE) AUDIT(ALL(READ))
PERMIT 'CNB.PROD.ACCTMSTR' ID(CNBATCH) ACCESS(UPDATE)
PERMIT 'CNB.PROD.ACCTMSTR' ID(CNBCICS) ACCESS(READ)
PERMIT 'CNB.PROD.ACCTMSTR' ID(CNBAUD) ACCESS(READ)

Generic profiles protect multiple datasets matching a pattern:

ADDSD 'CNB.PROD.**' UACC(NONE) AUDIT(ALL(READ))
PERMIT 'CNB.PROD.**' ID(CNBPROD) ACCESS(READ)

The UACC(NONE) is critical — it sets the Universal Access to NONE, meaning anyone not explicitly permitted has zero access. This is the default-deny posture that compliance frameworks require.

RACF profile matching rules (in order of specificity): 1. Discrete profile (exact dataset name match) 2. Generic profile with most specific qualifier match 3. Generic profile with ** (double asterisk, matches any number of qualifiers) 4. If no profile matches: the PROTECTALL setting determines whether access is granted or denied

:red_circle: Production Rule: Always set SETROPTS PROTECTALL(FAILURES). This means that any dataset without a RACF profile is denied access. The alternative — PROTECTALL(NONE) — means unprotected datasets are accessible to anyone. I have seen shops running PROTECTALL(NONE) in production. It is indefensible in any compliance audit.

28.2.3 General Resource Classes

RACF protects more than datasets. General resource classes extend RACF protection to any z/OS resource — CICS transactions, DB2 objects, MQ queues, console commands, system functions, and more.

Key general resource classes for COBOL architects:

Activating a resource class:

SETROPTS CLASSACT(TCICSTRN)
SETROPTS RACLIST(TCICSTRN)
SETROPTS GENERIC(TCICSTRN)

The RACLIST command loads profiles into memory for fast lookup. Without RACLIST, RACF reads the database for every security check — a performance disaster in a CICS environment doing thousands of transaction attaches per second.

:bar_chart: Performance Data: RACF in-storage profile lookup: ~2 microseconds. RACF database I/O lookup: ~2,000 microseconds. That is a 1,000x difference. Always RACLIST active resource classes.

28.2.4 DB2 Security Integration

DB2 security is a two-layer model. First, RACF controls whether a user can connect to the DB2 subsystem at all (DSNR class). Second, DB2's own authorization mechanism (GRANT/REVOKE) controls what the user can do once connected.

Layer 1 — RACF connection control:

RDEFINE DSNR DB2P.BATCH UACC(NONE)
PERMIT DB2P.BATCH CLASS(DSNR) ID(CNBATCH) ACCESS(READ)

RDEFINE DSNR DB2P.CICS UACC(NONE)
PERMIT DB2P.CICS CLASS(DSNR) ID(CNBCICS) ACCESS(READ)

Layer 2 — DB2 authorization:

GRANT SELECT ON TABLE CNB.ACCOUNT_MASTER
  TO CNBCICS_AUTHID;

GRANT SELECT, UPDATE ON TABLE CNB.ACCOUNT_MASTER
  TO CNBATCH_AUTHID;

GRANT SELECT ON TABLE CNB.ACCOUNT_MASTER
  TO CNBAUD_AUTHID;

Notice the separation: the CICS region can SELECT (read) the account master, and batch can SELECT and UPDATE, and the auditors can only SELECT. This is least privilege at the DB2 level, on top of the RACF controls at the dataset level, on top of the CICS transaction security at the CICS level.

:link: Cross-Reference (Chapter 16): Recall from Chapter 16 that CICS supports surrogate user security — the CICS region userid (e.g., CNBCICS) connects to DB2, but the end user's userid is passed as the secondary authorization ID. This allows DB2 to enforce row-level or column-level security based on who the actual human user is, not just which CICS region they're connected through.

28.2.5 CICS Security Domains Revisited

Chapter 16 covered CICS security in detail. Here we revisit it in the context of the full security architecture.

CICS security operates across multiple domains, each controlled by its own RACF resource class:

CNB's CICS security for the fund transfer transaction (XFRT):

RDEFINE TCICSTRN XFRT UACC(NONE) AUDIT(ALL(READ))
PERMIT XFRT CLASS(TCICSTRN) ID(CNBTELLER) ACCESS(READ)
PERMIT XFRT CLASS(TCICSTRN) ID(CNBSUPRV)  ACCESS(READ)

RDEFINE FCICSFCT ACCTFILE UACC(NONE)
PERMIT ACCTFILE CLASS(FCICSFCT) ID(CNBCICS) ACCESS(UPDATE)

RDEFINE TCICSTRN CSMI UACC(NONE)
PERMIT CSMI CLASS(TCICSTRN) ID(CNBSYSADM) ACCESS(READ)

Only tellers and supervisors can initiate a fund transfer. The CICS region userid has UPDATE access to the account file. Only system administrators can use the CICS master terminal transaction.

28.2.6 MQ Security Profiles

MQ security is controlled through RACF resource classes that protect queues, channels, processes, and connection factories.

CNB's MQ security for the transfer request queue:

RDEFINE MQQUEUE CNBQM01.XFER.REQUEST.QUEUE UACC(NONE)
PERMIT CNBQM01.XFER.REQUEST.QUEUE CLASS(MQQUEUE)
  ID(CNBCICS) ACCESS(UPDATE)
PERMIT CNBQM01.XFER.REQUEST.QUEUE CLASS(MQQUEUE)
  ID(CNBATCH) ACCESS(READ)

RDEFINE MQQUEUE CNBQM01.XFER.REPLY.QUEUE UACC(NONE)
PERMIT CNBQM01.XFER.REPLY.QUEUE CLASS(MQQUEUE)
  ID(CNBATCH) ACCESS(UPDATE)
PERMIT CNBQM01.XFER.REPLY.QUEUE CLASS(MQQUEUE)
  ID(CNBCICS) ACCESS(READ)

The CICS region can PUT to the request queue and GET from the reply queue. The batch process can GET from the request queue and PUT to the reply queue. Nobody else can touch either queue.

:bar_chart: RESLEVEL and MQ Security Checks: The RESLEVEL profile controls how many security checks MQ performs for a given userid. At RESLEVEL 0, MQ performs security checks at both the queue manager level and the queue level. At RESLEVEL 1, only one check. At RESLEVEL 2, no checks. Never set RESLEVEL above 0 for application userids. RESLEVEL 1 or 2 is acceptable only for the MQ queue manager started task itself.

28.3 Encryption on z/OS: ICSF, CPACF, and AT-TLS

Encryption on z/OS is not an aftermarket add-on. It is built into the hardware. Every IBM Z processor since the z14 (2017) includes the CP Assist for Cryptographic Functions (CPACF), which performs AES encryption at hardware speed with zero CPU overhead — it does not consume general-purpose CPU capacity.

Let me say that again because it matters: encryption on z/OS is free in terms of CPU cost. The cryptographic operations run on dedicated hardware coprocessors that are not measured for software licensing purposes. This eliminates the "encryption is too expensive" argument that plagues distributed environments.

28.3.1 The Cryptographic Architecture

z/OS provides cryptographic services through three layers:

+------------------------------------------+
|  Application Layer                        |
|  (COBOL CALL 'CSNBENC', DB2 encryption,  |
|   TLS handshakes, dataset encryption)     |
+------------------------------------------+
|  ICSF (Integrated Cryptographic           |
|  Service Facility)                        |
|  - Key management                         |
|  - Callable services API                  |
|  - PKCS#11 token services                 |
+------------------------------------------+
|  Hardware Layer                           |
|  - CPACF (on-chip, AES/SHA)              |
|  - Crypto Express adapters (RSA, ECC,     |
|    random number generation)              |
+------------------------------------------+

CPACF handles symmetric encryption (AES-128, AES-256) and hashing (SHA-256, SHA-512) on the main processor chip. It is always available — no additional hardware required.

Crypto Express adapters are optional PCI cards that handle asymmetric encryption (RSA, ECC), key generation, and true hardware random number generation. CNB has four Crypto Express7S adapters across their Sysplex — two per physical frame.

ICSF is the software layer that manages keys and provides callable services to applications. ICSF maintains the CKDS (Cryptographic Key Data Set), PKDS (Public Key Data Set), and TKDS (Token Key Data Set). These are RACF-protected datasets — access to encryption keys is itself a security-controlled resource.

28.3.2 Dataset Encryption (z/OS Data Set Encryption)

Starting with z/OS 2.3 (2017), z/OS supports transparent dataset encryption. When a dataset is in an encryption-enabled SMS storage class, all data written to the dataset is automatically encrypted. All data read from the dataset is automatically decrypted — if the requesting userid has RACF access to the encryption key label.

Setting up dataset encryption:

Step 1 — Define the encryption key in ICSF:

ICSF Key Label: CNB.ACCTMSTR.AES256
Algorithm: AES
Key Length: 256 bits
Status: Active

Step 2 — Create or update the SMS data class:

DATACLAS NAME(ENCRAES)
  DSNTYPE(...)
  KEYLABL1(CNB.ACCTMSTR.AES256)
  KEYLABL2(CNB.ACCTMSTR.AES256.BACKUP)

Step 3 — Protect the key label with RACF:

RDEFINE CSFKEYS CNB.ACCTMSTR.AES256 UACC(NONE)
PERMIT CNB.ACCTMSTR.AES256 CLASS(CSFKEYS) ID(CNBATCH) ACCESS(READ)
PERMIT CNB.ACCTMSTR.AES256 CLASS(CSFKEYS) ID(CNBCICS) ACCESS(READ)

Step 4 — Assign the data class to datasets:

//ACCTMSTR DD DSN=CNB.PROD.ACCTMSTR,
//            DISP=SHR,
//            DATACLAS=ENCRAES

Now here is the elegant part: the COBOL program does not change. The encryption is transparent — OPEN, READ, WRITE, CLOSE work exactly as before. The encryption and decryption happen at the I/O layer, below the access method. But access control to the encrypted data requires both the RACF dataset profile (can the user access the dataset?) and the RACF CSFKEYS profile (can the user use the encryption key?). Two gates, not one.

:bulb: Key Insight: Dataset encryption protects data at rest on the physical disk. If someone steals the disk pack (or the backup tape), the data is unreadable without the key. This is a PCI-DSS Requirement 3 control (protect stored cardholder data).

28.3.3 DB2 Column-Level Encryption

For databases, z/OS offers two encryption approaches:

Approach 1: Transparent tablespace encryption (DB2 12+). The entire tablespace is encrypted at the storage layer. Like dataset encryption, this is transparent to SQL — no application changes required.

Approach 2: Column-level encryption using DB2 built-in functions. Specific columns are encrypted and decrypted using ENCRYPT_AES and DECRYPT_AES functions:

-- Encrypting on INSERT
INSERT INTO CNB.CARDHOLDER
  (CUST_ID, CARD_NUMBER, CARD_EXPIRY, CARD_CVV)
VALUES
  (:WS-CUST-ID,
   ENCRYPT_AES(:WS-CARD-NUMBER, :WS-ENCRYPT-KEY),
   ENCRYPT_AES(:WS-CARD-EXPIRY, :WS-ENCRYPT-KEY),
   ENCRYPT_AES(:WS-CARD-CVV, :WS-ENCRYPT-KEY));

-- Decrypting on SELECT
SELECT CUST_ID,
       DECRYPT_AES(CARD_NUMBER, :WS-DECRYPT-KEY),
       DECRYPT_AES(CARD_EXPIRY, :WS-DECRYPT-KEY)
  FROM CNB.CARDHOLDER
 WHERE CUST_ID = :WS-CUST-ID;

Column-level encryption gives finer control — you encrypt only the sensitive columns (PAN, CVV, SSN, PHI) rather than the entire tablespace. The cost is that your COBOL program must call the encryption/decryption functions and manage the key reference.

:warning: Common Pitfall: Never embed the encryption key directly in your COBOL program as a literal. Use ICSF key labels and retrieve the key reference from a secured configuration dataset or CICS container at runtime. A hard-coded key in source code is a guaranteed audit finding.

28.3.4 Network Encryption: AT-TLS

Application Transparent Transport Layer Security (AT-TLS) provides TLS encryption at the z/OS TCP/IP stack level. Like dataset encryption, it is transparent to applications — the COBOL program sends and receives data normally, and the TCP/IP stack handles encryption and decryption.

AT-TLS policy configuration (in the Policy Agent):

TTLSRule              CICS_INBOUND
{
  LocalPortRange      8080
  Direction           Inbound
  TTLSGroupActionRef  CICS_GROUP
  TTLSEnvironmentActionRef CICS_ENV
}

TTLSEnvironmentAction CICS_ENV
{
  HandshakeRole       Server
  TTLSKeyringParmsRef CICS_KEYRING
  TTLSCipherParmsRef  TLS13_CIPHERS
}

TTLSCipherParms       TLS13_CIPHERS
{
  V3CipherSuites      TLS_AES_256_GCM_SHA384
  V3CipherSuites      TLS_CHACHA20_POLY1305_SHA256
}

TTLSKeyringParms      CICS_KEYRING
{
  Keyring             CNBCICS/CNBKeyring
}

This configuration ensures that all traffic to the CICS web services port (8080) is TLS 1.3 encrypted, using AES-256-GCM or ChaCha20 cipher suites. The COBOL program behind the CICS web service doesn't know or care that encryption is happening.

:link: Cross-Reference (Chapter 21): When you designed the z/OS Connect API layer in Chapter 21, the API gateway handled TLS termination. AT-TLS provides the same protection for direct CICS connections that bypass the API gateway — ensuring no unencrypted path exists to COBOL services.

28.3.5 Key Management

Encryption is only as strong as your key management. A 256-bit AES key is unbreakable — unless you store it in a dataset that a junior developer can read, or in a COBOL copybook checked into a source control system.

CNB's key management architecture:

Dual control for master keys: At CNB, changing the master key requires two security officers, each holding half the key, entering their portions in separate ceremonies. Neither person alone has enough information to reconstruct the key. This satisfies PCI-DSS Requirement 3.5 (protect keys used to encrypt cardholder data) and HIPAA's key management requirements.

28.4 Secure COBOL Coding: SQL Injection, Buffer Management, Audit Logging, and Data Masking

This section is where most COBOL developers will find the biggest gaps in their knowledge. The mainframe platform provides excellent infrastructure security (RACF, encryption, AT-TLS), but none of that protects against vulnerabilities in the application code itself. A COBOL program with a SQL injection vulnerability or a buffer overflow is a security hole regardless of how well-configured your RACF profiles are.

28.4.1 SQL Injection in COBOL

"SQL injection in COBOL? That's a web application problem." I hear this regularly from experienced mainframers. They are wrong.

SQL injection occurs whenever user-supplied input is concatenated into a SQL statement without validation. In COBOL, this happens primarily with dynamic SQL — and increasingly with CICS web service inputs.

Vulnerable code — dynamic SQL with concatenated input:

       MOVE SPACES TO WS-SQL-STMT
       STRING 'SELECT ACCT_BAL FROM CNB.ACCOUNTS'
              ' WHERE ACCT_NUM = '''
              WS-USER-INPUT
              ''''
              DELIMITED BY SIZE
              INTO WS-SQL-STMT
       END-STRING

       EXEC SQL
         PREPARE STMT1 FROM :WS-SQL-STMT
       END-EXEC

       EXEC SQL
         OPEN CSR1
       END-EXEC

If WS-USER-INPUT contains ' OR '1'='1, the resulting SQL becomes:

SELECT ACCT_BAL FROM CNB.ACCOUNTS
 WHERE ACCT_NUM = '' OR '1'='1'

That returns every account balance in the table.

Secure code — parameterized query:

       EXEC SQL
         SELECT ACCT_BAL
           INTO :WS-ACCT-BAL
           FROM CNB.ACCOUNTS
          WHERE ACCT_NUM = :WS-ACCT-NUM
       END-EXEC

The parameterized query (using host variables) never concatenates user input into SQL text. DB2 treats WS-ACCT-NUM as a value, not as SQL syntax. Injection is structurally impossible.

The rule is absolute: never construct dynamic SQL from user input using STRING or concatenation. Always use host variables.

If you genuinely need dynamic SQL (for ad-hoc reporting with variable WHERE clauses), use parameter markers:

       MOVE 'SELECT ACCT_BAL FROM CNB.ACCOUNTS'
            & ' WHERE ACCT_NUM = ?'
            TO WS-SQL-STMT

       EXEC SQL
         PREPARE STMT1 FROM :WS-SQL-STMT
       END-EXEC

       EXEC SQL
         EXECUTE STMT1 USING :WS-ACCT-NUM
       END-EXEC

The ? parameter marker tells DB2 to expect a bind variable — the user input is never parsed as SQL.

:red_circle: Production Rule: Every code review at CNB checks for STRING statements that feed into EXEC SQL PREPARE. Lisa Tran's DBA team has an automated scan that flags these patterns in the source code repository. If you are writing dynamic SQL that includes user input without parameter markers, you are writing a security vulnerability. Full stop.

28.4.2 Buffer Overflow Prevention

COBOL's fixed-length fields provide natural protection against many buffer overflow attacks. A PIC X(20) field cannot hold 21 characters — the MOVE statement truncates. But buffer overflows in COBOL do exist, and they create real security vulnerabilities.

Vulnerable pattern 1 — REFERENCE modification without bounds checking:

       MOVE WS-USER-OFFSET TO WS-OFFSET
       MOVE WS-BUFFER(WS-OFFSET:WS-LENGTH)
            TO WS-OUTPUT

If WS-OFFSET or WS-LENGTH exceeds the bounds of WS-BUFFER, the program reads memory beyond the buffer boundary. In a CICS environment where multiple tasks share the same storage, this can expose another user's data.

Secure pattern — validate before referencing:

       IF WS-USER-OFFSET < 1
          OR WS-USER-OFFSET > WS-BUFFER-MAX-LEN
          OR (WS-USER-OFFSET + WS-LENGTH - 1)
             > WS-BUFFER-MAX-LEN
          PERFORM 9100-SECURITY-VIOLATION
       ELSE
          MOVE WS-BUFFER(WS-USER-OFFSET:WS-LENGTH)
               TO WS-OUTPUT
       END-IF

Vulnerable pattern 2 — unbounded STRING/UNSTRING:

       UNSTRING WS-INPUT-MSG
          DELIMITED BY ','
          INTO WS-FIELD-1
               WS-FIELD-2
               WS-FIELD-3
       END-UNSTRING

If the input contains more delimiters than expected, the receiving fields may be improperly populated. More critically, if the input fields are longer than the receiving fields, truncation occurs silently — potentially corrupting data.

Secure pattern — use OVERFLOW and COUNT:

       UNSTRING WS-INPUT-MSG
          DELIMITED BY ','
          INTO WS-FIELD-1 COUNT IN WS-CNT-1
               WS-FIELD-2 COUNT IN WS-CNT-2
               WS-FIELD-3 COUNT IN WS-CNT-3
          ON OVERFLOW
             PERFORM 9100-SECURITY-VIOLATION
       END-UNSTRING

       IF WS-CNT-1 > WS-FIELD-1-MAX-LEN
          OR WS-CNT-2 > WS-FIELD-2-MAX-LEN
          PERFORM 9100-SECURITY-VIOLATION
       END-IF

28.4.3 Audit Logging from COBOL

Infrastructure-level auditing (SMF type 80 records) captures security decisions — who was allowed or denied access to a resource. Application-level auditing captures security-relevant actions — who transferred $50,000 between accounts, who viewed a patient's medical record, who changed a benefits calculation parameter.

Both are necessary. Infrastructure auditing without application auditing tells you who accessed the CICS transaction but not what they did with it.

CNB's audit logging pattern for the fund transfer program:

       01  WS-AUDIT-RECORD.
           05  WS-AUD-TIMESTAMP    PIC X(26).
           05  WS-AUD-USERID       PIC X(08).
           05  WS-AUD-TERMINAL     PIC X(04).
           05  WS-AUD-TRANID       PIC X(04).
           05  WS-AUD-ACTION       PIC X(20).
           05  WS-AUD-FROM-ACCT    PIC X(12).
           05  WS-AUD-TO-ACCT      PIC X(12).
           05  WS-AUD-AMOUNT       PIC S9(13)V99 COMP-3.
           05  WS-AUD-RESULT       PIC X(10).
           05  WS-AUD-REASON       PIC X(50).

       PERFORM 8000-WRITE-AUDIT-LOG

       8000-WRITE-AUDIT-LOG.
           EXEC CICS ASKTIME
                ABSTIME(WS-ABSTIME)
           END-EXEC
           EXEC CICS FORMATTIME
                ABSTIME(WS-ABSTIME)
                YYYYMMDD(WS-AUD-DATE-PART)
                TIME(WS-AUD-TIME-PART)
                TIMESEP(':')
           END-EXEC
           EXEC CICS ASSIGN
                USERID(WS-AUD-USERID)
                FACILITY(WS-AUD-TERMINAL)
           END-EXEC
           MOVE 'XFRT' TO WS-AUD-TRANID

           EXEC CICS WRITEQ TD
                QUEUE('AUDL')
                FROM(WS-AUDIT-RECORD)
                LENGTH(LENGTH OF WS-AUDIT-RECORD)
           END-EXEC
           .

The audit record captures the who (userid), what (action, accounts, amount), when (timestamp), where (terminal, transaction), and outcome (result, reason). This record is written to a CICS transient data queue that is backed by a RACF-protected dataset.

:bulb: Key Insight: Write the audit record before the business action, then update the result field after the action completes. If the program abends after the action but before the audit write, you lose the audit trail. If it abends after the audit write but before the action, you have a "started but not completed" record — which is detectable and recoverable.

28.4.4 Data Masking in COBOL

Data masking replaces sensitive data with obfuscated values for users who need to see that data exists but don't need to see what the data is. Classic example: a customer service representative sees account number ****-****-1234 rather than the full PAN.

Masking patterns for common data types:

       01  WS-MASK-ROUTINES.
           05  WS-FULL-PAN         PIC X(16).
           05  WS-MASKED-PAN       PIC X(16).
           05  WS-FULL-SSN         PIC X(09).
           05  WS-MASKED-SSN       PIC X(11).

       8100-MASK-PAN.
      * PCI-DSS: Display only last 4 digits
           MOVE ALL '*'          TO WS-MASKED-PAN
           MOVE WS-FULL-PAN(13:4)
                                 TO WS-MASKED-PAN(13:4)
           .

       8200-MASK-SSN.
      * Display only last 4 digits, formatted
           STRING '***-**-'
                  WS-FULL-SSN(6:4)
                  DELIMITED BY SIZE
                  INTO WS-MASKED-SSN
           END-STRING
           .

When to mask: The masking decision must be based on the user's authorization level, not the program's authorization level. In a CICS environment, use EXEC CICS ASSIGN USERID to get the signed-on user, then check their RACF group membership to determine the masking level.

       8300-CHECK-MASK-LEVEL.
           EXEC CICS QUERY SECURITY
                RESTYPE('FACILITY')
                RESID('CNB.PAN.FULLVIEW')
                LOGMESSAGE(NOLOG)
                RESIDLENGTH(20)
           END-EXEC

           EVALUATE EIBRESP
             WHEN DFHRESP(NORMAL)
                SET WS-FULL-VIEW TO TRUE
             WHEN DFHRESP(NOTAUTH)
                SET WS-MASKED-VIEW TO TRUE
             WHEN OTHER
                SET WS-MASKED-VIEW TO TRUE
           END-EVALUATE
           .

This checks whether the current CICS user has access to the CNB.PAN.FULLVIEW FACILITY resource. If authorized, show the full PAN. If not, mask it. The security decision is externalized to RACF — the COBOL program doesn't hard-code user lists.

:scales: Architectural Decision: Masking in the application layer (COBOL) vs. masking in the database layer (DB2 column masks) vs. masking in the presentation layer (3270 BMS map or JSON transformation). CNB uses application-layer masking for CICS programs and DB2 column masks for direct SQL tools (SPUFI, QMF). The principle: mask at the earliest point where you know the consumer's authorization level.

28.5 PCI-DSS Compliance: Twelve Requirements Mapped to z/OS Controls

The Payment Card Industry Data Security Standard (PCI-DSS) version 4.0 defines twelve requirements for protecting cardholder data. Every organization that stores, processes, or transmits credit card data must comply. CNB processes 500 million transactions per day — PCI-DSS compliance is existential for them.

Here is how each requirement maps to z/OS controls. This is the table that Kwame built for the PCI-DSS auditor, and it passed the audit.

Requirement 1: Install and Maintain Network Security Controls

z/OS Implementation: - z/OS Communications Server IP packet filtering (IPSec policies) - VLAN segmentation isolating the Cardholder Data Environment (CDE) LPARs - AT-TLS for all inbound connections to the CDE - z/OS Intrusion Detection Services (IDS) for network anomaly detection

RACF Controls:

RDEFINE SERVAUTH EZB.STACKACCESS.*.*.TCPIP UACC(NONE)
PERMIT EZB.STACKACCESS.*.*.TCPIP CLASS(SERVAUTH)
  ID(CNBCICS) ACCESS(READ)

This restricts which address spaces can even access the TCP/IP stack — a control that has no equivalent on distributed platforms.

Requirement 2: Apply Secure Configurations to All System Components

z/OS Implementation: - System PARMLIB members reviewed and hardened (IEASYSxx, SMFPRMxx, COMMNDxx) - Default userids disabled or password-changed (IBMUSER removed from production) - Unnecessary subsystems not started - Health Check utility (HZSPROC) validates security settings continuously

Requirement 3: Protect Stored Account Data

z/OS Implementation: - z/OS dataset encryption (AES-256) for all datasets containing cardholder data - DB2 column-level encryption for PAN and CVV columns - RACF CSFKEYS profiles controlling key access - Key rotation on quarterly schedule - Dual control for master key management

:test_tube: CNB Implementation Detail: CNB encrypts the entire tablespace containing cardholder data and applies column-level encryption to the PAN column. This is belt-and-suspenders — if someone somehow decrypts the tablespace (perhaps by stealing the backup tape and the tablespace key), the PAN column is still encrypted with a different key. Kwame's philosophy: "One lock is a control. Two locks is defense in depth."

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission

z/OS Implementation: - AT-TLS (TLS 1.3) for all network connections to/from the CDE - MQ channel encryption (SSL/TLS) for inter-system message transfer - z/OS Connect TLS termination for API traffic - No unencrypted paths to cardholder data

Requirement 5: Protect All Systems and Networks from Malicious Software

z/OS Implementation: - z/OS is inherently resistant to commodity malware (no Windows/Linux malware runs on z/Architecture) - IBM Z Multi-Factor Authentication prevents credential theft - Program-controlled libraries (RACF PROGRAM class) prevent unauthorized program execution - APF authorization controls which programs can execute privileged instructions

:bulb: Key Insight: This is one area where mainframes have a structural advantage. The z/Architecture instruction set is incompatible with x86/ARM malware. There is no known malware that targets z/OS from the outside. The threat model is insider threat, misconfiguration, and application vulnerabilities — which is why Sections 28.4 and 28.6 matter.

Requirement 6: Develop and Maintain Secure Systems and Software

z/OS Implementation: - Secure COBOL coding standards (Section 28.4) - Code review procedures checking for SQL injection, buffer overflows, hard-coded credentials - Change management process (Chapter 36 covers CI/CD) with security review gates - Vulnerability scanning of z/OS Connect and CICS web services

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

z/OS Implementation: - RACF user/group architecture with least-privilege access (Section 28.2) - UACC(NONE) on all profiles (default-deny) - DB2 GRANT/REVOKE with column-level granularity - CICS transaction security limiting user access to authorized functions - Quarterly access recertification reviews

Requirement 8: Identify Users and Authenticate Access to System Components

z/OS Implementation: - RACF user authentication (password or passphrase) - PassTicket for application-to-application authentication (eliminates stored passwords) - Digital certificate authentication for TLS client certificates - IBM Z Multi-Factor Authentication (MFA) for privileged access - RACF password rules (minimum length 8, complexity requirements, 90-day expiry, 24-generation history)

SETROPTS PASSWORD(RULE1(LENGTH(8:64)
  CONTENT(ALPHANUM,SPECIALCHAR)))
SETROPTS PASSWORD(INTERVAL(90) HISTORY(24))

Requirement 9: Restrict Physical Access to Cardholder Data

z/OS Implementation: - Physical data center security (badges, biometrics, cameras) — infrastructure, not z/OS-specific - z/OS Tape Encryption (encrypts all tape data written by DFSMSdss and DFSMShsm) — protects offsite tape storage - RACF protection of tape volumes and tape datasets

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

z/OS Implementation: - SMF type 80 (RACF access decisions) for every resource access - SMF type 102 (DB2 accounting) for every DB2 connection - SMF type 110 (CICS transaction data) for every CICS transaction - Application-level audit logging (Section 28.4.3) - SIEM integration via SMF-to-syslog forwarding - Real-time alerting on failed access attempts exceeding threshold

:bar_chart: CNB's Monitoring Thresholds: - 5 failed RACF authentications in 10 minutes from same userid: auto-revoke + alert - 3 failed RACF authentications in 10 minutes from same IP: IP block + alert - Any access to PAN data outside the authorized transaction flow: immediate alert to security team

Requirement 11: Test Security of Systems and Networks Regularly

z/OS Implementation: - z/OS Health Check utility (continuous configuration validation) - RACF IRRDBU00 unload for offline security database analysis - Penetration testing of CICS web services and z/OS Connect APIs - Annual security configuration review by external auditor

Requirement 12: Support Information Security with Organizational Policies and Programs

z/OS Implementation: - Documented security policies and procedures - Incident response plan (Section 28.7) - Security awareness training for mainframe staff - Vendor management (IBM support access controls)

:scales: The Compliance Map: The table above is not academic. At CNB, each PCI-DSS requirement has an owner, an implementation document, a test procedure, and evidence of the last successful test. This "compliance map" is a living document maintained in a RACF-protected dataset. The auditor reviews it annually. Build yours now, not during audit prep.

28.6 HIPAA Compliance: PHI Protection, Access Controls, and Audit Requirements

The Health Insurance Portability and Accountability Act (HIPAA) Security Rule establishes national standards for protecting electronic Protected Health Information (ePHI). Pinnacle Health Insurance processes 50 million claims per month — every one of them containing ePHI.

Diane Okoye, Pinnacle's systems architect, came from the distributed world. "In my Java/Spring days, HIPAA compliance was a checklist we handed to the security team after development. When I got to the mainframe, Ahmad Rashidi sat me down and said, 'On this platform, security is the first design conversation, not the last.'" Ahmad Rashidi, Pinnacle's compliance-turned-technical lead, reviews every design document before it reaches Diane's architecture review board.

28.6.1 HIPAA Security Rule — Administrative Safeguards on z/OS

28.6.2 HIPAA Security Rule — Technical Safeguards on z/OS

Access Control (164.312(a)): - RACF user authentication (unique user identification) - RACF session management (automatic logoff after inactivity) - Dataset encryption + DB2 encryption (encryption and decryption of ePHI)

Audit Controls (164.312(b)): - SMF type 80 (RACF decisions) - SMF type 102 (DB2 access) - SMF type 110 (CICS transactions) - Application audit logs for PHI access events - 6-year retention of audit records (HIPAA minimum)

SETROPTS AUDIT(FAILURES(READ))    /* Log all failed access */
SETROPTS AUDIT(ALL(READ))          /* For PHI datasets: log all access */

:warning: Common Pitfall: HIPAA requires logging all access to ePHI, not just failed access. Many shops configure RACF to audit only failures. For datasets and DB2 tables containing ePHI, you must audit successful access too. This generates significant SMF volume — budget for it.

Integrity Controls (164.312(c)): - RACF dataset profiles preventing unauthorized modification - DB2 referential integrity and check constraints - Application-level validation in COBOL programs

Transmission Security (164.312(e)): - AT-TLS for all ePHI in transit - MQ channel encryption for inter-system ePHI transfers - VPN or dedicated circuits for ePHI transmission to external partners

28.6.3 Pinnacle's PHI Access Control Model

Ahmad Rashidi designed Pinnacle's PHI access control model around the "minimum necessary" standard — HIPAA's requirement that access to ePHI be limited to the minimum amount necessary to accomplish the intended purpose.

Implementation in RACF + DB2:

-- DB2 column-level grants: claims adjusters see claim data
-- but NOT diagnosis codes or treatment details
GRANT SELECT(CLAIM_ID, MEMBER_ID, PROVIDER_ID,
             CLAIM_DATE, BILLED_AMT, ALLOWED_AMT,
             PAID_AMT, CLAIM_STATUS)
  ON TABLE PINNACLE.CLAIMS
  TO ROLE PIN_ADJUSTER;

-- Clinical reviewers see diagnosis and treatment
-- but NOT payment details
GRANT SELECT(CLAIM_ID, MEMBER_ID, PROVIDER_ID,
             CLAIM_DATE, DIAGNOSIS_CD, PROCEDURE_CD,
             TREATMENT_NOTES)
  ON TABLE PINNACLE.CLAIMS
  TO ROLE PIN_CLINICAL;

-- No one except the audit role sees ALL columns
GRANT SELECT ON TABLE PINNACLE.CLAIMS
  TO ROLE PIN_AUDIT;

This is the minimum necessary standard implemented at the database level. The claims adjuster needs payment information but not clinical details. The clinical reviewer needs medical information but not payment details. Only the auditor needs to see everything.

:bulb: Key Insight: Ahmad maps every job function to a DB2 role with column-specific grants. When an auditor asks "Who can see a patient's diagnosis code?", the answer is a simple SQL query against the DB2 catalog: SELECT * FROM SYSIBM.SYSCOLAUTH WHERE TNAME = 'CLAIMS' AND COLNAME = 'DIAGNOSIS_CD'. Thirty seconds, definitive answer, auditor satisfied.

28.6.4 The Breach Notification Clock

HIPAA requires notification within 60 days of discovering a breach of unsecured ePHI. "Unsecured" means unencrypted. If the ePHI is encrypted and the encryption key was not compromised, it is not a "breach" under HIPAA's Safe Harbor provision.

This is why Pinnacle encrypts all ePHI at rest (dataset encryption) and in transit (AT-TLS): it converts a potential "breach requiring notification" into a "security incident that doesn't trigger the 60-day clock." The encryption doesn't prevent the incident — but it removes the regulatory notification obligation.

Diane puts it bluntly: "Dataset encryption costs us zero CPU and saves us the existential risk of a breach notification. It's the highest-ROI security control we've ever implemented."

28.7 Security Monitoring and Incident Response

Security controls without monitoring are security theater. If nobody is watching the logs, the controls exist but the response doesn't. This section covers the monitoring and incident response framework that makes the controls in Sections 28.2 through 28.6 operationally effective.

28.7.1 Real-Time Security Monitoring

z/OS generates a firehose of security data. The challenge is not collection — it's filtering signal from noise.

The monitoring pyramid:

                    /\
                   /  \  Tier 1: Immediate Response
                  / 3-5 \  (credential theft, unauthorized
                 /  alerts \  admin access, data exfiltration)
                /____per____\
               /    day      \
              /                \
             /   Tier 2: Same-  \
            /    Day Review       \
           /   50-100 events/day   \
          /  (failed logins, access  \
         /   anomalies, config changes)\
        /________________________________\
       /    Tier 3: Weekly/Monthly Review   \
      /   10,000+ events/day                  \
     /  (normal access patterns, successful      \
    /   authentications, routine operations)        \
   /____________________________________________________\

Tier 1 alerts at CNB (immediate pager notification): - RACF userid with SPECIAL or OPERATIONS attribute added outside change window - 10+ failed authentications from any single userid in 5 minutes - Access to the RACF database datasets (SYS1.RACF*) by non-RACF address spaces - Attempt to execute an APF-authorized program from a non-APF library - SMF recording stopped or SMF dataset switched outside scheduled window

Tier 2 events (security analyst reviews within 8 hours): - New RACF PERMIT commands granting access to production datasets - CICS transaction security violation (NOTAUTH) for sensitive transactions - DB2 authorization failure for ePHI or cardholder data tables - MQ channel connection from unrecognized IP address

28.7.2 SMF-Based Security Analytics

SMF type 80 records are the foundation of mainframe security analytics. Each record contains:

COBOL program to analyze SMF type 80 records for failed access to cardholder data:

This is a real pattern at CNB — a batch program that runs every hour, reads the SMF data, and generates alerts for suspicious patterns:

       01  WS-SMF80-RECORD.
           05  SMF80-LEN          PIC S9(04) COMP.
           05  SMF80-TYPE         PIC S9(04) COMP.
           05  SMF80-TIME         PIC S9(08) COMP.
           05  SMF80-DATE         PIC S9(08) COMP.
           05  SMF80-SID          PIC X(04).
           05  SMF80-UID          PIC X(08).
           05  SMF80-EVT          PIC S9(04) COMP.
           05  SMF80-QUAL         PIC S9(04) COMP.
           05  SMF80-RNM          PIC X(44).
           05  SMF80-CLS          PIC X(08).
           05  SMF80-ACC-INTENT   PIC X(01).
           05  SMF80-ACC-GRANTED  PIC X(01).

       PROCEDURE DIVISION.
           PERFORM 1000-PROCESS-SMF-RECORDS
              UNTIL WS-EOF = 'Y'
           PERFORM 2000-CHECK-THRESHOLDS
           STOP RUN.

       1000-PROCESS-SMF-RECORDS.
           READ SMF-INPUT INTO WS-SMF80-RECORD
             AT END SET WS-EOF TO TRUE
             NOT AT END
               IF SMF80-ACC-GRANTED = 'N'
                 AND SMF80-CLS = 'DATASET '
                 AND SMF80-RNM(1:12) = 'CNB.PROD.CHD'
                 PERFORM 1100-LOG-CHD-VIOLATION
               END-IF
           END-READ.

28.7.3 Incident Response Plan

Every mainframe shop needs a documented incident response plan. Here is the framework used at CNB, validated during their PCI-DSS audit:

Phase 1: Detection (0-15 minutes) - Security monitoring tool generates alert - On-call security analyst validates the alert (true positive vs. false positive) - If true positive: declare incident, assign severity level

Phase 2: Containment (15-60 minutes) - Severity 1 (active data exfiltration): RACF ALTUSER REVOKE the compromised userid immediately - Severity 2 (unauthorized access attempt): increase monitoring, do not revoke yet (preserve evidence) - Severity 3 (policy violation): document and investigate during business hours

Phase 3: Investigation (1-24 hours) - Collect SMF type 80 records for the affected period - Collect CICS journal records for affected transactions - Collect DB2 audit trace for affected tables - Reconstruct the sequence of events - Determine scope: what data was accessed or compromised?

Phase 4: Eradication (1-48 hours) - Remove the vulnerability that enabled the incident - Rotate any compromised credentials or keys - Apply patches or configuration changes - Verify through security scan

Phase 5: Recovery (1-72 hours) - Restore normal operations - Re-enable any revoked access (with corrected permissions) - Increase monitoring for 30 days post-incident

Phase 6: Lessons Learned (within 2 weeks) - Post-incident review with all stakeholders - Update security controls, monitoring rules, or procedures - Update the incident response plan itself

:red_circle: Production Rule: At CNB, the incident response plan is tested quarterly through tabletop exercises. Kwame runs the exercise himself: "At 2:47 AM, you receive an alert that userid CNBBAT07 has attempted ALTER access to the cardholder data tablespace. It's a Saturday. Walk me through your next 60 minutes." If the on-call analyst can't answer fluently, the team practices until they can.

28.7.4 Federal Security Requirements

At Federal Benefits Administration, Sandra Chen faces security requirements that go beyond PCI-DSS and HIPAA. Federal systems must comply with NIST SP 800-53 (Security and Privacy Controls for Information Systems), FISMA (Federal Information Security Modernization Act), and agency-specific directives.

The key differences from private-sector compliance:

Marcus Whitfield, the retiring legacy SME at FBA, has maintained RACF profiles for 15,000+ resources across a 40-year codebase. "Half the security profiles in this system protect resources that were retired in the 1990s," he says. "But removing an old profile is more dangerous than keeping it — you might remove protection from a resource that's still active under a different name. That's why I document everything."

Sandra's modernization effort includes a RACF profile cleanup project: mapping every active RACF profile to an active resource, retiring orphaned profiles, and documenting the business justification for every remaining profile. It is, she admits, "the least glamorous modernization project and the most important one."

28.8 Progressive Project: Security Architecture for the HA Banking System

It's time to design the complete security architecture for your HA Banking Transaction Processing System. This checkpoint builds on every prior checkpoint — the Sysplex topology (Chapter 1), the DB2 design (Chapter 6), the CICS topology (Chapter 13), the MQ design (Chapter 19), the batch architecture (Chapter 23), and the monitoring framework (Chapter 27).

Requirements Recap

Your system processes 100 million transactions per day across a multi-LPAR Sysplex. It handles: - Online fund transfers via CICS (PCI-DSS scope: cardholder data present) - Batch end-of-day settlement (PCI-DSS scope: cardholder data in batch files) - MQ-based integration with external payment networks (PCI-DSS scope: data in transit) - REST APIs via z/OS Connect for mobile banking (PCI-DSS scope: data in transit)

Security Architecture Components

Your deliverable for this checkpoint is a comprehensive security architecture document covering:

1. RACF user/group hierarchy — Define the complete group structure, user roles, and access levels
2. Dataset security — RACF profiles for all production datasets, with encryption designations
3. DB2 security — Connection control (DSNR), authorization model (GRANT/REVOKE), column-level encryption for sensitive data
4. CICS security — Transaction security, resource security, surrogate user model
5. MQ security — Queue profiles, channel authentication, RESLEVEL settings
6. Encryption architecture — Data at rest (datasets, DB2), data in transit (AT-TLS, MQ SSL), key management
7. PCI-DSS compliance map — All 12 requirements mapped to your specific controls
8. Monitoring and incident response — Alert thresholds, escalation procedures, SMF analysis plan

:microscope: Deep Dive Checkpoint: The project checkpoint file (code/project-checkpoint.md) provides the complete template. This is the most complex checkpoint in the book — it integrates security considerations from every prior chapter. Budget 3-4 hours for a thorough response.

Chapter Summary

Security on z/OS is not a feature you enable. It is an architecture you design.

This chapter took you through the complete mainframe security stack: from the hardware-enforced address space isolation that makes z/OS inherently more secure than any distributed platform, through RACF's comprehensive access control for datasets, DB2, CICS, and MQ resources, through encryption at the hardware, dataset, database, and network layers, through secure COBOL coding patterns that prevent the vulnerabilities your infrastructure can't catch, to the compliance frameworks (PCI-DSS and HIPAA) that validate your security architecture.

The threshold concept — security is an architecture decision, not a bolt-on — should now be concrete in your mind. Security decisions shape your data model (which columns are encrypted), your API design (which endpoints require MFA), your RACF group hierarchy (which users can access which resources), your batch architecture (which userids run which jobs), and your monitoring infrastructure (which events trigger which alerts). If you try to add these decisions after the system is built, you face months of rework. If you design them in from the beginning, they are a natural part of the architecture.

Kwame's four months of audit preparation were the direct result of a generation of architects who treated security as someone else's problem. The architects reading this chapter will not make that mistake.

What comes next: Chapter 29 (Capacity Planning) will show you how to forecast the MSU, storage, and transaction volume requirements for your HA banking system. Security and capacity planning intersect in encryption — dataset encryption has storage overhead, and SMF audit records consume I/O and storage. The capacity plan must account for the security architecture you designed in this chapter.

:link: Spaced Review Schedule: The threshold concept from this chapter — "Security is an architecture decision, not a bolt-on" — will be reviewed in Chapter 30 (Disaster Recovery, where security and recovery intersect), Chapter 33 (Strangler Fig Pattern, where security boundaries must be maintained during incremental modernization), and Chapter 37 (Hybrid Architecture, where security spans z/OS and cloud).

Next chapter: Chapter 29 — Capacity Planning and Performance Forecasting