6-b security aspects of os390 systems, racf · file 6-b security aspects of os390 systems, racf ......

1

PART 6-B

SECURITY ASPECTS OF OS/390 SYSTEMS:

RACF

Ronald Paans and Leen van Rij

kpmg IRM

vrije Universiteit amsterdam

21 & 28 October 2002

File 6-B Security aspects of OS390 systems, RACF © 2002

2

RP/LvR/VU OCT/2002

Security aspects of OS/390 systems: RACF

Contents

CONTENTSA. Access control in generalB. Users and groups

– authentication via passwords– password propagation– groups

C. Resources– authorization– U.S. Department of Defense, Orange book– Global Access Checking

D. Management processes– administrative attributes and SETROPTS command– RACF data bases and RVARY command

E. Audit of RACF– DSMON, RACFRW and Cross Reference Lister

F. Relation with Code of PracticeG. Answers to presented questionsH. Only for OS/390 auditor (not to be discussed during the lecture)

2

3

RP/LvR/VU OCT/2002


Optional literature

OPTIONAL LITERATURE• Ernst & Young Technical Reference Series, “Audit, control and security of

RACF”, can be ordered via ISACA Bookstore, member price $ 50.00 (1995) (*** no longer on Sept 1998 list ***)

• ISACA, “Instructions for auditing the MVS operating system”, order number 1-DC, member price $ 75.00 (1996)

See also literature list

4

RP/LvR/VU OCT/2002


Security topology

Network security

Security in system/service

Security in application

Operating system

Computingcenter staff

Physicalsecurity of thecomputing center

End user

‘Frontdoor’

Trusted ComputingBase (TCB - certifiedusing US Departmentof Defense standards)

Measures depend upon securityobjectives and the enterprise’ssecurity strategy

TOPOLOGY OF SECURITY LAYERS

Note: The security measures in the network, services and applications may use the ‘Access Control’ in the TCB. Although this access control mechanism may have been classified in accordance with the US DoD standards, the actual security depends upon how the security facilities are used.

Hardware

DATA

Access control

3

5

RP/LvR/VU OCT/2002


Security topology ...

SECURITY LAYERS• Security-objective dependent layers:

– Network security: NETVIEW/Access Services, connectivity, sessions– Security in the service: Time Sharing Option (TSO), Customer Information

Control System (CICS), Information Management System (IMS), logon, authorization, resources

– Application security: functions, transactions, records, data items, programmed controls

• Trusted Computer Base (TCB) layers:– Access control: Resource Access Control Facility (RACF), support above three

layers, protect resources etc.– Operating system: Multiple Virtual Storage (OS/390), UNIX, OS/400,

Windows 95, software foundation for security and integrity– Equipment: hardware foundation

TCB classified by USA DoD Orange Book:– C1 - discretionary security protection– C2 - controlled access protection (RACF up to 1.8)– B1 - mandatory labeled security protection (RACF 1.9 and higher)

• Physical security of equipment and staff

6

RP/LvR/VU OCT/2002


MEY: Logical access path analysis

Access control product

Data communication software

Transaction software

Application software

Data access method

Operating system

Ernst & Young “A practical approach to logical access control” (1993)

Interactiveuser

Batch

DATA

Note: A slight modification to the model. Calls to the access control product go through the operating system. Access control is invoked to decide on user requests

4

7

RP/LvR/VU OCT/2002


Model of Lister

MODEL OF LISTER

The System can be modelled as an onion

INTERRUPTHANDLING

LOCKSDISPATCHER

HARDWARE

MEMORY MANAGEMENT

I/OFILE ACCESS

ASSIGNING SYSTEM ELE-MENTS AND SCHEDULING

PROTECTION

USER INTERFACE

Logical access control

8

RP/LvR/VU OCT/2002


Causes of damage to information

CAUSES OF DAMAGE TO INFORMATION

Investigation Price Waterhouse UK, causes are33% Human errors10% Strikes (UK)10% Industrial espionage10% Fraud33% Errors in information systems

and technical infrastructure

Investigation Price Waterhouse UK, causes are33% Human errors10% Strikes (UK)10% Industrial espionage10% Fraud33% Errors in information systems

and technical infrastructure

Similar investigation in USA55% Human errors16% Dishonest acts11% Disgruntled employees10% Fire5% Water3% Other causesAlmost 82% is caused by human actions.

Similar investigation in USA55% Human errors16% Dishonest acts11% Disgruntled employees10% Fire5% Water3% Other causesAlmost 82% is caused by human actions.

• The conclusion is: people are the weak link in computer security• The financial consequences due to fraud substantially exceed those due to errors.

Exact figures are not available due to enterprises’ reluctancy to provide details

SECURITY IS BASED ON PROCEDURES AND CONTROLLING THE PEOPLE IN YOUR ENTERPRISE

}}

5

9

RP/LvR/VU OCT/2002


LOGICAL ACCESS CONTROL IN GENERAL

PART A.

LOGICAL ACCESS CONTROLIN GENERAL

PART A.

LOGICAL ACCESS CONTROLIN GENERAL

Note: The owner of a (number of) computers providing services to users is here called the Provider of Service (PoS)

10

RP/LvR/VU OCT/2002


Security objectives

Phil Dolan: ‘Power corrupts; absolute power corrupts absolutely’Each enterprise must have a strategy and objectives for securing IT and

controlling the powers of system/data owners, administrators and users• Description of what to protect

– data classification– business value of information systems– replacement value of equipment

• Description of how to protect– physical controls– logical controls– networking controls

• Description of how to verify adherence• When to apply which measure

Note• Objectives must inform Provider of Service (PoS) how to protect data and

systems and how it will be audited• Controls must be specified independent of type of platform (i.e. hardware,

operating system and subsystem)• Implementation rules / measures must be specified per platform

6

11

RP/LvR/VU OCT/2002


Data classification

DATA CLASSIFICATION (for Confidentiality and Integrity)

One must classify all data, systems and equipment. Within IBM, the following data classification is used:

• Unclassified - public information (or information belonging to business partners, to be protected as agreed with the owner)

• IBM Internal Use Only - no real value outside the company. However, it is preferred not to distribute it beyond the company’s premises and employees

• IBM Confidential - only to be distributed to persons or groups with a need to know

• IBM Confidential Restricted - sensitive information about new products and marketing plans, only to be distributed to authorized individuals (called: SECRET)

• Registered IBM Confidential - highly sensitive information with specifications of future products and business strategies, all copies must be registered (called: TOP SECRET)

12

RP/LvR/VU OCT/2002


Information system types for continuity

INFORMATION SYSTEM TYPES (for Continuity)• How dependent is the business on continuity of a specific information system?• What are the costs if the system is down ?

TYPE A systems. Keyword: critical to the business• Removal from service for any significant period of time cannot be tolerated (hours)• Examples: medical information, electronic patient files

TYPE B systems. Keyword: important to the business• Removal from service for an extended period of time cannot be tolerated (days)• Examples: invoicing, payroll, general ledger, e-mail, systems containing an aggregation

of highly classified information

TYPE C systems. Keyword: useful service• Removal from service for an extended period of time can be tolerated• Examples: workstations

7

13

RP/LvR/VU OCT/2002


Overview: types versus controls

Find a balance between the enterprise’s dependency on the information system and the costs of the controls

PHYSICAL CONTROLS: the approach is

• Type A. Key assets of the company, strict physical controls (since damage to the equipment may endanger the business)

• Type B. Important service or a lot of vital data. Limited access must be enforced

• Type C. Useful systems, in principle they may reside on an individual’s desk

LOGICAL CONTROLS: the approach is

• Type A and B. System owners and administrators must be controlled (Note: no difference between A and B for logical controls)

• Type C. Leave it to the owners (only a limited set of specified controls)

14

RP/LvR/VU OCT/2002


Access control system

ACCESS CONTROL SYSTEMThe intent and purpose of an access control system is to

provide means for• Security administration: set, modify or disable access control functions• Identification and authentication of users: ensure individual

accountability• Definition and protection of resources: ensure that access is limited to

those authorized• Logging access attempts: ensure that successful and failing attempts can

be logged (if so requested)• Reporting access violations: either immediately or on subsequent

analysis

The means must be available within the access control product selected for a certain computer or information system

8

15

RP/LvR/VU OCT/2002


Access control system ...

ACCESS CONTROL SYSTEMWith regard to an access control system, note• Access control is passive: it never takes the initiative, but is

invoked by the operating system as a reaction to users’ activities

• The primary function of access control: reply YES or NO to an access request, and maintain an overview of all access requirements and authorities(Note: In fact, an access control system is a data base system)

• The secondary function: report violations of the rules

Note: Be careful when using an audit trail: only the failing attempts are reported, while the succesful burglarious activities are recorded as valid and legitimate accesses

16

RP/LvR/VU OCT/2002


RACF

Reportcreatingprogram

Messageson securityconsole(alert)

SystemManagement

Facility (SMF)WRITER

SMF data sets

SMF dump data sets (archive)

OR

Mainframe operation and logging

CONSOLE USER address spaces

SMF log buffer

USER address space

RACF data base(s)(profiles)

Answer: YES/NO

calls toRACF

OK?SYS1.MAN1

SYS1.MANn

RACF: Resource Access Control Facility SMF = System Management Facilities (logging)

9

17

RP/LvR/VU OCT/2002


Principle of access control: access to a service

LOGON function of interactive service / start batch job

LOGON function of interactive service / start batch job

Interactive service (TSO, CICS, IMS etc.) or batch service

Interactive service (TSO, CICS, IMS etc.) or batch service

RACINIT SVC:is user X allowed to use the service ?

RACINIT SVC:is user X allowed to use the service ?

RACF: in fact only a data base manager. Provides answer Yes/No


User X (subject)

Alternative: services may use their own mechanism to verify identity and authenticity

IdentificationAuthentication

Yes = continueNo = kill the session or job, log the incident

Note: The OS invokes access control !

RACF data base

Information about:• Subjects• Users & groups

• Objects• Resources and

authorisations

18

RP/LvR/VU OCT/2002


Identification and authentication

IDENTIFICATION AND AUTHENTICATION• User identification codes (USERIDs) must be traceable to the individual to

whom they have been assigned• Before granting access to a service, identification must be verified through

authentication. Ask the user, e.g.:– something he/she knows (“kenniskenmerk”) (name, account number,

password)– something he/she has (“bezitskenmerk”) (badge, plastic card, key)– something he/she is (“biometrisch kenmerk”) (fingerprint, voiceprint,

hand size, signature)– personal characteristics (dialog with the computer using pre-specified

user-related information: name of eldest son, birthday of granny etc., randomly selecting questions)

Note: RACF uses passwords. The control objective is: A password must not be predictable nor trivial.

NORM

NORM

10

19

RP/LvR/VU OCT/2002


Principle of access control: access to a resource

DATA

Command or applicationCommand or application

Data access methodData access method

OPEN SVCOPEN SVC

RACHECK SVC:is user X allowed to have Read/Write access to data Y ?

RACHECK SVC:is user X allowed to have Read/Write access to data Y ?



User X (subject)

Data Y (object)

Yes = continueNo = kill the request, log the incident

Authorization

RACF data base

Information about:• Subjects• Users & groups

• Objects• Resources and

authorizations

20

RP/LvR/VU OCT/2002


Subjects versus objects: profiles in RACF data base

