longpelaexpertise.com.au/ezine/AuditzOS.php?ezinemode=printfriend

LongEx Mainframe Quarterly - November 2009

management: Is z/OS Too Hard to Audit?

Many auditors are terrified of their z/OS systems. They know that these systems are critical to their organisation, hold the most sensitive data, and that do more processing than most other platforms combined. They are very aware that mainframes have more applications, files, users, and administrators than anything else. They know that z/OS systems are very complex.

These auditors see two options: get someone else to audit the z/OS systems, or don't audit them at all. With constricting budgets and increasing compliance workloads on other systems, it's easy to choose the second option. After all, z/OS is the most secure operating system on the planet.

But the reality is that because of their importance, z/OS systems need to be audited at least as often as other systems, if not more. With far more users, administrators, applications and databases, the risk of an internal security incident is higher. Companies that have outsourced some or all of their mainframe operations and support are even more at risk, having surrendered control to a third party.

But why is z/OS such a brute to audit? And more importantly, how can it be done without blowing the budget?

Why is z/OS So Difficult to Audit?

Like an old house that has undergone countless renovations and modifications, z/OS is a complex mixture of what was needed before, what is needed now, and what is needed to get the two to work together. Original features that were essential 40 years ago are still supported today, and have been added to with functionality like UNIX Systems Services (a POSIX shell for z/OS), cryptographic features, TCPIP, and new languages such as Java, C, PHP and Perl. Other software written for z/OS has undergone similar changes. Software like RACF, IMS and CICS are very different to what they were twenty years ago to make them relevant to the needs of today.

To make things more difficult, most organisations with a mainframe have been running the same applications for decades: applications that have had to undergo similar transformations to the systems software under which they run. Business units have been reformed again and again, constantly changing security access requirements, and how they are administered and monitored.

z/OS provides remarkable recording features requiring minimal processor overhead, based on the System Management Facility (SMF). SMF can record every logon, file and application access, rule change, and security failure. Such recording provides an enormous number of records that needs software (such as CA-MICS, Tivoli Decision Support or SAS/MXG), and technical knowledge of this software to process.

All of this adds up to an incredibly complex mixture of features, functionality and administrative tools that is difficult for a subject matter expert to keep track of, far less someone new to the z/OS world.

How Can You Audit z/OS?

The easiest way to audit z/OS is to get an external company to do it. However this isn't the only answer - or the cheapest. Although a security audit of z/OS is a large project, it is not impossible to do it in-house, even for an auditor new to the platform. However two things are essential:

A technical expert
A CAAT

1. A technical expert

No auditor will have the z/OS technical expertise to perform a comprehensive audit of z/OS. An expert with current, in-depth knowledge of z/OS and other systems software is essential: a systems programmer. This systems programmer will:

Assist in customising security and audit software.
Identify reports required, and work with decision support software to prepare them.
Assist in preparing a work program.
Analyse reports and systems, identifying true security exposures, and find sustainable ways to eliminate them.
Work with in-house security and technical teams to eliminate security exposures.
Setup procedures and utilities to periodically perform relevant security checks in the future.
Identify candidates for future or follow-up audits.

Companies that have not outsourced their mainframe operations will have in-house systems programmers available. However auditors will prefer an external consulting systems programmer that is independent from the groups being audited. An in-house audit with such a consultant will cost far less than hiring an external company to do the whole project. Additional advantages include keeping control, and retaining mainframe-related skills gained during the project.

2. A CAAT

As z/OS is so complex, the number of parameters, rules and records to analyse in an audit can quickly get out of control. Anything more than the most minimal audit will need the use of commercial software for most of the 'leg work' - Computer Aided Audit Tools (CAATs).

These tools run on z/OS, and typically analyse the

system setup, including parameter libraries, key system files and z/OS program libraries
security databases
historical records (including SMF records)

From this, the software can identify potential security exposures, and even recommend how to eliminate them. A big advantage of CAATs is that they can ease the pain of creating a work program.

