Chapter 16: CICS Security — RACF Integration, Transaction Security, Resource-Level Security, and Audit Compliance

Threshold Concept: Security is not a feature — it's an architecture layer. Once you understand that CICS security isn't bolted on via RACF profiles but is a fundamental architectural concern affecting region topology, transaction design, and data flow, everything about enterprise security design clicks.

Spaced Review

Before we dive in, let's reconnect with two critical foundations:

From Chapter 1 — z/OS Security Overview: You learned that z/OS security is built on the concept of an External Security Manager (ESM) — typically RACF, but potentially ACF2 or Top Secret. Every resource access decision passes through the ESM. The SAF (System Authorization Facility) router intercepts security calls and directs them to the ESM. This chapter builds directly on that architecture: CICS makes SAF calls, RACF evaluates them, and the result determines whether a user can execute a transaction, access a resource, or issue a command.

From Chapter 13 — CICS Topology and MRO: You designed multi-region architectures with Terminal-Owning Regions (TORs), Application-Owning Regions (AORs), and File-Owning Regions (FORs). Security doesn't just live in one region — it spans the entire topology. A user authenticated at the TOR must carry their security context through MRO links to AORs and FORs. The decisions you made about region topology in Chapter 13 now have direct security implications.

16.1 Security Architecture for CICS

Let me be direct: most CICS security problems I've seen in 25 years aren't technical failures. They're architectural failures. Someone bolted security onto a system that was designed without it, and the result was either a swiss-cheese security model full of bypass paths or a system so locked down that the help desk fielded 200 calls a day from users who couldn't do their jobs.

Security in CICS is an architecture layer. It sits between the user and every single resource the system manages. It affects how you design regions, how you route transactions, how you structure your application code, and how you prove to auditors that you've done all of the above correctly.

16.1.1 The CICS Security Model

CICS security operates through the External Security Manager (ESM) interface. When CICS needs to make a security decision, it issues a call through SAF to your ESM — which in this chapter we'll assume is RACF, since that's what 80% of the shops I've worked in use. The flow looks like this:

User Action → CICS Security Domain → SAF Router → RACF → Decision
                                                          ↓
                                                   PERMIT or DENY
                                                          ↓
                                              CICS enforces result

CICS security is controlled at several levels, each enabled independently:

1. Sign-on Security — authenticating users entering the CICS region
2. Transaction Security — controlling who can execute which transactions
3. Resource-Level Security — controlling who can access specific resources (files, queues, programs)
4. Command Security — controlling who can issue CICS system programming commands
5. Surrogate Security — controlling when one user can act on behalf of another

Each level is toggled through CICS System Initialization Table (SIT) parameters and backed by RACF class definitions. You don't get security by turning on one switch. You get security by designing all five levels to work together as a coherent architecture.

16.1.2 The Cost of Getting Security Wrong

Before we get into the technical details, let's be clear about what's at stake. I've been called in to three shops after security breaches in CICS systems. The pattern is always the same:

1. The system was designed in the 1990s or early 2000s when CICS was "internal only"
2. Web services were added later, connecting the "internal" system to the internet
3. Nobody redesigned the security architecture when the exposure model changed
4. An attacker (or more commonly, a curious insider) discovered that the AORs had no security
5. Data was exfiltrated through a path that nobody anticipated because nobody mapped the attack surface

The average cost of a mainframe data breach — according to IBM's own Cost of a Data Breach Report — is significantly higher than the average breach because mainframes tend to hold the most critical data: financial records, health information, government benefits, core banking. When a CICS system is compromised, the data that leaks is the data that matters most.

At SecureFirst Insurance, Carlos Rivera quantified it: "Our CICS system holds policy data for 2.3 million customers. At the regulatory fine rate of $150 per breached record for PII, our maximum exposure is $345 million. Our annual security budget for the mainframe is $1.2 million. That's the math that gets executive attention."

16.1.3 SIT Security Parameters

The SIT is where CICS security starts. These parameters determine what CICS even asks RACF about:

SEC=YES              * Enable external security
XTRAN=YES            * Enable transaction security
XRES=YES             * Enable resource-level security
XCMD=YES             * Enable command security
XUSER=YES            * Enable surrogate user checking
XPPT=YES             * Enable program security
XFCT=YES             * Enable file security
XTST=YES             * Enable TSQ security
XDCT=YES             * Enable TDQ security
XEJB=NO              * EJB security (if applicable)

💡 Practitioner Note: I've seen shops run SEC=YES and XTRAN=YES but leave everything else at NO, then wonder why their auditors flagged them. Transaction security without resource-level security means a user who can execute a transaction can access any file or queue that transaction touches. That's not security — that's a suggestion.

16.1.4 The Security Domain — DFHXS

CICS manages security through its security domain, controlled by the DFHXS program. DFHXS handles:

• Sign-on verification and password management
• Security token creation and propagation
• SAF calls for resource authorization
• Security caching for performance
• Audit event generation

When a user signs on, DFHXS creates a security token — an ACEE (Accessor Environment Element) — that travels with the user's task through the system. This ACEE is what RACF evaluates when making authorization decisions. In an MRO environment, this token must propagate across region boundaries, which is where things get architecturally interesting.

16.1.5 Security and Region Topology

Here's where Chapter 13 meets Chapter 16. Your MRO topology directly affects your security architecture:

TOR-AOR Model:

                    ┌─────────────────┐
  User ──────────→  │  TOR (SEC=YES)  │  ← Authentication happens here
                    │  XTRAN=YES      │  ← Transaction routing security
                    └────────┬────────┘
                             │ MRO Link (ACEE propagated)
                             ▼
                    ┌─────────────────┐
                    │  AOR (SEC=YES)  │  ← Attached user security
                    │  XRES=YES       │  ← Resource-level checks here
                    │  XCMD=YES       │  ← Command security here
                    └─────────────────┘

In this model, the TOR authenticates the user and checks transaction authority. The user's security context flows over the MRO link to the AOR, where resource-level security is enforced. This is the "security follows the user" pattern, and it's the correct approach for most shops.

The Anti-Pattern — Trusted AOR:

I've seen shops configure their AORs with SEC=NO because "the TOR already checked." This is catastrophic. If an attacker or misconfigured application gains access to the AOR directly — via a batch interface, a web service endpoint, or an internal MRO path — there's no security at all. Every AOR must have SEC=YES and appropriate XTRAN/XRES settings.

⚠️ Warning: Never assume that because a region is "internal" it doesn't need security. Internal regions are exactly where privilege escalation attacks succeed. The 2019 Capital One breach wasn't through the front door — it was through a misconfigured internal resource.

16.1.6 CNB's Security Architecture Decision

At City National Bank, Kwame Asante faced this exact decision when designing the new payment processing system. The existing architecture had SEC=YES on the TOR but SEC=NO on three AORs — a legacy configuration from the 1990s when the AORs were "trusted internal" regions.

Lisa Park, the security architect, laid out the problem: "We have 47 transactions in those AORs that bypass security entirely. Any userid that can route to those regions — including batch jobs and web service connections — has unrestricted access to every file and queue."

Rob Chen ran the numbers: retrofitting security to the AORs would require defining RACF profiles for 47 transactions, 200+ files, and 30 queues. It would take three weeks. Not retrofitting it would mean failing the next OCC audit.

They retrofitted it. Three weeks of work prevented a finding that would have cost millions. That's the economics of security architecture.

16.2 RACF-CICS Integration

16.2.1 RACF Classes for CICS

RACF uses resource classes to organize security profiles. CICS uses several specific classes:

The naming convention follows a pattern: the first letter is a category prefix, followed by CICS and then a three-character resource type identifier. These are the member classes. RACF also has corresponding grouping classes (prefixed with G, V, etc.) that allow you to define security for groups of resources using generic profiles.

16.2.2 Defining RACF Profiles for CICS

Let's walk through the RACF commands to secure a CICS region. This isn't abstract — this is what you'd type at a TSO READY prompt or code in a RACF batch job.

Step 1: Activate the RACF classes

SETROPTS CLASSACT(TCICSTRN CCICSCMD FCICSFCT SCICSTST DCICSDCT)
SETROPTS RACLIST(TCICSTRN CCICSCMD FCICSFCT SCICSTST DCICSDCT)
SETROPTS GENCMD(TCICSTRN CCICSCMD FCICSFCT SCICSTST DCICSDCT)
SETROPTS GENERIC(TCICSTRN CCICSCMD FCICSFCT SCICSTST DCICSDCT)

CLASSACT activates the class. RACLIST loads profiles into memory for performance. GENCMD enables generic profile commands. GENERIC enables generic profile checking. You need all four.

Step 2: Define transaction security profiles

RDEFINE TCICSTRN CICS.PROD.ACCT READ UACC(NONE)
PERMIT CICS.PROD.ACCT CLASS(TCICSTRN) ID(ACCTGRP) ACCESS(READ)
PERMIT CICS.PROD.ACCT CLASS(TCICSTRN) ID(ACCTMGR) ACCESS(READ)

This creates a profile for the ACCT transaction in the CICS region identified by the CICS.PROD prefix. Only members of the ACCTGRP and ACCTMGR groups can execute it. Everyone else gets denied.

Step 3: Define file security profiles

RDEFINE FCICSFCT CICS.PROD.ACCTMAST READ UACC(NONE)
PERMIT CICS.PROD.ACCTMAST CLASS(FCICSFCT) ID(ACCTGRP) ACCESS(READ)
PERMIT CICS.PROD.ACCTMAST CLASS(FCICSFCT) ID(ACCTMGR) ACCESS(UPDATE)

Notice the ACCESS levels: READ allows read-only access, UPDATE allows read and write. The ACCTGRP can read the account master file; only ACCTMGR can update it. This is resource-level security enforcing least privilege.

Step 4: Refresh the in-storage profiles

SETROPTS RACLIST(TCICSTRN) REFRESH
SETROPTS RACLIST(FCICSFCT) REFRESH

After defining or modifying profiles, you must refresh the RACLIST to load the changes into memory. CICS caches security decisions, so you may also need to issue EXEC CICS PERFORM SECURITY REBUILD to clear the CICS security cache.

16.2.3 Profile Naming Conventions

The profile naming convention for CICS RACF profiles follows this pattern:

<applid>.<resource-name>

Where <applid> is the CICS region's APPLID from the SIT. This allows you to have different security rules for the same transaction in different CICS regions. For example:

CICSPROD.ACCT     ← ACCT transaction in production
CICSTEST.ACCT     ← ACCT transaction in test (more permissive)
CICSDR.ACCT       ← ACCT transaction in DR region

You can also use generic profiles:

CICSPROD.*         ← Default for all transactions in production
CICSPROD.ACC*      ← All transactions starting with ACC

📊 Architecture Decision: At Federal Benefits Administration, Sandra Okonkwo implemented a three-tier naming convention: PROD. prefix for production, TEST. prefix for test, and DR. prefix for disaster recovery. Each tier had progressively more permissive UACC settings. Production was UACC(NONE) across the board. Test was UACC(NONE) for data-modifying transactions but UACC(READ) for inquiry transactions. DR mirrored production exactly — because a DR region that's less secure than production is a compliance disaster waiting to happen.

16.2.4 CICS Security Caching

RACF lookups are expensive — each one involves a search through the RACF database or in-storage profiles. CICS mitigates this with security caching:

• RESSEC/CMDSEC on transaction definitions: Each CICS transaction resource definition includes RESSEC(YES|NO) and CMDSEC(YES|NO) flags. RESSEC(YES) means "check resource-level security for resources accessed by this transaction." If RESSEC(NO), CICS skips resource checks even if XRES=YES in the SIT.
• Security cache: CICS maintains an in-region cache of security decisions. A successful authorization is cached for the configured timeout period (default 30 minutes, controlled by the SECTIMEOUT SIT parameter).
• RACLIST: RACF's RACLIST facility loads frequently-used profiles into memory, eliminating I/O to the RACF database.

💡 Performance Tip: In a high-volume CICS region processing 10,000 transactions per second, security caching isn't optional — it's survival. Without caching, you'd be making tens of thousands of RACF calls per second, and your ESM would become the bottleneck. But caching has a tradeoff: changes to RACF profiles don't take effect until the cache expires or is manually refreshed. For emergency security changes (revoking a compromised userid), you need both SETROPTS RACLIST REFRESH and a CICS PERFORM SECURITY REBUILD.

16.2.5 Group-Level Security Design

Real CICS security isn't defined user by user — it's defined by RACF groups mapped to business roles. Here's how CNB structures their RACF groups for CICS:

CNBCSOP    ← CICS system operators (CEMT, CEDA authority)
CNBCADM    ← CICS administrators (full command authority)
CNBTLR     ← Tellers (inquiry + limited update transactions)
CNBSUPTL   ← Supervisor tellers (teller access + overrides)
CNBLOAN    ← Loan officers (loan transactions + credit file access)
CNBAUDIT   ← Auditors (read-only access to everything)
CNBBATCH   ← Batch userids (specific transaction + file access)
CNBWSVC    ← Web service userids (API transactions only)

Each group gets precisely the access it needs. The CNBTLR group can execute teller transactions and read customer files. They cannot update loan files, execute administrative transactions, or issue CICS commands. The CNBAUDIT group can read every file and execute every inquiry transaction, but cannot update anything or execute any data-modifying transaction.

This is role-based access control (RBAC) implemented through RACF groups. It's not glamorous, but it's been working for 40 years because it maps cleanly to business organizational structures.

16.3 Transaction-Level Security

16.3.1 How Transaction Security Works

When a user enters a transaction code (or when a program issues EXEC CICS START TRANSID), CICS checks whether the user is authorized to execute that transaction. The flow:

1. User enters ACCT at a CICS terminal (or API request routes to transaction ACCT)
2. CICS checks: is XTRAN=YES in the SIT?
3. If yes, CICS issues a SAF call: "Is userid JSMITH authorized to resource CICSPROD.ACCT in class TCICSTRN?"
4. SAF routes to RACF
5. RACF evaluates: find the most specific profile matching CICSPROD.ACCT in TCICSTRN, check if JSMITH (or any group JSMITH belongs to) has at least READ access
6. RACF returns PERMIT or DENY
7. CICS either initiates the transaction or returns the DFHAC2030 "not authorized" message

16.3.2 Transaction Security Profiles in Practice

Here's a realistic set of transaction security profiles for a banking application:

* Teller transactions - accessible by tellers and supervisors
RDEFINE TCICSTRN CICSPROD.TINQ  UACC(NONE)
RDEFINE TCICSTRN CICSPROD.TACCT UACC(NONE)
RDEFINE TCICSTRN CICSPROD.TDEP  UACC(NONE)
RDEFINE TCICSTRN CICSPROD.TWTH  UACC(NONE)
RDEFINE TCICSTRN CICSPROD.TXFR  UACC(NONE)

