DB2 AUDIT PROGRAM 1 of 2

AUDIT: DB2

AREA: APPLICATION SYSTEMS

OBJECTIVE: To ensure that applications which make use of DB2 databases

are adequately controlled.

SECURITY ADMINISTRATION

1. Is there a security administrator who is tasked with granting authority

to access data as required or is this devolved. Whichever way is used, is

there any control over the granting of authority to ensure that all

authorisations are valid and have been approved.

ADMINISTRATIVE FUNCTIONS

Determine who has access to the high level administrative privileges as

follows. Ensure that these facilities are restricted to those persons who

require them as part of their regular duties.

1. DBADM Determine who has DBADM for the particular database under review

from review of the SYSDBAUTH table in the DB2 catalog. Ensure that these

are not held with the GRANT option unless absolutely necessary.

2. DBCTRL Determine who has DBCTRL authority for the database under review

from the SYSDBAUTH table of the catalog. Ensure that these are not held

with the GRANT option unless absolutely necessary.

3. DBMAINT Determine who has DBMAINT authority for the database under

review from the SYSDBAUTH table of the catalog. Ensure that these are not
held with the GRANT option unless absolutely necessary. MONITORING

SECURITY

1. Are there procedures to monitor all access rights to data on a regular

basis to ensure that they are all still valid.

2. Are there any installation defined reports which indicate applications

where access has failed so that investigations can be carried out.

3. Are sensitive DB2 functions logged for review. These are the sensitive

functions used by those with SYSADM, DBADM, DBCRTL, DBMAINT AND SYSOPR.

These functions are recorded on SMF records which can be extracted on a

regular basisand listed (or further analysed) for review by the DBA or

security administrator.

DATABASE SECURITY

1. For each database, determine the names of all relevant tables and

views. This can be found from the SYSTABLES table of the catalog.

For each table and view in the relevant database, review the SYSTABAUTH

table in the catalogue to determine who is authorised to: update data,

alter the table, delete rows, create indexes, insert rows, select rows

update rows,

Ensure that this authority is conducive to good security and that all

accesses are approved within installation procedures. 2. Determine which

columns are contained in each table or view. This can be found from the
SYSCOLUMNS table of the catalog.

Determine which data items are significant and ensure that adequate access

controls exist to limit access to data. Review the SYSCOLAUTH table of the

catalog to determine who has UPDATE authority over the data item in

question.

3. For each view of the data in the relevant database, determine what

columns are in the view. This can be found from the SYSVTREE table in the

catalog. In the case where extremely sensitive data is contained in the

database, ensure that access to views containing this data is limited to

maintain confidentiality.

EXIT ROUTINES

1. For each database table under review determine whether use is made of

the Edit and Validation exits. The procedure names associated with each

table can be found within the SYSTABLES table of the catalog.

Determine what processing is carried out by each exit and evaluate what

effect it will have on the control and security over the particular table.

Ensure that each exit load module is contained within a library which is

protected using RACF or some other mechanism and that updating of exit

load modules is limited by the installation change management and control

procedures.

2. For each field within each table, determine if there are attached field
procedures. This can be determined from the FIELDPROC indicator in the

SYSCOLUMNS table in the catalog. The name of the particular procedure can

be determined from the SYSFIELDS table in the catalog.

Determine what processing is carried out by each field procedure and

evaluate what effect it will have on the control and security over the

particular data item.

Ensure that each field procedure is contained within a library which is

protected using RACF or some other mechanism and that updating of field

procedures is limited by the installation change management and control

procedures. UTILITY PROGRAMS

The authority to use utility programs is controlled by the DB2 authorisation

mechanism.

DB2 UTILITY PROGRAMS

Certain of the DB2 utilitiesallow sensitive functions. They should be

restricted to those persons who have a need to use them for the

maintenance of the databases. Determine who has the authority to use the

following utilities and evaluate any potential security and control

implications:

1. COPY AND MERGECOPY Determine who has the authority to run these

utilities against the particular database. In addition to the person with

SYSADM authority, DBADM, DBCTRL OR DBMAINT authority over the particular

database the utility can also be run by anyone who has been granted the
IMAGCOPY privilege for the database containing the table space named. This

can be determined from the IMAGCOPYAUTH parameter of the SYSDBAUTH table

in the catalog. Ensure that this authority is limited. Ensure that back-up

image copies are taken regularly and that MERGECOPY is used only when

required for recovery purposes.

2. LOAD Determine who has the authority to use this utility to load data

into database tables. In addition to the persons with SYSADM authority,

DBADM or DBCTRL authority over the particular database it can

*************************************************************************************
DB2 AUDIT PROGRAM 2 of 2

DB2

AREA: SOFTWARE INSTALLATION

OBJECTIVE: To ensure that adequate control and security is applied over

_________ the DB2 software and operating environment and that adequate

standards and procedures are in place for applications which use DB2.

ADMINISTRATION AND ORGANISATION

1. Review the organisational structure to determine who is responsible for

the installation of the software, maintenance of the software, performance

monitoring, administration of security, database design and application

development.

2. Ensure that the organisational structure provides for an adequate

division of duties to provide for control and security. No one individual

should have total responsibility for all areas.

STANDARDS AND PROCEDURES

1. Review all standards as they pertain to the use of DB2 within the

installation. Ensure that standards exist and that they provide a

framework within which the software can be controlled and applications can

be developed in a manner which is conducive to control and security as

well as being efficient.

Standards should exist in the following areas:

a. The level of security to be applied to the data being stored. This

should provide a definition of the access controls to be applied as well

as a method for determining the sensitivity of the data. Security needs to

be applied depending on sensitivity. These standards should also cover the

policy on the granting of privileges, especially when the "GRANT with

GRANT" option is used. In addition, the granting of the administrative

privileges needs to be properly defined within standards.

b. The control over the data which is to be applied. This should include

requirements for editing and validating the data which is entered into the

database, the requirements for control totalling and the requirement for

audit trail. These standards should cover the use of the standard SQL

exits to provide for control routines.

c. There should be some form of standard which details the steps to be

followed when designing applications which use DB2. These standards should

specify the responsibility for database design and should also cover such
areas as standard naming conventions. This has a beneficial effect when

systems are being maintained. Other items which can be included are

standards for the issuing of COMMIT statements by application programs.

d. There should be written procedures for the operation of the DB2

software. This should lay down responsibility for starting and stopping

DB2 and individual databases and should cover the emergency procedures to

be followed in the event of DB2 or database failure.

e. There should be written standards and procedures for the taking of

image copies for recovery purposes. The frequency of copying and the use

of incremental as well as full image copies should be defined. There

should be a definition of the minimum time between full image copies to

minimise recovery time, while minimising the time to take the copies.

Ensure that these times are realistic. SECURITY ADMINISTRATION

1. Determine whether the required level of security over DB2 databases is

defined within installation standards. Such standards should define who is

allowed the administrative functions and how authority is to be granted.

2. Is there a security administrator who is tasked with granting authority

to access data as required or is this devolved. Whichever way is used, is

there any control over the granting of authority to ensure that all

authorisations are valid and have been approved.

