Manage Learn to apply best practices and optimize your operations.

Mainframe security best practices for compliance with PCI DSS

Mainframe security is a largely overlooked topic by QSAs assessing compliance with PCI DSS, but expert Mike Villegas explains why enterprises can't ignore the key security controls to ensure mainframe compliance.

This Content Component encountered an error

The System/360 -- announced in April 1964 -- represented the first basic reorganization of the electronic computer...

by IBM since the development of the 701 in 1952. While there are fewer today than in the 1980s, the mainframe computer remains an enormous (pun intended) part of the core IT infrastructure of the biggest enterprises, especially retailers, and yet few understand the nuance of mainframe data security.

How widely used is the mainframe today? Consider these data points from IBM (.pptx): As of 2013, all 65 of the world's biggest banks -- and all but one of the top 25 U.S. retailers -- use mainframes; 80% of the world's corporate data is still managed by mainframes; and two-thirds of all U.S. banks' business transactions run on mainframes.

PCI DSS compliance assessment

The primary focus of the Payment Card Industry Data Security Standard (PCI DSS) is the protection of cardholder data. PCI DSS provides required controls for cardholder data that is stored, processed or transmitted on any platform. Unfortunately, many mainframes are currently not being assessed properly for PCI DSS compliance.

Today, numerous QSAs, merchants and service providers have a disjointed approach to PCI DSS assessments of mainframes. They will either consider the mainframe out-of-scope due to its tenured security or, if they can't justify excluding it from the assessment since it's viewed as a glorified file server, decide that all application environments are now in scope.

Let's discuss the security controls inherent to mainframes, and then how to apply PCI DSS requirements to mainframes within the cardholder data environment.

External security management systems

Mainframes have three external security management systems (ESMs) used for data and access protection: IBM's RACF, CA-TopSecret and CA-ACF2. Mainframe assessors not trained on or with limited exposure to these platforms will run a RACF DSMON, TopSecret TSSAAUDIT report or ACF SHOW ALL command that provides global security options at the OS level, but doing so still fails to give detailed protection of cardholder data. A third-party security monitoring and protection product -- such as those from Vanguard or CA -- can help if in place, but even still, those products operate primarily at the OS level, and may not be sufficient to thoroughly assess PCI DSS compliance of cardholder data.

Why is such scrutiny of mainframe security controls important? The majority of payments today touch or are processed on mainframes, regardless of whether the merchant or service provider is aware of it.

Not having sufficient understanding of mainframe security constructs is not a valid reason to ignore them or justify minimizing the risk of cardholder data on insecure mainframes.

Since the 1980's, ESMs for mainframes have become feature-rich, robust and expansive. Consequently, many QSAs are less concerned with PCI cardholder data on the mainframe. They believe that the mainframe is so secure because of ESMs, they would rather focus on the ubiquitous server environment. The server environment certainly requires attention. However, ESM security features are installation-selectable. This means installations can choose to activate them -- or not. Security professionals and IT auditors who perform mainframe ESM assessments invariably find these features turned off for performance, cost and inconvenience reasons. This not only affects PCI compliance, but can also put cardholder data on those systems at risk.

Understanding PCI DSS mainframe requirements

Ignorance is not a control. Not having sufficient understanding of mainframe security constructs is not a valid reason to ignore them or justify minimizing the risk of cardholder data on insecure mainframes. Assuming few individuals know how to exploit mainframe vulnerabilities is unwise and portends negative results. Most QSAs and penetration testers don't have a background in mainframes and thus don't know how to exploit even the simplest vulnerability. However, remember attackers only need to be right once.

Below is an outline of PCI DSS requirements and how they should be applied to z\OS subsystems within the cardholder data environment. This is not an exhaustive list, but it represents various areas that are emblematic of z\OS-neglected environments.

PCI DSS requirement Mainframe Cardholder Environment (CDE)
1. Install and maintain a firewall configuration to protect cardholder data. Network security using and configuring System Network Architecture (SNA), SNA subnets to ensure CDE is segmented from non-PCI environments.
2. Do not use vendor-supplied defaults for system passwords and other security parameters. All mainframe system software had vendor-supplied defaults such as z\OS, ESM products, databases, job schedulers, OLTPs, etc.
3. Protect stored cardholder data. PAN scans, PAN/SAD/Track Data/PIN storage, protection and management of keys used for encryption of cardholder data.
4. Encrypt transmission of cardholder data across open, public networks. Protect, encrypt and monitor RJE/NJE, telnet, SFTP and VPN channels that transmit CHD across external networks.
5. Protect all systems against malware and regularly update antivirus software or programs. Although this appears to be non-existent, history shows numerous system utilities, modules, exits and privileged programs can be high jacked that bypass ESM and z\OS controls.
6. Develop and maintain secure systems and applications. Secure coding standards are not new to the Web or .NET environments. Cobol, C, C++, COBOL, PL/I, Fortran and Assembler (BAL) applications. Change control is also required.
7. Restrict access to cardholder data by business need-to-know. RBAC, SOD (separation of duties) and principle of least privilege have been mainframe terms since the 1970's that still exist today.
8. Identify and authenticate access to system components. I-A-A: identification, authentication, authorization. Unique identifiers per individuals, accountability and audit trail integrity.
9. Restrict physical access to cardholder data. Colocations, in-house data centers, physical security, environmental controls.
10. Track and monitor all access to network resources and cardholder data. SMF logs, system logs, application logs, trace logs, database logs, network sniffers and related monitoring and follow up.
11. Regularly test security systems and processes. z\OS technical reviews, CICS\IMS online transaction system reviews, z\OS system software reviews, DB2/IMS database reviews.
12. Maintain a policy that addresses information security for all personnel. Enterprise security policies include all personnel. Mainframe staff is not an exception.

Conclusion

PCI DSS does not take a holistic approach to security. In the pre-PCI DSS information security world, these 12 requirements cover what would otherwise be considered sound, yet basic, security. Protection of cardholder data that PCI DSS proposes should not be conditionally excluded because the cardholder data environment is not fully understood. This also includes issuing and acquiring financial institutions whose payment processing is predominantly mainframes -- but that is yet another neglected topic.

About the author:
Miguel (Mike) O. Villegas is Vice President for K3DES LLC, a payment and technology-consulting firm. Mike has been a CISO for a large online retailer, partner for a "Big Four" consulting firm, VP of IT Risk Management, IT Audit Director for large commercial banks and owner of an information security professionals firm over a span of 30 years.

Next Steps

Want to test your mainframe knowledge? Take our refresher quiz.

This was last published in October 2014

Dig Deeper on PCI Data Security Standard

This Content Component encountered an error
This Content Component encountered an error

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close