PERMIT CICSPROD.TINQ  CLASS(TCICSTRN) ID(CNBTLR CNBSUPTL) ACCESS(READ)
PERMIT CICSPROD.TACCT CLASS(TCICSTRN) ID(CNBTLR CNBSUPTL) ACCESS(READ)
PERMIT CICSPROD.TDEP  CLASS(TCICSTRN) ID(CNBTLR CNBSUPTL) ACCESS(READ)
PERMIT CICSPROD.TWTH  CLASS(TCICSTRN) ID(CNBTLR CNBSUPTL) ACCESS(READ)
PERMIT CICSPROD.TXFR  CLASS(TCICSTRN) ID(CNBTLR CNBSUPTL) ACCESS(READ)

* Supervisor-only transactions
RDEFINE TCICSTRN CICSPROD.TSOVR UACC(NONE)
RDEFINE TCICSTRN CICSPROD.TSADJ UACC(NONE)

PERMIT CICSPROD.TSOVR CLASS(TCICSTRN) ID(CNBSUPTL) ACCESS(READ)
PERMIT CICSPROD.TSADJ CLASS(TCICSTRN) ID(CNBSUPTL) ACCESS(READ)

* Administrative transactions - CICS administrators only
RDEFINE TCICSTRN CICSPROD.CEMT UACC(NONE)
RDEFINE TCICSTRN CICSPROD.CEDA UACC(NONE)
RDEFINE TCICSTRN CICSPROD.CEDF UACC(NONE)

PERMIT CICSPROD.CEMT CLASS(TCICSTRN) ID(CNBCADM CNBCSOP) ACCESS(READ)
PERMIT CICSPROD.CEDA CLASS(TCICSTRN) ID(CNBCADM)          ACCESS(READ)
PERMIT CICSPROD.CEDF CLASS(TCICSTRN) ID(CNBCADM)          ACCESS(READ)

Note that CEMT is available to both administrators and operators, but CEDA and CEDF are admin-only. Operators can inquire and manage running resources; they cannot define new resources or debug programs in production.

16.3.3 The Default Transaction Security Problem

Here's a trap I've seen catch experienced systems programmers: if you enable XTRAN=YES but don't define a profile for a specific transaction, RACF returns a "resource not found" decision. What CICS does with that depends on the XDFTRAN SIT parameter:

• XDFTRAN=YES — CICS checks a default transaction security profile (the generic <applid>.* profile or the DFLTCLASS profile). If no default exists, the transaction is allowed.
• XDFTRAN=NO — if no specific profile exists, the transaction is denied.

⚠️ Critical: For any security-conscious shop, XDFTRAN=NO is the only acceptable setting. XDFTRAN=YES with no default profile means any undefined transaction is executable by anyone. That's an implicit PERMIT — the exact opposite of least privilege.

But XDFTRAN=NO means you must define a RACF profile for every single transaction in the CICS region, including internal CICS transactions like CSMI, CSNE, and CPMI. Forget one, and it stops working. This is why the initial security setup requires a complete inventory of every transaction in the CSD.

16.3.4 Transaction Security in MRO

When a transaction is routed from a TOR to an AOR via MRO, transaction security can be checked at either end — or both:

• TOR check: The TOR checks whether the user can execute the transaction before routing it
• AOR check: The AOR checks whether the attached user can execute the transaction when it arrives
• Both: Both regions check (belt and suspenders)

The best practice is to check at the TOR for user-facing transactions (catches unauthorized attempts before they consume AOR resources) and at the AOR for all transactions (catches anything that arrives via non-TOR paths, including web services and internal starts). This means defining transaction security profiles in both the TOR's and AOR's RACF environments.

Rob Chen at CNB initially argued against dual checking: "It's redundant. We're doing twice the RACF calls." Lisa Park's response was definitive: "Redundancy in security is called defense in depth. Redundancy in features is waste. Know the difference." They check at both.

16.3.5 Transaction Groups and Generic Profiles

In a large CICS environment with hundreds of transactions, defining individual RACF profiles for each transaction becomes unwieldy. RACF supports generic profiles that can cover multiple transactions:

* Generic profile covering all teller transactions (T*)
RDEFINE TCICSTRN CICSPROD.T* UACC(NONE)
PERMIT CICSPROD.T* CLASS(TCICSTRN) ID(CNBTLR CNBSUPTL) ACCESS(READ)

However, generic profiles are a blunt instrument. The profile CICSPROD.T* covers TINQ (inquiry), TDEP (deposit), and also TSOVR (supervisor override). You'd need the supervisor override on a more specific profile:

* Specific profile overrides generic for supervisor transactions
RDEFINE TCICSTRN CICSPROD.TSOVR UACC(NONE)
PERMIT CICSPROD.TSOVR CLASS(TCICSTRN) ID(CNBSUPTL) ACCESS(READ)

RACF evaluates the most specific matching profile first. So CICSPROD.TSOVR takes precedence over CICSPROD.T* for the TSOVR transaction. This gives you a layered approach: broad generic profiles for common access, specific profiles for exceptions.

The RACF profile evaluation order is:

1. Exact match (CICSPROD.TSOVR)
2. Most specific generic match (CICSPROD.TS*)
3. Less specific generic match (CICSPROD.T*)
4. Least specific generic match (CICSPROD.*)

Understanding this evaluation order is critical. I once debugged a security failure where a shop had defined both CICSPROD.TINQ and CICSPROD.T profiles. The specific TINQ profile had different permissions than the generic T profile, and the team was confused about which one RACF was using. The answer: RACF always uses the most specific match.

CICS also supports transaction grouping through the GCICSTRN class, where you define logical groups of transactions and assign security at the group level. This adds a layer of indirection but can simplify administration in very large environments.

At Pinnacle Health, Diane Morrison's team manages 340 CICS transactions. They use a hybrid approach: generic profiles for broad departmental access (all claims transactions start with CL, all billing with BL, all clinical with CR), with specific profiles for the 30 transactions that require granular access control different from the departmental default.

16.4 Resource-Level Security

16.4.1 Beyond Transaction Security

Transaction security answers one question: "Can this user execute this transaction?" It doesn't answer: "Can this user read this file?" or "Can this user write to this queue?" That's resource-level security.

Consider this scenario: user JSMITH is authorized to execute transaction TINQ (teller inquiry). TINQ reads the customer master file, the account file, and the transaction history file. Without resource-level security, JSMITH can read all three files through TINQ — and so can every other transaction JSMITH is authorized to execute. If JSMITH can also execute transaction TRPT (a reporting transaction), and TRPT reads the same files plus the loan file, JSMITH gets loan file access through TRPT even though they're a teller who should never see loan data.

Resource-level security fixes this by checking file access independently of transaction access. Even though JSMITH can execute TRPT, if JSMITH's groups don't have READ access to the loan file in the FCICSFCT class, the file read will fail with a security violation.

16.4.2 Enabling Resource-Level Security

Resource-level security requires two things:

1. SIT parameters: XRES=YES and the specific resource class parameters (XFCT=YES for files, XTST=YES for TSQs, XDCT=YES for TDQs, XPPT=YES for programs)

2. Transaction RESSEC: Each transaction's CSD definition must specify RESSEC(YES). This is the per-transaction toggle. If RESSEC(NO), CICS skips resource-level checks for that transaction even if the SIT says XRES=YES.

DEFINE TRANSACTION(TINQ) GROUP(TELLER)
    PROGRAM(TINQPGM)
    RESSEC(YES)
    CMDSEC(NO)
    TASKDATALOC(ANY)
    ...

16.4.3 File Security Profiles

File security profiles map CICS file names to RACF access levels:

* Customer master file - tellers can read, supervisors can update
RDEFINE FCICSFCT CICSPROD.CUSTMAST UACC(NONE)
PERMIT CICSPROD.CUSTMAST CLASS(FCICSFCT) ID(CNBTLR)   ACCESS(READ)
PERMIT CICSPROD.CUSTMAST CLASS(FCICSFCT) ID(CNBSUPTL)  ACCESS(UPDATE)
PERMIT CICSPROD.CUSTMAST CLASS(FCICSFCT) ID(CNBAUDIT)  ACCESS(READ)

* Account file - tellers can update (deposits/withdrawals)
RDEFINE FCICSFCT CICSPROD.ACCTFILE UACC(NONE)
PERMIT CICSPROD.ACCTFILE CLASS(FCICSFCT) ID(CNBTLR)   ACCESS(UPDATE)
PERMIT CICSPROD.ACCTFILE CLASS(FCICSFCT) ID(CNBSUPTL)  ACCESS(UPDATE)
PERMIT CICSPROD.ACCTFILE CLASS(FCICSFCT) ID(CNBAUDIT)  ACCESS(READ)

* Loan file - loan officers only, tellers have NO access
RDEFINE FCICSFCT CICSPROD.LOANFILE UACC(NONE)
PERMIT CICSPROD.LOANFILE CLASS(FCICSFCT) ID(CNBLOAN)  ACCESS(UPDATE)
PERMIT CICSPROD.LOANFILE CLASS(FCICSFCT) ID(CNBSUPTL)  ACCESS(READ)
PERMIT CICSPROD.LOANFILE CLASS(FCICSFCT) ID(CNBAUDIT)  ACCESS(READ)

The RACF ACCESS levels map to CICS file operations:

16.4.4 TSQ and TDQ Security

Temporary Storage Queues and Transient Data Queues also require security profiles:

* TSQ security - protect sensitive temporary data
RDEFINE SCICSTST CICSPROD.CUSTDATA UACC(NONE)
PERMIT CICSPROD.CUSTDATA CLASS(SCICSTST) ID(CNBTLR CNBSUPTL) ACCESS(UPDATE)

* TDQ security - protect audit log queues
RDEFINE DCICSDCT CICSPROD.AUDITLOG UACC(NONE)
PERMIT CICSPROD.AUDITLOG CLASS(DCICSDCT) ID(CNBCADM) ACCESS(ALTER)
PERMIT CICSPROD.AUDITLOG CLASS(DCICSDCT) ID(CNBAUDIT) ACCESS(READ)

📊 Real-World Pattern: TSQ security is often overlooked because TSQs are "temporary." But in many applications, TSQs hold sensitive data during multi-screen transactions — customer SSNs, account balances, credit scores. At Pinnacle Health, Ahmad Rashid discovered that 14 CICS transactions stored patient PHI in TSQs with no security. Any user who could guess or enumerate the TSQ name (and they followed a predictable naming pattern) could read the data. That finding alone triggered a HIPAA incident review.

16.4.5 Program Security

Program security (XPPT=YES) controls which users can execute which CICS programs. This is distinct from transaction security — transaction security controls the entry point, program security controls every program in the execution chain.

RDEFINE MCICSPPT CICSPROD.TINQPGM UACC(NONE)
PERMIT CICSPROD.TINQPGM CLASS(MCICSPPT) ID(CNBTLR CNBSUPTL) ACCESS(READ)

RDEFINE MCICSPPT CICSPROD.UPDTPGM UACC(NONE)
PERMIT CICSPROD.UPDTPGM CLASS(MCICSPPT) ID(CNBSUPTL) ACCESS(READ)

Program security adds another layer but also adds complexity. Most shops I've worked in use transaction security and file security but skip program security because the administrative overhead of profiling every program is significant. The exceptions are shops with extremely strict separation-of-duty requirements — typically financial and government.

16.4.6 Command Security

Command security (XCMD=YES) controls who can issue CICS system programming interface (SPI) commands — the EXEC CICS SET, INQUIRE, PERFORM, DISCARD, and CREATE commands that manage CICS resources programmatically.

* CICS SPI command security
RDEFINE CCICSCMD CICSPROD.SETTRAN UACC(NONE)
PERMIT CICSPROD.SETTRAN CLASS(CCICSCMD) ID(CNBCADM) ACCESS(UPDATE)

RDEFINE CCICSCMD CICSPROD.INQTRAN UACC(NONE)
PERMIT CICSPROD.INQTRAN CLASS(CCICSCMD) ID(CNBCADM CNBCSOP) ACCESS(READ)

RDEFINE CCICSCMD CICSPROD.PERFORM UACC(NONE)
PERMIT CICSPROD.PERFORM CLASS(CCICSCMD) ID(CNBCADM) ACCESS(UPDATE)

For each transaction that issues SPI commands, you must set CMDSEC(YES) in the transaction's CSD definition:

DEFINE TRANSACTION(CEMT) GROUP(DFHOPER)
    PROGRAM(DFHEMTP)
    RESSEC(YES)
    CMDSEC(YES)
    ...

This ensures that even though an operator can execute CEMT, they can only issue the specific SPI commands they're authorized for. An operator with READ access to INQTRAN can inquire on transactions but cannot set (enable/disable) them.

16.5 Surrogate User and Web Service Security

16.5.1 The Surrogate User Problem

Modern CICS systems don't just serve terminal users. They serve web services, API clients, batch processes, and MQ message flows. These non-terminal interactions create a security challenge: who is the "user" when a web service call arrives?

Consider: a mobile banking app makes a REST API call to a CICS Transaction Gateway (CTG) endpoint. The API call includes a JWT token identifying the end user. But the CTG itself connects to CICS using a service userid — a single userid shared by all API calls. Without surrogate user processing, every API call runs under the service userid's authority, regardless of which end user initiated it.

Surrogate user processing allows the service userid to "assume" the identity of the end user for security checking purposes. The service userid asks CICS: "Execute this transaction as if user JSMITH were running it." CICS then checks:

1. Is the service userid authorized to act as a surrogate for JSMITH? (SURROGAT class check)
2. Is JSMITH authorized to execute the requested transaction? (TCICSTRN class check)
3. Is JSMITH authorized to access the resources the transaction uses? (FCICSFCT etc.)

16.5.2 Configuring Surrogate Security

Surrogate security requires RACF profiles in the SURROGAT class:

* Allow web service userid WEBSVCID to act on behalf of any user
* in the CNBTLR group
RDEFINE SURROGAT CICSPROD.WEBSVCID.DFHSTART UACC(NONE)

* Or more granularly, allow WEBSVCID to assume specific userids
RDEFINE SURROGAT JSMITH.DFHSTART UACC(NONE)
PERMIT JSMITH.DFHSTART CLASS(SURROGAT) ID(WEBSVCID) ACCESS(READ)

The profile name format is <target-userid>.DFHSTART — this controls who can start transactions under the target userid's identity. The PERMIT grants the surrogate userid (WEBSVCID) authority to assume the target identity.

16.5.3 Web Service Security Architecture

For CNB's mobile banking integration, Yuki Tanaka at SecureFirst Insurance helped design a reference architecture that CNB adapted:

Mobile App → API Gateway → CICS Transaction Gateway → CICS TOR → AOR
                ↓                    ↓                    ↓        ↓
            JWT Token           CTG userid            Surrogate  Resource
            Validation         (CTGSVCID)             to end-    security
                                                      user ID    as end user

Step 1: API Gateway validates the JWT token and extracts the end-user identity.

Step 2: CTG connects to CICS using the CTG service userid (CTGSVCID). This userid has limited direct authority — it can execute the CWBA transaction (CICS Web Bridge Adapter) and nothing else.

Step 3: The CWBA transaction performs a surrogate sign-on, switching the security context to the end user's userid. CICS checks the SURROGAT class to verify CTGSVCID can act as the end user.