ADMINISTRATIVE FUNCTIONS

Determine who has access to the high level administrative privileges as

follows. Ensure that these facilities are restricted to those personswho

require them as part of their regular duties.

1. SYSADM - Determine who has this authorisation. It allows the holder to

execute any operation within DB2. This can be determined by enquiring

against the SYSUSERAUTH table in the DB2 catalog and by determining who

can use the relevant authorisation ids specified in DSNZPARM. Ensure that

these are not held with the GRANT option unless absolutely necessary.

2. SYSOPR - Determine who has SYSOPR authority from the SYSUSERAUTH table

of the catalog. Ensure that these are not held with the GRANT option

unless absolutely necessary.

MONITORING SECURITY

1. Are there procedures to monitor all access rights to data on a regular

basis to ensure that they are all still valid.

2. Are SMF records showing the number of failed access attempts produced

and reviewed on a regular basis. Is action taken to investigate any

abnormal failed activity.

3. Are there any installation defined reports which indicate applications

where access has failed so that investigations can be carried out.

4. Are sensitive DB2 functions logged for review. These are the sensitive

functions used by those with SYSADM, DBADM, DBCRTL, DBMAINT AND SYSOPR.

These functions are recorded on SMF records which can be extracted on a

regular basis and listed (or further analysed) for review by the DBA or

security administrator. SOFTWARE CONTROLS

The DB2 software is parameter driven. The auditor should examine the

current values of these parameters and evaluate the effect on control and

security.
*******************************************************************************

PBX TELECOMMUNICATIONS AUDIT PROGRAM

SUBMITTED BY:

Dr Frederick Cohen

Audit Plan:

Protection Management

Who is responsible for maintaining and operating

the equipment?

Are maintenance agreements the most cost effective

agreements available?

* Surely there are a lot more protection management

responsibilities than this. What are they, how can

they be clarified, how do they relate to the rest of

this checklist?

Protection Policy

Is there a company written policy on phone use?

* What is it? Are there particular features it should have,

and what are they?

Are there things it should not have, and what are they? Why

is the policy set as it is, who sets it, how does it change,

is it realistic for the environment?

Standards and Procedures

Are Customer Service Records reconciled with the Property

Accounting Fixed Asset Register?

Are monthly phone bill tracking reports reviewed?

Are PBX traffic, performance, circuit outage, and problem

reports reviewed by telecom management?

Is there an agreement with the LEC, the IXC, and the

equipment vendors for the ability of only authorized

personnel to request service level changes, and to

report errors?

Is there a regular dump of Incoming Peg Count, Attendant

Response, All Trunks Busy, Service Queue, and Trunk

Group Overflow reports? Reported to telecom management?

What are the procedures for making PBX SW or HW changes.

Is the PBX program backed up whenever changes are made?

Does anyone on the telecom staff carry a pager number

during off-hours?

Are all orders for services in writing? Are confirmations

in writing?

Are service order numbers used?

Are bills reviewed for accuracy? How often?

Are monthly telephone bills distributed to department

managers for review? Do they sign approval and return them?

How are phone charges allocated to each cost center?

Are they accurate?

Are all toll calls billed verified against the PBX

traffic reports?

How are billing issues resolved?

Is there internal recording of Install/Remove services?

Are all leased trunks, lines, and circuits billed

verified against the PBX inventory reports?

Are services for part of the month pro-rated?

 Is Call Detail Recording (CDR) or Call Accounting

reconciled with phone bills?

Are maintenance bills reviewed, broken down, and

verified? By who? How and who approve replacement parts?

* There are a lot of good standards and procedures questions here, but

they are not tracked to policy requirements, they don't track to the

documentation or other components of the questions, and the people

responsible for them are not asked about.

Documentation

Obtain network maps and topology diagrams, telecommunication

records, and policy and procedure guides. Are they up

to date and easily understood?

Are Customer Service Records listing the equipment

reviewed and retained? By whom?

Are monthly phone bill tracking reports generated?

Accurate and up to date list of current trunks and

leased lines?

Are circuit numbers clearly marked on channel banks,

CSU/DSUs, and modems?

 Is there an up to date list that correlates telephones

and Central Office lines to ports on the PBX?

Are MDFs and IDFs clearly labeled?

Are the procedures for making PBX SW or HW changes

fully documented?

Is there a list of authorized contacts?

Does the telecom manager have a list of home phone

numbers for the LEC, IXC, and PBX account executives?

Are PBX operating manuals available to telecom staff?

Are there 3rd party calls on the phone bills?

Is Call Detail Recording (CDR) or Call Accounting enabled?

* This is an interesting list. It is probably not comprehensive,

but it is more so than the other areas. There is no question

about where the documentation is kept and who has access, how

the documentation tracks to the other areas, etc. but it's a

real good start.

Protection Audit

* Oops! Nothing on protection audit to speak of. Who audits

 the PBX, how often, what do they look for, etc. This is

covered to some extent in standards and procedures, but

only a few issues are loosely covered and no explanation of

why is provided. Audit has to be done by specific people

who do PBX audits in order to be effective.

Technical Safeguards

Are DISA capabilities activated?

Are "leaky PBX" capabilities designed?

Is there a modem on the PBX programming port?

Is there a UPS?

Are 976, (900), and (700) calls blocked?

Is Call Detail Recording (CDR) or Call Accounting enabled?

* This is a starting point, but hardly comprehensive. A good

PBX auditor will cover many other technical issues.

This is, of course, PBX specific, so it's hard to make

a generic list, but more than these items should be included.

Incident Response

Is there a disaster recovery plan?

 Is there a standby site for moving operations in the

event of a disaster? Does it have sufficient trunking

for voice and data? Is it periodically re-evaluated or

tested?

Is the PBX program backup stored off-site?

Has a "bounty hunter" telecom payment consultant been

used in the past? Results?

Do maintenance agreements guarantee technician

response time?

* This is deisnged for disaster recovery only. It doesn't

take a comprehensive view of incidents and how they are

responded to. How do we respond to day-to-day incidents?

How do we detect them? Who does it? What tools do they need? etc.

Testing

Has the disaster recovery plan been tested?

Is the UPS tested?

* Only a beginning. There are a lot of other testing issues

that have to be addressed in a comprehensive PBX audit.

Physical Protection

Where is the telephone equipment (PABXs) located?

Who has access to the equipment?

What are the visiting procedures for accessing the

equipment?

Are craftspeople escorted?

Is there fire suppression equipment installed and

tested?

Are cabinet doors kept closed and locked?

Do the cables entering and leaving the PBX or equipment

room pass through firestop material?

Are power circuits clearly marked?

* This is a good starting list, but not a comprehensive list

of physical security issues to be considered.

Personnel Issues

* Oops. Persopnnel issues are largely ignored in this

checklist.
Legal Considerations

What are the purchase/lease/rental agreements for

telecom equipment?

What maintenance agreements are signed?

* It's a start, but where is corporate liability covered?

How about employee agreements? Is policy properly

verified by legal, and is it enforcable? How do we

proceed to track down attackers so that we can prosecute,

