So You still Have a Mainframe? Edward Napoleon, CISSP, CISM. ISACA March 17, 2016

Transcription

1 1 So You still Have a Mainframe? Edward Napoleon, CISSP, CISM ISACA March 17, 2016

2 2 So You Still Have a Mainframe In this day of highly distributed systems and networks who still talks about mainframe computers? Most major banks, insurance companies, government agency, etc. still have mainframe systems as a key component of their IT infrastructure. The problem is most people that supported their organizations mainframes have already or are ready to retire.

3 This presentation is an overview for those who still have to secure or audit their organizations mainframe. We will also briefly discuss the three major mainframe security sub systems, CA-ACF2, CA- Top Secret and IBM s RACF. 3

4 What Is a Mainframe? Enterprise Server

5 What Is a Mainframe? An obsolete device still used by thousands of obsolete companies serving billions of obsolete customers and making huge obsolete profits for their obsolete shareholders. And this year s run twice as fast as last year s. The Devil s IT Dictionary, I predict that the last mainframe will be unplugged on March 15, Stewart Alsop, Infoworld, March 1991

6 What Is a Mainframe? (Cont.) The IBM mainframe is a traditionally large computer (large as in physical size, data processing and I/O performance, or both). System/ System/ System/ z/os Series Hosts the databases, transaction servers, and applications that require a great degree of security and availability. The primary operating systems are: z/os (also called OS/390) - Still based on the MVS z/vm) VSE TPF GNU/Linux

7 What Is a Mainframe? (Cont.) Businesses today rely on the mainframe to: Perform large-scale transaction processing (thousands of transactions per second) Support thousands of users and application programs concurrently accessing numerous resources Manage terabytes of information in databases Handle large-bandwidth communications The roads of the information superhighway often lead to a mainframe.

8 Why the Mainframe High Standards System z is the only computing platform that demonstrates compliance to the Common Criteria's Evaluation Level 5+ rating EAL5: Semiformally Designed and Tested The mainframe has the highest mean-timebetween-failure rating: 30 Years Most mainframes experience: less than 5 minutes of downtown a year

9 Why Are Mainframes Still Used? The reasons for mainframe use are many, but most generally fall into one or more of the following categories: Reliability, availability, serviceability Security Scalability Continuing compatibility Evolving architecture

10 Why Are Mainframes Still Used? (Cont.) Mainframes Very high reliability and stability >99,999%, or less than 5 minutes of downtime a year Very high storage capacity Disks, tapes: several terabytes Very high I/O throughput Large number of users (more than 5,000)

11 Why Enterprise Server Audit Training? 96 of the world s top 100 banks 23 of the 25 top retailors 9 0f 10 largest insurance companies 75% of the global 500 companies Mainframes process 30 billion transactions per day The roads of the information superhighway often lead to a mainframe.

12 IBM z13 -Mainframe IBM claims the z13 mainframe is the first system able to process 2.5 billion transactions a day (or the equivalent of 100 Cyber Mondays every day, according to the company). It can encrypt mobile transactions in real-time and provide on-the-fly insights on all transactions that pass through it. This will help companies and governments improve fraud detection, IBM says, and it give them a live view of a your purchasing habits so they can push related promotions to consumers right when they re in-store.

13 System z Integrity Statement Designed to help protect the systems data, transactions and applications from accidental or malicious modification System integrity is the inability to bypass the security on system resources IBM will always take action to resolve if a case is found where the above can be circumvented System z integrity statements and the Common Criteria certifications are helpful proof points in addressing compliance requirements.

14 Auditing z/os

15 Module z/os Objectives Gain a general understanding of IBM z/os operating system Understand IBM z/os audit considerations and their effect on the audit approach Gain an understanding of the z/os Enterprise Security Managers (ESMs) and the audit approach

16 Let's get a little technical

17 IBM Integrity Statement A paraphrase: IBM warrants, provided that mechanisms under the user s control are properly protected, z/os integrity is guaranteed. That is if you find an undocumented exposure in the z/os operating system, IBM will close that exposure or provide you with a mechanism to control it.