Step 4: The end user's transaction executes under their own security context. All resource-level security checks use the end user's RACF identity.

This architecture preserves the principle of least privilege: the service userid has minimal authority, and the end user's actual RACF profile controls what they can do through the API, just as it would at a terminal.

16.5.4 SSL/TLS Configuration for CICS

Any CICS system accepting web service connections must enforce transport-level security. CICS supports SSL/TLS through the CICS TCP/IP service definitions:

DEFINE TCPIPSERVICE(HTTPS1) GROUP(WEBSVC)
    PORTNUMBER(8443)
    PROTOCOL(HTTP)
    SSL(YES)
    CERTIFICATE(CICSPROD)
    AUTHENTICATE(CERTIFICATE)
    TRANSACTION(CWBA)
    ...

The CERTIFICATE attribute references a certificate label in the RACF keyring associated with the CICS region's userid:

RACDCERT ID(CICSRGN) ADDRING(CICSKeyring)
RACDCERT ID(CICSRGN) CONNECT(LABEL('CICSProdCert')
    RING(CICSKeyring) USAGE(PERSONAL) DEFAULT)
RACDCERT CERTAUTH CONNECT(LABEL('EnterpriseCA')
    RING(CICSKeyring) USAGE(CERTAUTH))

AUTHENTICATE(CERTIFICATE) means CICS will request and validate the client's certificate. Combined with SSL(YES), this provides mutual TLS authentication — both the client and server verify each other's identity.

16.5.5 LDAP Integration

For organizations that maintain user directories in LDAP, CICS can integrate with LDAP for user authentication through RACF's LDAP support. The flow:

1. CICS receives a sign-on request with userid and password
2. CICS issues a SAF VERIFY call to RACF
3. RACF, configured with LDAP identity mapping, queries the LDAP directory
4. If the LDAP bind succeeds, RACF creates a local ACEE and returns success

This is configured through RACF's ICTX (Identity Context) facility and the RACF LDAP configuration in the IRR.LDAP.* profiles. The key benefit is single-source user management — user provisioning and de-provisioning happens in one place (the LDAP directory) and is reflected across all systems including CICS.

At Federal Benefits Administration, Marcus Brown implemented LDAP integration to connect CICS to the agency's Active Directory. This allowed the same user credentials that accessed email and web applications to authenticate to CICS mainframe transactions — a significant improvement in user experience and a reduction in help desk password-reset calls.

16.5.6 MQ Message Security and Channel Security

In many enterprise architectures, CICS communicates with other systems via IBM MQ (formerly WebSphere MQ). When a CICS transaction places a message on an MQ queue, or receives one, security must flow with the message.

MQ supports two mechanisms relevant to CICS:

MQ Channel Authentication Records (CHLAUTH): Control which userids can connect through specific MQ channels. When CICS connects to an MQ queue manager, the MQ channel authentication rules determine the security context for the connection.

MQ Message Security (AMS): Encrypts and signs message payloads. When CICS writes a message containing sensitive data (account numbers, SSNs, PHI), AMS can encrypt the message at rest in the queue. The receiving application must have the appropriate certificate to decrypt it.

For the HA banking system, MQ message security is particularly important for cross-system communication. Payment messages flowing from the CICS AOR-PAY to the Federal Reserve's FedNow service contain card data that falls under PCI-DSS scope. These messages must be encrypted both in transit (channel SSL) and at rest (AMS).

* MQ channel security for CICS-to-payment-network
DEFINE CHANNEL('CICS.TO.FEDPAY') CHLTYPE(SDR) +
    SSLCIPH('TLS_AES_256_GCM_SHA384') +
    SSLPEER('CN=FedPayGateway,O=Federal Reserve') +
    MCAUSER(' ')

The MCAUSER(' ') setting means MQ uses the userid from the channel connection rather than a fixed userid — preserving the security context from CICS through the MQ message flow.

16.5.7 Password Phrase Support and Multi-Factor Authentication

Modern mainframe security increasingly supports password phrases (up to 100 characters, mixed case) and multi-factor authentication (MFA). RACF supports password phrases natively, and CICS can authenticate users with password phrases through the standard SAF interface.

For MFA, z/OS supports RACF MFA through the IBM Multi-Factor Authentication for z/OS product. When enabled, a CICS sign-on requires both a password (something you know) and a token or push notification (something you have). The MFA challenge can be integrated into custom CICS sign-on transactions.

At CNB, Kwame Asante deployed MFA for all CICS administrative transactions — CEMT, CEDA, and any transaction that modifies production data. Regular teller transactions use standard password authentication, but any elevated-privilege action triggers an MFA challenge. This was a key control for their most recent OCC examination.

16.6 Audit Compliance (PCI-DSS, HIPAA, SOX)

16.6.1 Why Audit Compliance Matters

I'll be blunt: if your shop handles credit card data, you're subject to PCI-DSS. If you handle health information, you're subject to HIPAA. If you're publicly traded, you're subject to SOX. These aren't suggestions — they're legal requirements with real penalties for non-compliance.

CICS security isn't just about preventing unauthorized access. It's about proving you prevent unauthorized access, demonstrating that you detect unauthorized attempts, and documenting that you respond to security events. The auditors don't care what you say your security does — they care what the evidence shows.

I've sat through dozens of audits across financial services, healthcare, and government. The auditors' questions follow a predictable pattern:

1. "Show me your security policy document for CICS." If you don't have one, you fail immediately. The document must describe your security architecture, role definitions, access control model, and audit mechanisms.

2. "Show me evidence that user X was authorized to perform action Y on date Z." This requires a functioning audit trail — not just log data, but correlated log data that links a specific user to a specific action on a specific resource at a specific time.

3. "Show me evidence that unauthorized access is detected and responded to." This requires real-time monitoring with documented incident response procedures. Having logs that nobody reads is insufficient.

4. "Show me that your security controls are tested regularly." This requires documented test plans, test results, and evidence of remediation for any findings.

5. "Show me your access recertification process." Quarterly or semi-annual reviews where managers certify that each user's access is still appropriate. Stale access — employees who changed roles but kept their old access — is one of the most common audit findings.

16.6.2 PCI-DSS Requirements Mapped to CICS

PCI-DSS has 12 requirements organized in 6 categories. Here's how they map to CICS security controls:

16.6.3 PCI-DSS Requirement 10 — The Audit Trail

Requirement 10 is the one that gets the most shops in trouble. It requires:

• 10.1: Audit trails linking access to individual users
• 10.2: Automated audit trails for all system components
• 10.3: Record audit trail entries with specific fields (user ID, event type, date/time, success/failure, origination, identity/name of affected resource)
• 10.5: Secure audit trails so they cannot be altered
• 10.7: Retain audit trail history for at least one year, with a minimum of three months immediately available

For CICS, this maps to three mechanisms:

SMF Type 110 Records: CICS writes SMF 110 records for transaction activity. These records contain the transaction ID, userid, start time, end time, CPU time, and response time. Subtype 1 records contain performance data; subtype 2 records contain exception data. For security auditing, you need both.

To enable comprehensive SMF 110 recording:

* SIT parameters for SMF recording
SMF=YES
SMFCOMP=YES

And in the MCT (Monitoring Control Table):

DFHMCT TYPE=RECORD,CLASS=3,STATUS=ACTIVE
DFHMCT TYPE=RECORD,CLASS=4,STATUS=ACTIVE

Class 3 records contain performance data. Class 4 (exception monitoring) captures security violations, abends, and other exceptional events.

RACF Audit Records (SMF Type 80): RACF writes SMF type 80 records for every security decision. You control the granularity:

* Enable RACF auditing for CICS classes
RDEFINE TCICSTRN CICSPROD.ACCT AUDIT(ALL)
RDEFINE FCICSFCT CICSPROD.ACCTFILE AUDIT(FAILURES)

AUDIT(ALL) records every access — both successes and failures. AUDIT(FAILURES) records only denied attempts. For PCI-DSS, you typically need AUDIT(ALL) for cardholder data resources and AUDIT(FAILURES) for everything else (to keep the audit volume manageable).

CICS Journals: CICS journaling provides application-level audit trails. Your COBOL programs can write journal records containing whatever audit data your compliance framework requires:

EXEC CICS JOURNAL JFILEID(01)
    JTYPEID('AU')
    FROM(WS-AUDIT-RECORD)
    LENGTH(LENGTH OF WS-AUDIT-RECORD)
    WAIT
END-EXEC

The journal record can include the userid, transaction, timestamp, action performed, data before-image, data after-image, and any other fields the auditors require. This is where your COBOL programs become part of the security architecture.

16.6.4 HIPAA Compliance for CICS

HIPAA's Security Rule requires administrative, physical, and technical safeguards for Protected Health Information (PHI). The technical safeguards relevant to CICS:

At Pinnacle Health, Diane Morrison's team had to implement what HIPAA calls the "minimum necessary" rule: users should access only the minimum PHI necessary for their job function. In CICS terms, this meant:

1. Claims processors could access claims data but not clinical records
2. Clinical staff could access clinical records for their department but not other departments
3. Billing staff could access financial data and diagnosis codes but not treatment notes
4. IT operations could manage CICS resources but could not read any PHI files

This required not just transaction and file security but also field-level security within the application. The claims processing transaction displayed different data fields depending on the user's RACF group — a claims processor saw billing codes and amounts; a clinician saw diagnosis and treatment details. The COBOL program checked the user's group membership at runtime and formatted the screen accordingly.

* Check user's group for field-level display control
EXEC CICS QUERY SECURITY
    RESTYPE('DFTCLASS')
    RESID('CLINDATA')
    RESIDLENGTH(8)
    LOGMESSAGE(NOLOG)
    RESP(WS-RESP)
    RESP2(WS-RESP2)
END-EXEC

EVALUATE WS-RESP
    WHEN DFHRESP(NORMAL)
        PERFORM DISPLAY-CLINICAL-FIELDS
    WHEN DFHRESP(NOTAUTH)
        PERFORM DISPLAY-BILLING-ONLY
    WHEN OTHER
        PERFORM SECURITY-ERROR-HANDLER
END-EVALUATE

16.6.5 SOX Compliance — Separation of Duties

Sarbanes-Oxley (SOX) compliance centers on separation of duties and change management for financial systems. The key CICS implications:

1. Developers cannot deploy code to production. CICS program definitions (CEDA DEFINE PROGRAM) must be restricted to operations staff. Developers must not have CICS command authority in production.

2. Production data access must be logged. Every access to financial data files must generate an audit record.

3. Change management must be documented. Every CSD change, SIT modification, and RACF profile update must go through a documented change management process.

The RACF implementation:

* SOX: Developers have NO authority in production CICS
* No transaction authority
* No command authority
* No file authority
* (They get test CICS regions instead)

* SOX: Operations can manage but not develop
RDEFINE CCICSCMD CICSPROD.INSTALL  UACC(NONE)
PERMIT CICSPROD.INSTALL CLASS(CCICSCMD) ID(CNBCSOP) ACCESS(UPDATE)

RDEFINE CCICSCMD CICSPROD.NEWCOPY  UACC(NONE)
PERMIT CICSPROD.NEWCOPY CLASS(CCICSCMD) ID(CNBCSOP) ACCESS(UPDATE)

* Operations cannot define new resources - that requires
* change management approval and CNBCADM authority
RDEFINE CCICSCMD CICSPROD.CREATE   UACC(NONE)
PERMIT CICSPROD.CREATE CLASS(CCICSCMD) ID(CNBCADM) ACCESS(UPDATE)

16.6.6 Building the Audit Trail Program

A comprehensive audit trail requires more than just SMF records. You need an application-level audit program that your transactions call to record business-level audit events. Here's the architecture:

Transaction Program
        ↓
  EXEC CICS LINK PROGRAM('AUDITPGM')
        ↓
  AUDITPGM formats audit record
        ↓
  EXEC CICS JOURNAL (writes to CICS journal)
        ↓
  SMF exits forward to audit repository
        ↓
  SIEM/Audit Analysis (Splunk, QRadar, etc.)

The audit program (AUDITPGM) is a shared service that every security-sensitive transaction calls. It formats a standardized audit record containing:

• Timestamp (ABSTIME from CICS)
• Terminal ID (from EIBTRMID)
• Transaction ID (from EIBTRNID)
• User ID (from EXEC CICS ASSIGN USERID)
• Action code (passed by calling program)
• Resource name (passed by calling program)
• Before image (passed by calling program, if update)
• After image (passed by calling program, if update)
• Outcome (success/failure)

See code/example-02-audit-program.cbl for a complete implementation of this program.

16.6.7 Protecting the Audit Trail

An audit trail that can be tampered with is worthless. PCI-DSS Requirement 10.5 specifically requires that audit trails be secured:

1. Journal files must be in secured datasets. The CICS journal datasets (DFHJ01, DFHJ02, etc.) must have RACF DATASET profiles restricting UPDATE access to the CICS region userid only.

2. SMF data must be protected. SMF datasets should be readable by audit staff and the security team only.

3. Archive journals regularly. Journal data should be archived to WORM (Write Once Read Many) storage or equivalent tamper-evident media.

4. Monitor for gaps. Any gap in the audit trail — a period with no records — must be investigated. Gaps often indicate that someone disabled journaling to perform unauthorized actions.

* RACF protection for journal datasets
ADDSD 'CICS.PROD.JOURNAL.J01' UACC(NONE)
PERMIT 'CICS.PROD.JOURNAL.J01' ID(CICSRGN) ACCESS(UPDATE)
PERMIT 'CICS.PROD.JOURNAL.J01' ID(CNBAUDIT) ACCESS(READ)

ADDSD 'CICS.PROD.JOURNAL.J02' UACC(NONE)
PERMIT 'CICS.PROD.JOURNAL.J02' ID(CICSRGN) ACCESS(UPDATE)
PERMIT 'CICS.PROD.JOURNAL.J02' ID(CNBAUDIT) ACCESS(READ)

16.7 Security Testing and Validation

16.7.1 Security Testing Is Not Optional

You've defined your RACF profiles, configured your SIT, and set RESSEC(YES) on your transactions. Are you secure? You don't know until you test. And "it works for the users" is not a security test — that tests the positive case. Security testing must test the negative case: can someone who shouldn't have access actually get access?

16.7.2 The Security Testing Methodology

A comprehensive CICS security test plan includes:

1. Positive Access Testing (Verify Authorized Users) - For each RACF group, identify one test userid - Execute every transaction the group should access — verify success - Access every file/queue the group should read — verify success - Access every file/queue the group should update — verify success

2. Negative Access Testing (Verify Unauthorized Users Are Denied) - For each RACF group, attempt transactions the group should NOT access — verify DFHAC2030 - Attempt file access that should be denied — verify NOTAUTH response - Attempt SPI commands that should be denied — verify NOTAUTH response

3. Cross-Region Testing (MRO Security) - Verify security context propagates correctly from TOR to AOR - Verify that directly connecting to an AOR (bypassing the TOR) still enforces security - Verify surrogate user processing across MRO boundaries