or do we want to prosecute? Is there adequate insurance? etc.

Protection Awareness

Are there education programs for users?

* This is not an adequate question to cover the issue of

awareness.

Training and Education

What training is provided telecom staff for the PBX?

* This is not an adequate question to cover these issues.

Organizational Suitability
* This is not addressed in the audit at all.

Supplied by

Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

---> See: Info-Sec Heaven at URL http://all.net

***********************************************************************************

TELECOMMUNICATIONS AUDIT PROGRAM

SUBMITTED BY:
-------------------------------------------------------------------------------
Denis Kelly, | Phone: 7027137 / 6765831
Senior Computer Auditor | Fax: 6778463 / 6615376
Electricity Supply Board | Int Phone: 353-1-7027137.
Lr Fitzwilliam St, | Internet: Denis.Kelly@N1.ESB.IE
Dublin 2. Ireland. | < Standard Disclaimers Apply>
--------------------------------------------------------------------------------

AUDIT OF A CORPORATE TELECOMMUNICATIONS FUNCTION

Introduction: Telecommunications is a critical service for the majority if not

all businesses. The scale of dependence on telecommunications will vary greatly
from the sole trader with a mobile phone, to large corporates such as banks and
power utilities with vast telecommunication infrastructures. This audit program
concentrates on the large corporate end of the scale where organisations have a
large telecommunications infrastructure. These organisations usually have
internal divisions or subsidiaries which are responsible for the operations and
management of the infrastructure. With the high dependence on telecomm services
and the large expenditure usually incurred in providing these services effective
control is essential. This audit program therefore considers the telecomms
group as a business entity in it's own right and considers all users of the
services as customers. In the context of my own organisation the group are
internal but this approach could also be used for a subsidiary.

This audit program was designed to look at both the financial and technical
controls employed. The control objectives and standards of both ISACA and the
Institute of Internal Auditors (IIA) were incorporated into the design of tests.
In addition relevant local and corporate regulations were considered. This
audit program is a prototype of how a telecommunications function can be
audited. Each auditor needs to consider the specific needs of their own
organisation and the jurisdiction where the organisation operates. These
differences may have a very significant impact on the emphasis and coverage of
the audit program. However this program should give a good general framework
for such an audit.

TELECOMMUNICATIONS AUDIT

AUDIT SCOPE

To assess the quality of internal controls in the

Telecommunications Function including controls over the
achievement of Value for Money.

DETAILED OBJECTIVES

O Review the objectives and plans.

O Assess the management information provided.

O Review the compliance with internal and external regulations,

procedures and legislation.

O Review the controls in place for safeguarding assets.

O Review the controls in place to ensure that the required

quality of service is provided.

O Assess the control of Projects.

1. REVIEW THE OBJECTIVES AND PLANS.

Review of the objectives of telecomms for compatibility with

Corporate, Business Unit and Department Objectives. Ensure plans and
structures are in place to meet those objectives.

1.1 Objectives: Review objectives including Corporate,

 Departmental and Division. Are they clear, coherent
and compatible.

1.2 Telecomm Planning: Are plans in place to meet

objectives. Assess the planning process, is it well
controlled. Is there a Strategic Plan for Corporate
Communications, Assess its coverage and content.

1.3 Structures: Review the structure of the

Telecommunications Function. Is it logical and
effective. Is is compatible with the objectives and
plans. Are roles and responsibilities clearly
defined.

2 ASSESS THE MANAGEMENT INFORMATION PROVIDED.

General test of management information centres around testing for

accuracy, relevance, timelines, usability and presentation. How well
informed are management.

2.1 Review the Financial Information.

Establish what financial information managers currently

receive for capital and revenue purposes.

Review the Financial Information provided to managers and

assess it's relevance, timelines and input into the decision
making process.

Sample the data provided and verify its accuracy and

completeness.

Review the budgeting process.

Identify information gaps and shortfalls.

Review overtime, expenses, work in progress and other

operational costs including the cost of delays in job
closing.

2.2 Review Operational Information.

Review information provided to managers on Work Plans,

including progress reporting and work allocation.

Review information provided to managers to assist with the

management of traffic and control of the cost of the telecomms
network.
 Review information provided to management on faults and
outages on the telecomms network.

Review information provided to management on staff

productivity including job costing and time usage.

Review information provided to verify the accuracy of external

service providers bills. e.g. PABX billing information to
cross check PTT Bills.

Review information provided on transport fleet management.

Review the information provided on accommodation/ space

management.

What management information is available, Is it reviewed on an

ongoing basis?

2.3 Review the links achieved between Financial and Operational

Information.

Are management using the information effectively. Is it

adequate for control purposes.

Review the tracking of jobs from a financial and operational

perspective.

How is the Financial and operational information linked to

maximise VFM.

3 REVIEW THE COMPLIANCE WITH INTERNAL AND EXTERNAL REGULATIONS,

PROCEDURES AND LEGISLATION.

Review the compliance of telecomms to internal and external

regulations. The main focus being the controls in place to ensure
this is happening.

3.1 Review the controls in place to ensure awareness and compliance

with non technical Internal Regulations/Procedures including
Human Resources, Purchasing, etc... Do clear lines of
responsibility exist. Establish how compliance assured.

3.2 Review the controls in place to ensure awareness and compliance

with technical Internal Regulations/Procedures. Do clear lines
of responsibility exist.

The following points will be tested.

1. Identify the key regulations and procedures which apply to

telecomms in the following areas:

- Safety e.g. Certificates of Fitness, Safety procedures,

etc.
- Security and Data Protection.
- Code of Ethics including Conflict of Interests.
- Corporate Regulations and Circulars.
 2. Discuss with Telecomms Management how they are made aware of
and ensure that Internal Regulations and Procedures are
complied with ?

- Briefings.
- Library/ Standards Files.
- Reviews and Technical Audits.

3. Review the documentation which is produced by Telecomms to

comply with Regulations and Procedures ?

- Safety Manuals.
- Training Records.
- Security Documentation.
- Operating and Maintenance.
- Circulation and Update of same.

4. Review the awareness of staff to the compliance required ?

- Awareness with requirements.

- Training/Briefings.

3.3 Review the controls in place to ensure awareness and compliance

with External Technical Regulations/Legislation. Do clear
lines of responsibility exist.

The following points will be tested.

1. Identify the key legislation and regulations.

- Safety.
- Broadcasting Act.
- Conditions of Service from TE.
- Communications Regulations and Licensing Conditions.
- Equipment Supplier Conditions.
- Procedures for work at Third Party sites including
insurance.

2. Discuss with Telecomms Management how they are made aware of

and ensure that Legislation and Regulations are complied with ?

- Briefings.
- Library/ Standards Files.
- Legal advice.
- Reviews and Technical Audits.

3. Review the documentation which is produced by Telecomms to

comply with Legislation and Regulations?

- Correspondence, Certificates and Licences.

- Copies of standards, Legislation and Regulations.
- Safety Manuals.
 - Training Records.
- Security Documentation.
- Operating and Maintenance Instructions.

4. Review the awareness of staff to the compliance required ?

- Awareness with requirements.

