COBIT OS Z

z/OS Security Audit/Assurance Program
ISACA®
With more than 86,000 constituents in more than 160 countries, ISACA (www.isaca.org) is a recognized worldwide
leader in IT governance, control, security and assurance. Founded in 1969, ISACA sponsors international
conferences, publishes the ISACA Journal®, and develops international information systems auditing and control
standards. It also administers the globally respected Certified Information Systems Auditor™ (CISA ®) designation,
earned by more than 60,000 professionals since 1978; the Certified Information Security Manager ® (CISM®)
designation, earned by more than 10,000 professionals since 2002; and the new Certified in the Governance of
Enterprise IT™ (CGEIT™) designation.
Disclaimer
ISACA has designed and created z/OS Security Audit/Assurance Program (the “Work”), primarily as an
informational resource for audit and assurance professionals. ISACA makes no claim that use of any of the Work
will assure a successful outcome. The Work should not be considered inclusive of all proper information, procedures
and tests or exclusive of other information, procedures and tests that are reasonably directed to obtaining the same
results. In determining the propriety of any specific information, procedure or test, audit/assurance professionals
should apply their own professional judgment to the specific circumstances presented by the particular systems or IT
environment.
Reservation of Rights
© 2009 ISACA. All rights reserved. No part of this publication may be used, copied, reproduced, modified,
distributed, displayed, stored in a retrieval system or transmitted in any form by any means (electronic, mechanical,
photocopying, recording or otherwise) without the prior written authorization of ISACA. Reproduction and use of
all or portions of this publication are permitted solely for academic, internal and noncommercial use, and
consulting/advisory engagements, and must include full attribution of the material’s source. No other right or
permission is granted with respect to this work.
ISACA
3701 Algonquin Road, Suite 1010
Rolling Meadows, IL 60008 USA
Phone: +1.847.253.1545
Fax: +1.847.253.1443
E-mail: info@isaca.org
Web site: www.isaca.org
ISBN 978-1-60420-084-3
Printed in the United States of America
© 2009 ISACA. All Rights reserved. Page 2

ISACA wishes to recognize:

Author
Norm Kelson, CISA, CGEIT, CPA, The Kelson Group, USA
Expert Reviewers
Gary S. Baker, CA, Deloitte & Touche, Canada
Per Gøbel Jensen, CISA, CISM, VP Securities Services, Denmark
Larry Marks, CISA, CGEIT, CFE, CISSP, CSTE, PMP, Resources Global Professionals, USA
Reinhard Erich Voglmaier, GlaxoSmithKline Spa – Pharmaceuticals, Italy
ISACA Board of Directors

Lynn Lawton, CISA, FBCS, FCA, FIIA, KPMG LLP, UK, International President
George Ataya, CISA, CISM, CGEIT, CISSP, ICT Control SA, Belgium, Vice President
Howard Nicholson, CISA, CGEIT, City of Salisbury, Australia, Vice President
Jose Angel Pena Ibarra, CGEIT, Consultoria en Comunicaciones e Info. SA & CV, Mexico, Vice President
Robert E. Stroud, CA Inc., USA, Vice President
Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Vice President
Frank Yam, CISA, CIA, CCP, CFE, CFSA, FFA, FHKCS, FHKIoD, Focus Strategic Group Inc., Hong Kong, Vice
President
Marios Damianides, CISA, CISM, CA, CPA, Ernst & Young, USA, Past International President
Everett C. Johnson Jr., CPA, Deloitte & Touche LLP (retired), USA, Past International President
Gregory T. Grocholski, CISA, The Dow Chemical Company, USA, Director
Tony Hayes, Queensland Government, Australia, Director
Jo Stewart-Rattray, CISA, CISM, CSEPS, RSM Bird Cameron, Australia, Director
Assurance Committee
Gregory T. Grocholski, CISA, The Dow Chemical Company, USA, Chair
Pippa G. Andrews, CISA, ACA, CIA, Amcor, Australia
Richard Brisebois, CISA, CGA, Office of the Auditor General of Canada, Canada
Sergio Fleginsky, CISA, ICI, Uruguay
Robert Johnson, CISA, CISM, CISSP, Executive Consultant, USA
Anthony P. Noble, CISA, CCP, Viacom Inc., USA
Robert G. Parker, CISA, CA, CMC, FCA, Deloittte & Touche LLP (retired), Canada
Erik Pols, CISA, CISM, Shell International - ITCI, Netherlands
Vatsaraman Venkatakrishnan, CISA, CISM, CGEIT, ACA, Emirates Airlines, UAE

Table of Contents
I. Introduction.........................................................................................................................................4
II. Using This Document..........................................................................................................................5
III. Controls Maturity Analysis..................................................................................................................8
IV. Assurance and Control Framework......................................................................................................9
V. Executive Summary of Audit/Assurance Focus.................................................................................11
VI. Audit/Assurance Program..................................................................................................................13
1. Planning and Scoping the Audit.....................................................................................................13
2. Preparatory Steps...........................................................................................................................15
3. Operating System Configuration...................................................................................................18
4. PARMLIB.....................................................................................................................................20
5. Appendages...................................................................................................................................26
6. Configuration Change Management..............................................................................................39
7. System Backups.............................................................................................................................42
VII. Maturity Assessment.........................................................................................................................43
VIII. Assessment Maturity vs. Target Maturity—z/OS Only....................................................................48
I. Introduction
Overview
ISACA has developed the IT Assurance FrameworkTM (ITAFTM) as a comprehensive and good-practice-
setting model. ITAF provides standards that are designed to be mandatory, and are the guiding principles
under which the IT audit and assurance profession operates. The guidelines provide information and
direction for the practice of IT audit and assurance. The tools and techniques provide methodologies,
tools and templates to provide direction in the application of IT audit and assurance processes.
Purpose
The audit/assurance program is a tool and template to be used as a road map for the completion of a
specific assurance process. The ISACA Assurance Committee has commissioned audit/assurance
programs to be developed for use by IT audit and assurance practitioners. This audit/assurance program is
intended to be utilized by IT audit and assurance professionals with the requisite knowledge of the subject
matter under review, as described in ITAF, section 2200—General Standards. The audit/assurance
programs are part of ITAF, section 4000—IT Assurance Tools and Techniques.
Control Framework
The audit/assurance programs have been developed in alignment with the IT Governance Institute ®
(ITGITM) framework, Control Objectives for Information and related Technology (COBIT®)—specifically
COBIT 4.1—using generally applicable and accepted good practices. They reflect ITAF, sections 3400—
IT Management Processes, 3600-IT Audit and Assurance Processes, and 3800—IT Audit and Assurance
Management.
Many organizations have embraced several frameworks at an enterprise level, including the Committee of
Sponsoring Organizations of the Treadway Commission (COSO) Internal Control Framework. The
importance of the control framework has been enhanced due to regulatory requirements by the US
Securities and Exchange Commission (SEC) as directed by the US Sarbanes-Oxley Act of 2002 and
similar legislation in other countries. They seek to integrate control framework elements used by the
general audit/assurance team into the IT audit and assurance framework. Since COSO is widely used, it

has been selected for inclusion in this audit/assurance program. The reviewer may delete or rename these
columns to align with the enterprise’s control framework.
IT Governance, Risk and Control

IT governance, risk and control are critical in the performance of any assurance management process.
Governance of the process under review will be evaluated as part of the policies and management
oversight controls. Risk plays an important role in evaluating what to audit and how management
approaches and manages risk. Both issues will be evaluated as steps in the audit/asssurance program.
Controls are the primary evaluation point in the process. The audit/assurance program will identify the
control objectives and the steps to determine control design and effectiveness.
Responsibilities of IT Audit and Assurance Professionals

IT audit and assurance professionals are expected to customize this document to the environment in
which they are performing an assurance process. This document is to be used as a review tool and starting
point. It may be modified by the IT audit and assurance professional; it is not intended to be a checklist or
questionnaire. It is assumed that the IT audit and assurance professional holds the Certified Information
Systems Auditor (CISA) designation, or has the necessary subject matter expertise required to conduct the
work and is supervised by a professional with the CISA designation and necessary subject matter
expertise to adequately review the work performed.
II. Using This Document

This audit/assurance program was developed to assist the audit and assurance professional in designing
and executing a review. Details regarding the format and use of the document follow.
Work Program Steps

The first column of the program describes the steps to be performed. The numbering scheme used
provides built-in work paper numbering for ease of cross-reference to the specific work paper for that
section. The physical document was designed in Microsoft ® Word. The IT audit and assurance
professional is encouraged to make modifications to this document to reflect the specific environment
under review.
Step 1 is part of the fact gathering and pre-fieldwork preparation. Because the pre-fieldwork is essential to
a successful and professional review, the steps have been itemized in this plan. The first-level steps, e.g.,
1.1, are in bold type and provide the reviewer with a scope or high-level explanation of the purpose for
the substeps.
Beginning in step 2, the steps associated with the work program are itemized. To simplify the use of the
program, the audit/assurance program describes the audit/assurance objective—the reason for performing
the steps in the topic area. The specific controls follow and are shown in blue type. Each review step is
listed below the control. These steps may include assessing the control design by walking through a
process, interviewing, observing or otherwise verifying the process and the controls that address that
process. In many cases, once the control design has been verified, specific tests need to be performed to
provide assurance that the process associated with the control is being followed.
The maturity assessment, which is described in more detail later in this document, makes up the last
section of the program.
The audit/assurance plan wrap-up—those processes associated with the completion and review of work
papers, preparation of issues and recommendations, report writing and report clearing—has been