4. Boundary Testing - Test with expired passwords - Test with revoked userids - Test with userids at maximum password-failure count - Test during RACF class deactivation - Test with RACF in WARNING mode vs. FAIL mode

5. Audit Verification - Execute test transactions and verify SMF 110 records are generated - Attempt unauthorized access and verify SMF 80 records capture the failure - Verify journal records contain the required audit fields - Verify audit records cannot be deleted by non-admin users

16.7.3 Automated Security Validation

Manual security testing doesn't scale. For CNB's 47 transactions and 200+ file profiles, manually testing every positive and negative combination would take weeks. The solution is automated security validation using a CICS program that systematically tests access:

* Pseudo-logic for automated security testing
* (See code/example-02-audit-program.cbl for audit program)
*
* For each test userid:
*   EXEC CICS VERIFY to sign on as test user
*   For each transaction in the test matrix:
*     EXEC CICS QUERY SECURITY RESTYPE('TCICSTRN')
*       RESID(transaction-id)
*     Compare result to expected-access-matrix
*     Log discrepancies
*   For each file in the test matrix:
*     EXEC CICS QUERY SECURITY RESTYPE('FCICSFCT')
*       RESID(file-name)
*     Compare result to expected-access-matrix
*     Log discrepancies

The EXEC CICS QUERY SECURITY command is your friend here. It checks authorization without actually attempting the operation. You can probe RACF's response for any resource type without triggering the actual resource access — perfect for security validation.

EXEC CICS QUERY SECURITY
    RESTYPE('TCICSTRN')
    RESID(WS-TRAN-ID)
    RESIDLENGTH(4)
    LOGMESSAGE(NOLOG)
    RESP(WS-RESP)
    RESP2(WS-RESP2)
END-EXEC

EVALUATE WS-RESP
    WHEN DFHRESP(NORMAL)
        MOVE 'AUTHORIZED' TO WS-TEST-RESULT
    WHEN DFHRESP(NOTAUTH)
        MOVE 'DENIED' TO WS-TEST-RESULT
    WHEN OTHER
        MOVE 'ERROR' TO WS-TEST-RESULT
END-EVALUATE

The LOGMESSAGE(NOLOG) option prevents the query from generating audit records — you don't want your security tests polluting the audit trail with thousands of authorization checks.

16.7.4 Security Monitoring and Incident Response

Testing happens before go-live. Monitoring happens continuously. A complete CICS security architecture includes real-time monitoring for:

• Repeated sign-on failures: Could indicate a brute-force attack or a misconfigured batch job
• Authorization failures on sensitive resources: Could indicate an attempted privilege escalation
• Unusual transaction volumes: A user executing 10,000 inquiry transactions in an hour might be exfiltrating data
• Off-hours activity: A teller transaction at 3 AM on a Sunday warrants investigation

Most shops feed their SMF data to a SIEM (Security Information and Event Management) system — Splunk, IBM QRadar, or similar. The SMF 80 (RACF) and SMF 110 (CICS) records flow to the SIEM, which applies correlation rules to detect patterns that individual records wouldn't reveal.

At SecureFirst Insurance, Yuki Tanaka and Carlos Rivera built a set of QRadar correlation rules specifically for CICS:

• Rule 1: More than 5 sign-on failures from the same terminal in 10 minutes → Alert
• Rule 2: Any authorization failure on a PCI-DSS scope resource → Alert
• Rule 3: Any CICS command (SPI) activity from a non-admin userid → Alert
• Rule 4: Transaction execution outside the user's normal working hours → Flag for review
• Rule 5: More than 100 file READ operations by a single user in 5 minutes → Flag for review

These rules transformed CICS security from "lock the door and hope" to "active surveillance with automated response."

16.7.5 Penetration Testing CICS

Yes, you should penetration test your CICS regions. This is increasingly required by PCI-DSS (Requirement 11.3) and expected by regulators. CICS penetration testing targets:

1. Web service endpoints: Can an attacker bypass authentication or authorization through the CICS web interface? Test for injection attacks, authentication bypass, and authorization escalation.

2. MRO paths: Can a compromised AOR be used to access resources in other AORs? Test lateral movement through MRO links.

3. Surrogate user exploitation: Can the service userid's authority be leveraged to access resources beyond its intended scope? Test the SURROGAT class profiles for over-permissive configurations.

4. Default credential scanning: Are there any CICS regions with default userids still active? Check for CICSUSER, WEBUSER, DFHUSER, and similar well-known defaults.

5. Transaction injection: Can an attacker craft MRO messages that trick an AOR into executing unauthorized transactions?

Sandra Okonkwo at Federal Benefits Administration runs quarterly penetration tests against their CICS web service endpoints. In the first test, the penetration testers found that the CTG service userid had UACC(READ) on transaction profiles that should have been UACC(NONE). This meant any authenticated user of the web portal could theoretically execute any read-only transaction. It was a design flaw in the initial RACF profile setup, caught only because someone actually tested the negative cases.

16.7.6 Security Regression Testing

Security testing isn't a one-time event. Every change to the CICS environment — new transactions, new programs, CSD modifications, RACF profile updates, SIT parameter changes — can introduce security regressions. Build security testing into your change management process:

1. Pre-deployment: Before any CSD or RACF change goes to production, run the automated security validation program against the test CICS region with the proposed changes.

2. Post-deployment: After deploying changes to production, run the validation again to confirm the production result matches the test result.

3. Periodic baseline: Monthly, run a full security validation and compare the results to the established baseline. Any deviation from the baseline must be investigated and either justified (intentional change through change management) or remediated (unauthorized or accidental change).

4. Access recertification: Quarterly, generate a report of all RACF group memberships for CICS-related groups. Business managers must certify that each user in their group still needs the access. This is a SOX control and a PCI-DSS Requirement 7 control.

At SecureFirst, Yuki Tanaka automated this entire pipeline. A batch job runs nightly that executes the security validation program, compares results to the baseline, and emails any discrepancies to the security team. The monthly and quarterly reports are generated automatically and routed to the appropriate managers for certification. The entire process runs without manual intervention — because manual security processes are processes that eventually get skipped.

✅ Best Practice: Treat your RACF security profiles like code. Store them in a version control system. Require peer review before deployment. Track every change with a ticket number. Run automated tests. This is infrastructure-as-code applied to mainframe security, and it works.

16.8 Architecting Security for the HA Banking System

16.8.1 Security Requirements for the Project

The HA Banking Transaction Processing System has specific security requirements:

1. Multi-region security: The system spans multiple CICS regions (TORs, AORs, FORs) — security must be consistent and complete across all of them
2. Web service integration: Mobile and online banking channels connect via APIs — surrogate user processing is mandatory
3. PCI-DSS compliance: The system processes credit and debit card transactions — full PCI-DSS scope
4. High availability: Security mechanisms must not become single points of failure
5. Audit completeness: Every transaction touching financial data must generate an audit trail

16.8.2 Security Architecture for the HA Banking System