- Training/Briefings.

4 REVIEW THE CONTROLS IN PLACE FOR SAFEGUARDING ASSETS.

Review the controls, procedures and standards in place to ensure

corporate telecommunications assets are safeguarded. This should
include accurate recording and tracking of assets, safe operation,
regular maintenance, adequate security and orderly disposal.

4.1 Establish what policies, procedures and standards are in place

to safeguard assets. This should include maintenance,
operations and security controls.

4.2 Review the procedures and controls in place to ensure effective

and efficient Risk Management is undertaken.

The following points will be tested.

1. Identify the main risks which exist?

2 Does a formal Risk management strategy and plans exist?.

Does this include regular review?

3. Are the plans adequate?

4. Are management and staff aware of risks and plans?

5. Are liability exposures identified? Is there sufficient

Insurance cover?.

4.3 Review the general security controls and procedures in place.

This should include Physical Security, Logical Security,
Segregation of Duties, etc.

How is liaison with the Corporate Security Manager and IT

Security Manager achieved. What Authorisation Procedures and
Reviews take place. ?

What management information is provided to ensure security is

operating and effective. ?

Do standards exist which specify the level of controls to be

implemented ?
 Review the contingency Planning which has been undertaken by
Telecomms under the following points

- Does an overall contingency strategy exist for Telecomm

systems ?

- Identify the the Contingency Plans which exist?. Is the

coverage adequate.

- Do regular formal reviews, including testing, take place?

- Assess the staff awareness of contingency and contingency

plans?

4.4 Review the controls in place that ensure assets are acquired in
compliance with established policies and procedures including
VFM.

4.5 Review the controls in place to ensure that recording of

assets, for financial and operational purposes, is accurate and
adequate.

4.6 Review the procedures and systems in place to ensure the

continued existence and protection of assets occurs over their
entire lifetime. Do stock checks take place.

4.7 Review the procedures in place to ensure that maintenance and

operation of telecommunications assets is carried out
effectively, safely and to the required standard.

Testing will include:

1. Refer to OBJ 4.1 Re policy.

2. Review how Telecomms Management ensure maintenance and

operations are effective.

3. Review how Telecomms Management ensure the standards of

maintenance and operations are assured. Including
compliance to supplier requirements and recommended
procedures.

4. Review how Telecomms Management ensure operations and

maintenance is carried out how safely and in compliance to
relevant regulations.

5. Review the control of maintenance carried out by external

contractors. How is the work verified and it's quality
checked.

6. Does fault analysis take place to ensure maintenance is

optimised to reduce failures ? Is the analysis adequate?
 7. Review the use of periodic performance monitoring of
systems to predict when preventive maintenance is required.
How are failures or service degradation detected and
monitored.? Is the monitoring adequate.?

8. How is the cost effectiveness of maintenance and operations

assured? Are systems reviewed to identify potential
improvement and cost savings? Consider the following:

- Checks on PTT Bills.

- Inventory of Lines on lease and their use.
- On going Cost Benefit Analysis of services.
- Review of service quality and availability from
alternative suppliers.
- Capacity Planning ?

9. Review the maintenance undertaken by Telecomms staff using a

sample of maintenance records.

10. Review the recording of faults, tracking of progress and

sign off of work. ?

4.8 Review the controls in place to ensure assets are disposed of

in compliance with established procedures.

5 REVIEW THE CONTROLS IN PLACE TO ENSURE THAT THE REQUIRED QUALITY

OF SERVICE IS PROVIDED.

Review the controls in place to ensure that the services required

by customers are delivered cost effectively and to the agreed
level of quality. Specific emphasis should be given to the VFM
aspects of the service delivery.

5.1 Review the controls which ensure Telecomms management and staff
are aware of Customer requirements.

5.2 Review the controls which ensure the Services Delivered are
those requested by users and are provided in a timely and cost
effective manner.

5.3 Assess the controls in place to assure the quality of the

services provided by Telecommunications.

5.4 Assess the controls in place to assure that value for money is
maximised in the provision of services to customer.

6 ASSESS THE CONTROL OF PROJECTS.

Review the control of Telecommunications Projects to ensure
that they are effectively managed and controlled. ( The project
management objective was reviewed in two parts (i) Business and
Financial Controls (ii) Technical controls.)

PROJECT REVIEW: FINANCIAL AND MANAGEMENT INFORMATION ASPECTS.

These tests will be applied to each of the sample projects

selected

Test 6.1 Establish the current status of the project, ie.

completed, in-progress, etc.

Test 6.2 Approval stage should be reviewed under the following

headings

- procedures for project approval.

- approval and authorisation records.

- establish if the project was subject to re-approval or

modification at any stage. Were controls complied with.

Test 6.3 Implementation Planning: Review procedures in place

for control of the following.

- Material/Services and Spares procurement planning

including lead times.

- Work Planning, including scheduling, work breakdown and the

impact on the resources other areas inside and outside of
Telecomms.

- Planning of the control procedures to be put in place for

the control and management of the Project.

Test 6.4 Project Implementation: Review procedures in place for

the following.

- Procurement of materials/services (including external

contractors)

- Individual job control, including authorisations.

- Work Scheduling - Time

- Materials Distribution
- Feedback controls - ie reporting
Project Mgt.
 - Project Tracking - Performance monitoring
- Budget/financial resources incl.
re-approvals
- Progress vs Plans for work and
materials.

- Disposal of Retired Assets

Review procedures in place for disposal of retired assets

including following aspects:

- Authority

- Procedures (Stores)

- Documentation to remove from Asset Register

including approval.

Test 6.5 Project Handover: Review procedures for the following.

- Handover to customers

- Handover to maintainers including

- Listing of equipment for handover.

- Listing of Test equipment
- Listing of Spares
- Capitalisation of Completed Projects including:

- Costs reviewed before capitalisation.

- Re-approval procedures.
- Controls over capitalisation to asset
identifier.
- Asset Register Updates.

Test 6.6 Post Project Review

Review procedures in place for reviewing the following:

- Assessment of the project as a whole and it's sub

components.
- Lessons learnt from the project.
- planning and control of the project.
- how well were objectives achieved
- Completed Cost V Budget and approvals.

PROJECT REVIEW TECHNICAL ASPECTS.

These tests will be applied over a number of projects but will

concentrate on the general approach taken.
6.1 Review the controls in place on the initiation, planning and
approvals of Telecomms Projects.

Consider the controls mechanisms used for the following steps.

- Project initiation, fit to the overall Strategy and

Approvals.
- Decision to opt for Turnkey or Build Internally.
- Planning and Associated Approvals.
- Management of the Risks associated with the project.
- Technical Benefit Analysis Process.
- Tendering/Approvals.
- Award of contract.

6.2 Review the control of project in progress with specific

attention to the reporting on progress and actions to address
divergence from plans. The control of contractors, equipment
compliance to specification, Acceptance Testing and
Commissioning should be considered.

consider the control of projects in progress under the

following headings.

- How is progress reported.