SUBJECTS:people, groups and their relations

OBJECTS: resources (things)

Group A1

User JOHNPassword: *****Authority:• RACF administratorConnected to:• Group A1

Data set JOHN.DATAOwner = JOHNAccess list:• SYLVIA may UPDATE• Group A1 may READUniversal Access = NONE

Relations between objects and subjects: specified in the resource profiles

Data set profile (resource profile)

Group profile

User profileConnect

11

21

RP/LvR/VU OCT/2002


Group X Superior group

Resource name Owner Access list Universal access



- - - - - - - - - - -

- - - - - - - - - - -

ClassA

ClassB

ClassC

User A Group X Authority Name N x Connect attributes to groupsTSO segmentSMS segmentWorkattribute segmentOper segment

RACF data base structure (profiles)

User

Group

- - - - - - - - - - -

RACF DATA BASE: PROFILES

22

RP/LvR/VU OCT/2002


Function SUBJECT OBJECTUser Group Data General

set resource

define ADDUSER ADDGROUP ADDSD RDEFINE

alter/ ALTUSER ALTGROUP ALTDSD RALTERmodify PASSWORD CONNECT PERMIT PERMIT

REMOVE

list LISTUSER LISTGRP LISTDSD RLIST

delete DELUSER DELGROUP DELDSD RDELETE

TSO commands for RACF

SEARCH - locate RACF informationSETROPTS - set/reset RACF security optionRVARY - turn RACF on/off and switch RACF data base

Note: RACF commands affect RACF profiles, but do not affect data stored in any user or system data set

12

23

RP/LvR/VU OCT/2002


USERS AND GROUPS

PART B.

USERS & GROUPS

• Identification• Authentication via passwords• Password propagation• Groups

PART B.

USERS & GROUPS

• Identification• Authentication via passwords• Password propagation• Groups

24

RP/LvR/VU OCT/2002


User profile

Objective: User identification codes (USERIDs) must be traceable to the individual to whom they have been assigned

USER PROFILE for a TSO user or a batch job contains• Name of user and encrypted password• Attributes (to be discussed later: Administrative Authority)

– SPECIAL - security administrator: may issue any RACF command and access any field in RACF profiles, except those reserved for the AUDITOR

– OPERATIONS - system maintenance: backup and restore of data– AUDITOR - monitor system security: may view any field in RACF profiles

• UAUDIT - all access requests of this user are logged (this bit is set and inspected only by those with the AUDITOR attribute)

• REVOKE status - userid temporarily disabled• Data and time of last logon (e.g., used for password expiration)• Names of groups connected and the user’s authorities within these groups• etc.

NORM

13

25

RP/LvR/VU OCT/2002


REVOKE and RESUME

CONTROL OF REVOKE/RESUME BY DATE

The system or group administrator (with SPECIAL or group-SPECIAL) may specify dates for revoking and for restoring a user’s authority to access the system

EXAMPLE: User JOHN is on vacation from 1-SEP-98 to 30-SEP-98. The administrator enters

ALTUSER JOHN REVOKE(9/1/98) RESUME(9/30/98)

thus preventing abuse of JOHN’s userid during his vacation. At return of the vacation, the authority is automatically restored and JOHN can work again

NOTE: The userid also becomes revoked after entering N invalid passwords or not using the userid during M days (usually N=5 and M=90, to be specified by the security administrator via the SETROPTS command)

26

RP/LvR/VU OCT/2002


Example of User Profile

EXAMPLE OF USER PROFILEIf an AUDITOR issues the command LISTUSER JOHN, the output may read

USER=JOHN NAME=JOHN JOHNSON OWNER=SYLVIACREATED=98.220DEFAULT-GROUP=SYSGRP (must be one of the groups connected)PASSDATE=98.242 PASS-INTERVAL=60 (less or equal to system value)ATTRIBUTES=SPECIALATTRIBUTES=UAUDIT (only displayed for auditor)REVOKE DATE=NONE RESUME DATE=NONELAST-ACCESS=98.244LOGON ALLOWED (DAYS) (TIME)

WEEKDAYS 0800:1800GROUP connections: GROUP-A1, SYSGRP, PURCHASE etc.SECURITY-LEVEL=TOP SECRETSECURITY-CATEGORY=NONE SPECIFIED

Note: The fields underlined can be changed by the user via the ALTUSER or PASSWORD command. So don’t trust them for audit purposes

}(security label)

14

27

RP/LvR/VU OCT/2002


Example of user profile ...

EXAMPLE: DEFINE A USER PROFILETo be entered by security administrator (with SPECIAL attribute)

ADDUSER (JOHN) PASSWORD(SECRET) NAME(‘John Johnson’)OWNER(SYLVIA) DFLTGRP(SYSGRP) SPECIALWHEN(DAYS(WEEKDAYS) TIME(0800:1800))TSO(ACCTNUM(12345AB) PROC(TSOUSER) SIZE(4000K)) etc.

Notes• The password is always marked ‘expired’, thus forcing the user to change it at

initial logon• The owner may modify this profile. Sometimes the group HELP-DESK is

defined as owner, so they can support the user, e.g., to reset the password• The WHEN operand applies only to logon. An existing session is not terminated

by it and a batch job may be processed at any time and day• The TSO segment contains administrative information such as account number,

name of JCL procedure (in SYS1.PROCLIB) to tailor the address space and the size of virtual memory available to this user

28

RP/LvR/VU OCT/2002


Welcome to Time Sharing Option of company ABCThis internal system must only be used for conducting

ABC’s business or for purposes authorized by ABC management.

ABC has the right to audit.

USERID = _________ GROUPID = ________PASSWORD = _________ SECLABEL = ________NEW PASSWORD = _________

Logon to mainframe

The TSO logon screen is displayed at the start of a session

15

29

RP/LvR/VU OCT/2002


Userid and password in batch job

BATCH JOB: A user submits a batch job with the JCL

//JOHN1 JOB 123,’JOHN SMITH’,USER=JOHN,PASSWORD=SECRET//STEP EXEC PGM=IEFBR14

The JOB card contains the RACF parameters USER and PASSWORD. Theinitiator issues a RACINIT SVC to verify the userid/password combination, and the user’s authority to submit batch jobs

Password may be changed via JCL by specifying

//JOHN1 JOB 123,’JOHN SMITH’,USER=JOHN,// PASSWORD=(old-password,new-password)//STEP EXEC PGM=IEFBR14

Note: If jobs are restarted or executed in another sequence than expected, a password change often leads to jobs abnormally terminating due to password violations

30

RP/LvR/VU OCT/2002


Controls related to user identification

Controls related to user identification1 Access authority based on current need and by verifying identity2 Each userid must be identifiable to user/application3 PoS must have process to authorizing users and must notify the user’s manager4 Process for authorizing users5 When user leaves enterprise or no longer has a business need, user's manager or local

procedure must inform PoS to revoke or lock access immediately6 Quarterly process to remove users no longer employed7 Annual process to revalidate each userid by sending report to user’s manager8 Revoke userids inactive for 186 days9 Remove access of users who no longer have business need for access

System type Controls

A system 1 2 3 5 6 7 8B system 1 2 3 5 6 7 8Multi-user C system with SECRET data 1 2 3 5 6 7Other multi-user C systems 1 2 4 9

16

31

RP/LvR/VU OCT/2002


AUTHENTICATION VIA PASSWORDS

B.1

AUTHENTICATIONVIA

PASSWORDS

B.1

AUTHENTICATIONVIA

PASSWORDS

32

RP/LvR/VU OCT/2002


TSO and batch authentication

VTAMstarted task

TSOUser A

TSOUser B

TerminalMonitorProgram

BatchUser C

TCASstarted task

UserAttributeData set

TMP Batchinitiator

SYS1.UADS: if RACF is not used, it contains the users’ password

LOGONviaTerminalControlAddressSpace

Each user has its own addres space

Note: In the base OS/390 system, the userid and password (in clear text) reside in the system library SYS1.UADS. An EDP-auditor has to verify that this library does not contain highly priviliged userids (such as IBMUSER used for installing RACF)

17

33

RP/LvR/VU OCT/2002


General remarks about passwords

GENERAL REMARKS ON THE USE OF PASSWORDS• Users tend to use trivial, easy to remember passwords. PoS must enforce

robust syntax rules• If the rules are too complex, users will put the passwords on paper. There

must be a balance between security and userfriendliness!• Many users ask for non-expiring passwords. Be careful: sometimes they create

a logon batch file on their workstation with a hardcoded userid and password. Pay attention to workstations providing automated logon

• Workstations with hardcoded userids/passwords are used for automated operations and performance monitoring. Pay attention to their physical security

• Passwords in Job Control Language (JCL) appear in clear text in user libraries, user listings, SPOOL data set, page data sets and on lines. Use a mechanism such as ‘password has already been verified’ bit in the job header

• Passwords may reside in clear text in virtual memory and can be viewed in dumps. Pay attention to dump procedures, dump data sets and listings

Note: A password syntax must be independent of language and keyboard layout (due to the multi-language European environment)

34

RP/LvR/VU OCT/2002


Objectives for password control

OBJECTIVES FOR PASSWORD CONTROL

Applicable to all systems• PoS must have a means to inform users when to change the password, if supported

by the platform• Upon the fifth invalid logon attempt, the userid must be revoked or locked, if

supported by the platform (to avoid unlimited quessing)

Applicable to type A and B systems and multi-user type C systems with SECRET data• There must be a process to reset passwords, ensuring for positive identification of

requestor or sending new password to user’s manager• All invalid logon attempts must be logged• There must be a capability to provide reports of invalid logon attempts on request

(investigate attacks)• A manager or designee must be informed whenever the invalid logon attempt rate

or revoke rate exceed an installation-defined limit (to avoid denial-of-access)

NORMEN

18

35

RP/LvR/VU OCT/2002


Password syntax rules

PASSWORD SYNTAX RULES (IBM standard)The password syntax must be robust. The password must

1. Be at least 6 position in length2. Contain at least one numeric and one alphabetic (to avoid WILLIAM,

MERCEDES and 123456)3. Have a non-numeric in the first and last position (to avoid JUNE1994 and

1994JUNE)4. Contain no more than three identical consecutive characters from any

position from the previous password (to avoid rules of thumb such as MY1BIKE followed by MY2BIKE, MY3BIKE etc.)

5. Contain no more than two identical consecutive characters (to avoid A1AAAAAA)

6. Not contain the userid or groupid as part of the password7. Not be reused until after at least 24 iterations8. Not be shared, unless individual accountability is maintained

MAATREGELEN

36

RP/LvR/VU OCT/2002


Examples of valid and invalid passwords

Valid INVALID Reason being invalid

RAT1TY RA1TY Rule #1: at least six positions in length

J8YY54QL JKYYTCQL Rule #2: at least one numeric

$739461A 57394613 Rule #2: at least one alphabetic (plus rule #3)

RON3ALD RONALD3 Rule #3: non-numeric in last position

old: new: Rule #4: no more than three consecutiveHOTR9FMA AHOTR7DA characters from previous password

AZZUV5MQ AZZZV5MQ Rule #5: no more than two identical consecutivecharacters

user RON Rule #6: userid not part of the passwordABC1PWRD RON1PWRD

EXAMPLES OF VALID AND INVALID PASSWORDS

The password syntax must be enforced through a password checker, if the platform provides for it

19

37

RP/LvR/VU OCT/2002


