In the security world, few stories receive more headlines than credit card breaches. The headlines are littered with these cases because credit card breaches affect consumers who might otherwise never think twice about data security.

That’s part of the reason why credit card companies formed up to create the Payment Card Industry Security Standards Council (PCI SSC), which is managed jointly by American Express, VISA, MasterCard, Discover, and JCB International. The PCI Data Security Standards (DSS) were developed to create controls for merchants that store, process, or transmit cardholder data on any platform.

Ultimately, that means that IT professionals are tasked with making sure their organizations are adequately protecting cardholder data. That includes mainframe professionals – 87 percent of the world’s credit card transactions are processed on the mainframe. And yet, many mainframes are currently not being evaluated correctly for PCI DSS compliance.

PCI Standards on the Mainframe

The mainframe is the most “securable” of any of the PCI platforms available today. Weak External Security Manager (ESM) implementations, improperly managed operating system controls, or software coding vulnerabilities will leave a company prone to attack. Implementing modern security controls can help prevent these types of attacks.

Why is it so difficult to manage PCI compliance in a mainframe environment?

Mainframe operations is sort of a specialized art, and unless you’ve had experience in that world, applying PCI to the mainframe can present unique challenges. The DSS isn’t necessarily written to deal with the complexities of mainframe security, and yet PCI compliance guidelines often require you to have a deep technical understanding of the technology you’re working with in order to reach compliance.

Also, current-day security testing practices, techniques, and vulnerability management systems don’t actively research or address systems and applications. This leaves security practitioners and auditors at somewhat of an unknown from a security posture.

What challenges might CIOs encounter when trying to comply with the PCI DSS?

PCI requires that you patch critical security vulnerabilities within a certain period. It’s resource-intensive work: a patch list could have hundreds of patches, and they take time to apply across the enterprise.

A common challenge with the mainframe is simply identifying whether you have the most recent patches.  There is no public database that tracks mainframe integrity vulnerabilities or fixes. Mainframe operations will need to check with their vendors to see if they’re up to date on patches. Vendors don’t share the details explaining why a patch was released. So, it’s very hard to get a list of recently discovered vulnerabilities.

In the case of mainframe code vulnerabilities, this is a danger because it means that zero-day vulnerabilities can be researched, and exploits developed anywhere.  The exploits can be “imported” into any mainframe environment. It is not a viable risk assumption that few individuals, with access to the mainframe operating environment, would have the expertise to carry out an attack. There is a significant distinction between developing an exploit and being able to execute it. Most software code vulnerabilities can be exploited using a CLIST or REXX Exec. Assuming only a few individuals know how to exploit mainframe vulnerabilities is unwise.

That makes it hard to follow another requirement under PCI, which states that companies should create a risk-ranking process, in which they identify and evaluate newly discovered mainframe security vulnerabilities that might have an impact on their organization. The lack of transparency and public reporting around mainframe vulnerabilities means organizations have a hard time satisfying this requirement.

So, what’s the best way to securely manage cardholder data on the mainframe?

PCI is an open book test. If you get the right stakeholders using the correct technology in the room with experts who know the regulations, there’s no reason to fail this. You have to get the full organization on board to understand the challenges and come up with the right kind of program that keeps data safe and saves you money in the long run, rather than labeling PCI testing as an IT issue or security issue.

As you dig in, you’re going to have hard questions. Some organizations must fundamentally look at how they do business and decide if something needs to change so they can meet security and compliance requirements.

PCI is pass/fail: You’re either compliant or not. This is not a job for two weeks before your audits. You want to have it well planned out and integrated into your organization’s control structure.

PCI DSS Requirements

The following is a list of pertinent PCI DSS requirements and how they should be applied to mainframes, ESM’s, and z\OS subsystems within the cardholder data environment.

Click to learn how Key Resources keeps customers PCI compliant

All mainframe system software comes with vendor-supplied defaults for z/OS, ESM products, databases, job schedulers, and OLTPs. Automated configuration reviews can be performed using the z/Assure® CAM product to validate that defaults have been removed.

It is a known fact that system utilities, exits, and privileged programs if coded improperly, can be exploited and bypass ESM and z/OS controls. Vulnerability scans should be performed as part of a company’s standard Q/A process using z/Assure VAP.

System Integrity and secure coding standards are not new to z/OS. Vulnerability scans should be performed as part of a company’s standard Q/A process using z/Assure VAP to make sure the operating system layer is secure. Web applications are also susceptible to exposure to credit card information.

The principle of least privilege has been a standard within the mainframe security industry since the 1970s. Automated configuration reviews can be performed using the z/Assure® CAM product to validate access controls are following the company’s security policy.

Automated configuration reviews can be performed using the z/Assure® CAM product to confirm user authentication and authorization.

Automated configuration reviews can be performed using the z/Assure® CAM product to validate the ESM security baseline against the current security policy, as well as z/OS operating system security parameters, and DISA STIGs.

Automated configuration reviews can be performed using the z/Assure® CAM product to validate company security policy follows current DoD DISA Standards and meet PCI standards.