|
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:
David
Stephens
|