excluded from this document, since it is standard for the audit/assurance function and should be identified
elsewhere in the enterprise’s standards.
COBIT Cross-reference
The COBIT cross-reference provides the audit and assurance professional with the ability to refer to the
specific COBIT control objective that supports the audit/assurance step. The C OBIT control objective
should be identified for each audit/assurance step in the section. Multiple cross-references are not
uncommon. Processes at lower levels in the work program are too granular to be cross-referenced to
COBIT. The audit/assurance program is organized in a manner to facilitate an evaluation through a
structure parallel to the development process. COBIT provides in-depth control objectives and suggested
control practices at each level. As the professional reviews each control, he/she should refer to C OBIT or
the IT Assurance Guide: Using COBIT for good-practice control guidance.
COSO Components
As noted in the introduction, COSO and similar frameworks have become increasingly popular among
audit and assurance professionals. This ties the assurance work to the enterprise’s control framework.
While the IT audit/assurance function has COBIT as a framework operational audit and assurance
professionals use the framework established by the enterprise. Since COSO is the most prevalent internal
control framework, it has been included in this document and is a bridge to align IT audit/assurance with
the rest of the audit/assurance function. Many audit/assurance organizations include the COSO control
components within their report and summarize assurance activities to the audit committee of the board of
directors.
For each control, the audit and assurance professional should indicate the COSO component(s) addressed.
It is possible but generally not necessary to extend this analysis to the specific audit step level.
The original COSO internal control framework contained five components. In 2004, COSO was revised
as the Enterprise Risk Management (ERM) Integrated Framework and extended to eight components. The
primary difference between the two frameworks is the additional focus on ERM and integration into the
business decision model. ERM is in the process of being adopted by large enterprises. The two
frameworks are compared in figure 1.
Figure 1—Comparison of the COSO Internal Control and ERM Integrated Frameworks
Internal Control Framework ERM Integrated Framework
Control Environment: The control environment sets the tone of an Internal Environment: The internal environment encompasses the
organization, influencing the control consciousness of its people. It is tone of an organization, and sets the basis for how risk is viewed and
the foundation for all other components of internal control, providing addressed by an entity’s people, including risk management
discipline and structure. Control environment factors include the philosophy and risk appetite, integrity and ethical values, and the
integrity, ethical values, management’s operating style, delegation of environment in which they operate.
authority systems, as well as the processes for managing and
developing people in the organization.
Objective Setting: Objectives must exist before management can
identify potential events affecting their achievement. Enterprise risk
management ensures that management has in place a process to set
objectives and that the chosen objectives support and align with the
entity’s mission and are consistent with its risk appetite.
Event Identification: Internal and external events affecting
achievement of an entity’s objectives must be identified, distinguishing
between risks and opportunities. Opportunities are channeled back to
management’s strategy or objective-setting processes.

Figure 1—Comparison of the COSO Internal Control and ERM Integrated Frameworks
Internal Control Framework ERM Integrated Framework
Risk Assessment: Every entity faces a variety of risks from external Risk Assessment: Risks are analyzed, considering the likelihood and
and internal sources that must be assessed. A precondition to risk impact, as a basis for determining how they could be managed. Risk
assessment is establishment of objectives, and thus risk assessment is areas are assessed on an inherent and residual basis.
the identification and analysis of relevant risks to achievement of
assigned objectives. Risk assessment is a prerequisite for determining
how the risks should be managed.
Risk Response: Management selects risk responses – avoiding,
accepting, reducing, or sharing risk – developing a set of actions to
align risks with the entity’s risk tolerances and risk appetite.
Control Activities: Control activities are the policies and procedures Control Activities: Policies and procedures are established and
that help ensure management directives are carried out. They help implemented to help ensure the risk responses are effectively carried
ensure that necessary actions are taken to address risks to achievement out.
of the entity's objectives. Control activities occur throughout the
organization, at all levels and in all functions. They include a range of
activities as diverse as approvals, authorizations, verifications,
reconciliations, reviews of operating performance, security of assets
and segregation of duties.
Information and Communication: Information systems play a key Information and Communication: Relevant information is
role in internal control systems as they produce reports, including identified, captured, and communicated in a form and timeframe that
operational, financial and compliance-related information that make it enable people to carry out their responsibilities. Effective
possible to run and control the business. In a broader sense, effective communication also occurs in a broader sense, flowing down, across,
communication must ensure information flows down, across and up and up the entity.
the organization. Effective communication should also be ensured with
external parties, such as customers, suppliers, regulators and
shareholders.
Monitoring: Internal control systems need to be monitored—a Monitoring: The entirety of enterprise risk management is monitored
process that assesses the quality of the system’s performance over and modifications made as necessary. Monitoring is accomplished
time. This is accomplished through ongoing monitoring activities or through ongoing management activities, separate evaluations, or both..
separate evaluations. Internal control deficiencies detected through
these monitoring activities should be reported upstream and corrective
actions should be taken to ensure continuous improvement of the
system.
Information for figure 1 was obtained from the COSO web site www.coso.org/aboutus.htm.
The original COSO internal control framework addresses the needs of the IT audit and assurance
professional: control environment, risk assessment, control activities, information and communication,
and monitoring. As such, ISACA has elected to utilize the five-component model for these
audit/assurance programs. As more enterprises implement the ERM model, the additional three columns
can be added, if relevant. When completing the COSO component columns, consider the definitions of
the components as described in figure 1.
Reference/Hyperlink
Good practices require the audit and assurance professional to create a work paper for each line item,
which describes the work performed, issues identified and conclusions. The reference/hyperlink is to be
used to cross-reference the audit/assurance step to the work paper that supports it. The numbering system
of this document provides a ready numbering scheme for the work papers. If desired, a link to the work
paper can be pasted into this column.
Issue Cross-reference
This column can be used to flag a finding/issue that the IT audit and assurance professional wants to
further investigate or establish as a potential finding. The potential findings should be documented in a
work paper that indicates the disposition of the findings (formally reported, reported as a memo or verbal
finding, or waived).

Comments
The comments column can be used to indicate the waiving of a step, or other notations. It is not to be used
in place of a work paper describing the work performed.
III. Controls Maturity Analysis

One of the consistent requests of stakeholders who have undergone IT audit/assurance reviews is a desire
to understand how their performance compares to good practices. Audit and assurance professionals must
provide an objective basis for the review conclusions. Maturity modeling for management and control
over IT processes is based on a method of evaluating the organization, so it can be rated from a maturity
level of nonexistent (0) to optimized (5). This approach is derived from the maturity model that the
Software Engineering Institute (SEI) of Carnegie Mellon University defined for the maturity of software
development.
The IT Assurance Guide Using COBIT, Appendix VII—Maturity Model for Internal Control, in figure 2,
provides a generic maturity model showing the status of the internal control environment and the
establishment of internal controls in an enterprise. It shows how the management of internal control, and
an awareness of the need to establish better internal controls, typically develops from an ad hoc to an
optimized level. The model provides a high-level guide to help COBIT users appreciate what is required
for effective internal controls in IT and to help position their enterprise on the maturity scale.
Figure 2—Maturity Model for Internal Control

Maturity Level Status of the Internal Control Environment Establishment of Internal Controls
0 Non-existent There is no recognition of the need for internal control. There is no intent to assess the need for internal control.
Control is not part of the organization’s culture or mission. Incidents are dealt with as they arise.
There is a high risk of control deficiencies and incidents.
1 Initial/ad hoc There is some recognition of the need for internal control. There is no awareness of the need for assessment of what is
The approach to risk and control requirements is ad hoc and needed in terms of IT controls. When performed, it is only on
disorganized, without communication or monitoring. an ad hoc basis, at a high level and in reaction to significant
Deficiencies are not identified. Employees are not aware of incidents. Assessment addresses only the actual incident.
their responsibilities.
2 Repeatable but Controls are in place but are not documented. Their operation Assessment of control needs occurs only when needed for
Intuitive is dependent on the knowledge and motivation of individuals. selected IT processes to determine the current level of control
Effectiveness is not adequately evaluated. Many control maturity, the target level that should be reached and the gaps
weaknesses exist and are not adequately addressed; the that exist. An informal workshop approach, involving IT
impact can be severe. Management actions to resolve control managers and the team involved in the process, is used to
issues are not prioritized or consistent. Employees may not define an adequate approach to controls for the process and to
be aware of their responsibilities. motivate an agreed-upon action plan.
3 Defined Controls are in place and adequately documented. Operating Critical IT processes are identified based on value and risk
effectiveness is evaluated on a periodic basis and there is an drivers. A detailed analysis is performed to identify control
average number of issues. However, the evaluation process is requirements and the root cause of gaps and to develop
not documented. While management is able to deal improvement opportunities. In addition to facilitated
predictably with most control issues, some control workshops, tools are used and interviews are performed to
weaknesses persist and impacts could still be severe. support the analysis and ensure that an IT process owner
Employees are aware of their responsibilities for control. owns and drives the assessment and improvement process.
4 Managed and There is an effective internal control and risk management IT process criticality is regularly defined with full support
Measurable environment. A formal, documented evaluation of controls and agreement from the relevant business process owners.
occurs frequently. Many controls are automated and regularly Assessment of control requirements is based on policy and
reviewed. Management is likely to detect most control issues, the actual maturity of these processes, following a thorough
but not all issues are routinely identified. There is consistent and measured analysis involving key stakeholders.
follow-up to address identified control weaknesses. A Accountability for these assessments is clear and enforced.
limited, tactical use of technology is applied to automate Improvement strategies are supported by business cases.
controls. Performance in achieving the desired outcomes is
consistently monitored. External control reviews are
organized occasionally.
5 Optimized An enterprisewide risk and control program provides Business changes consider the criticality of IT processes and
continuous and effective control and risk issues resolution. cover any need to reassess process control capability. IT
Internal control and risk management are integrated with process owners regularly perform self-assessments to confirm
enterprise practices, supported with automated real-time that controls are at the right level of maturity to meet business
monitoring with full accountability for control monitoring, needs and they consider maturity attributes to find ways to
risk management and compliance enforcement. Control make controls more efficient and effective. The organization

Figure 2—Maturity Model for Internal Control
Maturity Level Status of the Internal Control Environment Establishment of Internal Controls
evaluation is continuous, based on self-assessments and gap benchmarks to external best practices and seeks external
and root cause analyses. Employees are proactively involved advice on internal control effectiveness. For critical
in control improvements. processes, independent reviews take place to provide
assurance that the controls are at the desired level of maturity
and working as planned.
The maturity model evaluation is one of the final steps in the evaluation process. The IT audit and
assurance professional can address the key controls within the scope of the work program, and formulate
an objective assessment of the maturity levels of the control practices. The maturity assessment can be a
part of the audit/assurance report and can be used as a metric from year to year to document progression
in the enhancement of controls. However, it must be noted that the perception as to the maturity level may
vary between the process/IT asset owner and the auditor. Therefore, an auditor should obtain the
concerned stakeholder’s concurrence before submitting the final report to the management.
At the conclusion of the review, once all findings and recommendations are completed, the professional
assesses the current state of the COBIT control framework and assigns it a maturity level using the six-
level scale. Some practioners utilize decimals (x.25, x.5, x.75) to indicate gradations in the maturity
model. As a further reference, COBIT provides a definition of the maturity designations by control
objective. While this approach is not mandatory, the process is provided as a separate section at the end of
the audit/assurance program for those enterprises that wish to implement it. It is suggested that a maturity
assessment be made at the COBIT control level. To provide further value to the client/customer, the
professional can also obtain maturity targets from the client/customer. The sections can be summarized
using the graphic presentation (section VIII) describing the achievement or gaps between the actual and
targeted maturity levels. If this is used, it should be noted that this assessment addresses z/OS only, as
there are generally other operating systems in the enterprise.
IV. Assurance and Control Framework
ISACA IT Assurance Framework and Standards

