Chapter 16 Key Takeaways

Threshold Concept

Security is not a feature — it's an architecture layer. CICS security isn't something you bolt on after the system is designed. It's a fundamental architectural concern that affects region topology, transaction design, application code structure, data flow patterns, and operational procedures. Every design decision in a CICS system has security implications.

Core Principles

1. The Five Layers of CICS Security

CICS security operates through five independent but complementary layers, each controlled by SIT parameters and backed by RACF class definitions:

• Sign-on security (SEC=YES) — authenticating users
• Transaction security (XTRAN=YES) — who can execute what
• Resource-level security (XRES=YES, XFCT=YES, etc.) — who can access which files, queues, programs
• Command security (XCMD=YES) — who can issue system commands
• Surrogate security (XUSER=YES) — who can act on behalf of others

Implementing only one or two layers creates a false sense of security. All five must work together.

2. RACF-CICS Integration

• CICS security calls flow through SAF to RACF
• RACF uses specific classes for CICS resources (TCICSTRN, FCICSFCT, CCICSCMD, etc.)
• Profile naming convention: <APPLID>.<resource-name>
• Security caching (RACLIST + CICS cache) is essential for performance but requires explicit refresh when profiles change

3. Transaction Security

• Controls who can execute which CICS transactions
• UACC(NONE) is the only acceptable default for production
• XDFTRAN=NO prevents undefined transactions from being implicitly allowed
• In MRO environments, check at both TOR and AOR for defense in depth

4. Resource-Level Security

• Transaction security alone is insufficient — it doesn't control what resources a transaction can access
• RESSEC(YES) must be set on each transaction's CSD definition
• File, TSQ, TDQ, and program security are all independent controls
• RACF ACCESS levels (READ, UPDATE, ALTER) map to specific CICS operations

5. Surrogate User Processing

• Essential for web services, APIs, and any non-terminal CICS interaction
• Allows a service userid to execute transactions under an end user's security context
• SURROGAT class profiles control which service userids can assume which identities
• Without surrogate processing, all API transactions run under a single shared identity — an audit trail disaster

6. Compliance Is Evidence-Based

• PCI-DSS, HIPAA, and SOX require not just security controls but proof those controls work
• Three audit mechanisms: SMF 110 (CICS transactions), SMF 80 (RACF decisions), CICS journals (application-level)
• Audit trails must be tamper-proof, retained for required periods, and quickly retrievable
• RACF AUDIT(ALL) for sensitive resources; AUDIT(FAILURES) for everything else

7. Security Testing Must Test the Negative Case

• Verifying that authorized users can access resources is necessary but insufficient
• Security testing must verify that unauthorized users are denied
• EXEC CICS QUERY SECURITY enables automated security validation at scale
• RACF WARNING mode enables safe migration to restrictive security models

Critical Warnings

• Never run AORs or FORs with SEC=NO — internal regions are where privilege escalation succeeds
• XDFTRAN=YES without a restrictive default profile is an open door — undefined transactions will be allowed
• TSQ security is often overlooked — TSQs frequently hold sensitive data during multi-screen transactions
• Certificate expiration breaks DR failovers — validate certificates at all sites regularly
• Audit trail gaps require investigation — gaps often indicate someone disabled logging to perform unauthorized actions
• RACF WARNING mode before enforcement — always run new profiles in WARNING mode first to catch errors before they impact users

Architecture Checklist for the HA Banking System

For the progressive project, ensure your security architecture addresses:

• [ ] SEC=YES on every region (TOR, AOR, FOR)
• [ ] XTRAN=YES with XDFTRAN=NO on every region
• [ ] XFCT=YES, XTST=YES, XDCT=YES on resource-owning regions
• [ ] XCMD=YES on all regions
• [ ] XUSER=YES on TORs handling web service connections
• [ ] Role-based RACF groups with UACC(NONE) everywhere
• [ ] RESSEC(YES) and CMDSEC(YES) on security-sensitive transactions
• [ ] SURROGAT class profiles for all service userids
• [ ] SSL/TLS on all TCP/IP services with certificate management
• [ ] SMF 110 + SMF 80 + CICS journals for complete audit trail
• [ ] SIEM integration with correlation rules for CICS security events
• [ ] DR site security parity (RACF database, certificates, surrogate profiles)
• [ ] Quarterly security review and automated validation processes

Connecting to Previous Chapters

One-Line Summary

Design CICS security as an architecture layer — five complementary security levels backed by RACF, enforced at every region boundary, and proven by tamper-proof audit trails.