- How are divergences from plans addressed.
- How are contractors controlled and managed.
- How do Telecomms ensure equipment delivered is in compliance
with the specification.
- What level of Acceptance Testing and Pre-Commissioning is
undertaken. Does this include Pilot tests.
- Review the documentation and recording of systems while they
are being installed.
- How is Risk Managed during a project? Is it formally
reviewed regularly and changes reported?

6.3 Review the controls in place to ensure projects are correctly

completed and post implementation reviews are undertaken.
Specific emphasis should be given to Commissioning, Hand over
and Operation.

Review for each of the following:

1. Commissioning Procedures.

2. Hand over and Operation Procedures. Review the documentation

and records compiled for systems when they have been
commissioned.

3. Post Implementation Review. Is the delivered system reviewed

to ensure it meets the original specification with approved
changes.
This audit program was developed by Denis Kelly, Senior IT Auditor, Electricity
Supply Board, Dublin, Ireland.

DISCLAIMER:

This document is to be considered a prototype and no warranty or guarantee of

accuracy, implied or stated exists. No responsibility for loss occasioned to
any person acting or refraining from action as a result of any material included
in this paper is taken by the author or his employer. Permission for use is
granted for non-commercial, personal or educational purposes. Permission is
granted to describe this document in product or on-line services, but not to
produce it in whole or in part without written permission. For written
permission please contact Denis.Kelly@N1.ESB.IE

*************************************************************************************
TELEPHONE INFORMATION AUDIT PROGRAM

AUDIT OUTLINE QUESTIONS

* Physical Security

Where is the telephone equipment (PABXs) located?

Who has access to the equipment?

What are the visiting procedures for accessing the equipment?

Are craftspeople escorted?

Is there fire suppression equipment installed and tested?

Are cabinet doors kept closed and locked?

Do the cables entering and leaving the PBX or equipment room pass through

fire-

stop material?
Are power circuits clearly marked?

* Facilities Management

Who is responsible for maintaining and operating the equipment?

Obtain network maps and topology diagrams, telecommunication records, and

policy and procedure guides. Are they up to date and easily understood?

Are Customer Service Records listing the equipment reviewed and retained? By

whom? Are they reconciled with the Property Accounting Fixed Asset Register.

Are monthly phone bill tracking reports generated and reviewed?

Are PBX traffic, performance, circuit outage, and problem reports reviewed

by

telecom management?

Is there an agreement with the LEC, the IXC, and the equipment vendors for

the

ability of only authorized personnel to request service level changes, and to

report

errors?

* PBX Control

Accurate and up to date list of current trunks and leased lines?

Are DISA capabilities activated?

Are "leaky PBX" capabilities designed?

Are circuit numbers clearly marked on channel banks, CSU/DSUs, and modems?

Is there an up to date list that correlates telephones and Central Office

lines to
ports on the PBX?

Is there a regular dump of Incoming Peg Count, Attendant Response, All Trunks

Busy, Service Queue, and Trunk Group Overflow reports? Reported to telecom

management?

Are MDFs and IDFs clearly labeled?

What are the procedures for making PBX SW or HW changes. Are they fully

documented?

Is there a modem on the PBX programming port?

* Disaster Recovery

Is there a disaster recovery plan? Has it been tested?

Is there a standby site for moving operations in the event of a disaster?

Does it

have sufficient trunking for voice and data? Is it periodically re-evaluated

or

tested?

Is there a UPS? Is it tested?

Is the PBX program backed up whenever changes are made? Is it stored

off-site?

Is there a list of authorized contacts? Does anyone on the telecom staff

carry a

pager number during off-hours?

Does the telecom manager have a list of home phone numbers for the LEC, IXC,

and PBX account executives?

* Cost Management
What are the purchase/lease/rental agreements for telecom equipment?

What maintenance agreements are signed? Are they the most cost effective

agreements available? Do they guarantee technician response time? Are

maintenance bills reviewed, broken down, and verified? By who? How and who

approve replacement parts?

Are all orders for services in writing? Are confirmations in writing? Are

service

order numbers used?

Has a "bounty hunter" telecom payment consultant been used in the past?

Results?

* Training

What training is provided telecom staff for the PBX? Are operating manuals

available to them?

Is there a company written policy on phone use? Are there education programs

for users?

* Billing

Is Call Detail Recording (CDR) or Call Accounting enabled? Is it reconciled

with

phone bills?

Are bills reviewed for accuracy? How often?

Are monthly telephone bills distributed to department managers for review?

Do
they sign approval and return them?

How are phone charges allocated to each cost center? Are they accurate?

Are all toll calls billed verified against the PBX traffic reports?

Are all leased trunks, lines, and circuits billed verified against the PBX

inventory

reports?

How are billing issues resolved?

Is there internal recording of Install/Remove services?

Are services for part of the month pro-rated?

Are there 3rd party calls on the phone bills?

Are 976, (900), and (700) calls blocked?

*************************************************************************************

MVS PARMLIB

1. Review the current production versions of the IEAAPFxx and LNKLSTxx

members of SUS1.PARMLIB to determine the DSNLINK and DSNLOAD libraries for

the production DB2 system.

Ensure that the correct libraries are specified.

DSNZPARM ENTRIES

Review the DSNTIJUZ job which contains the macros used to build DSNZPARM.

Ensure that this job is held in a protected library and that changes to

the macros are

*************************************************************************************
CICS COMPUTER AUDIT PROGRAM
A. CICS SET-UP

There should be adequate control over the CICS initialisation process to

ensure that the appropriate control tables, data sets and terminals are used

during CICS processing.

1. Obtain a PDS listing of the CICS load libraries. Obtain a copy of the start

up procedures.

2. Determine the following from a review of the CICS Analyser report and the

PDS listing:

a. the number of versions of the SIT (System Initialisation Table). Determine

reasons for each version,

b. the procedures for determining and authorising the SIT used during

initialisation,

c. the number of versions of the control tables and management modules

available,

d. the procedures for determining and authorising the version of the control

tables and management modules used during initialisation,

e. the current production version of the control tables and management

modules,
f. the procedures for determining, authorising and reviewing any override

parameters used during initialisation,

g. if on-line resource definition is used (RDO), review the procedures for

determining and authorising the group list to be used.

3. Review the current production version of the SIT to determine that it

contains the current production versions of the control tables and management

modules, and that options are properly used.

a. determine that the current production version of the SIT was used.

b. examine for overriding parameters, particularly,

i. for excluding or including tables or modules, e.g. DCP=NO, FCT=NO

ii. for changes in suffixes, e.g. PCT=S3.

iii. disabling CICS security checking, XSP=NO

iv. disabling external security, EXTSEC=NO

c. Where overriding parameters have been used, ensure that they have been

appropriately authorised and documented.

d. Examine the order of concatenated load libraries to ascertain that the

correct control tables were initialised and only valid libraries were
included.

4. Evaluate the adequacy of start up procedures.

a. determine that computer operations personnel fully understand the

procedures.

b. review SYSLOG to ascertain that the correct procedures were used.

5. Review procedures for cancelling CICS.

6. Where on-line resource definition is used,

a. review the current production version of the SIT to determine that the

GRPLIST operand is teh current authorised group list.