ITAF section 3630.14—Operating System (OSs) Management and Controls—is relevant to z/OS
Security.
ISACA has long recognized the specialized nature of IT assurance and strives to advance globally
applicable standards. Guidelines and procedures provide detailed guidance on how to follow those
standards. IS Auditing Standard S15 IT Controls, and IS Auditing Guideline G38 Access Controls are
relevant to this audit/assurance program.
ISACA Controls Framework

COBIT is an IT governance framework and supporting tool set that allows managers to bridge the gap
among control requirements, technical issues and business risks. C OBIT enables clear policy development
and good practice for IT control throughout enterprises.
Utilizing COBIT as the control framework on which IT audit/assurance activities are based, aligns IT
audit/assurance with good practices as developed by the enterprise.
The COBIT IT control process DS9 Manage the configuration from the Deliver and Support (DS) domain,
addresses good practices for ensuring the integrity of hardware and software configurations. This requires
the establishment and maintenance of an accurate and complete configuration repository. DS5.3 Identity
management and DS 5.4 User account management address user identity and the IT control processAI6

Manage changes from the Acquire and Implement (AI) domain specifically addresses change
management. The relevant COBIT control objectives are:
 DS9.1 Configuration repository and baseline—Establish a supporting tool and a central repository to
contain all relevant information on configuration items. Monitor and record all assets and changes to
assets. Maintain a baseline of configuration items for every system and service as a checkpoint to
which to return after changes.
 DS9.2 Identification and maintenance of configuration items—Establish configuration procedures to
support management and logging of all changes to the configuration repository. Integrate these
procedures with change management, incident management and problem management procedures.
 DS9.3 Configuration integrity review—Periodically review the configuration data to verify and
confirm the integrity of the current and historical configuration. Periodically review installed software
against the policy for software usage to identify personal or unlicensed software or any software
instances in excess of current license agreements. Report, act on and correct errors and deviations.
 DS5.3 Identity management1—Ensure that all users (internal, external and temporary) and their
activity on IT systems (business application, IT environment, system operations, development and
maintenance) are uniquely identifiable. Enable user identities via authentication mechanisms. Confirm
that user access rights to systems and data are in line with defined and documented business needs and
that job requirements are attached to user identities. Ensure that user access rights are requested by
user management, approved by system owners and implemented by the security-responsible person.
Maintain user identities and access rights in a central repository. Deploy cost-effective technical and
procedural measures, and keep them current to establish user identification, implement authentication
and enforce access rights.
 DS5.4 User account management2—Address requesting, establishing, issuing, suspending, modifying
and closing user accounts and related user privileges with a set of user account management
procedures. Include an approval procedure outlining the data or system owner granting the access
privileges. These procedures should apply for all users, including administrators (privileged users)
and internal and external users, for normal and emergency cases. Rights and obligations relative to
access to enterprise systems and information should be contractually arranged for all types of users.
Perform regular management review of all accounts and related privileges.
 AI6.1 Change standards and procedures—Set up formal change management procedures to handle in
a standardized manner all requests (including maintenance and patches) for changes to applications,
procedures, processes, system and service parameters, and the underlying platforms.
 AI6.2 Impact assessment, prioritization and authorization—Assess all requests for change in a
structured way to determine the impact on the operational system and its functionality. Ensure that
changes are categorized, prioritized and authorized.
 AI6.4 Change status tracking and reporting—Establish a tracking and reporting system to document
rejected changes, communicate the status of approved and in-process changes, and complete changes.
Make certain that approved changes are implemented as planned.
Refer to the IT Governance Institute’s COBIT Control Practices: Guidance to Achieve Control
Objectives for Successful IT Governance, 2nd Edition, published in 2007, for the related control practice
value and risk drivers.
Minimum Audit Skills

This review is considered highly technical. The IT audit and assurance professional should have an
understanding of the good-practice z/OS processes and requirements, and be highly conversant in z/OS
1
Scope limitation—Identity management as it relates to technical services users having access to the operating
system only
2
Scope limitation—User account management as it relates to users accessing system functions

tools, exposures and functionality. It should not be assumed that an audit and assurance professional
holding a CISA certification has the requisite skills to perform this review.
V. Executive Summary of Audit/Assurance Focus
z/OS Operating System Security

The review of the operating system ensures management that the computer platform that supports the
various applications is secure and provides appropriate integrity of the operating system controls, and
system availability. If the foundation (operating system) is not secure, the applications can be
compromised (see risk in the following section).
z/OS is IBM’s most recent release of its long-running Multiple virtual storage (MVS) operating system
and is a standard operating system used on large-scale mainframe computers.
The typical enterprise mainframe is a capable of supporting multiple operating environments. The Logical
Partition (LPAR) segments a high-capacity hardware configuration into multiple independent operating
units, having separate operating system configurations (images) and complete separation from other
images. This feature facilitates the separation of production, test and development environments; separate
internal and external environments; and isolated web, database and other special purpose environments.
Each image is a distinct operating environment, requiring a separate audit/assurance process. They may
be grouped together, but the configurations need to be reviewed individually, since they are often
configured differently.
Business Impact and Risk

z/OS is widely used in the enterprise operating environment. The failure for z/OS to be properly
configured could result in the inability for the enterprise to execute its critical processes or its processes.
z/OS risks resulting from ineffective or incorrect operating systems configurations could permit the
operating system to become compromised resulting in:
 Disclosure of privileged information
 Loss of physical assets
 Loss of intellectual property
 Loss of competitive advantage
 Loss of customer confidence
 Violation of regulatory requirements
 Disruption of the computer infrastructure resulting in the inability to perform critical business
functions
 Use of the computer systems as a launching pad for malicious activity against other entities (and the
potential to be held liable for their damages)
Objective and Scope

Objective—The objective of the z/OS audit/assurance review is to provide management with an
independent assessment relating to the controls addressing the configuration and security of the z/OS
operations systems with the enterprise’s computing environment.
Scope—The review will focus on configuration of the relevant z/OS images within the organization, and
the controls over critical operating system (z/OS) libraries, exits to the operating system and supervisor
calls (SVCs). The selection of the applications/functions and specific images will be based upon the risks
introduced to the organization by these systems.

z/OS systems are subject to identity management, the process of identifying and authenticating users and
technical support administrators. Since this process is also addressed in the Identity Management
Audit/Assurance Program, this review is limited to technical services access (access to the operating
system’s configuration and security mechanisms) and general user controls (excluding users from access
to operating system resources) and the Time Sharing Option (TSO) configuration. Refer to the Identity
Management Audit/Assurance Program for controls relating to user identity.
The mainframe environment is complex and utilizes numerous subsystems. Excluded from this review are
the:
 Systems network configuration (e.g., System Network Architecture [SNA])
 Online processing configuration (e.g., Customer Information Control System [CICS], Information
Management System-Data Communication [IMS DC])
 Access control software (e.g., Resource Access Control Facility [RACF], Access Control Facility 2
[ACF2], Top Secret)
 Database management systems (e.g., Database 2 [DB2], IMS)
 System performance utilities
{The remainder of this paragraph needs to be customized by the audit/assurance professional to describe
which images and applications within the enterprise will be reviewed.}

VI. Audit/Assurance Program

COSO
CommunicationInformation and
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
COBIT Hyper- reference
Monitoring
Audit/Assurance Program Step Cross- link
reference
1. PLANNING AND SCOPING THE AUDIT

1.1 Define audit/assurance objectives.
The audit/assurance objectives are high level, and describe the overall audit goals.
1.1.1 Review the audit/assurance objectives in the introduction to this audit/assurance
program.
1.1.2 Modify the audit/assurance objectives to align with the audit/assurance universe,
annual plan and charter.
1.2 Define boundaries of review.
The review must have a defined scope. The reviewer must understand the operating environment
and prepare a proposed scope, subject to a later risk assessment.
1.2.1 Obtain and review the z/OS operating system security and management policies.
1.2.2 Obtain a list of z/OS images, their locations, the applications they processes or
support, and the version number.
1.2.3 Establish initial boundaries of the audit/assurance review.
1.2.4 Identify limitations and/or constraints limiting audit of specific systems.
1.3 Define assurance.
The review requires two sources of standards. The corporate standards defined in policy and
procedure documentation establish the corporate expectations. At minimum, corporate standards
should be implemented. The second source, a good practice reference, establishes industry
standards. Enhancements should be proposed to address gaps between the two.
1.3.1 Obtain and review good practice z/OS security and configuration standards.
1.3.2 Obtain corporate z/OS configuration standards.
1.3.3 Determine if there are gaps in the corporate policy.
© 2009 ISACA. All rights reserved. Page 13
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
1.4 Identify and document risks.

The risk assessment is necessary to evaluate where audit resources should be focused. In most
enterprises, audit resources are not available for all processes. The risk-based approach ensures
utilization of audit resources in the most effective manner.
1.4.1 Using the list of images identified previously, determine the risk category for each
image and establish a prioritized list of images to be assessed.
1.4.2 Review previous audits of z/OS and other assessments.
1.4.3 Determine if issues identified previously have been remediated.
1.4.4 Evaluate the overall risk factor for performing the review.
1.4.5 Based on the risk assessment, identify changes to the scope.
1.4.6 Discuss the risks with IT, business and operational audit management, and adjust the
risk assessment.
1.4.7 Based on risk assessment, revise the scope.
1.5 Define the change process
The initial audit approach is based upon the reviewer’s understanding of the operating environment
and associated risks. As further research and analysis is performed, changes to the scope and
approach will result.
1.5.1 Identify the senior IT assurance resource responsible for the review.
1.5.2 Establish the process for suggesting and implementing changes to the audit/assurance
program, and authorizations required.
1.6 Define assignment success.
The success factors need to be identified. Communication among the IT audit/assurance team, other
assurance teams and the enterprise is essential.
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
1.6.1 Identify the drivers for a successful review. (This should exist in the assurance
function’s standards and procedures.)
1.6.2 Communicate success attributes to the process owner or stakeholder and obtain
agreement.
1.7 Define required assurance resources.
The resources required are defined in the introduction to this audit/assurance program.
1.7.1 Determine audit/assurance skills necessary for review.
1.7.2 Determine estimated total resources (hours) and timeframe (start and end dates)
required for review.
1.8 Define deliverables.
The deliverable is not limited to the final report. Communication between the audit/assurance teams
and the process owner is essential to assignment success.
1.8.1 Determine the interim deliverables, including initial findings, status reports, draft
reports, due dates for responses and the final report.
1.9 Communications
The audit/assurance process is clearly communicated to the customer/client.
1.9.1 Conduct an opening conference to discuss the review objectives with the executive
responsible for operating systems and infrastructure.
PREPARATORY STEPS
2.1 Obtain and review the current organization chart for the operating system’s
configuration and security functions.
2.1.1 Identify the key staff and stakeholders.

COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
2.2 Select the images to be included in the review.

2.2.1 Based upon the prioritized list of images developed previously, identify the images to
be included in the review, including a representative sample of high risk images. A
group of images may have similar functions and can be aggregated into a group.
2.3 Obtain documentation for the images to be reviewed.
2.3.1 Obtain IT department organizational chart with names and phone numbers of IT
technical support and security administration personnel.
2.3.2 Obtain z/OS system and subsystem software inventory list with vendor and release
descriptions.
2.3.3 Obtain z/Image or S/390 hardware configuration diagram. This should include
processors, LPAR configurations, Direct Access Storage Device (DASD) volumes,
tape volumes, communication devices, routers and other peripherals.
2.3.4 Obtain z/Image or S/390 network configuration diagram. This should include, but not
be limited to, Systems Network Architecture (SNA), Transmission Control
Protocol/Internet Protocol (TCP/IP), File Transfer Protocol (FTP), Remote Job
Entry/Network Job Entry (RJE/NJE) and Internet connectivity.
2.3.5 Obtain access to automated z/OS assessment tools, if available.
2.3.6 Obtain access to z/OS system utilities such as AMBLIST, AMASPZAP3, IEHLIST or
IEBCOPY.
2.3.7 Obtain access to SDSF, IOF or other similar utilities that allow browsing (read-only)
JES queues and OS SYSLOG. This access should not be restricted and should have
access to all job classes and job names.
2.3.8 Obtain the IT standards manual. This manual should describe user ID, group, system,
3
This is a sensitive utility and may not be available to the audit/assurance professional. If it is available, it should be used with great caution.
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
development, test and application production naming conventions. It should also

describe naming standards for devices, such as DASD, tape, MSS and others.
2.3.9 Obtain a copy of z/OS System Change Management Procedures.
2.3.10 Obtain a copy of z/OS Disaster Recovery Procedures.
2.3.11 Obtain a copy of z/OS RACF Administration Procedures (or Exchange Systems
Manager [ESM]).
2.3.12 Obtain access to z/OS IBM documentation manuals. These manuals are available on
CD-ROM from IBM or on www.ibm.com.
2.3.13 Obtain access to OS/390 RACF documentation manuals. These manuals are available
on CD-ROM from IBM or on.www.ibm.com.
2.3.14 Request a copy of assembly listings (PRINT NOGENs should be removed for full
macro expansions) for all z/OS and ESM exits active for this installation.4 The
requested list should include, but not necessarily be limited to, the following:
 IGGPRE00—DASDM Exit(s)
 IGGPOST0—DASDM Exit(s)
 IKJEFF10—TSO Submit Exit
 IKJEFF53—TSO Output/Status/Cancel Exit
 IKJEFLD—TSO Logon Pre-Prompt Exit
 SMF Exits
 JES2 Exits
 z/OS Router Exits
 Job Accounting Exits (e.g., PACE, home grown)
 ESM Exits (e.g., CA-ACF2, RACF, CA-TSS)
 Job Scheduler Exits (e.g., CA-7, JES3, CA-Scheduler)
4
This may take some time to generate, but it is prudent to ask for it at the start of the audit and compare with actual exits installed on the z/OS environment. Caution: This
may result in large print jobs. Soft copies may be more prudent.
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
 Tape Management Exits (e.g., CA-1)

2.4 Obtain an understanding of the operating environment and management issues.
2.4.1 Interview the senior operating systems management analyst (manager or director) to
obtain an understanding of policy and procedures as well as known issues.
2.4.2 Obtain documentation of the hardware and software environment.
2.4.3 System Environment Analysis:
2.4.3.1 Generate the system environment analysis reports using utilities and review
them for reasonableness. If no automated analysis software is present, access
the SYSLOG of current z/OS image and print the IPL statistics at startup.
2.4.3.2 Ensure that the z/OS and RACF version levels are current based on IBM
support criteria.
2.4.3.3 Verify that the System Management Facility (SMF) CPU ID and the system
name (sysname) are the same. In a multi-processing environment, SMF
record lookups can be substantiated to run on a specified processor.
2.4.3.4 Review the computer operations log or system analysis output of the utilities
or tools. Document the:
 Date of last initial program load (IPL)
 SMF recording
 Primary job entry subsystem (JES)
 CPU model and serial numbers
 z/OS operating system version
2.4.4 Determine the number of z/OS images in use and identify which images are within
scope.
OPERATING SYSTEM CONFIGURATION

COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
3.1 System datasets

Audit/assurance objective: Critical system datasets should be properly secure with ESM
protection.5
5
System datasets are those used during the IPL process; datasets used for supporting subsystems of z/OS, such as distribution libraries; SMF datasets; and Local Product Agent
(LPA) imagery library and Authorized Program Facility (APF) libraries.
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
4. Systems data sets access restrictions DS9.2

X X
Control: Systems data sets are restricted to access by technical services and systems DS9.3
programmers. DS5.4

COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
4.1.1 Identify all system datasets by executing available utilities or tools.
4.1.2 Identify the high-level qualifier (i.e., SYS1, SYS2, SYSn) for each z/OS image under
review.
4.1.2.1 Identify those datasets with these high-level qualifiers and review the level of
ESM (RACF) protection for each.
4.1.2.2 Determine that the SYSn high-level qualifier is only used for system datasets.
4.1.2.3 If there are other dataset high-level qualifiers for system datasets, then run
RACF list profile commands for each.
4.1.2.4 Determine that all system datasets are not accessible by users outside the
scope of technical support, operations, STC and other subsystem IDs
(required for their job function or processing). Authorized users typically
have update or write access, but it should be based upon need.
4.1.2.4.1 Determine if requests for and review of users having access to the
system datasets is documented and approved by a technical
support manager, and if the access permissions are routinely
reviewed and reapproved.

COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
4.1.2.5 Review the RACF global access control (GAC) table for the dataset class.
Verify that there is no entry for system datasets (e.g., APF, SYSn, Linklist,
distribution libraries) that might allow access of greater than READ. 6
4.1.2.6 Verify that datasets considered system level, such as APF, SYSn, Linklist,
are not user datasets. High-level qualifiers of these libraries should not be for
individual TSO user IDs.
4.1.2.7 In a shared DASD environment, verify that APF and system data sets are
protected on all LPARs or CPUs that have access to them.
4.1.2.7.1 Verify that test LPARs that typically have a lower level of
protection do not have access to production APF or system
datasets on shared volumes that exceed what would have
otherwise been controlled in production.
4.1.2.8 Determine TSO and batch privileges with READ-only access to all z/OS
system libraries, APF libraries, link list, JES2 procedure libraries and system
programmer user libraries.
4.1.2.9 Determine the systemwide RACF auditor attribute or equivalent in other
ESM (external security manager, i.e., CA-ACF2 or CA-TSS).
PARAMETER LIBRARY (PARMLIB)
Audit/assurance objective: PARMLIB configuration controls should be in effect to limit access to
the PARMLIB; only authorized entries should be in the PARMLIB; and instructions for PARMLIB
overrides or use of alternate PARMLIBs should be explicitly documented.
DS9.1 X
5.1 PARMLIB datasets and parameters
DS9.2
Control: Only authorized modules are included in the PARMLIB IPL instructions.
6
The risk associated with GAC entries lies in the fact that they allow access overrides to RACF profiles. This means that a RACF profile (discrete or generic) may say that no
access is allowed, whereas the GAC may override it. An additional risk is the lack of audit trail records, since no SMF records are generated for accesses granted due to GAC
entries.
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
DS9.3
5.1.1 Compile a list of the PARMLIBS that constitute the PARMLIB concatenation for this
z/OS image.
5.1.1.1 Analyze the options available at IPL time by ascertaining:
 Will the IEA101A prompt be issued?
 If not issued, what are the procedures and practices for responding to this
prompt?
5.1.1.2 Run the appropriate tools to obtain an analysis of PARMLIB. Create a map,
starting with LOADxx, to each IEASYSxx member and all other PARMLIB
members pointed to by director parameters.
5.1.1.2.1 Determine that all members are properly authorized and required
for the system.
5.1.1.2.2 Determine if nonexistent PARMLIB members referenced by
director parameters are needed (for default members, the system
default values may be acceptable).
5.1.1.2.3 Determine if the OPI parameter (OPI=YES) allows the operator to
override parameters during IPL.7
5.1.1.2.4 Determine the purpose for IPL-related PARMLIB members not
specifically referenced by a director parameter. Note: Some
members normally found in PARMLIB, e.g., IKJTSO and
TSOKEY members, are not processed at IPL time.8
7
The risk of having the OPI parameter set to YES is that of delegation control authority of the IPL process to a larger number of people, and also gives rise to the need for
additional controls of the individual IPLs that are performed.
8
Having more members in PARMLIB than are actually required may give rise to confusion and possible mistakes at IPL time.
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
DS9.1 X
6. Alternate system parameter lists
DS9.2
Control: Alternate PARMLIB lists are documented with explicit instructions on their
DS9.3
use.
6.1.1.1 Verify that computer operations instructions state when it is necessary to use
alternate system parameter lists, LOADxx members or overrides during IPL.
6.2 Authorized program facility (APF)
Audit/assurance objective: Only operating system-related programs and installation preapproved
nonoperating systems programs requiring access to restricted operating system components should
be included in the APF.9
7. APF authorized datasets DS9.2
Control: Only datasets that are vendor supplied or locally developed and approved are X X
DS9.3
APF authorized.
7.1.1.1 Review link listed (LNKLST) data sets that are also APF authorized. 10
7.1.1.2 Load modules with the AC(1) indicator should be reviewed to determine that
they are vendor supplied and required for respective system applications.
7.1.1.3 Determine if nonvendor APF authorized datasets are reviewed and explicitly authorized by
management. Determine if the authorization is reviewed regularly.
7.1.1.4 Review APF libraries and identify APF indicated programs. If the module
appears to be in-house or installation written, request program
documentation, including the source code and possibly an assembly listing
(with PRINT NOGEN).11
9
The APF is used to identify programs that can execute sensitive supervisor service calls (SVCs), restricted macro instructions (e.g., MODESET), and privileged machine
instructions (e.g., LPSW).
10
The risk of compromising z/OS integrity is generally increased, with a higher number of APF authorized load modules.
11
In case the program is inadequately documented, and no reasonable justification for the existence and functions of the module can be found, a code review may be required.
The enterprise should have written documentation as to the purpose and a documented management approval. Review the source code to verify that the programs perform only
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
7.1.1.5 Verify that the APF libraries are protected via the access control software.
8. Monitoring access to APF library DS9.1
Control: The SMF utility is configured to report unauthorized AFP access or related DS9.2 X X
activities. DS9.3
8.1.1.1 Determine a reasonable period of time for which SMF data should be studied
in order to identify attempts by unauthorized programs to issue restricted
SVCs and all attempts by authorized programs to use programs not residing
in an APF library.
8.1.1.2 Use audit software or the SMF reporting tool to identify SMF type 4 records
for jobs or system events that have abended with codes “047” or “036.”
8.1.1.3 Determine if information security, computer operations and technical services
have procedures for follow-up of such SMF activity.
8.1.1.4 Review follow-up activity to determine the types of incidents and the actions
taken following an incident.
8.2 Program properties table (PPT)
Audit/assurance objective: Only approved APF programs should be listed in the PPT and those
programs have legitimate business reasons for being on the list.12
DS9.1 X X
9. PPT entry properties
DS9.2
Control: PPT entries are authorized and monitored to ensure that only approved
the documented functions requiring APFauthorization and that the functions do not violate systems integrity or bypass system security.
12
The PPT only specifies the name of the program to be granted special privileges, i.e., there is no linking of the program name to any specific program library; therefore, the
properties defined in PPT entries are assigned to APF-authorized programs based on their names only. Unapproved APF programs carrying the same name as a program on the
PPT list will automatically obtain the special privileges defined in the properties, from the beginning of its execution, without having to request these privileges at all. It may
thus be possible for bogus programs to acquire special privileges by simply having the same name as programs legitimately included in the PPT, provided that they are placed in
APF libraries.
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
programs are referenced in the PPT. DS9.3

