Case Study 1: City National Bank's PCI-DSS CICS Security Audit

Background

City National Bank (CNB) processes approximately 2.4 million debit and credit card transactions per month through their CICS-based core banking system. As a PCI-DSS Level 1 service provider, CNB undergoes an annual Qualified Security Assessor (QSA) audit. This year's audit is three months away, and the internal pre-assessment has revealed significant gaps in their CICS security posture.

Kwame Asante, the lead systems programmer, has been tasked with remediating the findings before the QSA arrives. Lisa Park, the security architect, is responsible for RACF profile design. Rob Chen, the CICS technical lead, is responsible for SIT and CSD configuration changes.

The Current State

The pre-assessment team identified the following findings mapped to PCI-DSS requirements:

Finding 1 — PCI-DSS Req 2: Vendor-Supplied Defaults (CRITICAL)

Three CICS regions still have the default CICS userid (CICSUSER) active with a known password. The CICSUSER userid has READ access to the TCICSTRN default profile, meaning it can execute any transaction without a specific deny. Additionally, the CEDF (CICS debugging) and CECI (CICS command interpreter) transactions are available in two production regions with no access restrictions.

Kwame's assessment: "CICSUSER has been active since we installed these regions in 2009. Nobody uses it — it's just there. But it's a standing invitation. CEDF in production is worse — it lets anyone step through live transactions and inspect working storage, including cardholder data fields."

Finding 2 — PCI-DSS Req 7: Restrict Access by Business Need (HIGH)

The CICS security model uses only two RACF groups for application access: CNBALL (all users, READ access to all transactions) and CNBADMIN (administrators, ALTER access to everything). There is no role-based segmentation. A teller can execute loan officer transactions. A loan officer can execute administrative transactions. The only restriction is whether a user is in CNBALL or CNBADMIN.

Lisa's assessment: "This is binary security — you're either in or you're out. There's no least privilege. We need to decompose CNBALL into at least six role-based groups and redefine every transaction profile."

Finding 3 — PCI-DSS Req 10: Track and Monitor All Access (HIGH)

SMF recording is enabled, but: - CICS monitoring class 3 (performance) is active; class 4 (exception) is not - No RACF AUDIT attributes are set on any CICS resource profiles - No CICS journaling is configured for application-level audit trails - SMF data is retained for only 30 days (PCI-DSS requires 1 year) - No SIEM integration exists — SMF data is reviewed only during incident investigations

Rob's assessment: "We're generating transaction performance data for capacity planning, but we've got zero security audit capability. If someone exfiltrated cardholder data last Tuesday, we couldn't tell you."

Finding 4 — PCI-DSS Req 3: Protect Stored Cardholder Data (HIGH)

The CICS files containing Primary Account Numbers (PANs) have no resource-level security. XFCT=NO in all production CICS SITs. Any user who can execute a transaction that opens the card data file gets full read/write access regardless of their role.

Finding 5 — PCI-DSS Req 8: Identify and Authenticate Users (MEDIUM)

The web service interface to the mobile banking app uses a single shared userid (WEBSVC01) for all API transactions. There is no surrogate user processing. Every mobile banking customer's transaction runs under the same WEBSVC01 identity. Audit trails for web transactions cannot be attributed to individual customers.

The Remediation Plan

Kwame, Lisa, and Rob developed a six-week remediation plan with three phases.

Phase 1: Critical Fixes (Weeks 1-2)

Task 1.1: Eliminate vendor defaults

Lisa generated the RACF commands:

* Revoke CICSUSER in all production regions
ALU CICSUSER REVOKE

* Revoke any other default/well-known userids
ALU DFHUSER REVOKE
ALU WEBUSER REVOKE

* Verify revocation
LU CICSUSER
LU DFHUSER
LU WEBUSER

Rob removed CEDF and CECI from the production CSD:

CEDA DELETE TRANSACTION(CEDF) GROUP(DFHOPER)
CEDA DELETE TRANSACTION(CECI) GROUP(DFHOPER)

And installed the change:

CEDA INSTALL GROUP(DFHOPER)

Task 1.2: Enable file security

Rob updated the SIT for all production CICS regions:

* Before (insecure)
XFCT=NO

* After (secure)
XFCT=YES