b. review the sample of actual start-up job streams to ensure that any

override GRPLIST operand has been appropriately authorised and documented.

7. Review the PDS listing of CICS load libraries for members with names other

than DFH***. Determine reasons for any found.

8. Review the naming convention for tables. Select samples from the production

libraries and test compliance.

B. GENERATING CICS

To determine that jobs which are assigned Security privileges and are designed
for initiating CICS subsystems (either started tasks) or standard batch jobs)

do not bypass security controls.

1. Determine if CICS is initiated by a started task (COMMND member

CMD="S,CICS").

2. Determine that the appropriate options, SECURITY, ACCOUNT, NO-SMC, MUSASS,

(STC if a started task) are associated with the LOGONID, attributes which

involve program pathing RESTRICT, SUBAUTH, PROGRAM and also validate APF

authority.

3. Determine if the default LOGONID for started tasks (STCDFLT LID =) exists

and evaluate the effect on control of CICS start-up procedures.

4. Identify the name of the CICS default LOGON ID.

5. Review and evaluate the attributes given to the CICS default LOGON ID

(attributes should include RESTRICT, SUBAUTH, PROGRAM = ACFAESIP).

6. Identify who can update source and linkage module.

D. CICS MANAGEMENTS TRANSACTIONS

There should be adequate controls over sensitive management transactions

to ensure that their use is restricted to authorised operators for

authorised purposes.

1. By enquiry and review of the PCT, determine which sensitive transactions

are available. By enquiry, determine if any have been renamed. At least the
following transactions and programs should be identified:

CECI

FDOD

CEDF

CEMT, CSMT

ADYN (=DALL)

OLTEP

CORE (=DBUG)

XAMS

OLIB

ADSP

CEDB (Release 1.7)

CEDC (Release 1.7)

DFH99

DFHBUG

2.a. Have the following attributes been included in the PCT for each

transaction:

i. Transaction priority and security identification.

ii. Transaction work area (TWA) length used to determine the size acquired for

this transaction.

iii. Initial processing program identification.

iv. Transaction statistics.

v. Transaction purge status (purgeable or non-purgeable).

2.b. By enquiry, determine how the sensitive management transactions and

programs are restricted and authorised.

NOTE - If RACF is used, determine the extent to which RACF controls these

transactions.

3. Determine the transaction security key values given to sensitive management

transactions.

a. CEMT, CEST, CSMT, CSST, CEDA, CECI, by reviewing the PCT entry (DFHPCT TYPE

= INITIAL TRANSEC operand).

i. If this is not coded, the default value is 1.

b. Using these values, review the SNT to determine the operators who have

access to these transactions (DFHSNT TYPE = ENTRY SCTKEY operand).

4. For all other sensitive transactions (including CEBR) review the PCT to

determine the transaction security value (DFHPCT TYPE = ENTRY TRANSEC

operand).

5. For CEDF/CECI/CECS, determine if default resource level security checking

is used by examining the PCT entry (for DFHPCT TYPE = ENTRY, RSLC = YES should

be coded). RSL should not be PUBLIC.

6. For all other sensitive management transactions and programs review the

resource rules.

7. For each temporary storage queue that can be browsed by CEBR, review the

TST entry for DFHTST TYPE = SECURITY, to ensure that security checking is

required.

8. If on-line resource definition is used, determine if an audit trail is

maintained by reviewing the DCT for DESTID = CSDL.

E. RESTART AND RECOVERY

1.a. Determine which resources have been defined as "protected" or

"recoverable" by enquiry and reference to the FCT.

1.b. Have the following attributes been specified for each data set in the

FCT.

i. Data set organisation (ISAM DAM or DL/I)

ii. Accessing options

iii. Data set characteristics (block size)

iv. Indirect accessing or indexing control information

v. Record segment definitions

Note: DL/I data bases are the only resources that are automatically
defined as protected. All others are optionally protected.

2. Determine by enquiry and review of the FCT whether logging an journalling

is performed automatically or by user application program (LOG= and JID=

entries)

3. For files that are journalled, review procedures for swapping journal files

to tape.

4. For files that are not journalled or logged, determine how files are backed

up for restart and recovery purposes. Determine how program FDP, PEP,NEP and

TEP can be used for restart and recovery purposes.

5. Review the JCT for BUFSIZE, BUFSUV, JTYPE and JOUROPT.

a. BUFSUV should be 2/3 size of BUFSIZE.

b. If JOUROPT = crucial, determine reasons.

c. Journal should have sufficient space to log activities. Determine how

system acts when log is full.

6. Review the start up job streams to determine the START option used, to

ensure that emergency restarts can be properly performed. (refer to SIT)

7. Determine by enquiry and review of FCT/SIT whether DTB is used.

8. Review SMF record, CICS statistics to determine the number of times for

CICS start-up shut down daily. Determine reasons for excessive start-up.
9. What SMF record will be recorded when CICS goes down. Perform applicable

tests as required.

F. APPLICATION CONTROL STANDARDS

1.By enquiry and review of available evidence, ensure that there are

up-to-date CICS application programming standards including standards for

purchased software systems.

2. Review the standards and assess their adequacy in the areas of:

a. coding requirements

b. requirements for user application journalling

*************************************************************************************

Following was contributed by (Rey LeClerc) at leclerc@scis.nova.edu

VM Operating System Review

Objectives: To ensure that adequate security procedures have been established

over VM.

General Description

The VM operating system was developed during the mid-1960s in order to create a
virtual system that would appear to each user as a dedicated machine.
Requirements vary among organizations of different sizes. Because of this,
there are different variations of VM to better meet these needs. Virtual
Machine/System Product (VM/SP) is really VM in its simplistic form. Running
VM/SP requires system programmer expertise for both installation and
maintenance, but provides flexibility to meet the needs of the organization.

VM/SP is generally considered to consist of two components: the Control Program

(CP) and the Conversational Monitor System (CMS).

CP is a set of programs which manages the real machine resources and creates
the virtual machine environment. The major functions of the CP can be
summarized as follows:
o user scheduling and dispatching;
o real storage management;
o virtual memory management;
o spool management;
o CP command processing;
o error recovery and recording.

CMS is an interactive operating system within VM, that operates under the
control of CP to manage the virtual machine environment. The basic components
of CMS are:
o editor;
o EXEC processor;
o Debug environment;
o OS simulation;
o commands, e.g., COMPARE, SORT, COPYFILE, etc.

Because of its capabilities of CP, VM is often referred to as the perfect

host. A myriad of different operating systems can coexist in the same machine
under the umbrella of VM's Control Program. These other operating systems CMS
are called guest operating systems. VM handles guest operating systems in much
the same way as multiple on-line users. Guest operating systems used for
production work should be subjected to complete audits as if they were running
in native mode.

System generation is the process that compiles the selected operating features
into an executable version of the operating system. System generation options
are specified in one of three CP source modules: DMKSYS, DMKSNT and DMKRIO.