9.1.1.1 Use appropriate utilities or tools to identify the PPT entries for a given z/OS
image.13
9.1.1.2 Review properties assigned to each entry for appropriateness. The RACF
DSMON report only reports on two properties (i.e., KEY and BYPASS); it
is essential that the auditor review all other properties for appropriateness,
focusing on installation-defined entries.
9.1.1.3 Review PPT definitions in the active SCHEDxx member to ensure that all
entries in the SCHEDxx member are properly documented and authorized
by management. The SCHEDxx member in PARMLIB contains entries that
supplement or possibly override IEFSDPPT (IBM-supplied). These entries
are made up of overrides of IBM-supplied entries, OEM product program
names required by vendor, or installation defined entries.
9.1.1.4 Determine if programs in the PPT portion of SCHEDxx member are vendor
supplied or installation written.
9.1.1.5 Verify that all vendor-supplied programs are authorized products and that
APF authorization is required
9.1.1.6 Obtain source code and assembly listings (without PRINT NOGENs) for any
installation-written programs added to the PPT. Review for integrity,
security, auditability and management authorization.
9.1.1.7 Perform a scan of all APF and LINKLST libraries and look for duplicate PPT
program names. List the entries such that they list the program name, aliases,
CSECTs, AC(n), zap history, link edit date and module length. Modules that
have differences in any of these are functionally different modules.
13
Entries supplied by IBM are in a member in SYS1.LINKLIB (IEFSDPPT). These entries should never be modified. Use AMASPZAP to obtain a full overview of these
properties.
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
9.1.1.8 Review the z/OS SYSLOG or SMF to determine if an override involving the
SET SCH command has occurred. The SET SCH command can be used to
dynamically modify the contents of the PPT by allowing the operator to
replace the current PPT definitions with another SCHEDxx member
specified on the command. The new PPT definitions take effect
immediately, without the need for an IPL.
9.2 Supervisor calls (SVC)

Audit/assurance objective: Supervisor calls (system routines and programs that execute supervisor
instructions on behalf of a program or other SVCs) should be monitored to ensure that no
unapproved SVCs exist and that no SVC code has been modified without proper approval.
10. IBM-supplied SVCs DS9.1
Control: IBM-supplied SVCs are documented and only IBM SVCs are identified as DS9.2 X X
such. DS9.3
10.1.1.1 Verify that only IBM-supplied SVCs are identified as IBM SVCs.
10.1.1.1.1 Use available utilities or tools to identify all IBM-supplied SVCs.
A hex-dump of the in-storage SVCTABLE can be used by using
the TSO TEST command. IBM SVCs typically range from 0 to
199. Entries that are not used by IBM will specify a load module
entry point with IGCERROR. These are empty entries not used
by the IBM z/OS base operating system. Type 1, 2 and 6 SVC
entries reside in the nucleus and are named IGCnnn. Types 3 and
4 reside in the link pack area and are named IGC00nnn.
10.1.1.2 Ensure that all SVCs reside in the appropriate storage areas as described by
the SVC type. For example: 81E18B08 C1008000—The first four bytes are

COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
the entry point for this SVC (81E18B08). This is a type 3 or 4 SVC (C1 =
1100 0001). It also has a local lock (80 = 1000 0000).
10.1.1.3 Ensure that SVCs 107, 32, 39, 76, 83 and 85 are restricted SVCs. Restricted
SVCs require that the calling program be APF authorized. Byte 4 bit 4
should be set to “on.”
11. Installation SVCs
Control: Installation SVCs (nonIBM SVCs required for the operating environment DS9.1
internal operating system customizations or third-party software-required SVCs) are DS9.2 X X
approved and monitored. DS9.3
11.1.1.1 Identify the active SVC used by this operating system. (Installation SVCs
typically range from 200-255. These are defined in the IEASVCxx member
in PARMLIB.)
11.1.1.1.1 Verify each vendor product or installation application in use.
(Consider, but do not rely on, the comments for each SVCPARM
entry in the IEASVCxx member.)
11.1.1.2 Identify those SVCPARM entries for vendor products and ensure that the
REPLACE, TYPE and APF indicators are appropriate based on vendor
documentation.
11.1.1.3 Identify those SVCPARM entries for installation, written routines or
applications. There should be supporting documentation for each entry.
(Historically, there have been examples of enterprises having an
“authorizing SVC,” i.e., one that that grants the caller the ability to switch
from problem state to supervisor state and back, without requiring APF
authorization. Such an SVC requires very little code primarily because it
performs very little integrity checking. Use AMBLIST or other utilities or
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
tools to find SVCs most commonly within the 200-255 range. Primarily look
for any SVC with a length of x‘40’, x‘64’ or less. Code analysis may be
assisted using the TSO TEST command.)
APPENDAGES
Audit/assurance objective: Appendages14 (application routines designed to handle the occurrence of
specific events during job processing and file access) should be documented, approved and monitored.
5.1 Use of appendages DS9.1
Control: The use of approved appendages is documented, subject to a review process and DS9.2 X X
its use is monitored. DS9.3
12.1.1 Determine if there are any appendages15 defined in IEAAPP00 in PARMLIB. Verify
if there are other appendages in other IEAAPPxx members of PARMLIB.
Appendages are named IGG019 plus two characters in the range WA-Z9. User
written appendages include:
 ABEAPP—Abnormal-end procedures
 CHEAPP—Channel-end procedures
 EOEAPP—End-of-extent procedures
 PCIAPP—Program-controlled interrupt procedures
 SIOAPP—Start I/O procedures
12.1.2 Obtain written documentation on the purpose, origin (vendor), or installation
specification regarding the need for enterprise-added appendage code.
12.1.3 All appendages, given the nature of the system privileges required to execute, should
14
Appendages will be invoked irrespective of the executing program and/or identity of the user. All appendages execute as authorized programs in supervisor state and system
key "0" and therefore have access to sensitive SVCs and restricted macro instructions.
15
These appendages, when listed, can be used by any unauthorized (APF) user program. Otherwise, only programs authorized under APF or running under system protection key
(0-7) may use the EXCP appendages. If the installation does not use EXCP appendages, you need not create IEAAPP00. If the EXCP caller is not in running under a storage key
different from 8 or the job step is not APF authorized, the system verifies that the caller’s appendage names are listed. If the names cannot be found, the system issues a 913
abend. If, however, the caller is authorized, the system loads the appendages without inspecting the list.
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
undergo normal program change controls (e.g., SMP/e).