But this required Lisa to define RACF profiles for every CICS file before the SIT change took effect — otherwise, with XFCT=YES and no profiles, the XDFTRAN behavior would apply to files (depending on the region's default settings).

Lisa created profiles for the 47 files in the cardholder data environment (CDE):

* Card data files - extremely restricted
RDEFINE FCICSFCT CICSPROD.CARDMAST UACC(NONE) AUDIT(ALL)
PERMIT CICSPROD.CARDMAST CLASS(FCICSFCT) ID(CNBCARD) ACCESS(UPDATE)
PERMIT CICSPROD.CARDMAST CLASS(FCICSFCT) ID(CNBAUDIT) ACCESS(READ)

RDEFINE FCICSFCT CICSPROD.CARDTXN UACC(NONE) AUDIT(ALL)
PERMIT CICSPROD.CARDTXN CLASS(FCICSFCT) ID(CNBCARD) ACCESS(UPDATE)
PERMIT CICSPROD.CARDTXN CLASS(FCICSFCT) ID(CNBAUDIT) ACCESS(READ)

* Non-CDE files - standard security
RDEFINE FCICSFCT CICSPROD.CUSTMAST UACC(NONE) AUDIT(FAILURES)
PERMIT CICSPROD.CUSTMAST CLASS(FCICSFCT) ID(CNBTLR) ACCESS(READ)
PERMIT CICSPROD.CUSTMAST CLASS(FCICSFCT) ID(CNBSUPTL) ACCESS(UPDATE)
...
* (45 more file profiles)

Note the AUDIT(ALL) on CDE files and AUDIT(FAILURES) on non-CDE files. PCI-DSS Requirement 10 requires audit trails for all access to cardholder data — not just failures.

Phase 2: Role-Based Access (Weeks 3-4)

Task 2.1: Decompose the CNBALL group

Lisa designed six role-based groups to replace CNBALL:

The migration from CNBALL to role-based groups required careful coordination:

* Step 1: Define new groups
ADDGROUP CNBTLR  OWNER(SECADMIN) SUPGROUP(CNBGRPS)
ADDGROUP CNBSUPTL OWNER(SECADMIN) SUPGROUP(CNBGRPS)
ADDGROUP CNBLOAN  OWNER(SECADMIN) SUPGROUP(CNBGRPS)
ADDGROUP CNBCARD  OWNER(SECADMIN) SUPGROUP(CNBGRPS)
ADDGROUP CNBCSOP  OWNER(SECADMIN) SUPGROUP(CNBGRPS)
ADDGROUP CNBAUDIT OWNER(SECADMIN) SUPGROUP(CNBGRPS)

* Step 2: Assign users to groups (example for tellers)
CONNECT JSMITH GROUP(CNBTLR)
CONNECT KLEE   GROUP(CNBTLR)
... (340 CONNECT commands generated from HR role data)

* Step 3: Define transaction profiles with new groups
RDEFINE TCICSTRN CICSPROD.TINQ UACC(NONE)
PERMIT CICSPROD.TINQ CLASS(TCICSTRN) ID(CNBTLR CNBSUPTL CNBLOAN CNBAUDIT) ACCESS(READ)

RDEFINE TCICSTRN CICSPROD.TDEP UACC(NONE)
PERMIT CICSPROD.TDEP CLASS(TCICSTRN) ID(CNBTLR CNBSUPTL) ACCESS(READ)

... (profiles for all 47 transactions)

* Step 4: Remove the old CNBALL group from all profiles
* (After verifying the new groups work correctly)

The rollout strategy: Lisa didn't flip the switch overnight. She used RACF's WARNING mode:

RDEFINE TCICSTRN CICSPROD.TINQ UACC(NONE) WARNING

In WARNING mode, RACF evaluates the profile but doesn't enforce it — it logs what would happen. This allowed the team to run for one week in WARNING mode, analyze the logs to identify any users who would be incorrectly denied, and fix the profiles before switching to enforcing mode.

After the WARNING week, Lisa found: - 14 users who were assigned to the wrong RACF group (tellers who also processed loan applications, not reflected in the role mapping) - 3 transactions that were missing from the profile definitions entirely - 1 batch userid that wasn't in any of the new groups

All issues were fixed before enforcement mode was activated.

Task 2.2: Activate resource security on all transactions

Rob updated every production transaction definition to include RESSEC(YES):

CEDA ALTER TRANSACTION(TINQ) GROUP(TELLER) RESSEC(YES)
CEDA ALTER TRANSACTION(TDEP) GROUP(TELLER) RESSEC(YES)
... (47 transactions)
CEDA INSTALL GROUP(TELLER)

Phase 3: Audit Trail and Monitoring (Weeks 5-6)

Task 3.1: Enable comprehensive SMF recording

Rob updated the SIT and MCT:

* SIT changes
SMF=YES
SMFCOMP=YES

* MCT changes (add exception monitoring)
DFHMCT TYPE=RECORD,CLASS=4,STATUS=ACTIVE

Task 3.2: Configure RACF auditing

Lisa added AUDIT attributes to all CDE resource profiles:

RALTER TCICSTRN CICSPROD.TCRD AUDIT(ALL)
RALTER FCICSFCT CICSPROD.CARDMAST AUDIT(ALL)
RALTER FCICSFCT CICSPROD.CARDTXN  AUDIT(ALL)

Task 3.3: Implement application-level journaling

Kwame wrote the AUDITPGM program (similar to the example in code/example-02-audit-program.cbl) and Rob integrated it into every card-data transaction:

* In every CDE transaction, before file access:
MOVE 'CARDREAD' TO WS-AUDIT-ACTION
MOVE 'CARDMAST' TO WS-AUDIT-RESOURCE
EXEC CICS LINK PROGRAM('AUDITPGM')
    COMMAREA(WS-AUDIT-RECORD)
    LENGTH(LENGTH OF WS-AUDIT-RECORD)
END-EXEC

Task 3.4: Extend SMF retention and integrate with SIEM

The storage team reconfigured SMF archival to retain 13 months of data (1 year + 1 month buffer). The security team configured Splunk forwarders to ingest SMF 80 and SMF 110 records in near-real-time.

Task 3.5: Implement surrogate user processing for web services

Rob enabled XUSER=YES in the TOR SIT. Lisa defined surrogate profiles:

* Allow WEBSVC01 to act as surrogate for mobile banking users
RDEFINE SURROGAT *.DFHSTART UACC(NONE)
* (This is deliberately restrictive - deny all by default)

* Create a group for mobile banking end users
ADDGROUP CNBMOB OWNER(SECADMIN) SUPGROUP(CNBGRPS)

* Allow WEBSVC01 to assume identities in CNBMOB group
* Using generic profiles with group-level SURROGAT

Kwame modified the web service bridge program to perform surrogate sign-on using the end user's identity extracted from the JWT token:

EXEC CICS VERIFY TOKEN(WS-JWT-TOKEN)
    TOKENTYPE('JWT')
    USERID(WS-END-USER-ID)
    RESP(WS-RESP)
END-EXEC

IF WS-RESP = DFHRESP(NORMAL)
    EXEC CICS START TRANSID('TMOB')
        USERID(WS-END-USER-ID)
        FROM(WS-REQUEST-DATA)
        LENGTH(WS-DATA-LEN)
    END-EXEC
END-IF

The Audit Result

The QSA arrived three months later and conducted a five-day on-site assessment. Key findings from the CICS portion:

Req 2 — PASS: No vendor defaults found. CEDF and CECI removed from production. All production regions use customized SIT parameters.

Req 3 — PASS: Cardholder data files secured with RACF profiles, UACC(NONE), and access limited to the CNBCARD group. AUDIT(ALL) enabled.

Req 7 — PASS: Six role-based RACF groups with documented role-to-group mappings. Quarterly access reviews scheduled. Least privilege demonstrated through the security test matrix.

Req 8 — PASS with OBSERVATION: Surrogate user processing implemented. The QSA noted that the mobile banking channel now attributes transactions to individual users. However, the QSA observed that the JWT token validation should use asymmetric keys rather than shared secrets. This was noted as an observation for next year's assessment, not a finding.

Req 10 — PASS: SMF 110 and SMF 80 records captured for all CDE transactions. Application-level journal records provide business-context audit data. 13-month retention with Splunk integration for real-time monitoring. The QSA verified audit trail integrity by requesting specific transaction records from six months ago — all were retrievable within minutes.

Discussion Questions

1. Phased Rollout: Lisa's use of RACF WARNING mode before enforcing the new profiles prevented a disruption to 490 users. What other strategies could be used to safely migrate from a permissive security model to a restrictive one?

2. Role Mapping: The pre-enforcement analysis found 14 users in the wrong groups. In a larger organization (10,000+ users), how would you systematically validate role-to-group mappings before enforcement?

3. Audit Trail Completeness: The QSA accepted the combination of SMF 110, SMF 80, and CICS journal records as a complete audit trail. Could a determined attacker modify all three record types? What additional controls would make the audit trail truly tamper-proof?

4. Cost-Benefit: The six-week remediation involved Kwame, Lisa, and Rob working essentially full-time, plus storage team and Splunk licensing costs. How would you present the ROI of this remediation to executive management?

5. Continuous Compliance: Passing the audit once is relatively straightforward. Staying compliant year-round is the real challenge. Design a quarterly security review process that would catch drift before the next annual audit.

6. Surrogate User Limitation: The QSA's observation about JWT token validation using asymmetric keys highlights a common pattern — the initial implementation passes, but there's always room for improvement. What is the security difference between symmetric and asymmetric JWT validation, and why does it matter for CICS web services?