DMKSYS, also known as the CP System Control File, consist of macro statements
that describe the following:
o CP system residence device;
o system storage device;
o CP-owned direct access devices;
o system operator's user identification;
o system timer value;
o system pointer variables;
o automatic performance monitoring parameters;
o accounting parameters;
o system identification;
o system spool parameters;
o security journalizing parameters;
o system dump space parameters;
o system T-DISK security parameters;
o missing I/O interruption timer intervals.

The Real Input/Output Configuration File (DMKRIO) consists of macros that

describe the input/output devices, control units, and channels attached to the
real processor.

The System Name Table (DMKSNT) consists of entries that identify the name and
location of saved systems or discontinuous saved segments.

After the three system generation modules are ready, the CP nucleus is
generated through a program called VMFLOAD. The CP nucleus can basically be
defined as the core of the VM system. It is the brains of the system, or the
code that gives the environment its basic VM attributes. After the system
generation is completed, and VM has gone through the Initial Program Load
(IPL), CP exists. The new CP resident nucleus is now loaded in real memory and
VM is available for further use.

The newly created VM system contains a CP directory, which is basically a list

of User-IDs and information about the virtual machines identified by User-IDs.

Audit Program

1. Obtain listings of DMKSYS, DMKRIO, DMKSNT and the CP Directory.

2. Check the value of the SYSCLR operand of the SYSRES macro in DMKSYS;
SYSCLR=YES should be specified to prevent unauthorized access to sensitive data
placed on T-disks. SYSCLR=YES is default. If SYSCLR=NO is specified, the
installation should have a published disclaimer for T-DISK security.

3. Check the SYSJRL macro specification in DMKSYS. JOURNAL=YES should be

specified to detect access attempts by unauthorized users. JOURNAL=NO is
default. PSUPRS=YES should be specified to suppress passwords as they are
being entered into the system. PSUPRS=NO is default.

4. Inspect the DMKRIO to verify that device specifications reflect the actual
hardware configuration and that excessive number of additional devices have not
been defined.

5. Verify the specifications of shared and saved systems in DMKSNT and check
for overlapping assignments on DASD.

6. Inspect the load list used by VMFLOAD and compare it with the IBM-supplied
list to ensure that no critical system modules have been deleted; verify that
deleted modules do not implement facilities that have been implied in DMKRIO or
DMKSYS and review any frequently used pagable modules that are or should be
resident.

VM OPERATING SYSTEM REVIEW

VM/SP Modifications

Objective: To determine whether VM/SP modifications are tested, documented and

performed according to established procedures.

General Description: Maintaining the VM operating system revolves around VM

product releases, which introduces new VM capabilities, and Program Update
Tapes (PUT), which provide fixes for previous problems. PUTs contain various
files that establish the system code at a specified PUT level. Typically, the
systems programmer applies an entire PUT. However, the programmer can also
apply a modification individually from the PUT to resolve a critical problem.

The systems programmer should maintain a log of all these changes, whether they
are IBM-supplied or local, including the date of the application, modules
affected, PTF (program temporary fix) number, and reason for the change. All
changes should be reviewed by the technical support manager so that users and
operations staff are aware of modifications that might affect them.
Audit Program

1. Review the latest PUT process output to verify that IBM-supplied maintenance
has been properly installed.

2. Confirm that all local modifications to CP have been properly installed,

adequately logged, and documented; review the justification for each local
modification.

3. Spot-check the CP nucleus map to verify that both IBM- and user-supplied
modifications have been included in the system nucleus.

4. Determine whether the systems supervisor or systems staff, other that the
original systems programmer, reviews all system and utility testing before
cataloging into production.

VM OPERATING SYSTEM REVIEW

Access Controls Review

General Description: The CP directory, also more broadly termed the VM

directory, serves as a repository for information including the definitions of
users, their CP privileges and classes, and the locations of their minidisks
where data is stored. There are two types of data sharing in VM. The first is
the directory link, which is used mainly for common applications like CMS.
This is automatically executed when a user logs on, and is maintained until the
user explicitly detaches this link. User may also share data through user
links. A user may explicitly link to share another user's minidisk.

There are four options that may be specified in designating a password:

o READ - permits access to data on a minidisk in a read-only mode;
o WRITE - permits users access to both read the data on the minidisk as well
as modify it;
o MULTIREAD - permits more that one user to read the minidisk at one;
o MULTIWRITE - more that one user can read and write into a minidisk at one.
This option has the potential for creating a nightmare, because data can be
modified concurrently with other users. This option is not supported for CMS
use because of its potential data destruction.

The logon password, which may also be up to 8 characters in length, is required

to log on to a User-ID, thereby gaining access to the system. The User-ID is
associated to one or more privilege class:
o Class A - Primary System Operator. This individual is allowed to control
and even terminate the total VM operation.
o Class B - System Resource Operator. At this level, the user is allowed to
examine the status of the system-owned units and make allocations for
requesting users.
o Class C - Systems Programmer. A Class C user can examine and modify real
storage, including the ability to examine and modify the main storage of other
users.
o Class D - Spooling Operator. This individual can alter the characteristics
of real spooling devices and queues. This would affect, for example, the
queues for printers and other devices.
 o Class E - System Analyst. This class allows the examination of real
storage, but without the ability to modify it.
o Class F - Engineer/Service Representative. A Class F user is allowed use of
extended I/O capabilities, preventing error recording while running. This
individual might be inclosed in making modifications to enhance response time.
o Class G - General User. This class is reserved for most users of the system.

It is also possible to tailor user privilege classes. With VM/SP Release 4,

installations have the ability to create up to 32 CP privilege classes as well
to dynamically assign capabilities.

Audit Program

1. Check user privilege classes against authorization forms to ensure that

users have proper resource accessibility.

2. Confirm that critical user IDs have password protection on their minidisks.
Verify that users have adequate level of privilege class.

3. Review the directory update directory for disk password changes. If

directory maintenance is performed manually, a log of all changes should be
kept. It an automatic system (e.g. DIRMAINT) is used, the system administrator
should retain all pertinent log information. Ensure that passwords are not
vendor supplied, easily guessed, repeated or users have multiple User-IDs.

4. Check the journal data for improper access attempts; note and check write
accesses to nonowner disks.

5. Determine whether User-ID AUTOLOG1 is defined in the user directory. The

user with this ID is automatically logged on at the conclusion of the system
initialization.

6. Inspect the file PROFILE EXEC on the 191 disk of user AUTOLOG1; review the
sequence of actions performed with AUTOLOG1 activated.

7. Review the VM utilities (e.g. VMFZAP, GENERATE) and determine if access to

them is adequately controlled.

VM OPERATING SYSTEM REVIEW

Tuning and Performance Efforts

Objective: To assess the quality of system performance and tuning efforts.

General Description: VM/SP has a built-in system activity monitor. VMAP

program product can produce a detail performance report. The review of this is
important because in addition to overall performance, we can see if there are
any overlapping minidisks. With overlapping minidisks, the process of getting
into data of others becomes easier because as this can be accomplished without
the need of a password. If not carefully mapped, it is easy to assign the same
minidisk space to two different users or simply waste the space contained in
the gap.
Audit Program

1. Obtain a DISKMAP listing and determine if gaps or overlaps affect system

performance or integrity.

