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.

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

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

I agree that “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.” I’m concerned that “financial institutions“ are increasingly targeted by hackers. We read that investigators believe the same hackers who recently stole data from J.P. Morgan Chase computers also were able to steal information from Fidelity Investments. There are so many ways to attack our systems at different points across the entire data flow and I think it is time to secure the sensitive data in the entire data flow with modern approaches. Recent studies reported that data tokenization for PCI and PII data can cut security incidents by 50 %. Tokenization can also exclude systems from most PCI DSS requirements (out-of-scope). Ulf Mattsson, CTO Protegrity
Cancel
Great article!
Cancel

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close