Some popular CAATs for z/OS include (in no particular order):

Janus ICU. z/OS analysis tool.
IBM Tivoli zSecure Audit (previously Consul zAudit). Another z/OS analysis tool.
CA-Auditor for z/OS (previously CA-Examine Audit). Another choice to audit z/OS.
Beta 88 zSecurity Auditor. More z/OS audit options.
Vanguard Analyzer. Vanguard's RACF analysis tool
IBM DB2 Audit Management Expert for z/OS. DB2 analysis tool.
IBM IMS Audit Management Expert for z/OS. IMS analysis tool.

These CAATs are invaluable when performing a detailed audit, however they can't check everything. For example, they won't check the security of ISV products that provide powerful system utilities and features like operator commands.

Nor are CAATs a replacement for technical expertise. A z/OS expert is still needed to setup this software, identify what reports are needed, analyse those reports, and look for reasons behind the report findings. Resist any urge to rely blindly on the reports generated from this software.

Some Hints When Auditing

Set a Reasonable Scope

Few audits will attempt to audit the entire z/OS system in one hit. Most will break the problem up into easier pieces: audit the base z/OS systems one year, DB2 databases the next. Its important not to underestimate the work involved in a z/OS audit, and bite off more than you can chew.

Of course this scope may be set for you by compliance requirements such as Sarbanes-Oxley, CLERP 9 and ISO/IEC 27001/27002. Some of the resources mentioned below can help determine your audit scope.

Setup Ongoing Procedures

Most z/OS audits are one-off projects, however it's no surprise to any auditor that ongoing, regular checks are far more effective. The fact is that most of the work required to produce regular audit reports will be done during any one-off audit. A systems programmer can quickly prepare regular, automatically submitted batch jobs to prepare audit reports for review by auditors and security administrators.

Conclusion

There's no reason to be afraid of z/OS. Although an audit is a large project, it's not impossible to perform, and will become easier the more often it is done. Hiring an external company to perform the entire audit is a valid option, however auditors on a tight budget will want to consider performing the audit in-house using an external z/OS technical expert and audit software.

References

z/OS

Auditors new to z/OS will need to find their feet fast:

What On Earth is a Mainframe. An easy-to-read book providing an independent introduction to mainframes, z/OS and related systems like CICS, IMS and DB2.
Introduction to the New Mainframe: z/OS Basics. IBM's free Redbook is a more detailed and formal introduction to z/OS.
Introduction to the New Mainframe: Security. Another free Redbook from IBM introducing security on the mainframe.
Mainframe Basics for Security Professionals: Getting Started with RACF. Another book by IBM, however this one isn't free. An introduction to RACF for the mainframe-challenged.
z/OS Basic Skills Information Centre. IBMs starting point for basic z/OS information.

IBM also provides copies of its technical manuals free online. Unfortunately these manuals are not an easy read, especially for beginners.

z/OS Security

Three invaluable resources are::

The book OS/390-z/OS Security, Audit and Control Features. This is perhaps the best book available to auditors working with z/OS. Not only does it give comprehensive coverage of security implications of all relevant z/OS features, but includes a sample work program. Unlike many other z/OS related books, this was published in 2004, so is relatively up to date.
The ISACA z/OS Security Audit / Assurance Program. This provides a starting point for creating a work program. Free for ISACA members, non-members will need to pay US$45.
AuditNet has some free work programs submitted by members. However carefully check these programs – many older programs won't have information on more recent z/OS developments.

Other z/OS security related resources include:

IBM Redbooks and Redpapers. IBM has many Redbooks dealing with security on z/OS. Some of the better ones include:
RACF-L Discussion List – RACF questions and answers on a free mailing list.
Share User's Group Security and Audit Project - presentations on z/OS security and audit.
Auditing CICS - A Beginner's Guide. New Era Software have produced a beginner's guide to auditing CICS systems.
Henderson Group – Mainframe security articles, and the newsletter Mainframe Audit News.

This article was updated in Dec-2011 to update the available CAAT software

David Stephens