12.2 Link pack areas (LPA)
Audit/assurance objective: The link pack areas where the operating system searches to identify
the search sequence for programs to be executed should be controlled and monitored for
unauthorized modification.16
13. Program authorization DS9.1
Control: The LPA is controlled, monitored, and only approved program are accessible. DS9.2 X X
DS9.3
13.1.1.1 Verify that all vendor-supplied programs located in the LPA are for
management-authorized products and that LPA residency is recommended.
13.1.1.2 For installation written programs residing in any of the LPAs, request
documentation and management approval. In case documentation/approval
documents cannot be obtained, review the source code by requesting the
assembly listings to verify that the programs perform only the desired
functions and do not bypass system integrity/security.
13.1.1.3 Perform a duplicate program search of the LPAs and link list in the order of
concatenation. Look for differences in the duplicate program names in
module length, link edit date and whether the AC(n) is different. Only the
first occurrence of the program name will ever be executed. 17
13.2 System management facility (SMF)
Objective: The SMF should be enabled and system activity recorded by SMD should be monitored
regularly.18
16
The LPA controls the job pack area, fixed link pack area, modified link pack area, pageable link pack area and link list libraries (in order of concatenation), which are used to
locate the program on the “EXEC PGM=” JCL card. This search sequence can be modified by the use of JOBLIB and STEPLIB DD statements.
17
Investigating the existence of duplicate programs does not lead to information that assists the auditor in determining who has update access to the libraries in question. The
existence of duplicate entries in a production environment only reveals poor housekeeping practices. The suggested use of a production system LPA for testing, hopefully, never
comes to pass. It will always be the recommendation to use a separate LPAR/z/OS image for testing.
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
DS9.1
14. SMF Configuration
DS9.2 X X
Control: The SMF configuration is set to record significant system activities.
DS9.3
14.1.1.1 Use the appropriate tools and to review current SMF settings. One can also
review the current SMF PARMLIB member pointed to by the SMFxx
director parameter in IEASYSxx; i.e., SMFPRMxx.
14.1.1.2 Ensure that SMF recording is ACTIVE.
14.1.1.3 Identify all SMF datasets being used for logging. These are traditionally
named SYS1.MANx, but may carry any name. Please refer to the
SMFPRMxx member of PARMLIB for names defined in the z/OS image
being audited.
14.1.1.4 Determine that SMF record types required by the enterprise are not being
excluded from logging. The list of critical SMF records should be DS9.2 X
determined based on the requirements of management, the current z/OS
environment and its related subsystems.
14.1.1.5 Use the IFASMFDP utility program to produce a summary report of all
records included within selected SMF datasets. Review to obtain an
overview of the number of SMF records collected for each type. Specifically
verify the absence of SMF record type 7. The existence of this record type
states that SMF records have been lost.
15. SMF exits DS9.1
Control: SMF exits are documented, approved and tested in accordance with DS9.2 X X
installation change management policy. DS9.3
18
SMF is used for the collection of system activity as well as ESM security events in SMF record types 80, 81 or 230. Incorrect settings of SMF parameters can cause records to
not be logged. SMF exits can also selectively or completely suppress SMF logging. Failure to log record types required by the enterprise may result in lack of information for
performance measurement, accounting, (security) event tracking and an incomplete audit trail. When an external security manager (RACF, CA-ACF2 or CA-Top Secret) is
used, the corresponding SMF records must be enabled.
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
15.1.1.1 Identify all SMF exits active for jobs, started tasks, TSO logons or other
actions. Request a copy of assembly listings without PRINT NOGENs for
code review.
15.1.1.2 Verify that the exits perform only the documented functions and do not
bypass system integrity/security.
15.1.1.3 Verify that the SMF change management adheres to installation change
management policy.
16. SMF Reporting DS9.1
Control: SMF data are retained, include the necessary data for and are controlled in a DS9.2 X X
manner to support security forensics activities. DS9.3
16.1.1.1 Review the procedure for dumping the active SMF datasets.
16.1.1.1.1 Ensure that none of the records collected in the primary SMF
datasets is eliminated in the dumping process.
16.1.1.1.2 Review possible exits that may be activated in the dumping process
since these may selectively eliminate SMF records based on criteria
found within the records themselves (e.g., user ID, jobname).
16.1.1.2 Verify the procedures for storing SMF records. Ensure that the necessary
SMF records are stored in a secure and tamper-proof manner. Further ensure
that the storage cycle is in compliance with the business requirements of the
enterprise and with applicable legislation.
16.1.1.3 Verify that applicable tools exist for creating the reports required by the
enterprise. Such tools should be able to cater to the need for reports raised by
the daily business activities and the ad hoc reports required by, e.g., the
security staff and the auditors.
16.1.1.4 Verify that reports necessary to the business operations of the enterprise are

COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
produced, distributed and reviewed on a regular basis as an integral part of

the enterprise’s internal control system.
16.2 z/OS subsystems
Audit/assurance objective: z/OS subsystems, used to provide services such as the Master
Scheduler, JES, tape management systems, CICS and other programs running under the control of
the operating system, should be configured to provide security and restrict unauthorized access.
17. z/OS subsystem configuration DS9.1
Control: The z/OS subsystems are configured to ensure that only authorized programs DS9.2 X X
have access to the subsystems. DS9.3
17.1.1.1 Verify that all z/OS subsystems defined in IEASSNxx are authorized and
documented products.
17.1.1.2 Identify any subsystem names that are installation defined. Ensure that
complete documentation and management approval exists.
17.2 Job entry subsystem

Audit/assurance objective: JES2, the job entry subsystem that serves as the point of entry for all
jobs and processes running in z/OS should be adequately controlled to prevent unauthorized jobs
and programs from entering the batch or online environment.
18. JES2 configuration
Control: JES2 is configured to ensure that only authorized applications and utilities are DS9.2 X
executed.
18.1.1.1 Review the dataset concatenation and ensure that no test libraries are ahead
of production libraries in a production z/OS system. Verify ESM security
controls over these libraries. All of these libraries should undergo installation
change control procedures and authorizations.

COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
18.1.1.2 Match the JES2 member in PARMLIB to the S JES2 system messages in
the z/OS SYSLOG. If there is a difference or if overrides are present, obtain
operator procedures and management approval to explain the deviations.
18.1.1.3 Review the MSTJCL00 member in PARMLIB and ensure that the JES2
start-up procedure resides in the first library in the IEFPDSI DD statement.
18.1.1.4 Verify ESM security controls over the PROCLIB dataset concatenation.
These datasets should not contain any user or test datasets.
18.1.1.5 Look for duplicate JCL procedure names in the PROCLIB concatenation
list. The first occurrence of a procedure within the PROCLIB concatenation,
referred to by an “EXEC PROC” JCL statement, will be the one executed.
Reconcile the need for the duplicate names since this may introduce integrity
and processing vulnerabilities.
18.1.1.6 If this is a RACF installation, ensure that the JES-BATCHALLRACF
option is active. Display this parameter using the RACF SETROPTS LIST
command. This prevents any job from executing in the z/OS environment
without a valid RACF user ID.
19. JES2 datasets DS9.2 X
Control: The JES2 datasets are configured for maximum security.
19.1.1.1 Identify the dataset(s) used to house the JES2 parameters. This is defined in
the HASPPARM DD statement in the JES2 start-up procedure. Usually the
sequence “JES2PARM” is part of the dataset name. Notice, however, that the
dataset(s) involved may be either sequential, or member(s) of partitioned
datasets. Most installations use a PDS member, and have the member name
as a variable of &MEMBER pointed to in the MEMBER= name in the PROC
statement. An alternate member (&ALTMEM) is also defined.
19.1.1.2 Verify ESM security controls over the dataset that houses the JES2

COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
parameter statements. The production version of this dataset should be under

installation change control procedures.
19.1.1.3 The prologue in the JES2 parameter member should contain a change log
that documents date, person and change made to JES2 parameters. These are
only comments; however, well-controlled installations typically keep this
information current.
19.1.1.4 Identify the JES2 spool dataset names defined in the SPOOLDEF JES2
parameter. Review to ensure that ESM security controls exist over these
datasets.
19.1.1.5 Identify the JES2 checkpoint dataset names defined in the CKPTDEF JES2
parameter. Review to ensure that ESM security controls exist over these
datasets.
19.1.1.6 Determine if operator console commands are allowed in JCL input job
statements. The JOBCLASS JES2 parameters have a COMMAND statement
that states the privilege. All COMMAND statements should use the
DISPLAY or IGNORE command option for production z/OS environments.
19.1.1.7 If z/OS commands are allowed, these commands can be grouped in the
AUTH statement within each job class. Review all those with AUTH=ALL
option. These should be documented and authorized for need and
management approval in z/OS production environments.
19.1.1.8 Some installations use ESM controls over z/OS console command and NJE
command security. In RACF, use the SETROPTS LIST command to
determine if the OPERCMDS class and FACILITY class are active. If so,
review operator command protection for integrity and control.
19.1.1.9 Review the SMFDEF JES2 parameter and ensure that the BUFNUM option
is not less than 2. This might introduce loss of SMF logging and audit trail
capabilities.
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
19.1.1.10 Identify any JOBCLASS that has the IEFUJP=NO statement. This
indicates that the SMF IEFUJP exit will not be taken when a job is purged
irrespective of the settings in SMFPRMxx member in PARMLIB. There
should be a documented reason for this parameter setting.
19.1.1.11 Determine if any JOBCLASS allows for BLP (bypass label processing).
BLP=YES allows magnetic tape labels to be bypassed during OPEN. This
could circumvent normal ESM dataset protection. Some installations do not
use this parameter and use the tape management system (e.g., CA-1) ESM
interface to control BLP.
19.1.1.12 Review the RJE definitions in the JES2 parameter member. All RJE
stations should have unique ESM user IDs assigned and possibly should
have restricted user IDs to limit their capabilities as their jobs are introduced
into the z/OS environment.
19.1.1.13 Determine if information security personnel review reports for SMF type
49 violations. The SMF record type 49 is written whenever a remote user
attempts to sign on with an invalid JES2 password.
DS9.1 X X
20. JES2 exits
DS9.2
Control: JES2 exits are documented and approved. DS9.3
20.1.1.1 Identify current JES2 exits. Use the following console command, or have a
computer operator to execute: $d exit(*), status=enabled,routines’?
20.1.1.2 Request an assembly listing without PRINT NOGENs for macro expansion.
Ensure that these exits do not compromise z/OS or ESM security controls.
20.1.1.3 Verify that JES2 exits have been approved and are fully documented and
tested.

COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
20.2 Time sharing option (TSO)

Audit/assurance objective: The TSO environment should be adequately controlled to ensure that
only authorized individuals have access to TSO, the access controls are in compliance with access
policies and TSO is appropriately configured to ensure that its usage does not affect the integrity of
the operating system.
21. TSO logon DS5.3
Control: TSO logon procedures utilize appropriate resources and are configured for DS5.4 X
maximum security. DS9.2
21.1.1.1 Review TSO logon procedures. For a given user, the TSO logon procedure
name can be found in the TSO logon menu or the ISPF primary option menu.
Many installations have unique TSO logon procedures for groups of TSO
users.
21.1.1.2 TSO logon procedures are found in the JES2 defined PROCLIB
concatenation. Identify those TSO logon procedures used for this installation
and ensure that they undergo normal change control procedures.
21.1.1.3 Using ESM security software query or report facilities, determine that
system datasets used in the TSO logon procedures have adequate controls.
21.1.1.4 Review ESM security over key TSO system libraries:
Dataset Contents RACF UACC
SYS1.UADS TSO user profiles NONE
SYS1.CMDLIB TSO commands EXECUTE
SYS1.BROADCAST TSO messages UPDATE
SYS1.HELP TSO help READ
22. TSO commands DS9.2

Control: TSO commands are appropriately authorized to the operating system and X X
DS9.3
sensitive commands are restricted based on business need.
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
22.1.1.1 Identify TSO commands that require APF authorization. If any commands
are installationdefined, there should be documentation as to the purpose,
controls and management authorization.
22.1.1.2 Determine if ESM security software is used to control TSO command usage.
Sensitive TSO commands should be strictly controlled to authorized TSO
users based on a business need. They should also have proper management
authorization.
23. TSO user IDs DS5.3
X X
Control: TSO user IDs are administered in compliance with user security policies. DS5.4
23.1.1.1 TSO users should be defined to the ESM security software. In RACF, TSO
user profiles have a TSO segment that allows for TSO usage. If
SYS1.UADS is also used, there should be additional controls.
23.1.1.2 Using RACF, list all user IDs with TSO privileges. This can be done by
issuing the following RACF command at the command prompt: LISTUSER
* TSO.
23.1.1.3 Verify that proper documentation exists to ensure that authorization exists
for each user ID assigned (security administration group assistance may be
required).
23.1.1.4 If SYS1.UADS is used exclusively, use the ACCOUNT command at the
command prompt to list all TSO users:
 ALLOC DA(SYS1.UADS) SHR
 ACCOUNT
 LISTIDS