Here's the security architecture for the HA banking system project:

                    ┌──────────────────────────┐
                    │     API Gateway / CTG     │
                    │  (SSL/TLS termination)    │
                    │  (JWT validation)         │
                    └────────────┬─────────────┘
                                 │ Mutual TLS
                    ┌────────────▼─────────────┐
                    │  TOR-1 / TOR-2 (Active)  │
                    │  SEC=YES, XTRAN=YES       │
                    │  Authentication           │
                    │  Transaction routing       │
                    │  Surrogate user sign-on   │
                    └────────────┬─────────────┘
                         MRO    │   (ACEE propagation)
              ┌──────────────────┼──────────────────┐
              ▼                  ▼                   ▼
     ┌────────────────┐ ┌────────────────┐ ┌────────────────┐
     │    AOR-PAY     │ │    AOR-ACCT    │ │    AOR-LOAN    │
     │  SEC=YES       │ │  SEC=YES       │ │  SEC=YES       │
     │  XTRAN=YES     │ │  XTRAN=YES     │ │  XTRAN=YES     │
     │  XRES=YES      │ │  XRES=YES      │ │  XRES=YES      │
     │  XCMD=YES      │ │  XCMD=YES      │ │  XCMD=YES      │
     │  Payment txns  │ │  Account txns  │ │  Loan txns     │
     └────────┬───────┘ └────────┬───────┘ └────────┬───────┘
              │                  │                   │
              └──────────────────┼───────────────────┘
                                 │
                    ┌────────────▼─────────────┐
                    │     FOR (File-Owning)     │
                    │  SEC=YES, XFCT=YES        │
                    │  File-level security       │
                    │  Journal-based audit trail │
                    └──────────────────────────┘

16.8.3 RACF Group Structure

HABKTLR    ← Tellers: inquiry + teller transactions
HABKSUP    ← Supervisors: teller + override + adjustment
HABKPAY    ← Payment processors: payment transactions
HABKLOAN   ← Loan officers: loan transactions
HABKWSVC   ← Web service userids (API channels)
HABKOPS    ← CICS operators: CEMT inquire/set
HABKADM    ← CICS administrators: full command authority
HABKAUDT   ← Auditors: read-only everything, update nothing
HABKBAT    ← Batch userids: specific file access

16.8.4 Security Checkpoints for Each AOR

Each AOR enforces security specific to its domain:

AOR-PAY (Payment Processing): - Only HABKPAY and HABKSUP can execute payment transactions - Only HABKPAY can UPDATE the payment file - All payment transactions write to the audit journal - PCI-DSS Requirement 10 compliance: every card data access logged

AOR-ACCT (Account Management): - HABKTLR and HABKSUP can execute inquiry and basic account transactions - Only HABKSUP can execute adjustment transactions - Customer master file: READ for tellers, UPDATE for supervisors - Account file: UPDATE for tellers (deposits/withdrawals), ALTER for supervisors

AOR-LOAN (Loan Processing): - Only HABKLOAN and HABKSUP can execute loan transactions - Loan file access completely segregated from teller file access - Credit report access logged with AUDIT(ALL) for fair lending compliance

16.8.5 Security Event Flow in the HA Architecture

Let's trace a complete security event through the HA banking system to see how all the pieces fit together.

Scenario: Mobile banking customer initiates a funds transfer.

1. Customer opens mobile app and authenticates with fingerprint + PIN (MFA at the app level)
2. App sends REST API request to the API Gateway with a JWT token
3. API Gateway validates the JWT, extracts userid CUST12345, forwards to CTG over mutual TLS
4. CTG connects to TOR-1 using service userid MOBSVCID
5. TOR-1 checks: Can MOBSVCID execute TWEB? (TCICSTRN check → YES, MOBSVCID is in HABKWSVC)
6. TWEB transaction performs surrogate sign-on to CUST12345 (SURROGAT check → YES, MOBSVCID can assume CUST12345)
7. TOR-1 routes transaction TXFR to AOR-ACCT with CUST12345's security context
8. AOR-ACCT checks: Can CUST12345 execute TXFR? (TCICSTRN check → YES, CUST12345 is in HABKMOB, which has TXFR access)
9. TXFR program calls AUDITPGM to log the transfer initiation
10. TXFR reads ACCTFILE to verify source and destination accounts (FCICSFCT check → YES, HABKMOB has READ on ACCTFILE)
11. TXFR updates ACCTFILE with new balances (FCICSFCT check → YES, HABKMOB has UPDATE on ACCTFILE)
12. TXFR calls AUDITPGM to log the completed transfer with before/after balances
13. CICS writes SMF 110 record for the transaction
14. RACF writes SMF 80 records for each authorization decision
15. SIEM ingests both SMF records and correlates them

Total security checks in this flow: 1 transport-level (TLS), 1 surrogate authorization, 2 transaction authorizations (TOR + AOR), 2 file authorizations, plus 2 application-level audit journal entries. The customer experiences a sub-second response time. Security is invisible to the user but comprehensive.

16.8.6 HA Considerations for Security

Security in a high-availability system must itself be highly available:

1. RACF database replication: The RACF database must be available at both the primary and DR sites. RACF supports a primary and backup database — both must be current.

2. Sysplex-wide security caching: In a z/OS sysplex, RACF can share its in-storage profile cache across systems. This ensures that a profile change on one system is reflected on all systems.

3. Certificate management: SSL/TLS certificates must be valid at both sites. Certificate expiration is a common cause of DR failover failures — the certificates work at the primary site but have expired or weren't installed at the DR site.

4. Surrogate definitions at DR: All SURROGAT class profiles must exist at the DR site. If the web service userids can't perform surrogate sign-on at DR, the mobile banking channel goes dark during a failover.

5. Audit continuity: The audit trail must survive a site failover. Journal data must be replicated or forwarded to the audit repository before a failover event. Any gap in the audit trail during a failover must be documented and explained to auditors.

16.8.7 Project Checkpoint

For this chapter's project checkpoint, you'll design and document the complete RACF security profile set for the HA banking system's CICS layer. This includes:

1. All SIT security parameters for each region (TOR-1, TOR-2, AOR-PAY, AOR-ACCT, AOR-LOAN, FOR)
2. RACF class definitions and profile naming conventions
3. Transaction security profiles for all banking transactions
4. Resource-level security profiles for all files and queues
5. Surrogate user definitions for web service integration
6. Command security profiles for operator/admin separation
7. Audit configuration (SMF, journals, monitoring rules)

See code/project-checkpoint.md for the full checkpoint specification.

Chapter Summary

Let me bring this full circle to the threshold concept we opened with: security is not a feature — it's an architecture layer. Every topic in this chapter — RACF integration, transaction security, resource-level security, surrogate processing, compliance frameworks, audit trails, security testing — is a facet of the same architectural reality. You can't add security to a CICS system after the fact any more than you can add a foundation to a building after it's built. You have to design it in from the beginning, and it has to permeate every decision.

The key takeaways:

1. RACF-CICS integration works through SAF — CICS calls SAF, SAF routes to RACF, RACF decides. Every security check follows this path.

2. Five security levels work together — sign-on, transaction, resource, command, and surrogate security are complementary layers, not alternatives. Implementing only one leaves gaps.

3. Region topology affects security — your MRO architecture determines where security checks happen and how security contexts propagate. Every region needs SEC=YES.

4. Surrogate user processing is essential for web services — modern CICS systems must handle API and web service connections where the end user's identity must be carried through a service userid.

5. Compliance requires evidence — PCI-DSS, HIPAA, and SOX don't just require security controls; they require proof that the controls work. SMF records, CICS journals, and SIEM integration provide that proof.

6. Test the negative cases — security testing means verifying that unauthorized users are denied, not just that authorized users succeed. Automated security validation using EXEC CICS QUERY SECURITY scales this across hundreds of profiles.

7. Security must be as available as the system — in an HA architecture, security components (RACF databases, certificates, surrogate definitions) must be replicated and maintained at all sites.

The threshold concept for this chapter — that security is an architecture layer, not a bolted-on feature — should now be concrete. You've seen how security decisions affect region topology, transaction design, application code, and operational procedures. In the next chapters, as we build out the HA banking system's CICS layer, every design decision will pass through this security architecture.

Next: Chapter 17 builds on the security foundation established here to address CICS performance tuning — because security and performance are often in tension, and the architect's job is to balance them without compromising either.