18 Operating System Integrity An operating system is said to have system integrity when it is designed, implemented, and maintained to protect itself against unauthorized access, and does so to the extent that security controls specified for that system cannot be compromised

19 Operating System Integrity Specifically for z/os, this means that there must be no way for any unauthorized program, using any system interface, defined or undefined, to do the following: Obtain control in an authorized state Bypass store or fetch protection Bypass password checking

20 The Hardware Controls and the Integrity Statement IBM mainframe computers (the z series ) have three hardware controls which form the basis of all z/os security: 1. The Supervisor State Switch (restricts when a program can execute privileged hardware instructions [such as the instruction to change the date and the instruction which writes directly to a disk drive]) 2. Protect Keys (restrict what memory a program can update or read) 3. Address Spaces (restrict what memory a program can touch)

21 The Hardware Controls and the Integrity Statement The z/os operating system uses these three controls to build a virtual fence around each program running on the computer This virtual fence prevents each program from interfering with other programs executing at the same time, and also from interfering with z/os itself. These hardware controls and the virtual fence z/os constructs from them are the basis of z/os security.

22 The Hardware Controls and the Integrity Statement This architecture is so solid that IBM provides us with written assurance that no program can break out of its virtual fence unless you modify the system to permit this This assurance is the basis of the IBM s Integrity Statement for z/os, which we ve already read IBM also provides several standard methods for you to modify the system to give a specified program privileges which permit it to break out of its virtual fence. Such programs (called privileged programs ) can bypass all security on the system, including that provided by CA ACF2, CA Top Secret, and IBM s RACF.

23 The Hardware Controls and the Integrity Statement A typical mainframe installation may have hundreds of such privileged programs These privileged programs act like backdoors, neither good or bad, just practical We need to be able to know however that they don t introduce security exposures to our systems