Passwords in RACF

PASSWORDS IN RACF• Old versions of RACF (up to 1.5) used only a masking

algorithm for passwords:– Hackers succeeded in analyzing this mechanism by creating

passwords such as A, B, ...Z, AA and AB, and so revealing the contents of the translation table

– Note: these hackers had READ access to RACF data base– It was decided that decryptable passwords are not secure

• From RACF 1.6 up, passwords are encrypted by a one-way Data Encryption Standard (DES) algorithm (during the process, bits are removed to provide for one-way)

• The user-supplied password is encrypted and compared with the encrypted password residing in the RACF data base. In case of a mismatch: the user is again prompted for the correct password

password provided by user

password provided by user

translation, e.g. A=D, B=L etc., or one-way encryption

masked or one-way encrypted password

masked or one-way encrypted password

RACFdata base

store or compare

38

RP/LvR/VU OCT/2002


SETROPTS options for passwords

SETROPTS OPTIONS FOR PASSWORDSThe RACF administrator may specify the password syntax via the command

SETROPTS PASSWORD(HISTORY(number of previous passwords stored)NOHISTORYREVOKE(number of failing attempts to provide password)NOREVOKEINTERVAL(number of days between password changes)RULEk(LENGTH(n m) content(position))NORULEWARNING(number of days before password expiration) )NOWARNING )

Note: SETROPTS is SET RACF OPTIONS command, dedicated to somebody with SPECIAL or AUDITOR attribute

20

39

RP/LvR/VU OCT/2002


SETROPTS options for passwords ...

HISTORY: Specify the number of previous passwords (1-32) to be saved for each USERID. The usual value is 24, enforcing the user not to use one of the 24 previous passwords

REVOKE: After N failing attempts, the userid is revoked. Somebody with (group) SPECIAL has to resume it. Usually, 5 attempts are allowed

INTERVAL: Enforce the user to change his password after the specified number of days. The usual value is 187 (6 months), if and only if the syntax rules are strong(Note: each user may reduce this value for his USERID by issuing the command PASSWORD INTERVAL(nr of days), but can never exceed the number of days set via SETROPTS)

WARNING: The text “YOUR PASSWORD WILL EXPIRE IN n DAYS” is displayed before password expiration

40

RP/LvR/VU OCT/2002


SETROPTS options for password syntax

SETROPTS OPTIONS FOR SYNTAX OF PASSWORDSUp to 8 syntax rules can be specified as an OR relation

SETROPTS PASSWORD(RULE1(LENGTH(n m) content(position))etc.RULE8(LENGTH(n m) content(position)) )

RULE1 to RULE8: syntax rules

LENGTH(n m): minimum and maximum length of password. E.g., LENGTH (6 8)for 6 to 8 characters, or LENGTH(8) for exactly 8

content(position): for contents one may select• ALPHA - alphabetic and national characters• ALPHANUM - also numerics (Note: this keyword requires at least one alphabetic

and one numeric keyword)• VOWEL - ‘A’ ‘E’ ‘I’ ‘O’ ‘U’• NOVOWEL - nonvowel, national and numeric characters• CONSONANT - nonvowel characters• NUMERIC - numeric characters

21

41

RP/LvR/VU OCT/2002


SETROPTS options for password syntax ...

EXAMPLES OF PASSWORD SYNTAX

Example 1

SETROPTS PASSWORD(RULE1(LENGTH(6 8) ALPHA(1:8))RULE2(LENGTH(6 8) ALPHANUM(1:8)) )

Note: The first rule allows trivial passwords such as MERCEDES

Example2

SETROPTS PASSWORD( RULE1(LENGTH(8) ALPHANUM(1:8)) )

Note: The password must contain at least one numeric and one alphabetic, such as 1RONALD2, 5JOHN43N or ABC3DEFG. These passwords are not trivial and cannot be guessed easily

42

RP/LvR/VU OCT/2002


Problem B.1: password security

PROBLEM B.1: PASSWORD SECURITYA system has the following characteristics:• 2,000 userids have been installed• For reasons of electronic mail, the userids have been included in the company’s

telephone directory (the userids are public knowledge)