Note: if SYS1.UADS is used exclusively, listing the UADS entry with the
ACCOUNT command will display the TSO password in the clear.
23.1.1.5 If both RACF and SYS1.UADS are used, take both outputs of the two
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
previous audit tasks and identify:

 User IDs defined in RACF and not defined in SYS1.UADS
 User IDs defined in SYS1.UADS and not defined in RACF
23.1.1.6 Identify all TSO users with the ACCOUNT, OPERATOR, PARMLIB,
RACONVRT, TESTAUTH and SYNCH TSO command privileges.
Documentation should exist for business need and management
authorization.
23.1.1.7 Review security administration procedures for requesting, defining,
deleting, modifying and management approval requirements for TSO user
IDs. All this activity should be properly documented and all user IDs should
conform to installation-established naming conventions.
23.1.1.8 Review established password naming conventions and syntax rules for
compliance with enterprise policies and procedures.
23.1.1.9 Identify TSO user IDs that have never been used and those that have not
been used for long periods of time. Password expiration controls only work
for those user IDs with a last used date.
23.1.1.10 Review the ESM user attributes assignments. Identify those that have
RACF SPECIAL, OPERATIONS and AUDITOR at the system or group
levels. Further review needs to be performed to justify those users, such as
technical support or RACF administrators, that have more than one or all
three attributes. All RACF attribute assignments need to be documented with
supporting management authorizations.
23.2 TSO Exits
DS9.1 X X
24. TSO exits
DS9.2
Control: TSO exits are documented and approved.
DS9.3

COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
24.1.1.1 Review any TSO exits that may exist in this z/OS environment. If no
adequate documentation exists, perform code review for any possible
security and integrity control vulnerabilities.
24.1.1.2 Review the following exits if installed:
 IKJEFF10—TSO Submit Exit
 IKJEFF53—TSO Output/Status/Cancel Exit
 IKJEFLD—TSO Logon Pre-Prompt Exit
24.1.1.3 Verify that TSO exits have been approved and are fully documented and
tested.
24.2 System log (SYSLOG)
Audit/assurance objective: The SYSLOG should be configured to record significant system activity
and provide a forensic trail of operator activities.
25. z/OS commands issued at IPL DS9.1
Control: The SYSLOG provides a history of commands issued during the IPL of the DS9.2 X X
system and these commands are monitored to ensure compliance with policies and DS9.3
procedures.
25.1.1.1 The COMMNDxx, IEAABD00, IEADMP00, IEADMR00, IEASYSxx, and
SMFPRMxx members of PARMLIB contain z/OS commands issued at IPL
time.
25.1.1.2 Verify that these commands are reviewed regularly against stated policies
and procedures.
DS9.1
26. Console events
DS9.2 X X
Control: Console events are reviewed regularly and the appropriate events are recorded.
DS9.3
26.1.1.1 Review selected system console events for operator-initiated overrides or
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
system error messages. The following commands and messages would be of

particular interest:
F Any MODIFY
MODIFY Any MODIFY
FORCE FORCE a job
V NET Vary VTAM
VARY NET Vary VTAM
HALT NET Halt VTAM
Z NET Halt VTAM
NIP IPL 'NIP' Messages
S ACF2 Start CA-ACF2
S TSS Start CA-TOPSECRET
P ACF2 Purge CA-ACF2
P TSS Purge CA-TOPSECRET
ICH409I RACF Database Index Error
RVARY RACF Activate\Inactivate
SET APF = SET APF Parameters Member
SET SMF = SET SMF Parameters Member
SET SVC = SET SVC Parameters Member
SET LNK = SET LNK Parameters Member
T APF = SET APF Parameters Member
T SMF = SET SMF Parameters Member
T LNK = SET LNK Parameters Member
T SVC = SET SVC Parameters Member
T CLOCK SET System Clock
T DATE SET System Date
SETSMF= SETSMF Parameters
SS = SETSMF Parameters (abbreviated)
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
$HASP050 JES2 Shortage Message

$HASP070 JES2 Error Termination
$HASP095 JES2 Catastrophic Error
$HASP098 Enter Termination Option
$HASP201 Remoter Operator Invalid Password Entered
$HASP397 Job Re-enqueued for Processing
$HASP398 Job Re-queued for Processing
$HASP50 Invalid NJE Signons or Passwords
$HASP628 INTRDR Internal Reader Has Been Reset
IEA101A Specify System Parameters
IEA347A Specify Alternate Master Catalog
IEA911E Complete Dump of SYS1.DUMPxx
IEC606I VTOC Disabled
IEE050I SMF Recording Stopped
IEE129I Console SWITCH Message
IEE351I SMF Recording Stopped
IEE357I SMF Init Change Occurred
IEE358I SYS1.MANx Not Found Recording Stopped
IEE361I SMF Data Lost
IEE363I SMF SER Not Direct Access
IEE364I SYS1.MANx I/O Error Recording Stopped
IEE365I SYS1.MANx PARMLIB NOP Opened
IEE366I SMF Data Sets Not Available
IEE950I SYS1.MANx Cannot Be Allocated
IEE951I SYS1.MANx DSORG Invalid
IEE959I System Error During SMF Processing
IEE960I SYS1.MANx Data Set Too Small
IEE961I SMF Initialization Failed
IEE962E SMF Terminated

COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
IEE962I SMF Terminated

IEE978E SMF Buffer Shortage
IEE979W SMF Data Lost
IEE980I SMF Restarted After Failure
IEE982I SMF Exit Inactive
26.1.1.2 Select SMF record type 90 and verify this against z/OS SYSLOG events.
There should be a complete audit trail of all console command activity.
26.1.1.3 Determine the frequency and process for reviewing SYSLOG and escalating
unusual activity.
26.2 z/OS exits
Audit/assurance objective: System exits should be documented, approved and well-tested using
installation change procedures. Access to systems exits should be monitored.
27. System exits DS9.1
Control: System exits are monitored and controlled according to installation change DS9.2 X X
management policies and procedures. DS9.3
27.1.1.1 System exits already identified in previous individual audit steps should be
reviewed to ensure that no exits circumvent or provide special privileges to
jobs or users that might introduce security and integrity vulnerabilities to the
operating system environment.
27.1.1.2 Dead code in assembler code is that which is never referenced, commented
out or branched around in normal processing. If indicated by other findings,
review exit code process flow to ensure that dead code is not assumed to be
effective.
27.1.1.3 Since system exits are deviations of normal processing, all exits should be
properly documented as to purpose, use, prolog of exit changes, author, date,
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
and management authorization.

27.1.1.4 All exits should be subject to installation program change control
procedures.
CONFIGURATION CHANGE MANAGEMENT
28.1 Operating system configuration changes/updates
Audit/assurance objective: Only operating systems configuration changes and updates/upgrades
that are authorized, evaluated and prioritized should enter the change process.
DS9.2
29. Management of operating system configuration changes DS9.3
Control: Management classifies, reviews, and approves operating system change AI3.3
X X X X
requests. This control ensures that management has considered the changes in the queue AI6.1
and has approved the changes. AI6.2
AI6.4
29.1.1.1 Obtain the entity’s standards, procedures and guidelines for identifying,
classifying and approving operating system configuration change requests.
29.1.1.2 Based on reviewing documentation, interview and observation:
29.1.1.2.1 Determine if a process exists to classify operating system change
requests as an infrastructure change.
29.1.1.2.2 Determine if a process exists to perform a risk assessment that is
focused on the impact of the change on other systems or
applications.
29.1.1.2.3 Determine if there is a process to perform an impact analysis on
changes to determine the effect the change would have on the
integrity and availability of the business process.
29.1.1.2.4 Determine if the appropriate approvers within IT operations and
IT technical support (operating systems responsibility) document
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
their approval of the change.

29.1.1.2.5 Determine if the change requests are subject to prioritization.
29.1.1.2.6 If prioritization is performed, determine if appropriate
management regularly authorizes the priority.
29.1.1.2.7 Determine that all system changes be applied using SMP/E. User
zaps should be discouraged or be supported with proper
documentation and management approvals.
DS9.2
DS9.3
30. Completion of review and testing prior to implementation AI6.1
Control: Program changes require signoffs by the appropriate management prior to X X X
AI6.4
implementation. AI6.5
30.1.1.1 Determine the sign-off process prior to a change moving into production
includes the following:
30.1.1.1.1 Technical support indicating completion of testing, quality
assurance, documentation.
30.1.1.1.2 IT operations, indicating acceptance of documentation,
scheduling changes, backup changes, runtime changes, etc.
30.1.1.1.3 Information security, indicating acceptance of information
security changes.
DS9.2 X X
31. Management monitoring of configuration changes/upgrades
DS9.3
Control: Management reviews program changes to ensure that only authorized
AI6.1
operating system configuration changes are included in the modification process.
AI6.2
AI6.4

COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
AI6.5
31.1.1.1 Determine how management reviews the changes to ensure that only
authorized changes have been implemented.
31.1.1.2 Determine if SMR/E is in use for configuration edits.
31.1.1.3 Verify compliance with change procedures.
31.2 Change management governance
Control Objective: Change management process is subject to management oversight to ensure
consistent and timely processing of changes.
32. Operating system change summaries DS9.2
Control: Management receives timely reports, summarizing change management DS9.3
X X X X
activities, key performance indicators and escalation of issues requiring management AI6.1
attention. AI6.4
32.1.1.1 Identify the reports management receives and the frequency and scope of
the reports.
32.1.1.2 Determine if service level agreements (SLA) are in use. If so, verify that the
reports summarize SLA attainment and/or deficiency.
32.1.1.3 Determine the escalation process for change management processes
operating outside of normal conditions.
SYSTEM BACKUPS
33.1 System backups
Audit/assurance objective: The systems should be backed up on a regular basis in a manner to
minimize data loss in the event of hardware or software failure, or a physical incident.
DS4.9 X
34. Backup procedures
Control: Appropriate backup procedures are in effect to ensure backups on schedule,
executed automatically and include the necessary files to ensure the capability of
COSO
Risk Assessment
Referenc Issue
Control Environment
e Cross- Comments
Control Activities
Monitoring
reference
restoring the operating system and applications.

34.1.1.1 Determine that the operating system and its components are backed up
regularly.
35. Backup generations DS4.9 X
Control: Multiple generations of the files are maintained off site.
35.1.1.1 Determine how many generations of the operating system files are retained.
36. Backup testing DS4.9 X
Control: Backup tapes are subject to test restores to ensure readability.
36.1.1.1 Determine if there is a program to restore backups on a rotational basis and
verify the accuracy and readability of the data contained therein.