VM OPERATING SYSTEM REVIEW

Sources/References

Auditing VM/SP by David M. Leonard (Auerbach Publishers Inc., 1985)

Handbook of EDP Auditing by Halper, Davis, O'Neil-Dunne, and Pfau (Warren,

Gorham & Lamont, 1985)

VM and Departmental Computing by Gary R. McClain (McGraw-Hill Book Company,

1988)

VM/SP General Information Manual (GC20-1838-4)

VM/SP Installation Guide (SC24-5237-2)

VM/SP Introduction (GC19-6200-3)

VM/SP Planning Guide and Reference (SC19-6201-04)

Following was contributed by (Rey LeClerc) at leclerc@scis.nova.edu

VM/BATCH

Objective: To ensure that adequate security procedures have been established

over VM BATCH.

Audit Program

1. Obtain and review the VMBATCH configuration file.

Key files for the VMBATCH configuration file that should be reviewed here are:

- ACCESS - identifies the VMBATCH database minidisks. Make sure that these
are restricted to the appropriate users only.

- AUTHORIZ - this record grants VMBATCH subcommand authorizations to the

specified users. Determine who has access to the ADMIN, OPERATOR, MANAGER, and
installation defined (if there are any) VMBATCH authorizations. Verify that
only the appropriate individuals have these capabilities.

- DIRECT - contains the virtual address of the read-only link between VMBATCH
and the CP object directory minidisk. Verify that access has been provided
only on an as needed basis.

- NODE - identified any RSCS nodes to be considered as part of a multiple-CPU

VMBATCH configuration. If this is defined, its also specifies various
processing options for each node in this configuration.
 - NOUSERIDF - controls whether a job can run on a remote VMBATCH system when
the submitting User-ID can not be found on the remote system.

- PREVENT - this record specifies any exceptions to the authorizations granted

ion the AUTHORIZ record. Review this in conjunction with the AUTHORIZ record.

- RESOURCE - allows the identification of special resources provided to

certain worker machines. This is significant only where the RESOURCE is coded
in the WORKER record and is used to control the foundations of a WORKER machine.

- USEREXIT - these optional records are used to specify the filenames of user
routines to receive control at various points in VMBATCH's operation.
Determine whether any exits are being used, and if so, which ones. Obtain the
source code for these exits and review them. Briefly describe their function
and evaluate their effect on VMBATCH controls.

- WORKER - specifies the User-IDs and characteristics of the worker machines.

Identify the production worker machines and the applications specifically
designated to them (in environment that have made associations between the
worker machines and specific applications).

2. Identify the users and groups that have been provided with access to the
production worker machines. This can be determined by reviewing the VMBATCH
user and group limits.

a. Using the VMBATCH configuration file, determine whether any of the AUTHORIZ
USER users are defined in (VMBATCH configuration file's) GROUP records.

GROUP records identify the User-IDs or subgroups that belong to specified

group. It also identified group managers.

User and groups can be only belong to one group; in the event that multiple
entries of this type have been made, VMBATCH insiders only the first entry to
be valid.

If the GROUP definitions rely on ACIGROUP definitions, review the CP directory

to determine the User-IDs of the group member entries. Identify any AUTHORIZ
USER User-IDs that are not in the GROUP definitions (e.g., those missing
ACIGROPU definitions in their CP directory entries, where ACIGROUP definitions
are being relied upon).

b. Signon to VMBATCH from a valid VMBATCH MANAGER account (the configuration

file AUTHOR MANAGER - and PREVENT - records specify who can perform this
function. From the Manager Function Menu, select LIMIT. Select CHANGE,
specifying each AUTHOR USER entry listed in the VMBATCH configuration file.

Evaluate the limits on the groups for the AUTHORIZ USER User-IDs first (i.e.
the User-IDs defined to the GROUP records). This is because group level limits
override user level limits ( and system level limits and user level limits).

Compare these limits with the characteristics defined to the production worker
machines in the WORKER records of the VMBATCH configuration file). Determine
who can run their jobs under the production WORKER User-IDs.
Reference Manual

VMBATCH System Administrators' Manual

VMBATCH User's and Group Manager's Guide

Following was contributed by (Rey LeClerc) at leclerc@scis.nova.edu

VM/Secure

Objectives: To ensure that adequate security procedures have been established

over VMSECURE.

Audit Program

1. Determine to what extent VMSECURE is controlling the data security

environment at this location, i.e. is VMSECURE used only for VM directory
maintenance, or is the rules facility also being used. If the rules facility
is being used, make sure that is appended to include examination of the rules
database and related configuration file records.

2. Obtain and review the VMSECURE configuration file listing. Examine the
parameters established for the key configuration file records.

The key configuration file records (for installations that are not using the
rules facility) and their associated audit concerns are:

- ACCESS - identifies the minidisks available to the VMSECURE service

machine. Determine whether access to these minidisks is adequately
restricted. verify that the DRCT and the BKUP minidisks do not reside on the
same DASD.

- DIRECT - identifies the CP-owned volume containing the page-formatted area

for the CP object directory. Verify that access to this minidisk is adequately
restricted. VMSECURE should have an MR link to the minidisk; if other users
share access to the minidisk, controls should prevent multiple users from
updating the CP object directory.

- ENCRYPT - this optional record tells VMSECURE that the directory database is
encrypted. This record is important because only where read access to the
directory database is not adequately restricted and the minidisk and/or logon
passwords in the directory are critical components to the access control
methodology at this location.

- GRANT - authorizes users to use VMSECURE subcommands, utilities and screen

selections. Ascertain that sensitive functions have been granted only as
needed.

- IGNORE - indicates which User-IDs or specific minidisks are ignored by

VMSECURE. This use of this record disallows VMSECURE from detecting (and
preventing) any minidisk overlays that involve the specified the specified
ignored minidisks.
 - LIST - groups authorizations or User-IDs for use on GRANT and WITHHOLD
records.

- USEREXIT - these optional records are used to specify the filenames of user
routines to receive control at various points in VMSECURE's operation.
Determine where any exits are being used, and if so, which ones. Obtain the
source code for these exits and review them. Briefly describe their function
and evaluate their effect on VMSECURE data security controls.

- VOLUME - identifies real and DASD volumes managed by VMSECURE. Make sure
that all intended volumes are included here.

- WITHHOLD - restricts users from using the VMSECURE commands, utilities, or

screen selections (that were explicitly provided to users in the GRANT
record). Review this record in conjunction with the GRANT record to determine
who has access to sensitive system functions.

3. Obtain and review the VMSECURE MANAGERS file listing (the file resides on
the VMSECURE 191 minidisk). Examine the MANAGER record(s) 'mgrid' parameter.
The User-ID(s) defined in this record have directory manager authority
(provided that MANGE subcommand capability has also been granted in the
VMSECURE configuration file). Determine whether the MANAGER capability has
been appropriately designated.

VMSECURE

Reference manuals

VMSECURE System Programmer's Reference manual

VMSECURE System Administrator's Guide
VMSECURE Directory manager's Guide
VMSECURE User's Guide
VMSECURE Rules Facility Guide