SETROPTS PASSWORD(INTERVAL(62) REVOKE(5)RULE1(LENGTH(6 8) ALPHA(1:8)RULE2(LENGTH(6 8) ALPHANUM(1:8)RULE3(LENGTH(8) NUM(1) ALPHANUM(2:8))

• Each user must change its password every two months (the passwords are secret information)

• After five failing logon (or start batch job) attempts, a userid is revokedQuestion: You as an EDP-auditor have to evaluate this system and must decide

whether or not the password security is sufficient. What is yourrecommendation?

22

43

RP/LvR/VU OCT/2002


Password weaknesses

PASSWORD WEAKNESSESIn general, there is still a weakness with one-way encrypted passwords• If the data base containing the passwords or any copy of it is accidentally

unprotected, somebody may read the encrypted string• There are password generators, generating all passwords from AAA... to 999...• The encryption algorithm is known (since the software resides in common area or

can be obtained in another way)• Hackers may generate all possible passwords, encrypt them and compare it with

the encrypted string• If there is a match, they have found the password (or any other password mapped to

the same string - since some bits have been deleted)

• The processing time of finding a usable password depends on the length of the password: say 4 characters takes some minutes, 5 characters approx. one hour, 6 characters up to 1 day etc.)

• It is hence important to specify a minimum length for passwords, preferably 7 or 8 characters

44

RP/LvR/VU OCT/2002


PASSWORD PROPAGATION

B.2

PASSWORDPROPAGATION

B.2

PASSWORDPROPAGATION

23

45

RP/LvR/VU OCT/2002


Password propagation

PASSWORD PROPAGATIONUserids and password combinations may reside in clear text in• data sets with JCL (principally libraries of users)• spool data sets (with JCL and SYSIN data of jobs submitted by users)

If somebody can read a user’s library with JCL or the spool, he/she can find useridsand the passwords associated. This is a security exposure

For a TSO user’s own jobs, the risk may be reduced due to the password propagationmechanism

• If a TSO user uses the SUBMIT command, a bit is set indicating ‘password already verified’

• (Obviously, Userid of batch job must match Userid of submitting user)• JES2 wil skip further password verification. Hence, no password has to be specified

in the JCL. E.g., TSO user JOHN submits

//JOHN1 JOB 123,’JOHN SMITH’,USER=JOHN (no password required here)//STEP EXEC PGM=IEFBR14

46

RP/LvR/VU OCT/2002


Life cycle of a batch job

Reader # @ wait ExecutionExecution wait Output #

SUBMIT STATUS, CANCELOUTPUT,ROUTE

Selection byINITIATOR #

Job initia-lization @

Jobexecution

Jobexecution

Job termi-nation #

INITIATOR

Step initialization Stepexecution

Stepexecution Step termination #

Allocate I/O

OPENI/O @

read/writeI/O

CLOSEI/O #

Unallocate I/O

@ = invocation of access control (RACF) # = logging (console and/or SMF)

!

!

24

47

RP/LvR/VU OCT/2002


Life cycle of a batch job ...

Reader @1 wait ExecutionExecution wait Output

SUBMIT STATUS, CANCELOUTPUT,ROUTE

Selection byINITIATOR

Job initia-lization @2

Jobexecution

Jobexecution

Job termi-nation

INITIATOR

Step initialization Stepexecution

Stepexecution Step termination

Allocate I/O

OPENI/O @3

read/writeI/O

CLOSEI/O

Unallocate I/O

Invocation of access control (RACF)@1 = password propagation (Userid of batch job must be equal to Userid TSO user)@2 = password verification (if there is no propagation)@3 = resource authorization verification

48

RP/LvR/VU OCT/2002


Surrogate user

SURROGATE JOB TRANSMISSIONSometimes somebody has to submit a batch job on behalf of a user with another Userid.

E.g., an operator PETER must submit a housekeeping job for backup of disks, using the Userid DISKBU

PETER submits //DISKBU1 JOB USER=DISKBU,SECLABEL=B23P• RACF builds a user token UTOKEN containing

– owner = DISKBU– submittor = PETER– security label = B23P

• If ‘submittor is not owner’ AND ‘no password’, RACF verifies whether PETER isauthorized to submit on behalf of DISKBU. This is controlled by commands for the resource class SURROGAT (Surrogate User)

RDEFINE SURROGAT DISKBU.SUBMIT UACC(NONE) OWNER(DISKBU)PERMIT DISKBU.SUBMIT CLASS(SURROGAT) ID(PETER) ACCESS(READ)

• Now PETER may submit batch jobs with DISKBU’s authorization, without a need to know DISKBU’s password

• Also Network Job Entry (NJE) support, so jobs may be submitted to other systems

25

49

RP/LvR/VU OCT/2002


Surrogate user ...

Profile DISKBU.SUBMITOwner = DISKBUAccess list = PETER has READ (he may use it)Universal Access = NONE (for all others)

Owner DISKBU may issue RALTER and PERMIT commands to change the profile, e.g., to add entries to the access list

Since PETER is on the access list with READ, he may submit JCL on behalf of DISKBU without knowing the password, e.g.//DISKBU JOB USER=DISKBU//STEP1 EXEC PGM=BACKUP//etc.

RACF class SURROGAT

Security administrator creates profile via RDEFINE command

Verify during Job Initialisation

50

RP/LvR/VU OCT/2002


NJE security controls

NJE SECURITY CONTROLS• NJE = Network Job Entry function of JES2 (exchange jobs and output between

hosts)• Propagate user validation across trusted nodes (bit “password already verified”)• Allow the use of SURROGATE user across trusted nodes• Control JOB/SYSOUT transmission and reception by node, userid and labelSpecify “trusted” or “non trusted” per node (host)

PRODUCTION SYSTEM“trusted node”(NJE security support al-lowed for defined NODES)

PRODUCTION SYSTEM“trusted node”(NJE security support al-lowed for defined NODES)

PRODUCTION SYSTEM“trusted node”(NJE security support allowed fordefined NODES)

PRODUCTION SYSTEM“trusted node”(NJE security support allowed fordefined NODES)

DEVELOPMENT/TEST SYSTEM“non trusted node” (not defined in pro-duction systems - no NJE security support)

DEVELOPMENT/TEST SYSTEM“non trusted node” (not defined in pro-duction systems - no NJE security support)

NJENETWORK

26

51

RP/LvR/VU OCT/2002


GROUPS

B.3

GROUPS

B.3

GROUPS

52

RP/LvR/VU OCT/2002


Groups

GROUPSEach user belongs to at least one groupA group corresponds to an organization, a department, a function, a product or any

other unit

Advantages of using a hierarchical group structure• reduction of administrative effort

• for authorization verification, one may use the name of a Group to specify access for all members of this group– e.g., for data set WAREHOUSE.DATA one may specify on the access list

READ for GROUP-A (allowing all members of GROUP-A to read)• limitation of the scope of powerful user attributes such as SPECIAL,

OPERATIONS and AUDITOR. With group-SPECIAL etc. only applicable to members and data of a group (and its sub groups, sub sub groups etc.)

27

53

RP/LvR/VU OCT/2002


Groups ...

GROUP: A collection of users sharing common access requirements to protected resources or having similar attributes within the system.

(from superior group)

GROUP A GROUP B

GROUP A1 GROUP A2 GROUP B1

JOHN SYLVIA CARL ...

• JOHN is connected to group A1 (and may not access data sets of group A2)• Group A1 is connected to group A (A1 is subgroup of A), by the security administrator’s

command ADDGROUP (A1) SUPGROUP(A)• Group A is superior of group A1• SYLVIA is connected to both group A1 and B1, the latter by the security administrator’s

command CONNECT (SYLVIA) GROUP(B1) AUTHORITY(CREATE)

CONNECT CONNECT user to group: allow to use group resources

54

RP/LvR/VU OCT/2002


Group authorities

Each user belongs to at least one group. At logon, a user is connected to the group specified as default group in his/her user profile, unless explicitly specifying another group. Obviously a user only may specify a group to which his/her user profile is connected

The GROUP OWNER connects and controls users in the group, and can specify• the group-related user attributes

– group-SPECIAL– group-OPERATIONS– group-AUDITOR– group-REVOKEThese authorities apply only to data sets owned by this group and to users

defined within this group• the responsibilities for resources of the group

USE - use group data setsCREATE - create group data setsCONNECT - connect other users to groupJOIN - define subgroups etc.

28

55

RP/LvR/VU OCT/2002


Group authorities ...

Example: scope of group-SPECIAL

(from superior group)

GROUP A

GROUP A1 GROUP A2

JOHN SYLVIA

Group-SPECIAL• YVONNE has group-SPECIAL for group A and subgroups A1 and A2• Can create, modify and delete user and resource profiles within this scope• Cannot affect profiles of groups B, B1 etc.

GROUP B1

CARL ...

GROUP B

YVONNE(group-SPECIAL)

56

RP/LvR/VU OCT/2002


RESOURCES

PART C.

RESOURCES

• Authorization• DoD Orange book• Resource profiles• Global Access Checking

PART C.

RESOURCES

• Authorization• DoD Orange book• Resource profiles• Global Access Checking

29

57

RP/LvR/VU OCT/2002


Objectives: Protecting data resources

OBJECTIVES: PROTECTING DATA RESOURCES

Data object: text, program or data

GENERAL RULES

• The owner of a data object is responsible for its classification• If possible, the classification should be included in the data object (near the

beginning, primarily for text and program sources)

• The PoS specifies the highest classification level of data allowed on the system (and ensures general IT controls appropriate to this level)

This obviously implies• PoS is not responsible to ensure that owners comply with data classification

standards; compliance is the owners’ responsibility• No need to print classification on output or separator pages• No need for PoS to provide means for external marking of data objects’

classification (no need to enforce the use of RACF SECLEVEL and CATEGORY or to provide similar means on other platforms)

NORM

58

RP/LvR/VU OCT/2002


Protection depends upon data classification

‘INTERNAL USE ONLY’ DATA• No need to restrict access from anyone who has access to the system, network or

LAN

‘CONFIDENTIAL’ DATA• Access must be authorized by owner to those with need-to-know• Residual data must be made unreadable prior to disposal or non-enterprise use

of media

‘SECRET’ DATA• PoS must declare whether SECRET data may be processed and, if so, must

provide encryption tools• Access must be authorized by owner to those with need-to-know• Residual data must be made unreadable prior to removal of logical or

procedural control (e.g., at the end of a batch job or after printing a SECRET print file)

NORM

30

59

RP/LvR/VU OCT/2002


Protection depends upon data classification ...

‘TOP SECRET’ DATA• PoS must declare whether TOP SECRET data may be processed and, if so, must

provide encryption tools• User must inform PoS when data is processed

• Data must only be stored in encrypted format• All access attempts must be logged: unsuccessful attempts to be reported weekly

and successful accesses monthly to owner• Residual data must be made unreadable prior to removal of logical or

procedural control• Data must be encrypted before transmission on LAN, with different paths for

key and data• A LAN system must de disconnected before processing clear-text data

NORM

60

RP/LvR/VU OCT/2002


World-readable data

WORLD-READABLE DATA

On LAN systems, data objects can be defined as ‘world-readable’, i.e. readable to any and all users who have access to the network

• The data owner must be aware that also non-enterprise personnel may have access to the network and so to the world-readable data objects

• The data owner is responsible for any consequences if data is exposed due to defining it as world-readable

• The PoS must not set the default data access control to be world-readable• The PoS is not required to scan for unprotected confidential data in the

LAN environmentNote: There is no similar mechanism in hosts (OS/390 and OS/400), since there

the user is always requested to authenticate. On the other hand, in Unix it is possible to define the userid guest without password verification

NORM

31

61

RP/LvR/VU OCT/2002


Resources

RESOURCEA resource is a facility of the computing system or OS required by a job or task,

including main storage, I/O devices, CPU, data sets and programs

Resources which can be protected by RACF are, e.g.• data sets• disk and tape volumes• load modules (executable programs residing in libraries)• IMS transactions, transaction groups and application groups• CICS transactions, files, journals, programs, program specification blocks,

transient data destinations, and temporary storage definitions• DB2 data• terminals• installation-defined resources• etc.

62

RP/LvR/VU OCT/2002


DEPARTMENT OF DEFENCE

C.1

U.S. DEPARTMENT OF DEFENSE (DoD)

ORANGE BOOK

C.1

U.S. DEPARTMENT OF DEFENSE (DoD)

ORANGE BOOK

32

63

RP/LvR/VU OCT/2002


USA DoD Orange Book

USA DEPARTMENT OF DEFENSE (DoD)Department of Defense ‘Trusted Computer System Evaluation Criteria’, DoD

Orange Book, 1983

OBJECTIVES• Standard unit of measure to indicate degree of trust to be placed in a

computer• Guidance to manufacturers• Uniform basis for specifying security requirements• Enforce development and installation of Multi Level Security (MLS) systems

– MLS means multiple security levels within one system, e.g., Internal Use, Confidential and Secret data

• (Encourage development of commercial MLS systems to distribute the costs across commercial and government sectors)

64

RP/LvR/VU OCT/2002


MAC and DAC

Topmanagement“business process owners”

Define policyDefine policy

Security administratorsets overall security rules via LABELS

Mandatory Access Control (MAC)

Application / Information System owners“technical owners”set access lists etc.

Discretionary Access Control (DAC)

ACCESS RULES TO RESOURCES

If allowed by MAC, technical owners may grant access via DAC

33

65

RP/LvR/VU OCT/2002


MAC and DAC

DISCRETIONARY ACCESS CONTROL (DAC)• The TCB provides the means to protect data• The means are used by the owners of data at their discretion (as they

think to be appropriate due to their requirements for Confidentiality and Integrity)

MANDATORY ACCESS CONTROL (MAC)• There is a higher authority above the owners, i.e. the security administrator• The security administrator sets the overall rules for Confidentiality

and Integrity• Implemented through Security Labels (each containing a Security Level and

one or more Security Categories)• The owners have to obey these overall rules• If allowed by the overall rules, the owners can grant access to their

data by users and groups (DAC)

!!

66

RP/LvR/VU OCT/2002


US DoD’s classes

A1Verified Design

A2(beyond current technology)

A2(beyond current technology)

B1Labeled Security Protection

B2Structured Protection

B3Security Domain

B3Security Domain

C1Discretionary Security protection

C1Discretionary Security protection

C2Controlled Access Protection

C2Controlled Access Protection

DMinimal Protection

DMinimal Protection

DEPARTMENT OF DEFENSE: CLASSES FOR TCBs

increasing degree of trust

TCB = Trusted Computing Base (hardware, OS and access control)A = Verified protectionB = Mandatory protection (owners have to follow the administrator’s rules)C = Discretionary protection (at the owner’s discretion)D = Minimal protection

34

67

RP/LvR/VU OCT/2002


Relevant DoD classes

RELEVANT DoD CLASSES

D = minimal protection– MVS without RACF (expiration dates, MVS password), workstations etc.

C1 = discretionary security protection– MVS with RACF up to 1.6

C2 = controlled access protection (DAC - Discretionary Access Control)– MVS with RACF 1.7 and higher (introducing PROTECTALL and Erase On

Scratch; the use of it is at the data owner’s discretion)

B1 = labeled security protection (MAC - Mandatory Access Control)– MVS 3.1.3 with RACF 1.9 (introducing MLS security and classifying all

users and all data; the data owners have to obey the rules set by the security administrator)

• Each higher class required all of the features of the lower classes.

68

RP/LvR/VU OCT/2002


DoD’s definition of B1

DoD’s DEFINITION OF B1 SECURITY

LABELS AND MANDATORY ACCESS CONTROLA security label is a combination of a hierarchical level and one or more non-

hierarchical categories, and is assigned by the security administratorUser X’s label dominates data Y’s label if X’s level is higher or equal to Y’s level,

and X’ categories contain all Y’s categories– Read only = label X dominates label Y– Write only = label Y dominates label X– Update = label X equals label Y

“read down and write up” = ∗-property (Bell LaPadula model)– Data cannot be declassified (no write-down)

Accountability: specify clearance (label) at logon and print it on all output pages

Life-Cycle Assurance: independent review of the product as provided by supplier

35

69

RP/LvR/VU OCT/2002


Levels and categories

SECURITY LEVELS AND CATEGORIES• Hierarchical security levels from 1 to 254 - a higher security level represents a

higher value of the data and higher confidentiality• Non-hierarchical categories may represent departments, projects etc.• RACF class SECDATA, add profiles and members via RESOURCE DEFINE and

RESOURCE ALTER commands, e.g., to specifyClass SECDATA

– Profile SECLEVEL» Member INTERNAL USE / 10» Member CONFIDENTIAL / 100» Member SECRET / 150» Member TOPSECRET / 200

– Profile CATEGORY» Member OFFICE» Member FACTORY» Member WAREHOUSE

Categories

1

Lev

els

25

4

Labels

70

RP/LvR/VU OCT/2002


EXAMPLE OF SECURITY LABELS

WARE-I FACT-IWARE-I FACT-IOFFC-IOFFC-I

OFFC-C WARE-C FACT-COFFC-C WARE-C FACT-C

OFFC-TSOFFC-TS

Example of security labels

CATEGORIES

LEVELS OFFICE WAREHOUSE FACTORYLABELS

DIRECTOR

PROD-MGR

GROUP-MGR

WORKER

CLERK

200 Top Secret

150 Secret

100 Confidential

10 Internal Use

• DIRECTOR dominates CLERK• DIRECTOR does not dominate PROD-MGR and GROUP-MGR (missing categories)• GROUP-MGR dominates CLERK and WORKER• NOTE: Introducing B1 requires an exhaustive list of authorities and relations

and a consistent set of labels (practically impossible to implement this in an existing system)

OFFC-S FACT-S

36

71

RP/LvR/VU OCT/2002


Example of security labels ...

DEFINITION OF SECURITY LABELSSecurity administrator with SPECIAL attribute issues the RACF commands• SETROPTS SECLABELCONTROL

• RDEFINE SECLABEL DIRECTOR SECLEVEL(TOPSECRET) ADDCATEGORY(OFFICE)

• RDEFINE SECLABEL PROD-MGR SECLEVEL(SECRET) ADDCATEGORY(OFFICE FACTORY)

– PERMIT DIRECTOR CLASS(SECLABEL) ACCESS(READ) ID(GEORGE,JOHN,SYLVIA)

– PERMIT PROD-MGR CLASS(SECLABEL) ACCESS(READ) ID(GEORGE,PETER)

Here, ‘read’ means that the user may use the label, i.e.• GEORGE may select DIRECTOR or PROD-MGR• JOHN and SYLVIA may only use DIRECTOR• PETER may only use PROD-MGR

72

RP/LvR/VU OCT/2002


RACF RESOURCE PROFILES

C.2


C.2


37

73

RP/LvR/VU OCT/2002


RACF access authorities

RACF ACCESS AUTHORITIESThe following RACF access authorities can be used (a level includes all

above)• NONE• EXECUTE: the user may execute a program, but not copy it• READ: can be executed and read/copied• UPDATE: execute, read and write (but no scratch and no create)• ALTER: execute, read, write, scratch, create and the authority to modify

the access list (adding, changing and removing authorities of users/groups to this resource)

Subjects: “Entire world”

Group

User}

NONEEXECUTE

READUPDATEALTER

{ dataset

program

Objects: Resources

74

RP/LvR/VU OCT/2002


Discrete resource profile


DISCRETE RESOURCE PROFILEA discrete profile is a 1:1 relation. For each resource, there is one discrete profile

containing1 resource name, e.g., SYS1.LINKLIB• volume name, e.g., DISK10 (unique identification: name and location)• name of owner, e.g., IBMUSER2 security level and categories, e.g., SECRET and PURCHASE3 access list with specification of user/group and access authority, e.g., JOHN

with UPDATE and SYLVIA with NONE4 Universal Access (UACC): default access authority for all users not specified

in the access list, e.g., UACC=READ (so all users may read, except for SYLVIA with NONE and JOHN who may UPDATE)

• conditional access list with specification of user/group, access authority and the program to be used (not to be discussed during this lecture)

5 auditing data

38

75

RP/LvR/VU OCT/2002


Generic resource profile

GENERIC RESOURCE PROFILEA generic profile is a one-to-many relation. For a group of resources, there is one

generic profile containing1 generic resource name, e.g., SYS1.∗ for all data set names starting with SYS1,

SYS1.LINKLIB for all instances at different disks etc.• ((( NO volume name: the generic profile is location independent )))• name of owner, e.g., IBMUSER2 security level and categories, e.g., SECRET and PURCHASE3 access list with specification of user/group and access authority4 Universal Access (UACC): default access authority for all users not specified in

the access list• conditional access list with specification of user/group, access authority and the

program to be used (not to be discussed during this lecture)5 auditing data

Aspects 1 and 3 to 5 are discussed on following foils (2 has been discussed before: DoD)

76

RP/LvR/VU OCT/2002


1. Data set and program names in OS/390

DATA SET AND PROGRAM NAMES IN OS/390

A data set name in OS/390 consists of one or more qualifiers, each up to 8 characters, separated by periods, e.g.

<high level qualifier>.<second qualifier>.<third qualifier>.etcPASSWORDSYS1.NUCLEUS, SYS1.HASPACESYS1.APF.LOAD

The first one is the high-level qualifier. Usually it is• userid• groupid• indication of a group of related data sets, e.g. GLM for all data sets related to

data and software of general ledger)

A program name in OS/390 consists of up to 8 character, e.g., AMSPZAP, HASJES2, MYPROG45 etc.

PROGRAM

DATA

39

77

RP/LvR/VU OCT/2002


Generic syntax rules

GENERIC RESOURCE PROFILE: one-to-many relationAdvantages of generic profiles: reduction in administrative effort when controlling

a large number of data sets, and improvement in performance by reducing I/O load on RACF data base

The syntax rules for a generic name are

• high-level qualifier must not contain a generic character (fully qualified, e.g., SYS1.∗ and RONALD.∗)

• ‘∗’ represents any character in that position and all subsequent characters until next period, if any (e.g., SYS1.∗ applies to SYS1.NUCLEUS and SYS1.APF.LOAD, while SYS1.∗.LOAD applies to SYS1.APF.LOAD)

• ‘∗∗’ Enhanced Generic Naming Convention (EGN) (if EGN is active, ‘∗’ applies to one qualifier, ‘∗∗’ applies to zero or more qualifiers)

• ‘%’ represents any character in that position (e.g., RON.FOIL%VU applies to RON.FOIL1VU, RON.FOIL2VU etc.)

78

RP/LvR/VU OCT/2002


3. Access list and 4. UACC

ACCESS LIST• Contains names of users or groups, and their access authorities• E.g.

– SYSPROGROUP UPDATE– JOHN ALTER– SYLVIA NONE

• At access attempt, RACF will search for the most specific entry in the access list

UNIVERSAL ACCESS (UACC)• If the name is not found in the access list, RACF will use the default specified in

the UACC field• E.g., UACC = READ

• In this example– RONALD has READ (not in access list, so UACC is used)– JOHN has ALTER– SYLVIA has NONE (access denied by specific entry in access list)– LEEN is member of group SYSPROGROUP and has UPDATE

40

79

RP/LvR/VU OCT/2002


5. Data set audit attributes

OWNER SPECIFIES AUDITING FOR DATA SET

ALTDSD ‘SYS1.LINKLIB’ AUDIT( NONE (READ) )FAILURES (UPDATE)SUCCESS (CONTROL)ALL (ALTER)

AUDIT operand: the owner of the data set specifies which access attempts must be logged into the SMF data set (audit trail)

Note: With some exceptions, owners are hardly interested in this audit trail, since they are usually not allowed to read the SMF data sets

80

RP/LvR/VU OCT/2002


Data set audit attributes ...

OWNER SPECIFIES AUDITING FOR DATA SET

ALTDSD ‘SYS1.LINKLIB’ NOTIFY(userid)

userid = user to be informed via a TSO message in case of denied access

NOTIFY operand: send a message to the user specified in case of a violation of the access rules. The message may be

USER(CARL) GROUP(PURCHASE) NAME(CARL TONG)ATTEMPTED ‘UPDATE’ ACCESS OFENTITY ‘SYS1.LINKLIB’IN CLASS ‘DATASET’ AT 15:33:35 ON JAN 2, 98

(Note: You cannot trust the NAME field, since a user may change this field in his/her User profile)

41

81

RP/LvR/VU OCT/2002


Data set audit attributes ...

AUDITOR SPECIFIES AUDITING FOR DATA SET

ALTDSD ‘SYS1.LINKLIB’ +GLOBALAUDIT( NONE (READ) ) NOTIFY(userid)

FAILURES (UPDATE)SUCCESS (CONTROL)ALL (ALTER)

GLOBALAUDIT operand: a user with the AUDITOR attribute specifies which access attempts must be logged into the SMF data set (audit trail)

Notes• AUDIT is specified by the owner. GLOBALAUDIT is specified by the auditor. If

any of the two operands indicates logging, a log record is written to SMF• GLOBALAUDIT can only be viewed by the auditor. So nobody else can notice that

it is on or off

82

RP/LvR/VU OCT/2002


Examples of discrete profiles

EXAMPLE: A discrete profile of a system data set

PROFILE NAME = ‘SYS1.LINKLIB’OWNER = SYSOWNERAUDIT = FAILURES(UPDATE)NOTIFY = SYLVIAUACC = READACCESS LIST = SYSPROGROUP has UPDATE

EXAMPLE: A discrete profile of a user data setPROFILE NAME = ‘JOHN.CNTL’OWNER = JOHNAUDIT = NONEGLOBLAUDIT = ALL(READ)NOTIFY = JOHNUACC = NONEACCESS LIST = GROUPA1 has READ

CARL has UPDATEJIM has ALTER

42

83

RP/LvR/VU OCT/2002


Example of generic profile

EXAMPLE: The generic ‘SYS1.∗’ describes, e.g.‘SYS1.LINKLIB’‘SYS1.ISPF.ISPPLIB’‘SYS1.TSO.SOURCE’etc. but not, say, ‘SYS2.TESTLIB’

This generic profile may be defined by issuing the commands

ADDSD ‘SYS1.∗’ UACC(READ) +AUDIT(ALL(UPDATE)) OWNER(SYSOWNER)

PERMIT ‘SYS1.∗’ ID(SYSGROUP) ACCESS(UPDATE)PERMIT ‘SYS1.∗’ ID(JOHN) ACCESS(ALTER)

It now reads

PROFILE NAME = ‘SYS1.∗’OWNER = SYSOWNERUACC = READAUDIT = ALL(UPDATE)ACCESS LIST = SYSGROUP has UPDATE

JOHN has ALTER

84

RP/LvR/VU OCT/2002


Process an access request

PROCESS AN ACCESS REQUEST: SEQUENCE OF TESTSEvent: Subject X asks access to object YThe sequence of tests by RACF is• Global Access Checking (covered by general rules? YES or next test)Read the most specific resource profile from RACF data base or an in-

storage buffer• MAC: Security label (level and category? NO or next test)• DAC:• High-level qualifier (own data set? YES or next test)• Access list (user/group access authority? NO, YES or next test)• UACC (access authority for those not in access list? YES or next test)• Operations attribute (access authority for backup/restore? YES or next test)• Conditional access list (user/group + program access authority? NO, YES or next)• If not yet a decision, the answer is NO

The answer to the access request is YES or NO

43

85

RP/LvR/VU OCT/2002


user/group in conditional access listuser/group in conditional access list

Process an access request ...

Global Access CheckingGlobal Access Checking

MAC: Security Level and CategoriesMAC: Security Level and Categories

High-level Qualifier=useridHigh-level Qualifier=userid

user/group in access listuser/group in access list

Universal Access (UACC)Universal Access (UACC)

within scope of operations attributewithin scope of operations attribute

allowed by global rules

Subject X asks access to object Y

no, use most specific generic/discrete profile

yes

no

no, program access to data set

security label processing

yes, personal data set

yes, explicitly allowed

allowed

allowed

yes, explicitly allowedaccess approved

not used for B1

no, incorrect

no, explicitlydenied

access denied no match, hence access denied

no, explicitlydenied

DAC:

86

RP/LvR/VU OCT/2002


RACF Erase On Scratch

ERASE ON SCRATCH (EOS) -per resource

An owner or user with ALTER may set the Erase Indicator via

ALTDSD ‘JOHN.DATA’ ERASE | NOERASE

If allowed by the security administrator, the effect is

• ERASE - Entire data set is overwritten with binary zeros before the pointer is removed

• NOERASE - At delete, only the pointer is removed

Usage depends upon data classification and is at the discretion of the data owner

Directory: pointer to SECRET

binary zeros

Directory

free space

DELETE

ERASE

Directory

data SECRET

free space

44

87

RP/LvR/VU OCT/2002


ERASE ON SCRATCH (EOS) - system settingThe security administrator (with system SPECIAL attribute) controls the

mechanism via

SETROPTS ERASE(ALL)ERASE(SECLEVEL(level number))ERASE(NOSECLEVEL)NOERASE

Options• ERASE(ALL): EOS applies to all data sets regardless of their individual Erase

Indicator• ERASE(SECLEVEL(level number)): EOS applies to all data sets with this

security level and higher, regardless of their individual Erase Indicator• ERASE(NOSECLEVEL): use the individual Erase Indicator of each data set• NOERASE: EOS is not used, the individual Erase Indicators are ignored

Preferred setting: SETROPTS ERASE(NOSECLEVEL)

RACF Erase On Scratch ...

88

RP/LvR/VU OCT/2002


RACF GLOBAL ACCESS CHECKING

C.3

RACFGLOBAL ACCESS CHECKING

(GAC)

C.3

RACFGLOBAL ACCESS CHECKING

(GAC)

45

89

RP/LvR/VU OCT/2002


Global Access Checking (GAC)

GLOBAL ACCESS CHECKING (GAC)A small number of rules are applicable to all users and groups, such as• A user has unlimited access to its personal data sets, e.g., ALTER to all data sets

with a high-level qualifier equal to the userid• A user has UPDATE access to all group data sets of its group• Everybody may read all system data sets, except those excludedThese rules may be specified in a fast accessable in-storage table, which is

used to handle the ‘trivial’ access requests

In-storage GAC table• &RACUID.∗ / ALTER• &RACGPID.∗ / UPDATE• etc.

In-storage GAC table• &RACUID.∗ / ALTER• &RACGPID.∗ / UPDATE• etc.

Subject X asks access to object Y

RACF• In GAC? Then YES• Else, fetch resource profile

to decide

RACF• In GAC? Then YES• Else, fetch resource profile

to decide

RACF data base• User profile X• Resource profile Y• ...

YES/NO

90

RP/LvR/VU OCT/2002


Commands to define GAC

COMMANDS TO DEFINE GACGAC is an in-storage table with names of resources and the associated access

authority assigned to all users. An entry in this table may be a• fully qualified name of a profile, e.g., ‘SYS1.LINKLIB’ with READ• generic name of a profile, e.g., ‘SYS1.∗’ with READ• name containing a generic RACF userid (indicated by &RACUID) with ALTER• name containing a generic RACF groupid (indicated by &RACGPID) with

UPDATE

The table is maintained through RACF commands such as

• RDEFINE GLOBAL DATASET ADDMEM( ‘SYS1.∗’ / READ )• RALTER GLOBAL DATASET ADDMEM( ‘&RACUID.∗’ / ALTER )• RALTER GLOBAL DATASET ADDMEM( ‘&RACGPID.∗’ / UPDATE )• RLIST ...• RDELETE ...

46

91

RP/LvR/VU OCT/2002


The GAC table may read

&RACUID.∗ / ALTER personal data sets(read as: ALTER for user &RACUID)

&RACGPID.∗ / UPDATE group data sets(read as: UPDATE for user connected to group &RACGPID)

ISP.∗.ISP%LIB / READ full screen editor and user commands(read as: READ to all users)

SYS1.∗ / READ system libraries, excluded the following:SYS1.BRODCAST / UPDATE broadcast messagesSYS1.DUMP∗ / NONE dumpsSYS1.HASP∗ / NONE spool and checkpointSYS1.MAN∗ / NONE SMF records (audit trail)SYS1.PARMLIB / NONE system parametersSYS1.RACF∗ / NONE security dataSYS1.UADS / NONE userids and passwords for non-RACF useSYS1.VTAM∗ / NONE network definitions

RACF uses the most specific entry in the GAC table for its decision. E.g., for a request to access ‘SYS1.DUMP23’, it will use ‘SYS1.DUMP∗’/NONE rather than ‘SYS1.∗’/READ

GAC table

92

RP/LvR/VU OCT/2002


PROBLEM C.1: Use the GAC table discussed during the presentation. The following access requests occur

nr user group access attempt

1 JOHN SYSPRO ALTER ‘SYS1.BRODCAST’2 CARL APPLIC UPDATE ‘SYS1.BRODCAST’3 CARL APPLIC READ ‘SYS1.DUMP23’4 JOHN SYSPRO UPDATE ‘SYSPRO.DATA’5 CARL APPLIC READ ‘SYSPRO.DATA’6 CARL APPLIC UPDATE ‘JOHN.CNTL’7 CARL APPLIC ALTER ‘CARL.CNTL’8 MAGGIE AUDITOR READ ‘SYS1.MANZ’

QUESTION: Which accesses are granted by GAC and by which rule?

Problem C.1: RACF GAC

47

93

RP/LvR/VU OCT/2002


MANAGEMENT PROCESSES

PART D.


• Administrative attributes• SETROPTS command• RACF data bases and RVARY command

PART D.


• Administrative attributes• SETROPTS command• RACF data bases and RVARY command

94

RP/LvR/VU OCT/2002


Administrative authorities

RACF uses three administrative attributes / authorities, i.e.• SPECIAL: allowed to issue any and all RACF commands and to view and modify

any and all fields in the RACF data base, except those dedicated to the Auditor• AUDITOR: allowed to view any and all fields in the RACF data base and to issue

RACF commands affecting specific logging options• OPERATIONS: allowed to access any and all data on peripheral devices (read

and write on disks and tapes)

Notes• The SPECIAL user is the security administrator for RACF, defining the RACF

structure and the profiles (usually only a few persons)• The AUDITOR verifies the use of the system and the effectiveness of access

control• The OPERATIONS user is responsible for backup/restore of storage media

(usually only 2 persons, i.e. operations analists preparing the housekeeping jobs)• If separation of duty is required in a large environment, nobody should have more

than one of these three attributes

!

48

95

RP/LvR/VU OCT/2002


Authorities for access control

AUTHORITIES FOR ACCESS CONTROL• SECURITY ADMINISTRATIVE AUTHORITY: attributes or privileges

associated with access control system, required for setting and administering system-wide security options.Note: For RACF, this is system-wide SPECIAL, OPERATIONS and AUDITOR (no GROUP authorities)

• SYSTEM AUTHORITY: attributes, privileges or access rights associated with operating system, to perform system support and maintenance.Note: Usually systems programmers and support staff

MISUSE OF AUTHORITYIt is recognised that these users can improperly use their authority to circumvent

access control. This is considered a misuse of authority, which cannot be tolerated. Management is to

• Be advised of the deviations (if detected, e.g., by Security Health Checking)• Investigate (via the audit trail, if necessary)• Take appropriate action (warning, suspension or dismissal)

96

RP/LvR/VU OCT/2002


Security administrative authority

SECURITY ADMINISTRATIVE AUTHORITY ON TYPE A AND B HOST• Authority granted to individual (or group or shared/surrogate userid, only if

individual accountability can be guaranteed)

• Written authorization for long-term assignment (over 2 weeks) and annual revalidation

• Emergency and short-term assignment to be approved by PoS or formal designee (emergency may in retrospective)

• All commands and activities with this authority must be logged (RACF: SAUDIT)• All activities must be authorized: by management, by change control or consistent

with job description

• The AUDITOR authority may be combined with the administrative authority (depending upon the size of the organisation and the requirements for separation of duty)

NORMEN

49

97

RP/LvR/VU OCT/2002


SETROPTS command

SETROPTS COMMAND

Via the SETROPTS command, a security administrator has full control over the major RACF options and features. Some options relevant to the EDP-auditor are

SETROPTS INITSTATS | NOINITSTATS

• record date and time of RACINIT SVC, i.e start of session or start execution of batch job

• used for password expiration (PASSWORD INTERVAL) etc.• preferred setting INITSTATS

SETROPTS INACTIVE(unused userid interval) | NOINACTIVE

• revoke a userid after it has not been used for a specified number of days• usually, this is 90 days• preferred setting INACTIVE(90)

98

RP/LvR/VU OCT/2002


SETROPTS command ...

SETROPTS SAUDIT | NOSAUDIT

• log all activities of a SPECIAL user (operand only to be used and viewed by AUDITOR)

• preferred setting SAUDIT

SETROPTS OPERAUDIT | NOOPERAUDIT

• log all activities of an OPERATIONS user (operand only to be used and viewed by AUDITOR)

• preferred setting OPERAUDIT

SETROPTS CMDVIOL | NOCMDVIOL

• log all command violations (operand only to be used and viewed by AUDITOR)• preferred setting CMDVIOL

50

99

RP/LvR/VU OCT/2002


SETROPTS command ...

SETROPTS PROTECTALL(FAILURES)PROTECTALL(WARNING)NOPROTECTALL

• Protect all: no data sets can be defined nor accessed for which there is no matching discrete or generic profile

• PROTECTALL(WARNING) only during an intermediate situation, in order to create all profiles required

• preferred setting PROTECTALL(FAILURES)

SETROPTS LIST

• this is a command, to be entered by the auditor: view all active options of SETROPTS

• the usage of this command is important for the EDP-auditor in order to inspect the current setting

100

RP/LvR/VU OCT/2002


RACF data bases and RVARY command

Passwords can be defined for the use of RVARY viaSETROPTS RVARY(SWITCH(passw1) STATUS(passw2))• RVARY may be issued by any TSO user (e.g., in case of malfunctioning RACF), but

has to be approved by the system operator at the Master Console (who has to provide the password)

• SWITCH: switch from primary to secondary data base, or vice versa• STATUS: switch to manual mode, i.e. operator has to approve all access requests

RACF DATA BASESFor reasons of continuity of operations, two RACF data bases must be defined• Primary RACF data base• Secondary RACF data base, hot standby (continuously up-to-date), preferably

located at another disk string and accessible through another I/O channel

Primary RACF data base

Secondary RACF data base

RACF

switch via

RVARY SWITCH

command(de)activate via

RVARY STATUS

command

51

101

RP/LvR/VU OCT/2002


Exposure: Help Desk

EXPOSURE: HELP DESKCommercial service bureau for data processing and electronic mail. Well-defined

procedures for the Help Desk. A student (hacker) authorized to use electronic mail sends a note to the Help Desk

from: Marc van Goethem P987 @ NODE123to: Help Desk HELPDESK @ NODE456subject: please reset password of PAANS @ NODE123

The Help Desk staff inspects the mail log, reading

from P654 @ NODE123 to HELPDESK @ NODE456subject: no dial-in access possible on 012-345678

from P987 @ NODE123 to HELPDESK @ NODE456subject: please reset password of PAANS @ NODE123

from Q234 @ NODE789 to HELPDESK @ NODE456etc. etc.

Without any verification, the password was reset and the new password was returned to the student, who now could logon with the userid PAANS

Advice: Do not only define procedures, but also verify whether the staff adheres to them and whether they are effective

102

RP/LvR/VU OCT/2002


AUDIT OF RACF

PART E.

AUDIT OF RACF

• Data Security Monitor (DSMON)• RACF Report Writer (RACFRW)• Cross Reference Lister (IRRUT100)

PART E.

AUDIT OF RACF

• Data Security Monitor (DSMON)• RACF Report Writer (RACFRW)• Cross Reference Lister (IRRUT100)

52

103

RP/LvR/VU OCT/2002


Activities of an auditor

ACTIVITIES OF AN EDP-AUDITOR• Specify logging of (to provide for audit trail / SMF data)

– specified users (ALTUSER ... UAUDIT)– specified data sets (ALTDSD ... GLOBALAUDIT)– SPECIAL users (SETROPTS SAUDIT)– OPERATIONS users (SETROPTS OPERAUDIT)– modification of RACF profiles (SETROPTS AUDIT(class names))– statistical data (SETROPTS STATISTIC and INITSTATS)– command violations (SETROPTS CMDVIOL)

• Inspect logging via commands– LISTUSER– LISTGRP– LISTDSD– RLIST– SETROPTS LIST– verify also SMF options (member SMFPRMnn in SYS1.PARMLIB, SMF

exits, procedures for saving SMF data etc.)

104

RP/LvR/VU OCT/2002


Activities of an auditor ...

ACTIVITIES OF AN EDP-AUDITOR

Run DSMON to obtain an overview• actual overview of current settings (at the very moment of executing DSMON)• for more in-depth investigations: use the LIST commands to inspect RACF

options and profiles

Issue the TSO command RACFRW to• process the audit trail (historical data)• verify compliance with the guidelines (e.g., a SPECIAL user is not allowed to

assign AUDITOR to him/herself, unless so authorised)• obtain an overview of command violations, rejected access requests etc.

Run the utility IRRUT100 (cross reference lister) to find and list all occurencesof userids and group names

• e.g., are authorisations adequate and relevant

53

105

RP/LvR/VU OCT/2002


DSMON

DATA SECURITY MONITOR (DSMON)Tool for EDP-auditors, it reports• system overview and status of RACF• group-tree report (owner of group, subgroups, sub-subgroups)• contents of Class Descriptor Table (each entry indicates a default UCC, auditing

on/off, statistics on/off, access by OPERATIONS users)• active RACF exit routines• contents of Global Access Checking (GAC) table• contents of the RACF Started Task Table (each entry describes the RACF userid

and groupid for a started task)• overview of users with SPECIAL etc.• overview of sensitive data sets and their protection

Only persons with the AUDITOR attribute can execute DSMON, unless explicitly authorized through the RACF program-control facility

106

RP/LvR/VU OCT/2002


System report

RACF DATA SECURITY MONITOR

SYSTEM REPORT

CPU-ID 201234CPU MODEL 3090 R34OPERATING SYSTEM/LEVEL MVS 3.8 SP 5.2.2

JBB 2125SYSTEM RESIDENCY VOLUME SYS001SMFID A123

RACF VERSION 2 RELEASE 2 IS ACTIVE

(alternative: IS INACTIVE, HAS BEEN DEACTIVATED, IS NOT INSTALLED)

54

107

RP/LvR/VU OCT/2002


Group tree report

RACF DATA SECURITY MONITORGROUP TREE REPORT

LEVEL GROUP (OWNER)

1 SYS1 (SYSOWNER)2 SYSPRO (SPROADM)2 NETMAINT (SPROADM)2 OPER (OPERADM)3 MVSOPER (OPERADM)3 NETOPER (OPERADM)3 OPERSUPP (OPERADM)2 USERS (SYSOWNER)3 DEPT01A (ADMIN801)4 GROUP01A (ADMIN801)4 GROUP01B (ADMIN801)

NOTE: Users are not displayed (use LISTGRP per group to obtain names or run IRRUT100)

108

RP/LvR/VU OCT/2002


RACF SVCs

Standard interface with RACF: four SuperVisor Calls (SVCs):

• SVC 130, RACHECK: verification– Is user allowed to access the resource specified?

• SVC 131, RACINIT: initialization– Is user allowed to logon or to start a batch job? Is the password correct?

• SVC 132, RACLIST: list– Build in-storage profiles for resources

• SVC 133, RACDEF: define– Create, modify or remove a profile

For each SVC, there is a pre-processing and a post-processing exit. If the computing center installs the exit routine, it is reported in the next DSMON report

55

109

RP/LvR/VU OCT/2002


RACF exit report

RACF DATA SECURITY MONITOR

RACF EXITS REPORT

EXIT MODULE NAME MODULE LENGTH

ICHPWX01 5,734ICHRCX01 1,234ICHRCX02 456ICHRDX01 4,046ICHRDX02 128ICHRIX01 6,780ICHRIX02 12,564

• ICHPWX01: syntax checker for new passwords• ICHRCX01/2: RACHECK, e.g., to support local conventions• ICHRDX01/2: RACDEF, ditto• ICHRIX01/2: RACINIT, e.g., for NJE support

QUESTION: How will you use the data reported?

110

RP/LvR/VU OCT/2002


GAC report

RACF DATA SECURITY MONITORGLOBAL ACCESS CHECKING TABLE REPORT

CLASS ENTRY ACCESSNAME NAME LEVEL

DATASET &RACUID.∗ ALTER&RACGPID.∗ UPDATEISP.∗.ISP%LIB READSYS1.∗ READSYS1.BRODCAST UPDATESYS1.DUMP∗ NONESYS1.HASP∗ NONESYS1.MAN∗ NONESYS1.PARMLIB NONESYS1.RACF∗ NONESYS1.UADS NONESYS1.VTAM∗ NONE

DASDVOL GLOBAL INACTIVE ---

NOTE: If access is not granted by GAC, RACF will use its data base to retrieve the most specific generic or discrete profile

56

111

RP/LvR/VU OCT/2002


Started task report

A Started Task (or Started Procedure) is a job started by the system operator with the command

S JCL-procedure-name,operandsThe operator has no userid, hence a userid and groupid are assigned to the job using the RACF Started Task Table

RACF DATA SECURITY MONITORSTARTED PROCEDURE TABLE REPORT

PROCEDURE ASSOCIATED ASSOCIATED PRIVILE-NAME USER GROUP GED

RMF SPROSTC SYSPRO NOGTF SPROSTC SYSPRO YESSAVEDUMP OPERSTC OPER YESDFHSM OPERSTC OPER YESNCCF NETSTC NETWORK YES∗ IBMUSER SYS1 NO

PRIVILEGED means that the RACHECK SVC is omitted during OPEN processing

112

RP/LvR/VU OCT/2002


Selected user attribute report

RACF DATA SECURITY MONITORSELECTED USER ATTRIBUTE REPORT

USERID SPECIAL OPERATION AUDITOR REVOKEJOHN SYSTEM SYSTEM SYSTEMSYLVIA SYSTEM SYSTEMCARL SYSTEMPIERRE SYSTEMVICTOR SYSTEMADM801 GROUP GROUP GROUPADM802 GROUP GROUPUSER801C SYSTEM

TOTALS:SYSTEM 2 3 2 2GROUP 2 2 1

TOTAL DEFINED USERS: 2,000

Rule of thumb:• No person should have SPECIAL and AUDITOR (except in small organisations)• Limit number of system-wide SPECIALs, say, to 5

57

113

RP/LvR/VU OCT/2002


Selected data set report

RACF DATA SECURITY MONITORSELECTED DATA SET REPORT

DATA SET NAME VOLUME SELECT RACF RACF UACCNAME CRITER INDI PROT

SYS1.LINKLIB SYS001 LNKLST YES YES READSYS1.APFLIB SYS002 APF NO YES READSYS1.APFLIB2 SYS002 APF N.F.SYS1.APFLIB3 SYS003 APF N.M. YES READSYS1.LPALIB SYS001 SYSTEM YES YES NONESYS1.NUCLEUS SYS001 SYSTEM YES YES NONESYS1.PARMLIB SYS001 SYSTEM YES YES READSYS1.RACF1 SYS008 RACFDB YES YES NONESYS1.RACF2 SYS009 RACFDB YES YES NONESYS1.USERCAT DISK10 UCAT YES YES UPDT

• N.F. means ‘Not Found’ and is a security exposure; somebody with CREATE authority may create the data set and fill it with own software

• N.M. means ‘Not Mounted’ and requires further investigation

114

RP/LvR/VU OCT/2002


RACFRW

RACF REPORT WRITER (RACFRW)

RACFRW is a tool dedicated to the AUDITOR to select and process SMF records (RACF’s audit trail) and to print

• Reports describing all accesses to a specified resource (including userid, group and name of subject)

• Reports describing activities of specified users and/or groups• Reports summarizing use of resources

Input are SMF records, output are reports

An EDP-auditor should note• RACF settings affect what is logged• SMF settings and exits may affect and modify log records• Operational procedures and errors may affect what is stored as audit trail• Interpreting the audit trail is far from trivial: one has to hire an expert

58

115

RP/LvR/VU OCT/2002


Syntax of RACFRW

RACF REPORT WRITER (RACFRW)

It is activated as an interactive TSO command

RACFRW TITLE(page header)DATA(data for exit routines of RACFRW)FORMATNOFORMATDATASET(input SMF data)SAVE(output for further processing)LINECNT(n)GENSUMNOGENSUM

The RACFRW command processor will prompt for the subcommands such as SELECT, EVENT, LIST, SUMMARY and END

116

RP/LvR/VU OCT/2002


RACFRW report

---- JOB / LOGON STATISTICS ----TOTAL JOB/LOGON ATTEMPTS 783TOTAL JOB/LOGON SUCCESSES 753TOTAL JOB/LOGON VIOLATIONS 30

JOB/LOGON VIOLATIONS BY HOUR -

0-1 1-2 2-3 3-4 4-5 5-6 6-7 7-80 0 0 0 0 0 0 2

8-9 9-10 10-11 11-12 12-13 13-14 14-15 15-168 10 2 0 0 8 0 0

16-17 17-18 18-19 19-20 20-21 21-22 22-23 23-240 0 0 0 0 0 0 0

Overview of violations during start of executing a batch job and TSO logon

59

117

RP/LvR/VU OCT/2002


RACFRW report ...

98.324 10:16:44 RACF REPORT - LISTING OF STATUS RECORDS

DATE TIME SYSID OPTIONS98.323 07:49:25 MVS1 ORIGIN: SETROPTS

CMDVIOL: YESRACINIT: STATS

TYPE STATUS SEQ UNIT VOLUME DATASETNAMEUADS 20D DISK12 SYS1.UADSPRIMARY ACTIVE 1 20D DISK12 SYS1.RACFPRIMBACKUP INACTIVE 1 22E DISK22 SYS1.RACFSEC

OTHER OPTIONS:INTERVAL: 30 DAYS INACTIVE: 365 DAYSHISTORY: 24 RULE 1 LENGTH(7:8) AAAAAAAAREVOKE: 5 TRIES RULE 2 LENGTH(4:8) NNNNNNNNWARNING: 10 DAYS

(continued on next foil)

118

RP/LvR/VU OCT/2002


RACFRW report ...

Output of process records, printed by RACFRW:

98.323 10:16:44 RACF REPORT - LISTING OF PROCESS RECORDS

DATE TIME SYSID USERID GROUP TERMINAL EVENT QUAL98.323 07:49:25 MVS1 JOHN SYSDEV LU234Q 9 0

(continuation of this line)... JOBID=(ADDGROUP 98.323 07:47:49),USERDATA=(),

OWNER=SYSOWNER,REASON=(CLASS,SPECIAL)

(or another example of a continuation)... ADDUSER TESTUSR DFLTGRP(SYS) PASSWORD(∗∗∗∗∗∗∗∗)

NAME(PETER) AUTHORITY(USE) NGRPACC UACC(NONE) NOADSP OWNER(JOHN) NOSPECIAL NOOPERATIONS NOAUDITOR

• In this way, one may view all commands issued by a SPECIAL user• Similar reporting is possible for OPERATIONS and for selected users

60

119

RP/LvR/VU OCT/2002


Utility IRRUT100

UTILITY IRRUT100 (CROSS REFERENCE LISTER)• List all occurences of a userid or group name• Required: SPECIAL or AUDITOR • Output: cross reference

• Per group– relation with other groups: superior and subgroups– relation with users: as default group, as CONNECT group– ownership of resources

• Per user– member or connected to a group– ownership of resources– included in access list of any resource

120

RP/LvR/VU OCT/2002


Utility IRRUT100 ...

UTILITY IRRUT100 (CROSS REFERENCE LISTER)

Sample output report, e.g., on USER01A

OCCURENCES OF USER01A

IN ACCESS LIST OF PROFILE SYS1.PARMLIBOWNER OF PROFILE SMP4.USERMOD.PTFININ ACCESS LIST OF SMP4.USERMOD.ASMFIRST QUALIFIER OF PROFILE USER01A.CNTLOWNER OF PROFILE MAINT01.∗ (G)OWNER OF PROFILE MAINT02.∗ (G)IN ACCESS LIST OF GROUP SYS1IN ACCESS LIST OF GROUP SMP4USER ENTRY EXISTS

61

121

RP/LvR/VU OCT/2002


RELATION WITH CODE OF PRACTICE

PART F.

RELATION WITH THECODE OF PRACTICE

PART F.

RELATION WITH THECODE OF PRACTICE

122

RP/LvR/VU OCT/2002


Relation with CoP

This presentation on access control by RACF is related to the following sections of the Code of Practice (CoP) / British standard BS 7799

9 Access control

9.1 Business requirements for system access

9.1.1 Access control policy

9.2 User access management

9.2.1 User registration

9.2.2 Privilege management

9.2.3 User password management

9.2.4 Review of user access rights

9.3 User responsibilities

9.3.1 Password use

62

123

RP/LvR/VU OCT/2002


Relation with CoP ...

9.5 Operating system access control

9.5.1 Automatic terminal identification

9.5.2 Terminal logon procedures

9.5.3 User identification and authentication

9.5.4 Password management system

9.5.5 Use of system utilities

9.5.6 Duress alarm to safeguard users

9.5.7 Terminal time-out

9.5.8 Limitation of connection time

9.7 Monitoring system access and use

9.7.1 Event logging

9.7.2 Monitoring system use

124

RP/LvR/VU OCT/2002


Homework

HOMEWORK

Read the sections of the Code of Practice, mentioned on the foils above, and attempt to find the relation with the RACF mechanisms discussed during this presentation.

Some differences, such as enforcing the user to change the password every 30 days (CoP) are a matter of professional judgment. Debates on the right choice may last forever...

63

125

RP/LvR/VU OCT/2002


ANSWERS TO PRESENTED QUESTIONS

PART G.


PART G.


126

RP/LvR/VU OCT/2002


Problem B.1: password security

ANSWER PROBLEM B.1: password security

• The password syntax allows the use of alphabetic passwords, so trivial words can be used

• A hacker notes that a userids is revoked after five failing attempts to provide a password

• He hence selects four possible passwords, and– selects a userid, tries the four possible passwords– if one fits, he has access to the system– if all four of them fail, the userid is still not revoked– he tries the next userid etc., untill the 2.000 userids are all tested

• So the hackers has 8.000 chances to find a matching userid-password combination

• Usually, this approach provides a number of hits

64

127

RP/LvR/VU OCT/2002


Problem C.1: RACF GAC

ANSWER PROBLEM C.1: Access Authority evaluation via GAC table

1. JOHN attempts ALTER to ‘SYS.BRODCAST’– GAC allows UPDATE to ‘SYS1.BRODCAST’– access is rejected

2. CARL attempts UPDATE to ‘SYS1.BRODCAST’– GAC allows UPDATE to ‘SYS1.BRODCAST’– access is granted

3. CARL attempt READ to ‘SYS1.DUMP23’– GAC allows READ to ‘SYS1.∗’, but there is a more specific entry with

NONE for ‘SYS1.DUMP∗’– access is rejected

4. JOHN connected to group SYSPRO attempts UPDATE to ‘SYSPRO.DATA’– GAC allows UPDATE to ‘&RACGPID.∗’– access is granted

128

RP/LvR/VU OCT/2002


Problem C.1: RACF GAC ...

5. CARL connected to group APPLIC attempts READ to ‘SYSPRO.DATA’– no matching GAC entry– access is rejected

6. CARL attempts UPDATE to ‘JOHN.CNTL’– GAC allows ALTER to ‘&RACUID.∗’, but this applies here to JOHN, not to

CARL– access is rejected

7. CARL attempts ALTER to ‘CARL.CNTL’– GAC allows ALTER to ‘&RACUID.∗’– access is granted

8. MAGGIE connected to the group AUDITOR attempts READ to ‘SYS1.MANZ’ (SMF records)– GAC allows READ to ‘SYS1.∗’, but there is a more specific entry with NONE for

‘SYS1.MAN∗’– access is rejectedNOTE: the group name AUDITOR means nothing, it is just one of the many groups

65

129

RP/LvR/VU OCT/2002


ONLY FOR THE OS/390 AUDITORS

PART H.

ONLY FOR THE OS/390

AUDITOR

PART H.

ONLY FOR THE OS/390

AUDITOR

130

RP/LvR/VU OCT/2002


Routertable

SAF

--RACROUTE

--RACHECK

VLF

ExitPre ProcExitPost Proc

RACINIT

RACDEF

RACHECK

RACLIST

DATABASEMANAGER

STORAGEMANAGERGlobal AccessChecking Table

Instorageprofiles

RACFDATABASE

GroupStructureProfiles

Data Space

Resource Access Control Facility (RACF)

66

131

RP/LvR/VU OCT/2002


Operating system resource (OSR)

SYSTEM INTEGRITY DEFINITION: OPERATING SYSTEM RESOURCEOperating System Resources (OSRs) are programs and data as part of:• The operating system• Its access control system• Sub-systems, program products and other applications as agreed by PoS

(including local modifications)This is the entire set of software and data acting as a foundation to support the user

programsRule of thumb: If a data set or program is not owned by a user or user group, it is

an OSR

132

RP/LvR/VU OCT/2002


Managing system authority

MANAGING SYSTEM AUTHORITYSYSTEM AUTHORITY: attributes, privileges or access rights associated with

operating system, to perform system support and maintenance. These are access rights to OSRs beyond that of a general user.

Note: Usually systems programmers and support staffThe rules are:• System authority must be based upon a valid business need, determined by PoS.

If it is part of the job description, no further written justification is required• System authority may be granted to a group, if individual accountability is

maintained.Note: Due to staff reduction, many systems programmers maintain multiple program products and act as mutual backups. It is more cost effective to grant the authority to their group

• The PoS must have a demonstrable process, including periodic reviews, to ensure currency of the list of people with system authority

• All activities with system authority must be authorized: job description, management or change control

67

133

RP/LvR/VU OCT/2002


Operating system resources ...

OPERATING SYSTEM RESOURCES (OSRs)The most efective way to protect OSRs is to provide default levels of protection:1. No OSRs may be updated by a general user, except those designed to be generally

writable.Example of exception: SYS1.BRODCAST in MVS

2. All OSRs may be read and/or executed by a general user, except where this would assist the user to bypass security controls.Examples of exceptions: RACF data base and RACF utilities in MVS

3. Logs must be maintained of all accesses to OSRs not allowed by general users.4. PoS must maintain a list of all exceptions above and must guarantee adequate

protection of these OSRs.With this approach, the list of exceptions is relatively short. The exceptions are

specified per platform in the appendices of the standards

134

RP/LvR/VU OCT/2002


Example: OSRs of OS/390

EXAMPLE: OSRs OF OS/390General rule: SYS1.∗ with READ for all users (updates must be logged)OSRs with UACC=UPDATE (no logging required)• User Catalogs (access to be determined by PoS)• SYS1.BRODCAST (exchange notes)OSRs with UACC=NONE (reads must be logged)• Page data sets (virtual memory)• Spool data sets (JCL and output)• System dump and trace data sets• SMF data sets (system logging)• RACF data bases - primary, secondary, backups• TSO User Attribute Data Set - UADS (passwords)• All system and subsystem parameter libraries, such as SYS1.PARMLIB and

JES2 parameter library• VTAMLST (switched node protection)• etc. for all MVS subsystems

68

135

RP/LvR/VU OCT/2002


Example: OSRs of OS/390 ...

OSRs, execution controlled (executes must be logged)• ADRDSSU - data management• AMASPZAP - authorized version of zap• ICKDSF - data management• IDCSC01 - cache management for disks• IEHATLAS - change disk volume names• IEHINIT - overwrite tape labels• RVARY - control RACF• PX021062 and CREDISP0 - allow to issue operator commands (emulate master

console)• etc.

136

RP/LvR/VU OCT/2002


Technical host review process

TECHNICAL HOST REVIEW PROCESS• All type A hosts must be audited (penetration test) at least annually• All type B hosts at least every 18 monthsPROCESS• Group of penetration testers, e.g., skilled systems programmers• Time schedule for the OS/390 images: PoS defines priorities and provides

userids• The team:

– Access the image through the network (no travel required)– Use general userid for penetration test– Use AUDITOR userid for obtaining fast overview– Inform PoS about details of findings and solutions– Report only statistics to Head Quarters

Purpose: Assist PoS to make the image impenetrableKeyword: Effective penetration test (so they must have access to all relevant

information to speed up the process and to find as many exposures as possible)

69

137

RP/LvR/VU OCT/2002


Example: penetration report

EXAMPLE: PENETRATION REPORT

Definitions for reporting

• System penetration: Bypassing access control and/or obtaining access to useridwith high authority

• Unauthorized access: Access to CONFIDENTIAL data or higher, or to someone else’s userid

138

RP/LvR/VU OCT/2002


Example: penetration report ...

Period: First quarter 1999 1Q99 4Q98 3Q98

Numbers of images tested 100 100 100

System penetrations 50 64 75Unauthorized access 35 52 75

Failed during first test 35 43 54Failed during re-test 30 35 38

System: ABC001 Date: April 18, 1998Tester: John JohnsonControl objective: Refer to list of OSRs with UACC=NONEFinding: Spool data set SYS1.HASPACE had UACC=READRisk: This allows all users to read the password of user XYZ with SPECIAL authorityRecommendation: Set UACC=NONE

Report to PoS:

Report to Head Quarters:

70

139

RP/LvR/VU OCT/2002


Reasonable level of impenetrability

REASONABLE LEVEL OF IMPENETRABILITYThe PoS must protect his/her images. During an audit, the following reasonable

level of security is expected:• Protected against attacks by general users who do not have internal information• If the penetration was detected by Operations and would have been corrected, a

penetration may not be considered a finding• Do not base the finding on: APARable product deficiencies, PTFs in error and

PTFs not properly flagged• The tools used must also be available to staff of PoSWhen exposures are identified:• PoS must write corrective action plan with time schedule• No need to address known exposures during a next penetration test, if there is an

action planNote: These rules protect the PoS against unreasonable findings by auditors!

140

RP/LvR/VU OCT/2002


Security health checking

SECURITY HEALTH CHECKINGA manual or automated process must be implemented to assess periodically the

status of the access control system of• Type A and B systems• Multi-user type C systems with SECRET dataIf automated: Execute the tool every workdayThe process must verify and report deviations of:• Access control system security settings

– Must be in compliance with detailed measures for platform. Note: For RACF, this is SETROPTS, GAC etc.

– Changes must be explained/justified• Userids with security administrative and system authority (unauthorized

privileges must be removed at once). Note: For RACF, this is system and group SPECIAL, OPERATIONS and AUDITOR, and CONNECTs to groups of systems programmers, operators, support staff etc.

• Profiles (access list and UACC) of operating system resources (OSRs)After each run, the reports must be inspected and deviations must be tracked

6-b security aspects of os390 systems, racf · file 6-b security aspects of os390 systems, racf ......

Documents