With question marks over ISV program integrity and observed failure of controls to keep pace with changing threats, it may be difficult to truly claim that mainframe deployments in practice are either secure or unhackable. The tools needed to achieve the required levels of security are available, but we need to use them wisely. System z is the most securable platform, but it takes skill and effort to ensure it remains the most secure.

Secure for Compliance, Don’t Comply for Security

What impact do compliance regimes have on our security considerations? Here, we refer to compliance with standards and regulations that deal with IT security either directly or indirectly such as:

• Sarbanes-Oxley (SOX)
• Gramm-Leach-Bliley Act (GLBA)
• Basel II
• Health Information Portability and Accountability Act (HIPAA)
• Payment Card Industry Data Security Standard (PCI DSS)  
• The International Organization for Standardization (ISO) 27001 standards.

As we noted in “Practically Secure” in June (http://bit.ly/9bGUOn), it’s possible to be compliant with one or more of these security standards, yet be woefully insecure in general.  

Generally, compliance auditors are not technicians and are unfamiliar with the mainframe. Moreover, the burden of compliance efforts on the technicians leaves them less time for genuine security improvements. David Stephens of Australian mainframe consultancy Longpela believes that many auditors are terrified of their z/OS systems. “With constricting budgets and increasing compliance workloads on other systems, it’ss easy to not audit z/OS at all. After all, z/OS is the most secure operating system on the planet” (http://bit.ly/b6EK0d).

Our efforts are diverted into passing the many, varied compliance audits—often by repeatedly gathering evidence to show that sections of the standard don’t apply to us or that we’re operating some banal, shallow controls, such as the common requirement to “Ensure IBMUSER is revoked.” In practice, this does little to improve the mainframe security posture and hampers our security technicians.

To achieve lasting security and compliance, we must revisit the technical documentation, review the current threats, and let our technicians close the gaps with their own skill and expertise. Then we need to invite the technical auditors in so they can write a report that we can use as evidence for all of our compliance audits. In short, we should secure for compliance, not comply for security.

Securable to Secure

Sadly, we’ve dispelled the “fortress mainframe” myth, but it’s not all bad news. Remember that System z is the most securable platform, and that all the tools, techniques, and knowledge are out there to help us make it extremely secure. IBM provides extensive documentation of System z and RACF, while CA provides similar texts for ACF2 and Top Secret. We should follow those and also review other sources of good practice, such as the U.S. Defense Information Services Agency (DISA) Security Technical Implementation Guides (STIGs) (http://bit.ly/dwTjIZ), so we can tackle the vulnerabilities, secure our mainframe, and position for compliance audits.

But we can go much further than security and compliance. We can automate and simplify security processes, integrate mainframe security with distributed systems, and leverage the mainframe security database. Today’s mainframe is an incredible resource in which much money and effort are invested. To make the most of it, we must first seek a mature security position. The rest of this article draws on the whitepaper “5 Steps to Mature System z Security” (available at www.pirean.com) to describe the mainframe security journey.