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):
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:
This article was updated in Dec-2011 to update the available CAAT software
David Stephens
|
Home
| Press
Room | Contact
Us | Site
Map