VII. Maturity Assessment
The maturity assessment is an opportunity for the reviewer to assess the maturity of the processes reviewed. Based on the results of audit/assurance review, and the
reviewer’s observations, assign a maturity level to each of the following C OBIT control practices.
Referenc
Assessed Target e
COBIT Control Practice Comments
Maturity Maturity Hyper-
link
AI6.1 Change Standards and Procedures
1. Develop, document and promulgate a change management framework that specifies the
policies and processes, including:
• Roles and responsibilities
• Classification and prioritization of all changes based on business risk
• Assessment of impact
• Authorization and approval of all changes by the business process owners and IT
• Tracking and status of changes
• Impact on data integrity (e.g., all changes to data files being made under system and
application control rather than by direct user intervention)
2. Establish and maintain version control over all changes.
3. Implement roles and responsibilities that involve business process owners and appropriate
technical IT functions. Ensure appropriate segregation of duties.
4. Establish appropriate record management practices and audit trails to record key steps in the
change management process. Ensure timely closure of changes. Elevate and report to
management changes that are not closed in a timely fashion.
5. Consider the impact of contracted services providers (e.g., of infrastructure, application
development and shared services) on the change management process. Consider integration
of organizational change management processes with change management processes of
service providers. Consider the impact of the organizational change management process
on contractual terms and SLAs.

Referenc
Assessed Target e
link
AI6.2 Impact Assessment, Prioritization and Authorization
1. Develop a process to allow business process owners and IT to request changes to
infrastructure, systems or applications. Develop controls to ensure that all such changes arise
only through the change request management process.
2. Categorize all requested changes (e.g., infrastructure, operating systems, networks,
application systems, purchased/packaged application software).
3. Prioritize all requested changes. Ensure that the change management process identifies both
the business and technical needs for the change. Consider legal, regulatory and contractual
reasons for the requested change.
4. Assess all requests in a structured fashion. Ensure that the assessment process addresses
impact analysis on infrastructure, systems and applications. Consider security, legal,
contractual and compliance implications of the requested change. Consider also
interdependencies amongst changes. Involve business process owners in the assessment
process, as appropriate.
5. Ensure that each change is formally approved by business process owners and IT technical
stakeholders, as appropriate.
AI6.4 Change Status Tracking and Reporting
1. Ensure that a documented process exists within the overall change management process to
declare, assess, authorize and record an emergency change.
2. Ensure that emergency changes are processed in accordance with the emergency change
element of the formal change management process.
3. Ensure that all emergency access arrangements for changes are appropriately authorized,
documented and revoked after the change has been applied.
4. Conduct a post-implementation review of all emergency changes, involving all concerned
parties. The review should consider implications for aspects such as further application
system maintenance, impact on development and test environments, application software
development quality, documentation and manuals, and data integrity.

Referenc
Assessed Target e
link
DS5.3 Identity Management
1. Establish and communicate policies and procedures to uniquely identify, authenticate and
authorize access mechanisms and access rights for all users on a need-to-know/need-to-have
basis, based on predetermined and preapproved roles. Clearly state accountability of any user
for any action on any of the systems and/or applications involved.
2. Ensure that roles and access authorization criteria for assigning user access rights take into
account:
• Sensitivity of information and applications involved (data classification)
• Policies for information protection and dissemination (legal, regulatory, internal policies
and contractual requirements)
• Roles and responsibilities as defined within the enterprise
• The need-to-have access rights associated with the function
• Standard but individual user access profiles for common job roles in the organization
• Requirements to guarantee appropriate segregation of duties
3. Establish a method for authenticating and authorizing users to establish responsibility and
enforce access rights in line with sensitivity of information and functional application
requirements and infrastructure components, and in compliance with applicable laws,
regulations, internal policies and contractual agreements.
4. Define and implement a procedure for identifying new users and recording, approving and
maintaining access rights. This needs to be requested by user management, approved by the
system owner and implemented by the responsible security person.
5. Ensure that a timely information flow is in place that reports changes in jobs (i.e., people in,
people out, people change). Grant, revoke and adapt user access rights in co-ordination
with human resources and user departments for users who are new, who have left the
organization, or who have changed roles or jobs.

Referenc
Assessed Target e
link
DS5.4 User Account Management
1. Ensure that access control procedures include but are not limited to:
• Using unique user IDs to enable users to be linked to and held accountable for their actions
• Awareness that the use of group IDs results in the loss of individual accountability and are
permitted only when justified for business or operational reasons and compensated by
mitigating controls. Group IDs must be approved and documented.
• Checking that the user has authorization from the system owner for the use of the
information system or service, and the level of access granted is appropriate to the business
purpose and consistent with the organizational security policy
• A procedure to require users to understand and acknowledge their access rights and the
conditions of such access
• Ensuring that internal and external service providers do not provide access until
authorization procedures have been completed
• Maintaining a formal record, including access levels, of all persons registered to use the
service
• A timely and regular review of user IDs and access rights
2. Ensure that management reviews or reallocates user access rights at regular intervals using
a formal process. User access rights should be reviewed or reallocated after any job
changes, such as transfer, promotion, demotion or termination of employment.
Authorizations for special privileged access rights should be reviewed independently at
more frequent intervals.
DS9.1 Configuration Repository and Baseline
1. Implement a configuration repository to capture and maintain configuration management
items. The repository should include hardware; application software; middleware;
parameters; documentation; procedures; and tools for operating, accessing and using the
systems, services, version numbers and licencing details.
2. Implement a tool to enable the effective logging of configuration management information
within a repository.
3. Provide a unique identifier to a configuration item so the item can be easily tracked and
related to physical asset tags and financial records.
4. Define and document configuration baselines for components across development, test and
production environments, to enable identification of system configuration at specific points
in time (past, present and planned).
5. Establish a process to revert to the baseline configuration in the event of problems, if
determined appropriate after initial investigation.
6. Install mechanisms to monitor changes against the defined repository and baseline. Provide
management reports for exceptions, reconciliation and decision making.
Referenc
Assessed Target e
link
DS9.2 Identification and Maintenance of Configuration Items
1. Define and implement a policy requiring all configuration items and their attributes and
versions to be identified and maintained.
2. Tag physical assets according to a defined policy. Consider using an automated mechanism,
such as barcodes.
3. Define a policy that integrates incident, change and problem management procedures with
the maintenance of the configuration repository.
4. Define a process to record new, modified and deleted configuration items and their relative
attributes and versions. Identify and maintain the relationships between configuration items
in the configuration repository.
5. Establish a process to maintain an audit trail for all changes to configuration items.
6. Define a process to identify critical configuration items in relationship to business functions
(component failure impact analysis).
7. Record all assets—including new hardware and software, procured or internally developed—
within the configuration management data repository.
8. Define and implement a process to ensure that valid licenses are in place to prevent the
inclusion of unauthorized software.
DS9.3 Configuration Integrity Review
1. To validate the integrity of configuration data, implement a process to ensure that
configuration items are monitored. Compare recorded data against actual physical existence,
and ensure that errors and deviations are reported and corrected.
2. Using automated discovery tools where appropriate, reconcile actual installed software and
hardware periodically against the configuration database, license records and physical tags.
3. Periodically review against the policy for software usage the existence of any software in
violation or in excess of current policies and license agreements. Report deviations for
correction.

VIII. Assessment Maturity Vs. Target Maturity—z/OS Only
DS9.1 Configuration Repository and Baseline

5
4
DS9.2 Identification and Maintenance of
AI6.4 Change Status Tracking and Reporting
Configuration Items
3
AI6.2 Impact Assessment, Prioritization DS9.3 Configuration Integrity

0
and Authorization Review
AI6.1 Change Standards and Procedures DS5.3 Identity Management
Target
DS5.4 User Account Management Assessment

COBIT OS Z

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

COBIT OS Z

Uploaded by

Copyright:

Available Formats

z/OS Security Audit/Assurance Program

© 2009 ISACA. All Rights reserved. Page 2

ISACA wishes to recognize:

ISACA Board of Directors

© 2009 ISACA. All Rights reserved. Page 3

© 2009 ISACA. All Rights reserved. Page 4

IT Governance, Risk and Control

Responsibilities of IT Audit and Assurance Professionals

II. Using This Document

Work Program Steps

© 2009 ISACA. All Rights reserved. Page 5

© 2009 ISACA. All Rights reserved. Page 6

© 2009 ISACA. All Rights reserved. Page 7

III. Controls Maturity Analysis

Figure 2—Maturity Model for Internal Control

© 2009 ISACA. All Rights reserved. Page 8

IV. Assurance and Control Framework

ISACA IT Assurance Framework and Standards

ISACA Controls Framework

© 2009 ISACA. All Rights reserved. Page 9

Minimum Audit Skills

© 2009 ISACA. All Rights reserved. Page 10

V. Executive Summary of Audit/Assurance Focus

z/OS Operating System Security

Business Impact and Risk

Objective and Scope

© 2009 ISACA. All Rights reserved. Page 11

© 2009 ISACA. All Rights reserved. Page 12

VI. Audit/Assurance Program

1. PLANNING AND SCOPING THE AUDIT

1.4 Identify and document risks.

© 2009 ISACA. All rights reserved. Page 15

2.2 Select the images to be included in the review.

development, test and application production naming conventions. It should also

 Tape Management Exits (e.g., CA-1)

© 2009 ISACA. All rights reserved. Page 18

3.1 System datasets

4. Systems data sets access restrictions DS9.2

© 2009 ISACA. All rights reserved. Page 20

4.1.1 Identify all system datasets by executing available utilities or tools.

© 2009 ISACA. All rights reserved. Page 21

programs are referenced in the PPT. DS9.3

9.2 Supervisor calls (SVC)

© 2009 ISACA. All rights reserved. Page 27

undergo normal program change controls (e.g., SMP/e).

© 2009 ISACA. All rights reserved. Page 32

produced, distributed and reviewed on a regular basis as an integral part of

17.2 Job entry subsystem

© 2009 ISACA. All rights reserved. Page 33

© 2009 ISACA. All rights reserved. Page 34

parameter statements. The production version of this dataset should be under

© 2009 ISACA. All rights reserved. Page 36

20.2 Time sharing option (TSO)

22. TSO commands DS9.2

previous audit tasks and identify:

© 2009 ISACA. All rights reserved. Page 39

system error messages. The following commands and messages would be of

$HASP050 JES2 Shortage Message

© 2009 ISACA. All rights reserved. Page 42

IEE962I SMF Terminated

and management authorization.

their approval of the change.

© 2009 ISACA. All rights reserved. Page 45