MVS AUDIT PROGRAM GENERAL OBJECTIVES Determine whether operating system features which control authorized programs are being properly administered and controlled to ensure that the installation and implementation of MVS provides maximum integrity and security of BTM's computer resources. Review prior years' recommendations (Internal Audit and BTM Head Office Examiners) for any recommendations related to MVS and if any, ensure they have been implemented. Update permanent file (MVS procedures, risk analysis, environment overview, etc.) The audit will address: I. System Software Environment II. System Generation and Initialization III. Authorized Program Facility (APF) Administration IV. System Software Maintenance Activities. V. Security I. System Software Environment Audit Steps 1. Organization and Staffing 1.1 Obtain the ISG organizational chart to identify the systems programming/ technical services function. 1.2 Determine the specific job responsibilities and special technical skills of each individual. 1.3 Determine the adequacy of staffing. 1.4 Determine the adequacy of supervision. 1.5 Determine the adequacy of separation of duties. 2. System Software Management Guidance 2.1 Obtain policies, standards, and procedures documentation pertaining to system software management. 2.2 Determine whether system software policies sufficiently state management's philosophies and strategies pertaining to system software installation and maintenance. 2.3 Determine whether system software policies sufficiently include the following elements: definition, general responsibilities, safeguards, scope, adequacy, and specific responsibilities. 2.4 Determine whether written procedures exist that implement policies pertaining to system software installation and maintenance. If written procedures do not exist, skip 2.5 through 2.7 below, and note in the audit report. 2.5 Determine whether procedures pertaining to system software installation and maintenance are fully coordinated with other technical support procedures (e.g., problem tracking and change management). 2.6 Determine whether procedures pertaining to system software management are regularly reviewed and kept current. 2.7 Determine whether sufficient orientation and training in procedures pertaining to system software management is given to all staff affected. 2.8 Determine whether standards of performance pertaining to system software installation and maintenance have been established by which the technical support function can be evaluated. 2.9 Determine whether there is a formal system software change control process having the following characteristics: * a formalized review board as the centralized approval point for all system software change requests * established authorized points of change origination * established procedures to ensure emergency changes are properly controlled * adequate approval points throughout the system software change control process * sufficient review points to ensure that system software changes are properly coordinated and approved * adequate "backout" procedures in the event testing indicates a "bad fix" * all changes to the system software environment are properly tested, verified, and documented, and change documentation is adequately secured. 3. Hardware and Software 3.1 Obtain an inventory of all hardware and its physical location making up the computer system configuration under review. Specifically, * CPUs * channels * operator consoles * disk devices (fixed and mountable) * tape drives * communications processors * miscellaneous channel attached devices such as printers and terminals * communications processors. 3.2 Obtain an inventory of all system software (including any software which requires "authorization" or system modification such as need for a special supervisor call -- SVC-- to be installed) noting its installed maintenance level vis-a-vis the vendor's current maintenance level. Specifically, * IBM primary system software - e.g., MVS control programs, JES, VTAM) * miscellaneous IBM program products - e.g., SDSF * other program products - e.g. CA-1, CA-ACF2, DMS/OS, CA-ASM2, IOF, RACF * other software either locally developed or obtained through CBT, NaSPA, etc. II. System Generation and Initialization 1. Obtain SYSGEN MACROs for the SVC table generation. 1.1 Determine the accuracy of local SVC MACROs. Using the AMBLIST service aid to map external and internal SVCs, verify the existence of local SVCs. 1.2 Review all local SVCs that have not been installed under APF controls for integrity considerations. 1.3 Using the appropriate CAATs software, run the SVC analysis routines and review all SVCs for integrity considerations that meet the following exception criteria: * the SVC resides in an unexpected location of virtual storage * the SVC does not conform to standard naming conventions. 2. Obtain a complete listing of SYS1.PARMLIB. 2.1 Determine the extent to which operator intervention has been minimized during IPL and subsequent system initialization. Member IEASYS00 should specify OPI=NO to prevent operator intervention and members COMMNDxx, IEACMDxx, and IEASLPxx should be used to automatically issue as many operator command streams as practicable. 2.2 Review SMF start-up parameters in member SMFPRMxx and all active SMF exists for system audit trail integrity and efficiency considerations. * is the job wait time (JWT) parameter excessive (e.g., more than 15 minutes)? * is either NOPROMPT or PROMPT (IPLR) in effect to prevent SMF modifications after IPL? * are excessive SMF records being collected? If the type 30 record is being collected, then the types 4,5, 20, 34, 35, and 40 are redundant. If the software monitor TSO/ MON is in use, then the type 32 record also may be eliminated. * are there any exists modifying or deleting SMF records? 2.3 Determine whether unused or superseded PARMLIB members have been deleted as recommended by IBM guidelines. 2.4 Determine whether PARMLIB can allocate a second extent, a condition which can cause an IPL failure. This step applies only to MVS/SP1.3 and earlier system. 2.5 Determine whether the CNTCLIST option in the IEAOPTxx member is set to YES which could introduce a system performance exposure form TSO CLIST loops. This applies only if the installation is running TSO Extension -- TSO/E. 2.6 Determine whether SRB time in the IEAIPSxx member is being included in SRM service unit calculations to reflect total resources consumed by address spaces. 2.7 Determine whether serviceability level indication processing (SLIP) definition traps are being used in the COMMNDxx, IEACMDxx, or IEASLPxx member to suppress unnecessary system dumps for certain ABENDs (e.g., 222, 322, 522, 622). 2.8 Determine whether I/O appendages (listed in member IEAAPP00) have been made available for use by unauthorized tasks and, if so, review the appendages for integrity considerations. Determine "ownership" and usage (they may be obsolete). 3. Obtain a complete listing of all JES initialization parameters specified by the JES start-up procedure. 3.1 Determine the disposition of operator commands in JCL submitted with batch jobs (the system should ignore operator commands in batch JCL streams). 3.2 Determine whether checkpoint data set duplexing (or more recently dual copy) is being used for improved JES integrity. 3.3 Review all JES2 exists in effect for integrity considerations. III. Authorized Program Facility (APF) Administration 1. Determine whether the installation under review has promulgated integrity guidelines pertaining to the acquisition or development of programs running APF-authorized. 2. Using the appropriate CAATs software, produce the APF library analysis reports that show duplicate load modules and non-existent APF libraries. 2.1 Review the APF program universe for integrity considerations. Include all other exit routines (not previously reviewed above under the SMF and JES2 sections) such as TSO exits (i.e.,IKJEFF10, IKJEFF53, and IKJEFLD in IKJEFLA). 2.2 For loosely coupled CPU environments, determine if non-shared APF libraries are in synchronization regarding software release and maintenance levels. 3. Using the appropriate CAATs software, analyze the contents of the in-storage program properties table (PPT). This step is not possible beginning with MVS/SP 2.2 unless the audit software is allowed to run authorized since the PPT was then moved into fetch-protected storage. 3.1 Identify PPT entries for load modules which do not exist in the APF library environment. (The accidental or deliberate addition of a program to any APF library with a name matching any of the uninstalled PPT entries will automatically cause the program to be given sensitive properties, thereby possibly introducing an integrity or security exposure. 3.2 Determine whether special properties have been properly assigned. (Review program documentation to verify the need for any property assigned. Keep in mind that the bypass password property also means RACF and CA-Top Secret checking will be bypassed.) 4. Determine whether all APF libraries are protected from unauthorized update. (Changes to the contents of APF libraries should be strictly controlled - no individual should have standing authority to update an APF library on a production MVS system.) 5. Determine whether all APF libraries reside on permanently resident (i.e., non-mountable) disk volumes. IV. System Software Maintenance Activities 1. Using the appropriate CAATs software (or the AMBLIST service aid), determine whether modifications have been improperly made by identifying "NO IDNET" IDRs (identification records) for all load modules in several key system libraries including SYS1.NUCLEUS, SYS1.LINKLIB, SYS1.SVCLIB, SYS1.LPALIB, and selected installation - added APF libraries, 2. Using SMP, make a card image copy of the CDS (SMP4's control data set) or CSI (SMP/E's consolidation software inventory) for subsequent analysis by the PAS software package to determine the extent to which unresolved high-impact problems exist in the MVS system under review. Remember that PAS assumes all maintenance is performed under the exclusive control of SMP. If you determine that this is not the case, make a note of it in the audit report. 3. Determine the installation's system software maintenance practices regarding the application of periodic program update tape (PUT) from IBM and conduct of problem research. V. Security 1. Identify sensitive system data sets including all data sets named "SYS*.-", all "APF-authorized" libraries, and any other system - related data sets containing control parameters (e.g., JESPARMS) or system data (e.g., the SMF data sets). 2. Determine whether the access profiles for sensitive system data sets are appropriate for proper security. (Update privilege to critical system libraries should be very tightly controlled under strict change control procedures and should involve security review.) 3. Determine whether sensitive system utility programs are properly controlled. 4. Determine whether security software installation options seem appropriate, such as minimum password length, password change frequency, number of access attempts allowed, etc., and that the security system is in "abort" mode where unauthorized accesses to the system and resources are denied. 5. Determine whether security personnel are reviewing violation and logging reports regularly and are actively following up on potential security problems. 6. Determine whether tape bypass label (BLP) processing is adequately controlled. 7. Determine whether special security interfaces have been installed for certain system software program products (typically those which bypass standard MVS services).