1. technology and computing
2. software
3. databases

PART 7-A
Technical audit of OS/390
Case “Local modifications”
Leen van Rij
kpmg IRM
vrije Universiteit amsterdam
29 October 2002
File 7-A Technical audit of OS390 case Local Modifications
© 2002
(with Note pages)
TECHNICAL AUDIT OF OS/390
SAMPLE ANSWER CASE
This example contains the attention items for answering the case. The structure of
standards, findings etc. is not strictly followed here, since the remarks are made
per foil.
Page 1
1
LvR/VU
OCT/2002
Contents
TECHNICAL AUDIT OF OS/390
CONTENTS OF THE WORKSHOP (3 groups of students)
• Case: Audit of local modifications and change management
• Computing center of VUBank:
– Organization and responsibilities
– Data-processing environment (mainframes, DASD and connections)
– Overview of current software and applications
(see handouts ‘VUBank’)
Technical audit of OS/390: Case local modifications
2
Page 2
2
LvR/VU
OCT/2002
How to write the report
HOW TO WRITE THE REPORT
• Objective and scope (objects and quality aspects), summary of major
findings and conclusions (directed to management)
• Appendices with per object of investigation:
– Standard (‘norm’: stellig, duidelijk en toetsbaar, zoals bijvoorbeeld
‘een wachtwoord dient niet triviaal en niet voorspelbaar te zijn’ en
‘voor iedere vitale dienst dient bekend en vastgelegd te zijn binnen
hoeveel uur na een incident deze weer toegankelijk is voor de
eindgebruikers en met welk kwaliteitsniveau’)
– Finding (in fact: observation)
– Evaluation (risk analysis)
– Recommendation
• Optional appendix with priorities for the implementation of the
recommendations (e.g., high, medium and low)
Technical audit of OS/390: Case local modifications
3
Page 3
3
CASE: AUDIT OF LOCAL MODIFICATIONS
LvR/VU
OCT/2002
CASE
CASE
AUDIT
AUDIT OF
OF LOCAL
LOCAL MODIFICATIONS
MODIFICATIONS
AND
AND CHANGE
CHANGE MANAGEMENT
MANAGEMENT
Technical audit of OS/390: Case local modifications
4
Page 4
4
Case: Audit of local modifications
LvR/VU
OCT/2002
CASE: AUDIT OF LOCAL MODIFICATIONS AND
CHANGE MANAGEMENT
• The VUBank computing center has a dedicated acceptance and
maintenance environment
• Change management has been introduced at an early stage and is used
for changes dealing with hardware, OS, standard program products and
the infrastructure
• A new application, called STOCKS and supporting stock-market
transactions, will be developed. It needs some new local modifications
• The development and maintenance of all code will be done by external
hires. All code is tested and installed by systems programmers of the
VUBank (via the change management process)
• The case deals with the ‘development phase’
Technical audit of OS/390: Case local modifications
5
Attention items are:
• Verify that only acceptance team members and authorized systems programmers
have access to the acceptance and maintenance environment. There must be
strict procedures and isolation to avoid access by any other person to this
environment.
• Verify that change management is effective and no changes are implemented
beyond this process.
• Verify that testing and installing at VUBank systems is really done by staff of the
VUBank and not by external hires.
Page 5
5
LvR/VU
OCT/2002
Exercise - group 1
EXERCISE: GROUP 1
• You, as an EDP-auditor, have to review the design for the SVC 202
routine
• Verify whether the design of the SVC 202 routine complies with the
guidelines for secure user SVCs
• Using the information in the handouts ‘VUBank’ and this case
description, can you find any weaknesses allowing you to obtain any data
or to issue any financial transaction for which you are not entitled?
• If there are (potential) weaknesses, describe them and suggest better
solutions
Technical audit of OS/390: Case local modifications
6
Conclusion: The current design of SVC 202 is insecure. Everybody can issue any
financial transaction or retrieve data through SVC 202 without the need for any
authorization. Moreover, hackers can misuse the SVC to endanger system
security and logging, and the continuity of the system. Recommend a redesign.
Page 6
6
LvR/VU
OCT/2002
Exercise - group 2
EXERCISE: GROUP 2
• You, as an EDP-auditor, have to review the effectiveness of the change
management process and the process of testing and implementing local
modifications
• Using the information in the handouts ‘VUBank’ and this case
description, can you find any weaknesses allowing you to obtain any data
or to issue any financial transaction for which you are not entitled?
• Pay attention to internal control, security, privacy, completeness of
logging, separation of duties, and verification by independent staff.
• The review has to include the initial installation of softeware,
maintenance and changes
• If there are (potential) weaknesses, describe them and suggest better
solutions
Technical audit of OS/390: Case local modifications
7
Conclusion: The current process for change management does not pay any attention
to security and internal control. There is no separation of duties within this
process. Testing is done by the developers themselves. Moreover, everybody can
issue any financial transaction without the need for any authorization.
Page 7
7
LvR/VU
OCT/2002
Exercise - group 3
EXERCISE: GROUP 3
• You, as an EDP-auditor, have to review the APF program and its
protection, the automatic job scheduling mechanisms, the JES2
modifications, and the exit routine
• The review has to include NJE, the usage of high RACF authorities by
the jobs involved, and the usage of passwords
• If there are (potential) weaknesses, describe them and suggest better
solutions
Technical audit of OS/390: Case local modifications
8
Conclusion: There is an unacceptable lack of control. With the current design, a
unknown number of people can do anything on the production system, without
any limitation by access control. Recommend an entire redesign of the
procedures and the local modifications. Partly the local modifications can be
replaces by using modern RACF facilities.
Page 8
8
LvR/VU
OCT/2002
Design of a new application
USERS connected
via network
MVS SYSTEM PROD-1
Automatic
submission of
job through OPC/A
STARTED TASK
‘STOCKS’, started
by operator
DATA BASE
APPLICATION
‘STOCKS’
TSO
APPL
SVC 202
CSA
Scratch and
individual data
SVC 202
data via
MVCP
MVCS
‘BANK.STOCK.TRANSACT’
transaction queue
APF BATCHJOB
‘STOCKJOB1’
(userid
TRUSTED)
SUBMIT job
via INTRDR and JES2
modification
NJE
JES2 modification
MVS SYSTEM PROD-2
‘BANK.STOCK.ACCOUNT’
financial data and
stock accounts
Technical audit of OS/390: Case local modifications
BATCHJOB
‘STOCKJOB2’
9
Attention items are:
• Why has the architect chosen for such a complicated structure? Using CICS or
IMS or a similar standard program product makes everything much easier.
Challenge the decisions by the architect.
• The number of local modifications and highly authorized jobs opens many
possibilities for weaknesses. As an EDP-auditor you have to verify all
components on their potential impact on security and internal audit.
Page 9
9
LvR/VU
OCT/2002
Started task
STARTED TASK ‘STOCKS’
The Data Base application STOCKS is started by a system operator at
08.00 by issuing the command S STOCKS. and stopped at 18.00 by issuing
the command P STOCKS
The JCL in ‘SYS1.PROCLIB(STOCKS)’ reads:
//STOCKS JOB (123),’Stock Apll’,TIME=1440,
// REGION=4000K,MSGCLASS=V
//STEP
EXEC PGM=STOCKS,PARM=PROCESS
//STEPLIB DD
DSN=BANK.STOCK.LOADLIB,DISP=SHR
//SYSOUT
DD
SYSOUT=*
//DATABASE DD
DSN=BANK.STOCK.TRANSACT,DISP=OLD
//CONTROL DD
DSN=BANK.STOCK.CNTL(STOCKS),DISP=SHR
//LOG
DD
DSN=BANK.STOCK.LOG,DISP=SHR
//
The data base is exclusively allocated (DISP=OLD)
Technical audit of OS/390: Case local modifications
10
Attention items are:
• Verify who has UPDATE or higher to ‘SYS1.PROCLIB’ and
‘BANK.STOCK.*’.
• Also verify who has READ-access. Verify whether somebody else can run the
program STOCKS as a batch job and, if so, whether it can be misused?
• Between 08.00 and 18.00 o’clock, the transaction database
BANK.STOCK.TRANSACT is exclusively claimed by this program (due to
DISPostion=OLD). However, can somebody get access to it beyond this time
period? If so, can transactions be read and/or inserted?
Page 10
10
LvR/VU
OCT/2002
Started task ...
STARTED TASK ‘STOCK’ (cont.)
• The RACF Started Task entry for this application reads:
PROGRAM NAME
= STOCKS
ASSOCIATED USERID = OPER
ASSOCIATED GROUP = OPER
PRIVILEGED
= YES
• The userid OPER has SPECIAL, OPERATIONS and AUDITOR
• Protection of load module: see below
• The application STOCKS:
– All transactions received via SVC 202 are stored in the data base
BANK.STOCK.TRANSACT, and statistics are updated
– Via SVC 202, the end user may view the transactions queued, the
transactions entered during the last 30 workdays, and the statistics
– Each hour, the transaction queue is copied via STOCKJOB1 to
PROD-2 and processed there
Technical audit of OS/390: Case local modifications
11
Attention items are:
• There is no need for any high RACF authority for the userid OPER. So one has
to remove SPECIAL, OPERATIONS and AUDITOR. Also the item
PRIVILEGED=YES in the RACF Started Task Table has to be removed, making
the program subject to proper RACF control.
• All transaction through SVC 202 are accepted. In which way is the authority to
submit transactions controlled? If this happens in the user’s program, everybody
writing his own program can issue any transaction through SVC 202.
• Which transactions can be viewed, only the user’s own transactions or all?
This description raises a number of questions, which are not answered by the foils of
this case. So you have to interview the developers and read the documentation of
the programs.
Page 11
11
LvR/VU
OCT/2002
Automatic job submission
AUTOMATIC JOB SUBMISSION
• Once per hour, the job STOCKJOB1 has to be submitted to transfer the
transactions from PROD-1’s queue to PROD-2’s data base
• One has installed IBM’s Operations Planning and Control /Advanced
(OPC/A) package as automatic job submission tool:
– The department Production Planning specifies a schedule for job
submissions, and provides JCL, userids and passwords
– Userids and passwords are stored in an OPC/A library which is
protected with UACC=NONE and UPDATE access only for two
persons in Production Planning
– The OPC/A program runs on all Level I systems, but the library with
userids and passwords is unique per system
Technical audit of OS/390: Case local modifications
12
Attention items are:
• Have all relevant logging options been activated to track the activities of these
two trusted persons?
No remarks on the use of OPC/A and the procedure. It seems to be OK.
Page 12
12
LvR/VU
OCT/2002
Automatic job submission ...
JCL OF STOCKJOB1
The JCL resides in a member in OPC’s JCL library, and reads:
//STOCKJOB1 JOB (123),’Stock Transactions’,
// MSGCLASS=V,REGION=4000K,TIME=2,NOTIFY=A99,
// USER=TRUSTED,PASSWORD=SECRET
//STEP
EXEC PGM=STOCKJOB1
//STEPLIB DD
DSN=BANK.STOCK.LOADLIB,DISP=SHR
//SYSOUT DD
SYSOUT=*
//SORTUT1 DD
DISP=(NEW,DELETE),UNIT=SYSDA,
//
SPACE=(CYL,(50,50))
//JOBSUBM DD
SYSOUT=(,INTRDR)
for JOB2
//CONTROL DD
DSN=BANK.STOCK.CNTL(STOCK1),DISP=SHR
//LOG
DD
DSN=BANK.STOCK.LOG,DISP=SHR
//
The SORTUT1 data set is used to sort the transactions. All data sets BANK.* are
cataloged in the Master Catalog of PROD-1
Technical audit of OS/390: Case local modifications
13
Attention items are:
• The password is included in the JCL. Verify that the spool dataset is properly
protected, so that nobody can read it.
• Moreover, using modern RACF support it is no longer necessary to specify a
password in the JCL. One may use password propagation or the Surrogate Userid
concept of RACF 1.9 up.
• The transactions are sorted in a temporary dataset (DDname SORTUT1 with
DISP=(NEW,DELETE). One should activate RACF Erase on Scratch for this
dataset or let the application erase the contents after using it, otherwise the
transactions will stay on disk after deleting the temporary dataset.
Page 13
13
LvR/VU
OCT/2002
Automatic job submission ...
JCL OF STOCKJOB2
STOCKJOB1’s code contains JCL reading:
//STOCKJOB2 JOB (123),’Stock Updates’,REGION=4000K,TIME=2
/*ROUTE XEQ
PROD-2
/*ROUTE PRINT PROD-1
//STEP1
EXEC PGM=STOCKJOB2,PARM=UPDATE
//STEPLIB DD
DSN=BANK.STOCK.LOADLIB,DISP=SHR
//SYSPRINT DD
SYSOUT*
//DATABASE DD
DSN=BANK.STOCK.ACCOUNT,DISP=SHR
//LOG
DD
DSN=BANK.STOCK.LOG,DISP=SHR
//SYSIN
DD
*
(sample input)
transfer f 50,- from 45678 to 90123 ...
transfer f 678,- from 34567 to 89012 ...
transfer f 234,- from 23456 to 78901 ...
transfer f 100,- from 12345 to 67890 ...
total amount is f 1062,//
All data sets BANK.* are cataloged in the Master Catalog of PROD-2
Technical audit of OS/390: Case local modifications
14
No remarks.
Page 14
14
LvR/VU
OCT/2002
Automatic job submission ...
CONTROL THE AUTOMATIC JOB SUBMISSION
• The JCL of STOCKJOB1 is stored in a well protected OPC library
• The JCL of STOCKJOB2 is part of the code of the program
STOCKJOB1 and does not contain a userid nor a password
• The programs reside in BANK.STOCK.LOADLIB which is an APF
library protected with UACC=NONE, UPDATE by two systems
programmers responsible for software installation at Level I, and READ
for the groups STOCK and Production Planning
• The member SYS1.PARMLIB(SCHED00) reads:
PPT PGMNAME(STOCKJOB2) NOPASS KEY(8)
• The log BANK.STOCK.LOG is protected with UACC=NONE,
UPDATE by the group STOCK, and READ by Production Planning
• The userid TRUSTED is connected to the group STOCK with the USE
authority
Technical audit of OS/390: Case local modifications
15
Attention items are:
• Why is the program STOCKJOB2 mentioned in the Program Properties Table
with NOPASS (this means, bypass RACF control). This program must be subject
to regular RACF control.
• Why has the entire group STOCK got UPDATE access to the logging dataset
BANK.STOCK.LOG? Only one or two userids with update for housekeeping
activities (copying and deleting log records) should be sufficient.
Page 15
15
LvR/VU
OCT/2002
Data classification
DATA CLASSIFICATION
The RACF administrator has enabled data classification by activating the
class SECDATA, adding a profile called SECLEVEL, and defining four
levels via the commands:
SETROPTS CLASSACT(SECDATA)
RDEFINE SECDATA SECLEVEL UACC(NONE)
RALTER SECDATA SECLEVEL
ADMEM(INTERNAL/50,
CONFIDENTIAL/100, RESTRICTED/150,
SECRET/200)
The numbers are used to perform comparisons such as ‘higher than or
equal to’
Technical audit of OS/390: Case local modifications
16
No remarks. Correctly defined.
Page 16
16
LvR/VU
OCT/2002
Data classification ...
DATA CLASSIFICATION (cont.)
All data bases and data sets of the group BANK.STOCK.* contain privacyrelated data, and are hence classified as Confidential. The RACF
administrator (with SPECIAL and AUDITOR) has issued:
ADDSD ‘BANK.STOCK.*’ GENERIC AUDIT(ALL(READ))
ERASE
NOTIFY(SECOFFICER)
OWNER(STOCKMGR)
SECLEVEL(CONFIDENTIAL)
SETROPTS ERASE(NOSECLEVEL)
SECLEVELAUDIT(CONFIDENTIAL)
so activating Erase-on-Scratch and auditing for these data bases and data
sets
Technical audit of OS/390: Case local modifications
17
No remarks. Correctly defined.
Page 17
17
LvR/VU
OCT/2002
Local modifications
LOCAL MODIFICATIONS
The new application STOCKS requires four new, additional local
modifications:
1 User SVC 202 for inter-address space data transfer between TSO
address spaces and the data base application STOCKS
2 APF mainline program and 24 APF subroutines for inter-system
exchange of data
3 JES/NJE modifications to prevent specification of USERID= and
PASSWORD= in JOB card for NJE jobs submitted by userid
‘TRUSTED’
4 RACF RACINIT exit routine interacting with the JES2/NJE
modifications
Technical audit of OS/390: Case local modifications
18
Attention items are:
• The standard is: “No local modifications, unless it is absolutely necessary”. So
verify the justification for developing the SVC, the JES/NJE modifications and
the RACF exit routine.
• Moreover, the JES/NJE modification and RACF exit are not necessary if one
uses modern RACF support, such as password propagation and Surrogate Userid.
Page 18
18
LvR/VU
OCT/2002
SVC 202
‘SYS1.PARMLIB(IEASVC00)’ contains:
SVCPARM 202,TYPE(3),EPNAME=DATAMOVE,APF(NO)
The function of the SVC-202 routine is:
• Caller provides in R1 pointer to his own buffer with data
• SVC routine for SVC 202 (running in Supervisor Mode with key-in-PSW =
ZERO):
1 GETMAIN 500-byte buffer in CSA; copy caller’s data to CSA buffer
2 submit SRB to the address space of the Data Base Application STOCKS
and wait
3 SRB task will:
» copy CSA data into private buffer
» execute requested STOCKS function (retrieve or update data)
» return reply data into CSA buffer
» awaken caller’s address space
4 copy 500 bytes from CSA to caller’s buffer; FREEMAIN CSA buffer
5 return to caller with caller’s mode and key-in-PSW
Technical audit of OS/390: Case local modifications
19
Attention items are:
• Everybody can issue this SVC. The description contains no indication of any
authorisation mechanism. This implies that everybody can write a program to
issue financial transactions and/or to retrieve data.
• A hacker can misuse this SVC to breach system security. In step 4, the SVC
routine (running in Supervisor Mode and Key=0) writes 500 bytes to a location
specified by the caller in register R1. The hacker can specify any address in
register R1, including key=0 areas of the operating system and RACF. Without
testing the caller’s key, the SVC routine will write 500 bytes to this area. This is
a threat to the continuity of the system and may, under certain circumstances, be
used to modify the system’s security and logging.
Page 19
19
LvR/VU
OCT/2002
APF batch job
APF BATCH JOB STOCKJOB1
• Collect every hour all transactions submitted by individual users and send
them to PROD-2 to update the data base BANK.STOCK.ACCOUNT
• The function of STOCKJOB1 is:
– Run with APF bit = ‘1’
– Establish a dual-address space environment to exchange data
– Use the code of the application STOCKS to obtain the transaction
queue’s contents (STOCKS then also copies it to the list of transactions
entered, so allowing future inquiries, and resets thereafter the queue)
– Obtain the transactions via the semi-privileged MOVE CHARACTER
FROM SECONDARY TO PRIMARY and MOVE CHARACTER
FROM PRIMARY TO SECONDARY (MVCP and MVCS) instructions
– Allocate the JES2 Internal Reader and submit the transactions as batch
job STOCKJOB2 to PROD-2
Technical audit of OS/390: Case local modifications
20
No remarks.
Page 20
20
LvR/VU
OCT/2002
JES2 modifications
JES2 MODIFICATION 1 ON PROD-1: This code is activated every time
when a job submits another job via the JES2 internal reader
FLOWCHART:
JES2/NJE
NO
if userid of submitter
is ‘TRUSTED’
YES
store in NJE header
field ABC = C’OK’
store in NJE header
field ABC = X’0000’
continue JES2/NJE processing
Technical audit of OS/390: Case local modifications
21
Explanation: If the user TRUSTED submits a batch job, the internal JES2/NJE
header is modified. A locally defined field ABC is filled with the text C’OK’.
This header is sent with the job to the destination system for further processing.
There the field ABC is used to bypass RACF password verification.
Question: Why this complicated solution? Use RACF facilities.
Page 21
21
LvR/VU
OCT/2002
JES modifications ...
JES2 MODIFICATION 1 ON PROD-1: A code review shows:
* load addresses of data fields in R1 and R2
LA R1,address(userid of submitter)
LA R2,address(NJE header field ABC)
* submitted by trusted user?
CLC 0(8,R1),=C’TRUSTED ‘ test 8 characters
BE OK
yes
* submitted by a systems programmer?
CLC 0(4,R1),=C’SPRO’
test 4 ch prefix
BE OK
yes, any syspro
* non-trusted submitter
MVC 0(2,R2),=X’0000’
mark non-trusted
B
EXIT
* trusted submitter
OK MVC 0(2,R2),=C’OK’
mark trusted
EXIT ...
Note: the syntax of Compare Logical Character and Move Character is:
CLC offset(length,address),string
MVC offset(length,destination-address),source-string
Technical audit of OS/390: Case local modifications
22
Attention items are:
• The solution is too complex.
• Why is also tested on the prefix C’SPRO’ ? This means that all systems
programmers may also submit batch jobs which bypass RACF password
verification on the production system PROD-2. This indicates misuse of the
system and creates possibilities for hackers and fraudsters.
• Ask the question: Who has designed this code and who has verified it? What
were their intentions? If there is any indication of intentional misuse or fraud,
this must be reported to your principal.
Page 22
22
LvR/VU
OCT/2002
JES modifications ...
JES2 MODIFICATION 1 ON PROD-2
This code is activated every time when a job arrives via NJE
FLOWCHART:
JES2/NJE
NO
if NJE header field
ABC is C’OK’
YES
- store in JCT field
XYZ = C’OK’
- store in JCT field
USERID=C’TRUSTED
- XYZ = X’0000’
- copy USERID from
JCL JOB card
- standard JES2 processing
continue JES2/NJE processing
(JCT = Job Control Table, associated to a batch job and residing in the JES2 checkpoint
data set)
Technical audit of OS/390: Case local modifications
23
Attention items are:
• On the previous foil, the code listing indicates that jobs by systems programmers
also have ABC=OK. With the code above, these jobs get assigned the userid
TRUSTED and now run as highly privileged jobs on the PROD-2 system. This is
unacceptable.
• Moreover, programmers on other systems connected by NJE connections, may
modify the NJE header of their jobs by adding ABC=OK. In such a case, their
jobs will run as TRUSTED on PROD-2.
Page 23
23
LvR/VU
OCT/2002
RACF exit routine
RACINIT PREPROCESSING EXIT ROUTINE ON PROD-2
This code is activated every time if a batch job is started by an initiator
FLOWCHART:
ICHRIX01 (RACINIT preprocessing exit routine)
NO
if JCT field XYZ is C’OK’
YES
set RACF flag bit PASSCHK=YES
(and let RACF bypass password verification)
continue RACF/RACINIT processing
The job submitted by ‘TRUSTED’ at PROD-1 is now accepted at PROD-2: here it also
has USERID ‘TRUSTED’ and can now be executed
Technical audit of OS/390: Case local modifications
24
Attention items are:
• See the previous foils. Jobs submitted by the userid TRUSTED on PROD-1, by
systems programmers and by an unknown number of programmers on other
systems all can get the userid TRUSTED. In such a case, password verification is
bypassed on PROD-2.
• All these jobs have access to the financial data and stock accounts on PROD-2.
You should investigate to which other resources access is allowed for the userid
TRUSTED (and all those persons who can misuse this userid).
Moreover, you must verify the logging (setting and procedures) on PROD-2 and the
reporting on system use. Will such a misuse of the userid TRUSTED be noticed
at once?
Page 24
24
Software acceptance and maintenance
LvR/VU
OCT/2002
SOFTWARE ACCEPTANCE AND MAINTENANCE
• New program products (including OS) are generated by systems
programmers on the ACCEPTANCE system (Level II) using SMP. After
testing the software is distributed over the other systems
• Applications (and code for local modifications) developed at Level III is
received at Level II via a mailbox
• New applications are tested and accepted on Level II
• After acceptance, the activities by systems programmers at Level I are:
– Save old Level I software
– Switch temporarily disks from II to I to copy software or use mailbox
disks (during maintenance window)
– Install new software at Level I
– Test it
– If it works properly, use it for production during one week
– If there are no problems, scratch the old software
Technical audit of OS/390: Case local modifications
25
No remarks.
Page 25
25
Software acceptance and maintenance ...
LvR/VU
OCT/2002
SOFTWARE ACCEPTANCE AND MAINTENANCE (cont.)
• The department Change/Problem Management (Mr. J. Tulip) verifies
for each new program product and application the existence of an
approved business justification and sufficient documentation
• All installation activities at Level I and III are subject to the change
management process (see flowchart below)
• All first-line managers of Technical Support and Operations meet daily
at 13:00 to discuss all open change requests (Change Advisory Board)
• Mr. Tulip guards the process and reports all deviations and potential
conflicts to the Change Advisory Board
• If there is any risk for continuity or the quality of the services, the
committee may reject or postpone a change
• Note: Level II and TEST environments under PR/SM are explicitly
excluded from the process due to their exploratory function
Technical audit of OS/390: Case local modifications
26
Attention items are:
• The process does not pay any attention to security and internal control. The
decisions are taken by people managers, who are not skilled as EDP auditors.
They only focus on the aspects continuity and quality.
Page 26
26
LvR/VU
OCT/2002
Change management
CHANGE RECORDS
• Each change request is logged as a record in the INFO/MAN data base
(see flowchart below)
• This record is updated at each event related to the change (such as a
decision by the Change Advisory Board, a test, a promote, a restore etc.)
• After completion of the change or after a restore, the record is closed
(note: a restore has to result in a new change request)
• Three months after closing, the records are scratched
Technical audit of OS/390: Case local modifications
27
Attention items are:
• Storing the change records during three months is too short. This must be at least
one year.
Page 27
27
LvR/VU
OCT/2002
Change management ...
REQUEST FOR CHANGE (RFC)
PREPARATION:
- assess risk and impact
- open change record in INFO/MAN
VERIFICATION: Change Advisory Board (CAB)
DECISION: CAB
ASSIGN A DATE
FEEDBACK: change record
REJECTED
APPROVED
FEEDBACK: change record
IMPLEMENTATION: backup and make change
EVALUATION:
- verify correct operation
- complete and close change record
SEVERE PROBLEM: RESTORE
OK: READY
Technical audit of OS/390: Case local modifications
28
Attention items are:
• There is no segregation of duties
• There is no verification of the impact on security and internal control
Page 28
28
LvR/VU
OCT/2002
Change management ...
CHANGE CATAGORIES INDICATING RISKS INVOLVED
Change Description
category
Examples
Warning time
(workdays)
E
Emergency
- system down
-
1
Impact on all users of system
- replace a CPU
- new version of OS
15
2
Impact on all users of a service
- new version of
application
5
3
Impact on some users
- reorganize data base
2
4
Minor change requiring an IPL
- configuration change
2
5
Minor change
- change a network
definition
1
Technical audit of OS/390: Case local modifications
29
Attention items are:
• What is the process of reporting (after the fact) what happened during the
emergency changes?
• Who authorizes emergency changes? Is this process documented and approved
by higher management?
Page 29
29
LvR/VU
OCT/2002
Changes in practice
CHANGES IN PRACTICE
• You interview Mr. J. van Klokkert, manager of Technical Support, and
ask: who tests, accepts and installs new applications?
• His answer is:
– We always adhere to the process
– However, because I have only a limited number of skilled experts in
my team, we use at Level II staff of System Analysis and Application
Programming to do the actual testing
– Usually they are the ones who developed the code at Level III; they
send it to Level II via the mailbox and receive it there to install it in
the test libraries (via SMP) and to test it
– After testing, my systems programmers are informed that they can
allocate the new production libraries at Level I and may copy the
software to Level I
– Local modifications: ditto
Technical audit of OS/390: Case local modifications
30
Attention items are:
• There is no segraration of duties. The persons developing the code (external
hires?) also do the acceptance tests at Level II. So the same people work at both
sides of the border between the levels II and III. This undermines the entire
concept of distinct security levels.
Page 30
30
LvR/VU
OCT/2002
Changes in practice ...
CHANGES IN PRACTICE (cont.)
• You interview Mr. X. Ling, manager Operations and responsible for change
management, and ask: if application programmers may work at Level II, is
that a security exposure?
• His answer is:
– In the past, we granted SPECIAL to all userids at Level II. After a
slashing report by an EDP-auditor, we defined new rules
– Now, only 3 userids of System Entry and two team leaders of System
Programming have SPECIAL
– All other users have individual userids with UAUDIT, all RACF logging
options have been switched on, and both the SMF log and the SMP log
are stored on tape cartridges for five years
– Activities requiring SPECIAL may be prepared by individual users, but
have to be approved and executed by one of the two team leaders
– It is no longer allowed to lend a userid to a colleague: we demand
individual accountability
Technical audit of OS/390: Case local modifications
31
Attention items are:
• This is a major improvement with regard to the use of highly authorized RACF
attributes. Nevertheless, there is still no separation of duties (see also the
previous foil).
• All users have access to the System Modification Program (SMP) and can so
insert changes in the operating system software for all systems. Nobody can
verify this.
Page 31
31