24 So What Is the Risk? The essential issue here is control of the ability to update Key Datasets The Key Datasets are those where the backdoors are specified and those where they reside User Supervisor Calls (these programs reside in the dataset SYS1.NUCLEUS or in the LPALIST datasets APF Authorization and TSO APF Authorization (these programs all reside in datasets which have been flagged as APF-authorized) I/O Appendages (acquire their privileges through APF authorized datasets) Functional Sub-Systems (acquire their privileges through LINKLIST datasets) Exits (assembler or REXX language programs which can modify the logic of standard software) (Many exits reside in APF-authorized or other system datasets.) The Program Properties Table (Programs listed in this table only receive privileges if they reside in APF-authorized libraries.) All these backdoors are specified in the parmlib datasets

25 So What is the Risk? cont. In other words, any programmer who can update (write to) such datasets can introduce or modify programs which can bypass all the security on the system. We want to know that management can provide reasonable assurance that these programs do not introduce security exposures to the system.

26 Operating System Integrity

27 z/os Security and Integrity Controls z/os Internal Security Controls Program Status Word Bypass store or fetch protection Storage Keys Supervisor State APF Authorization z/os Integrity Mechanisms Authorized Libraries Program Properties Table (PPT) User Supervisor Calls (SVCs) Command Authority (System, Operator) System Management Facility

28 Other Critical Areas of Concern Command Authority Restricted Utilities Exits Change Control

29 The Foundation of z/os Security

30 Instruction Set The instruction set architected is part of the hardware design. For example: on a System z system, there are instructions for changing the flow of a program. These are the BRANCH instructions. On Intel 80x86 processors, the same type of instruction is a JUMP. Each instruction in the instruction set has a numerical value. The BRANCH instruction is an 07. When a System z system sees an 07 it knows to extract an address from a register and fetch the instruction at that address in memory. That fetched instruction is then executed. If a System z system saw a JUMP instruction it would take exception to it, since JUMP isn t in the architected instruction set IBM

31 Instruction Set Many ways to ADD Name Mnemonic Type OpCode ADD A RX 5A ADD NORMALIZED (long) AD RX 6A ADD NORMALIZED (long) ADR RR 2A ADD NORMALIZED (short) AE RX 7A ADD NORMALIZED (short) AER RR 3A ADD HALFWORD AH RX 4A ADD HALFWORD IMMEDIATE AHI RI A7A ADD LOGICAL AL RX 5E ADD LOGICAL ALR RR 1E ADD DECIMAL AP SS FA ADD AR RR 1A ADD UNNORMALIZED (short) AU RX 7E ADD UNNORMALIZED (short) AUR RR 3E ADD UNNORMALIZED (long) AW RX 6E ADD UNNORMALIZED (long) AWR RR 2E ADD NORMALIZED (extended) AXR RR IBM

32 Multiplicity and Security issues Cont d Where all programs are not made equal Control Instructions: Have the capability of affecting the user execution environment. Should be made available to the OS only General Instructions: Can be executed by any program IBM

33 System z Control Instructions BRANCH AND SET AUTHORITY BRANCH AND STACK BRANCH IN SUBSPACE GROUP DIAGNOSE EXTRACT PRIMARY ASN EXTRACT SECONDARY ASN EXTRACT STACKED REGISTERS EXTRACT STACKED STATE INSERT ADDRESS SPACE CONTROL INSERT PSW KEY INSERT STORAGE KEY EXTENDED INSERT VIRTUAL STORAGE KEY INVALIDATE PAGE TABLE ENTRY LOAD ADDRESS SPACE PARAMETERS LOAD CONTROL LOAD PSW LOAD REAL ADDRESS LOAD USING REAL ADDRESS MODIFY STACKED STATE MOVE PAGE (Facility 2) MOVE TO PRIMARY MOVE TO SECONDARY MOVE WITH DESTINATION KEY MOVE WITH KEY MOVE WITH SOURCE KEY PROGRAM CALL PROGRAM RETURN PROGRAM TRANSFER PURGE ALB PURGE TLB RESET REFERENCE BIT EXTENDED SET ADDRESS SPACE CONTROL SET ADDRESS SPACE CONTROL FAST SET CLOCK SET CLOCK COMPARATOR SET CPU TIMER SET PREFIX SET PSW KEY FROM ADDRESS SET SECONDARY ASN SET STORAGE KEY EXTENDED SET SYSTEM MASK SIGNAL PROCESSOR STORE CLOCK COMPARATOR STORE CONTROL STORE CPU ADDRESS STORE CPU ID STORE CPU TIMER STORE PREFIX STORE THEN AND SYSTEM MASK STORE THEN OR SYSTEM MASK STORE USING REAL ADDRESS TEST ACCESS TEST BLOCK TEST PROTECTION TRACE 2006 IBM

34 z/os Security Controls Supervisor State/Problem State z/os architecture Two states: Supervisor (0) and Problem (1) 16 keys:0 7 system; 8 F user Storage protection key A program in supervisor state can perform any operation. A program in problem state can perform operations only within its address space. UNIX equivalent: kernel mode vs. user mode

35 Instruction Execution 2006 IBM

36 Interrupt Driven Systems Systems running on System z processors are interrupt driven When events occur in the system, execution of the program on the processor is paused and the event is handled Types of events that cause interruptions: Restart Supervisor-Call External I/O Machine-Check Program 2006 IBM

37 The Interruption Mechanism When an interruption event occurs, the program status word (PSW) is changed in favor of a PSW which drives the interrupt handling software This requires some strict conventions and preparation to happen The new PSW is fetched from memory locations fixed by the z/architecture. The Operating System prepares the new PSWs so that the proper instruction sequences are given control when the interruption occurs. The interrupted program eventually regains control when the OS retrieves the old PSWs from the architecturally defined location where it was stored IBM

38 z/os Security Control Security at the CPU Level Security within z/os begins at the CPU level with the Current Program Status Word (PSW) register. The PSW includes the instruction address and other information used to control and determine the state of the CPU for an executing program. The current PSW is the PSW for the program instructions currently being executed by the CPU. There is a PSW for each active processor.

39 Security at the CPU Level The PSW also contains the Problem State bit at bit 15. When this bit is set to 0, the CPU is said to be executing in supervisor state. In supervisor state, all instructions to be executed by the CPU are valid. When this bit is set to 1, the CPU is said to be executing in problem state. In the problem state, the only valid instructions are those instructions that provide meaningful information to the problem program and that cannot affect system integrity; such instructions are called unprivileged instructions.

40 Program Status Word

41 Multiprocessing 2006 IBM

42 Compartmenting the System z computer memory The Storage Protection keys. The Storage Key principles of operation Every page frame is allocated a Storage Key which consists of a set of four bits called the Access-Control bits plus an additional bit called the Fetch Protection bit. The Storage Key is physically located in associated system-only memory, that is storage keys and Fetch protection bits are not accessible as regular memory data by instructions.

43 Getting the Storage Protection Keys to work A control instructions is allowed to set a Storage key value, that is a specific value out of 16 possible values, for a given page frame. There is also a PSW key value that can be set in bits 8 to 11 of the PSW. When an instruction being executed in the CPU requests for memory access, the hardware compares the Storage Key and the current PSW key values before proceeding with any effective access.

44 Getting the Storage Protection Keys to work When the memory access is denied the requesting program is interrupted. The Storage protection Key violation event falls in the category of Program-check interrupt. It is typically expected that in such a case the operating system is not to resume the execution of the interrupted program, as it is either an addressing mistake in the user program or the user program deliberately attempts to penetrate memory areas it is not authorized to access.

45 z/os concepts Storage protection keys Keys 0 to 15 Key 0: Master Key Permitting read access to all storage Keys 1 7: z/os components, such as JES, RACF, VTAM, CICS, IMS, etc. Keys 8 15: User program keys

46 Security at the CPU Level The instructions that are never valid in the problem state are called privileged instructions. When a CPU in the problem state attempts to execute a privileged instruction, a privileged operation exception is recognized. Another group of instructions, called semi-privileged instructions, are executed by a CPU in the problem state only if specific authority tests are met (the program is authorized ); otherwise, a privilegedoperation exception or a special operation exception is recognized. The corresponding exception occurs.

47 Multiprocessing 2006 IBM

48 System z Virtual Storage The concept of virtual storage This physical mapping is transparent to programs in that programs use the memory address in a purely conceptual view: programs designers are expecting that: an address used to store data is also the address to be used to retrieve these same data. contiguous address values point at contiguous data.

49 System z Virtual Storage Address values as used by programs can be decoupled from actual physical addresses used by the memory technology. Such a decoupling would allow better use of the available space in the physical memory, which then became the real storage programs ranges of logical addresses that would go beyond the actual limit of real storage. The logical address being the address used by the CPU to fetch the instructions to be executed, to fetch the data to be worked on and to store the results of instructions execution. inter-user isolation at the virtual storage level. The term Virtual Storage was coined to designate the capability, offered by a system, to use logical addressing.

50 How virtual storage works Virtual storage is divided into 4-kilobyte pages Transfer of pages between auxiliary storage and real storage is called paging When a requested address is not in real storage, an interruption is signaled and the system brings the required page into real storage z/os uses tables to keep track of pages Dynamic address translation (DAT) Frames, pages, slots are all repositories for a page of information

51 Logical Partitioning PR/SM (processor resource/systems manager) is a standard feature of System z that allows the user to define logical partitions (LPARs) in the physical system. A logical partition provides the set of resources necessary to load an execute an Operating System and users applications. A single physical System z system can host several Operating Systems that operate concurrently under control of the PR/SM microcode and hardware mechanisms. Each logical partition appears as a complete system to its users and administrators IBM

52

53 z/os Integrity Mechanisms 1. APF Authorization 2. Authorized Libraries 3. Program Properties Table (PPT) 4. User Supervisor Calls (SVCs) 5. Command Authority (System, Operator) 6. System Management Facility

54 APF Authorization

55 What Is APF Authorization? APF authorization is a mechanism that permits the operating system to recognize itself and thereby distinguish between operating system software and other software. z/os contains a feature called the authorized program facility (APF) to allow selected programs to access sensitive system functions.

56 Authorized Programs APF was designed to avoid integrity exposures. The installation identifies which libraries contain those special functions or programs. Those libraries are then called APF libraries. Key Issue: An APF-authorized program can do virtually anything that it wants: It is essentially an extension of the operating system. It can put itself into supervisor state or a system key. It can modify system control blocks. It can execute privileged instructions (while in supervisor state). It can turn off logging to cover its tracks.

57 Control Issues The power of APF is such that, theoretically, a capable system programmer could intercept or reveal any data under the control of z/os or erase all online disks and set the entire virtual and real storage to binary zeros. Due to the privileged capabilities afforded to APF authorized programs: APF libraries should contain only programs authorized by APF (in one of the specified libraries). Access to APF-authorized libraries should be restricted, accesses monitored, all changes and additions carefully controlled. It is important to ensure that APF libraries physically exist, because if they do not, the possibility exists of substitution of a Trojan Horse library in place of the missing APF library.

58 Program Properties Table

59 Program Properties Table (PPT) Certain system programs need to run with special powers. The program properties table (PPT) lists these programs by name and the special properties assigned to each. The PPT is used to assign unique attributes to specific programs from the start of system initialization.

60 Program Properties Table Programs in the PPT can perform special actions: Bypass password checking Get a specific key <8; that is, get supervisor state Bypass integrity checking Allow access to a data set already in use by another program Be protected against cancellation or swap Program must be APF-authorized.

61 PPT Control Issues All programs in the PPT should be approved by management, and no application programs should reside therein. Attributes selected for the programs should be reviewed to ensure that they do not pose security concerns and they are in accordance with the installation s security policy. Access to the PPT also should be restricted and its use monitored. The PPT should not contain any redundant programs, as this could permit the use of that program s name for substitution into an APF-authorized library and therefore provide that program APF-authorized status.

62 Audit Program for PPT Review PPT definitions in the active SCHEDxx member of SYS1.PARMLIB. This member of PARMLIB has entries that supplement or override IEFSDPPT. Ensure that all entries are documented and authorized by management. Ensure that all entries are properly documented and authorized by management. Determine if programs in the PPT portion of the SCHEDxx member are vendor supplied or installation written. Perform a scan of all APF and LNKLST libraries and look for duplicate PPT program names. Use : RACF you (DSMON, SYSPPT function) CA-Audit

63 Supervisor Call (SVC)

64 Supervisor Call A supervisor call is a function that permits z/os programs to invoke one of the common functions of z/os, which must execute in an authorized state. SVCs are high-level programs that perform system services (e.g., allocating data sets) at the supervisor level. Two main types of SVCs exist: restricted and unrestricted. Restricted SVCs may be invoked only from APF-authorized programs and are not available to all programmers. These SVCs carry out sensitive supervisory or security related functions. Unrestricted SVCs may be used by any program to carry out functions needed by everyone.

65 Supervisor Call A main reason for SVCs is so that every programmer wanting to open a data set (file) and read data from that data set would not have to code all the program steps in their program. Supervisor call programs are normally launched from a macro issued from a program. Example: Open Macro calls SVC 19, open a data set. There are 256 possible supervisor calls: SVCs are IBM-supplied. SVCs are installation-written.

66 Supervisor Call (SVC) SVCs are defined at SYSGEN or in the IEASVCxx PARMLIB member. User-installed Third-party tools IBM subsystems not part of base z/os (CICS, etc.) SVCs are supposed to protect the supervisor state by performing integrity checks.

67 Restricted SVC If a program is APF-authorized, it can issue restricted SVCs. For example: SVC 76 may enable a programmer to falsify hardware and system software errors. SVC 83 may be used to falsify SMF records. SVC 85 may be used to swap one device for another during the execution of a job. SVC 107 may be used to swap the system s mode of operation: Key=ZERO Key=NZERO

68 Supervisor Calls (SVCs) The coding of SVCs requires exceptional assembler skills and usually leads to the compromise of z/os integrity. Many vendors and customers write their own SVCs and have had problems with them.

69 SVC Control Issues SVCs are of particular importance from a control perspective because they acquire control of the system in an authorized state. Installation-written SVCs are also important because they may contain unauthorized code. Access to the libraries where SVCs are stored should be restricted and such access should be monitored. Active SVCs, particularly installation-written SVCs, should be reviewed and authorized and their functions documented (because of the possibility of unauthorized code), and their use should be monitored. For sensitive SVCs, there should be a requirement for the caller to be APF-authorized. A caller is a program that tells the SVC to perform a task. Access to the SVCUPDTE macro and the update recording table should be reviewed for the latest changes to any SVCs.

70 Exits

71 Exits z/os exits are basically trap doors that allow changes in normal processing based on the function and location of the exit. From an audit and security standpoint, exits are important for a number of reasons: Exits can make the system operate differently from the way the vendor documentation describes it. Exits can introduce exposures in the security of your system: Most z/os components contain exits that can be used to customize their behavior and adapt to local need.

72 Control Issues Because of their ability to significantly affect processing and subsystems operation, it is important to ensure that only authorized exits are in place. Changes to exits also should be monitored, and only authorized changes, subject to proper change control procedures, should be implemented. Libraries where the exits are kept also should be subject to proper access controls. All of the mainframe security packages, RACF, CA-ACF2, and CA Top Secret, have a number of exits that need to be checked as well.

73 Critical and Sensitive System Data Sets

74 Sensitive and Critical Data Sets The sensitive and critical libraries are data sets used by the operating system, or components/subsystems, for initialization and smooth running of the operating system. These data sets, or libraries, along with other files, make up the system data sets which are required for z/os to operate. Illegal access to or corruption of these data sets may have a significant impact on the integrity of the operating system. These data sets contain IPL parameters and the programs that make up the system control parameters.

75 Sensitive and Critical Data Sets High-level qualifier for system libraries Most of time SYS(x) SYS1.PARMLIB SYS1.VTAMLST SYS1.UADS In many cases, another name is used. Depends on the naming convention of the.

76 SYS1.Parmlib(IEASYS00) LNKLSTxx IEAAPFxx PFKTABxx MPFLSTxx CONSOLxx LPASTxx IEASYS00 CLOCKxx IEALPAxx SMFPRMxx IEAFIXxx SCHEDxx IEASVCxx IEFSSNxx IEAAPP00 PROGxx

77 Standard System Libraries z/os has many standard system libraries; some of these are related to IPL processing, while others are related to the search order of invoked programs or to system security, as described here: SYS1.PARMLIB contains system control parameters. SYS1.LINKLIB has many system execution modules. SYS1.LPALIB contains the re-entrant system execution modules that are loaded into the link pack area when the system initializes. SYS1.PROCLIB contains JCL procedures distributed with z/os. SYS1.NUCLEUS has the basic supervisor modules of the system.

78 Sensitive Data Sets Reside on IPL Volume SYS1.NUCLEUS - Operating system nucleus and initialization code SYS1.LOGREC - Error log SYS1.SVCLIB - I/O appendages and non-standard label routines PASSWORD - z/os passwords

79 Sensitive Data Sets Optional : SYS1.MANx - SMF data sets SYS1.UADS - TSO user attributes SYS1.CMDLIB - TSO commands SYS1.VTAMLST - VTAM options SYS1.VTAMOBJ - VTAM options

80 Critical Data Sets Required : SYS1.PARMLIB - Parameter library SYS1.PROCLIB - First JCL procedure library SYS1.LPALIB - All re-entrant programs that will be loaded into PLPA SYS1.LINKLIB - All executable programs that are frequently used and available to everyone SYS1.MACLIB - Assembler macros

81 Critical Data Sets Control Issues Data sets used during an IPL and those supporting system libraries used to house system modules, utilities, and programs need to be adequately secure. The IPL process runs as a privileged system. If supporting data sets are not properly controlled, it is possible for someone to insert his own code to execute privileged during the IPL. System programmers often need access to these libraries to manage system update and additions. Update to these libraries should be tightly controlled, with any changes to SYS1.PARMLIB or nucleus data sets going through established change control procedures, with audit updates, sign-off, and appropriate review.

82 Audit Program for Sensitive and Critical Data Sets In most shops SYS1 is the high-level qualifier for system data sets. This is not always the case though, and you should ask which highlevel qualifiers are used by the organization. (SYSn) Ensure that all system data sets are adequately controlled. Users outside of technical support, or operations should not have update access. Ensure that any globally applied access rules contain entries for any critical system data set. Ensure that data sets considered system level are not user data sets. The high level qualifier should not be for an individual TSO user. Identify all system data sets.

83 System Management Facility (SMF)

84 System Management Facility (SMF) System Management Facility (SMF) is critical to the auditability of z/os and its subsystems. SMF is used for the collection of system activity as well as ESM security events. When an external security manager is used, the corresponding SMF records must be enabled. Equivalent to UNIX syslog.

85 System Management Facility (SMF) SMF collects several types of system information. This is used as the primary input to programs generating reports on system efficiency, performance, and usage. The SMF routines record the following data: System performance data JOB-related data Security violations and audit trails (ACF2, RACF) Data set access data (Open and Close) System configuration Job and job step identification, and much more The names of the data sets and which records are to be recorded in the SMF are defined in the SMFPRMxx member of PARMLIB.

86 SMF Control Issues Incorrect settings of SMF parameters can cause records not to be logged. SMF exits can also selectively or completely suppress SMF logging. Failure to log record types required by the enterprise may result in lack of information for performance measurement, accounting, security event tracking, and an incomplete audit trail.

87 Audit Program for SMF, Cont. SMF settings Example Extract of PARMLIB(SMFPRMxx) ACTIVE /*ACTIVE SMF RECORDING*/ DSNAME(SYS1.MAN1,SYS1.MAN2,SYS1.MAN3) MAXDORM(3000) /* WRITE AN IDLE BUFFER AFTER 30 MIN*/ STATUS(010000) /* WRITE SMF STATS AFTER 1 HOUR*/ LISTDSN /* LIST DATA SET STATUS AT IPL*/ SYS(NOTYPE(4:5,16:19,40,62:69,150),EXITS(IEFU83,IEFU84, IEFACTRT, IEFUJV, IEFUSI, IEFUJI, IEFUTL, IEFU29), INTERVAL(010000), DETAIL) SUBSYS(STC,EXITS(IEFU29,IEFU83,IEFU84,IEFUJP,IEFUSO))

88 Command Authority

89 Command Authority Execution of operator and/or system commands should be controlled by ESM Inspect: JES2 parameters for command authority on: INTRDR JOBCLASS TSUCLASS STCCLASS SDSF Netview Check for other products bypassing ESM for operation or system commands

90 Utility Programs

91 What Are Utility Programs? Tools to assist with the management of and collection of data Very helpful in collecting information related to the audit Programs that have been around since the early mainframe days

92 Utility Programs IEFBR14 IEBGENER IEBCOPY IEBDG IDCAMS IEBUPDTE

93 System-Oriented Utilities IEHLIST - The IEHLIST utility is used to list a partitioned data set directory or a disk volume VTOC. It is normally used for VTOC listings and provides bit-level information. IEHINITT - The IEHINITT utility is used to write standard labels on tapes. IEHPROGM - The IEHPROGM utility is almost obsolete. It is used primarily to manage catalogs, rename data sets, and delete data sets by a program instead of by JCL actions. It was primarily used during system installation or the installation of a major program product. ICKDSF - The ICKDSF utility is used primarily to initialize disk volumes. At a minimum, this involves creating the disk label record and the VTOC. ICKDSF can also scan a volume to ensure that it is usable, reformat all the tracks, write home addresses and R0 records, and so forth. SUPERZAP - The SUPERZAP program is used to patch VTOCs, executable programs, or almost any other disk record. In practice it is mostly used to patch executable programs. It was extensively used in earlier days to install minor fixes in programs.

94 Restricted Utilities Restricted utilities are programs that have the capability of bypassing normal security controls, like: Backup/recovery tools (ADRDSSU, FDR) ZAPPERS, AMASPZAP, IMASPZAP, IRRUT300 Initialization routines, IEHNITT, Tape INIT utilities Check Check programs defined in the PPT with NOPASS attribute Is all software evaluated for potential restricted utilities? Protection of restricted utilities by ESM against malicious execution

95 Change Control in z/os

96 Change Control Change control is the process of monitoring and controlling the application of changes to a mainframe environment. Enterprise Servers, because of their uptime requirements, are brought down only rarely to apply changes. Dues to the criticality and security requirements of mainframes, changes that are applied must be done so in a very controlled environment.

97 Greatest Source of Errors Is Change Unplanned changes to application and system software affect the stability and availability of critical business systems. Companies spend millions on change management systems only to have them circumvented and never know it.

98 Change Control To ensure that changes are applied appropriately, the change control process and supporting documentation should include the following: Who - the department, group, or person that requires the change and is responsible for implementing the change, completing the successful test, and backing out if required; also will sign off the change as successful What - the affected systems or services. Include as much detail as possible. Ideally, complete instructions should be included so that the change could be performed by someone else in an emergency. Where - scope of change; the business units, buildings, departments or groups affected or required to assist with the change When - start date and time and estimated duration of the change. There are often three dates: requested, scheduled, and actual. Priority - high, medium, low, business as usual, emergency, dated Risk - high, medium, low Impact - what will happen if the change is implemented; what will happen if it is not; what other systems may be affected; what will happen if something unexpected occurs.

99 z/os External Security

100 z/os Security z/os was not designed with a lot of internal access control capability. z/os natively has no built in authentication and authorization capability. All access control functionality is built into its subsystems. The major subsystems with their own internal access control mechanisms: TSO CICS IMS DB2 To get the level of security control needed in a mainframe, you need an external security manager (ESM): RACF CA-ACF2 CA-Top Secret

101 Systems with RACF, ACF2 or Top Secret

102 The Security Access Facility (SAF) Requests for security services on z/os are passed through the Security Access Facility (SAF). This facility is the interface between system services and the External Security Manager (ESM) installed on the system. SAF routes requests for authentication, resource accesses checking, and other security related processes to the ESM through control points. Applications and system components call these common control points in order to interface with the ESM. Security on z/os is therefore centralized on SAF and the installed ESM. When there is no ESM installed, SAF creates the security constructs needed by system services.

103 The SAF Router 112 For each request type presented to SAF, a different routine is accessed. The location of these routines are in the SAF Routing Table

104 Mechanics of Authorization Checking

105 RACF Overview Resource Access Control Facility RACF is a member of the SecureWay Security Server SecureWay Security Server consists of: LDAP server Firewall technologies DCE security server Open Cryptographic Enhanced Plugins (OCEP) RACF Very good utility programs (SETROPTS) OK reporting programs (DSMON)

106 CA ACF2 Overview Product of Computer Associates Intl. (CA) Data is protected by default. The security focus is on the resources and is controlled by access and resource rules. Requires a higher level of technical skill to administer (Not really, but was designed by system programmers) Very good utility programs OK reporting programs

107 CA-TSS Overview Product of Computer Associates Intl. (CA) Data is not protected by default (optional). The security focus is on the user. Some think it is the easiest to administer(?) Very good utility programs OK reporting programs

108 Conclusion 117

109 118 Conclusion The reasons for Enterprise Servers (mainframes) use are many, but most generally fall into one or more of the following categories: Reliability, availability, serviceability Security Scalability Continuing compatibility Evolving architecture

110 119 Conclusion (Cont.) Enterprise Servers have: Very high reliability and stability Very high storage capacity Very high I/O throughput Large number of users Very high number of transactions Biggest Problem It is a 50 year old technology that has been enhanced to support both current and future large scale system needs The people skilled at managing these system are rapidly retiring and there is a shortage of skilled professionals

111 120 Resources to Learn z/os Security Security Server RACF Audit Guide RACF Security Administrators Guide Stu Henderson s Clear Explanation of Effective z/os Security Auditing Reduce Risk and Improve Security on IBM Mainframes: Vol 1, 2, 3 Introduction to the New Mainframe Security, Large-Scale Commercial Computing, Networking

112 121 Edward Napoleon, CISSP, CISM Tutis Security Consulting and Training 30 years, of Information Technology and Information Security experience. He has worked with and taught z/os security and auditing practices for Computer Associates, Key Bank and EY. Ed has experience with ACF2, RACF and Top Security z/os enterprise security managers. Ed is a retired principal from EY s security and risk management practice.