A Security Review of MVS/RACF: Part 2 Kurt Meiser Payoff

Transcription

1 A Security Review of MVS/RACF: Part 2 Kurt Meiser Payoff An efficient and effective security review of an MVS/RACF system depends on several factors. Reviewers must use a well-considered methodology. They must be appropriately trained and understand how to evaluate an organization's security management, its MVS/RACF system integrity controls, and the security of its applications. This article discusses the last four of these factors. Problems Addressed The first part of this article, A Security Review of MVS/RACF: Part 1 ( ), describes the controls IBM Corp.'s Resource Access Control Facility (RACF) provides when added onto its MVS operating system, as well as a methodology for evaluating the security on an MVS/RACF system. The second part of this article describes the skills that security reviewers should possess to examine these systems and some considerations they should remember when reviewing the different control layers of MVS/RACF systems. Skills Requirements A security review is a team sport, and building the right team is a key factor for success. The audit team should have a balance of the following skills, personal preferences, and experiences: General versus specific security review skills. A procedural versus technical orientation focus. System knowledge versus application knowledge. General skill and experience in security review is, of course, a basic requirement for the planning and management of a security review. Exhibit 1 shows different review areas, and the subsequent paragraphs describe the skills required to perform a controls assessment. Skill Matrix General versus Specific Skills. Security controls are typically built on a system of policies, procedures, and standards that can be assessed by auditors with general controls experience. However, some system and application controls require specific knowledge. For example, an organization's MVS/RACF security standards can be effectively reviewed only by a reviewer with a solid MVS/RACF background. Procedural versus Technical Focus. Solid technical skills and experience are necessary. However, it is easier to teach a technical person the necessary procedural skills than to teach a generalist the technical knowledge required for a sound technical assessment. Technical skills are required for both system and application audits. System versus Application Knowledge.

2 It is usually a primary goal of a security review to assess application controls; however, application controls depend on system controls. Application audit findings therefore are reliable only if a recent system audit has established adequate system controls or if fundamental system controls are assessed at the same time. Staffing Considerations The high number of technical platforms can make it difficult even for large organizations to have the right level of technical skills available at all times. Consequently, it is often a good business decision to hire consultants in areas in which standard systems and applications require highly specialized technical skills and to have permanent staff focus on controls unique to the organization. For example, the security review of MVS/RACF systems and the Canadian Independent Computing Services Association application environments may be more effective and efficient if local reviewers are supported by specialists who have solid technical backgrounds and experience from a large number of similar audits. An extreme example is a penetration test, an approach that is rarely cost-justifiable without external specialists. Similarly, the audit of a standard application package can greatly benefit from the participation of a specialist for the particular package. In contrast, permanent, local staff can probably best assess controls in nonstandard, locally developed applications and application controls. Internal auditors are also best suited to make final judgments on questions of conflict, interest, and necessary privileges in application and system audits. In summary, the ideal review team consists of a mix of technical specialists for the relevant products and platforms and auditors familiar with the organization and its specific applications, structures, and policies. Exhibit 2 illustrates this mix. Optimal Staffing Mix Security Review Program Considerations This section discusses some considerations regarding security review programs for the following control layers: Security management. MVS/RACF system integrity controls. Application controls. Security Management Some important aspects of security management are addressed in the following paragraphs. They include security policy, security standards, and security administration and audit. Security Policy. An organization's security policy is a set of high-level security rules and guidelines pronounced by executive management. The absence of an adequate policy often indicates management's lack of interest in and support of coherent controls. If a security policy is not

3 available, a reviewer will use a personal model of controls instead. This often leads to unnecessary disagreements between reviewers and reviewees. Security Standards. Security standards are the technical interpretation of a security policy. They represent the technical plan according to which controls are built and maintained and the yardstick for security reviews. Organizations with solid security standards have effective computer controls and few disagreements among support staff, security administrators, and auditors. Security Administration and Audit. A review of security administration typically addresses organizational structures and administrative procedures. Frequently, security administration independence (from system support, for example) is regarded as more important than technical competence and experience. In one organization, Resource Access Control Facility administration responsibility was transferred, in response to independence issues raised in an audit, from system support to plant security an organization experienced in dealing with physical security rather than software security. As a result, RACF security degraded. It is better to accept a slight lack in segregation of duties than incompetent security administration. Audit, of course, should be independent of both functions. Status and event monitoring are important aspects of security administration. Security administration should perform these tasks, and the audit should ensure they have been performed consistently throughout the audit period. MVS/RACF System Integrity Controls System integrity controls can be categorized as follows: Security configuration and system protection. Security implementation options. System and security authorization and privileges. Critical system functions. System extensions and modifications. Host-based network controls. The following paragraphs address each category and its major control considerations. Security Configuration and System Protection. This category addresses the environment in which the security system to be audited exists. The security configuration should match the system configuration so that all resources are protected by a unique set of rules. If disks are shared among different operating systems, the RACF data base should also be shared. A test system, for instance, that shares disk volumes with a production system, but has its own RACF data base (i.e., does not share the production RACF data base), may expose production data. If disks are shareable, they will be shared, even if the security policy calls for separation.

4 System Protection. System resources must be RACF-protected, and access must be restricted to system support staff. Public access to system data sets is rarely required, because the system provides implicit access to most commonly needed functions. Recovery and Performance. Recoverability and acceptable performance of the security function are important ingredients of a security implementation. Good recovery requires that the Resource Access Control Facility option to maintain an active backup data set be used and that periodic backup copies be taken. RACF performance management makes use of options such as resident RACF blocks, resident profiles, and adequate global table entries. Security Implementation Options. These are the global settings representing security policy and governing the overall shape of the access control system. Protection Mode. The protection mode is determined by a number of fundamental settings, such as: PROTECTALL. This is a default protection; it ensures that all data sets areracfprotected. BATCHALLRACF. All batch jobs must have a valid RACF-defined user ID. TAPEDSN. Data on tape is protected at the data set level. It is also determined by implementation decisions forcing RACF registration of all TSO and Canadian Independent Computing Services Association users. Active RACF interfaces of various system products are part of the overall protection mode as well. Protection Options. Protection options are other RACF settings that determine the strength of security controls. They include: Password control parameters, such as minimum length and automatic expiration. Profile styles, generic or discrete group, or entity profiles. Erase-on-scratch, the erasure of residual data. Security labels, the use of security classification controls. Some of these options may fall into the category of advanced controls, in contrast to baseline controls, (e.g., erase-on-scratch or mandatory access control through security labels). Logging and Recording. Another part of security implementation options is related to security event recording. These options determine the amount of RACF logging for authorized access or unauthorized access attempts as specified by data owners and their administrators or as set

5 by auditors individually or globally. Logging of privileged activities (e.g., SAUDIT, OPERAUDIT) and real-time notification definitions are other examples of the logging and recording function. System and Security Authorization and Privileges. This category addresses special system and user privileges that must be assigned and monitored carefully. Authorized Programs. The Authorized Program Facility is an external interface through which the installation defines additional system program libraries. The protection of these libraries and adequate access control to them are a major security concern. All libraries must be RACF protected; no public update access should be granted. Specific write access must be limited, and the contents of authorized program libraries must be adequately managed. Special Properties. Special privileges can be assigned to authorized programs through such tables as the Program Properties Table and the started procedures table. These tables must be properly designed and maintained. User Privileges. Privileges to administer RACF (RACF's SPECIALattribute), to perform global system maintenance tasks (RACF'sOPERATIONS attribute), and to monitor privileged users (RACF'sAUDITOR attribute) can be assigned in RACF. These privileges must be assigned restrictively to users with a true need only; their scope should be limited and, when possible, more specific controls should be used instead (e.g., DASDVOL authorization and system managed storage controls rather than OPERATIONS). Critical System Functions. In this category, critical but necessary functions are covered. They must be restricted to a limited number of trusted users. Command Authorities. MVS and Job Entry Subsystem commands can technically be issued from many software environments; for example TSO, IBM's Netview, Candle's Omegamon, and batch jobs. Controls can be implemented through the Resource Access Control Facility OPERCMDSand CONSOLEclasses. If these controls are not used, all environments from which commands can be issued must be secured and reviewed individually. Started Procedures. The started procedures environment must be secured in a way that unauthorized users cannot alter or abuse existing procedures or implant their own to gain unauthorized access or privileges. The security review must address controls overprocedure Libraries and the design of the RACF started procedures table. This table should assign individual user IDs, which have no operations attribute, and contain the privileged or trusted attributes only when they are required by vendor code and are documented accordingly. Unknown started procedures should not be given privileges.

6 Critical Programs and Functions. Programs containing functions to alter the system or security environment must be restricted. Some need to be controlled globally through Resource Access Control Facility program protection, others have built-in granular controls that should be interfaced with RACF. Examples of critical programs that should have program protection are: Programs performing volume initialization. Programs performing backup or restore operations. Programs performing general file manipulation (e.g., IBM's Superzap). Examples of critical programs to be secured by means of a RACF interface are Omegamon, Netview, and System Display and Spool Facility. System Extensions and Modifications. Interfaces to extend and modify standard MVS and RACF processing are addressed in this category. Installation Exits. Installation exits can change the results of system processing. Some of them have security and integrity implications, for example: All RACF exits. Many job entry subsystem exits. Most system management facilities exits. Most TSO exits. Some MVS exits. They should be well documented as to purpose, function, and origin and reviewed for coding in agreement with general IBM guidelines and individual coding rules established by the organization. User Supervisor Calls. The same rules apply to user supervisor calls (SVCs). They are a major area of observed integrity exposures. Faulty Switched Virtual Circuit fall into two categories: Those designed to provide program authorization or security bypass, and trap doors. (They often have pseudo-security features that can be defeated.) Those written in violation of SVCs coding rules. (They can be abused to perform authorization functions they were not designed for.) When source code is not available or code review is not practical, vendor integrity statements should be obtained for SVCs delivered as part of third-party products.

7 System Modifications. These modifications are difficult if not impossible to detect unless they are implemented openly (i.e., throughsystem Modification Program or Modified Link Pack Area techniques). To a limited degree, generating a check sum for modules or libraries to detect unauthorized modifications can be helpful. Host-Based Network Controls. This category addresses some controls that can be used to prevent importing weaknesses from a network or other hosts on the network. VTAM Application Protection. RACF provides protection of Virtual Telecommunications Access Method applications to prevent the implanting of bogus online applications that might, for example, be used to capture passwords. Network Job Entry and Remote Job Entry Controls. Remote job entry and particularly Network Job Entry can be implemented to accept jobs without proper local authentication. This acceptance is often based on trust in another system on the network that may not always be justified. An audit of these areas may be a necessary part of a system review. Secondary Authentication. User authentication, particularly in a network environment, can be strengthened through the use of secondary authentication. Similar to most software security systems, Resource Access Control Facility uses password checking as its primary authentication mechanism. Secondary authentication can be implemented through tokens and authentication devices that the authorized user has or uses to sign on. Application Controls A methodology for reviewing application controls should address the following categories: Security design The authentication of users, the transaction environment, and the design of rules. Security administration The administration of users and protection of resources. Production control The confinement of users in their designated environment, the separation of test and production, and security monitoring and auditing. These generic categories apply to all application environments; however, they may contain slightly different controls for different areas, such as TSO and batch or Canadian Independent Computing Services Association production environments. Security Design. The overall security design should be evaluated before the details of application protection. Sound security design is a prerequisite for security, and assessing the design helps in the planning and directing of subsequent tests.

8 Naming Conventions. Key design criteria are naming conventions (for users, groups, data sets, transactions and any other RACF-protected resources) and the RACF group design. Poor naming conventions usually increase the number of necessary Resource Access Control Facility definitions and make them unnecessarily volatile. This is particularly true for pooly designedracf groups. User Authentication. Full RACF user authentication is another important element of good security. The presence of undefined users and their authentication outside RACF can significantly weaken the overall security of an application. The reviewer must assess the potential exposure from such users. When users are authenticated byresource Access Control Facility, RACF IDs should be used for all decisions within applications. Resource Control. Full RACF control of the transaction environments represents sound design. Protection concepts allowing for unprotected resources are always prone to errors. For environments without default protection (i.e., Internet Multicasting Service), catch-all RACF profiles should be used to prevent access to unprotected entities. When default protection is not implemented, the reviewer must evaluate potential exposures from unprotected resources in addition to assessing access rules for protected ones. The design of rules (e.g., discrete, generic, group profiles) is also assessed. Security Administration. An application's security administration is evaluated to determine whether segregation of duties has been implemented adequately and whether least-necessary privileges have been assigned. Using RACF tools makes these evaluations effective and efficient. For example, Consul/RACF provides reports on the scope of a user's authority. This report contains all access that a user may have through: Public access such as Universal Access, ID(*), Global Table, and Warn Mode. Explicit access list entries for the user's ID or any group connection. Implicit access through profile ownership. User Administration. The user administration analysis focuses on the validity and integrity of the user definitions and tests for invalid but active IDs, inactive users, and unjustified access and use privileges. When user definitions are maintained outside RACF, the proper synchronization of the definitions is checked. Resource Protection. The analysis of RACF rules should check for adequate public access universal access and ID(*), specific access, and constrained access. It should be performed from two angles, from the perspective of the user and of resource protection. In addition, potential discrepancies must be identified (e.g., conflicting access rules in RACF profiles and the global table). An important protection element to be reviewed is the RACF audit option, the profile option controlling the creation of an audit trail.

9 Production Control. Production controls are designed to confine users to certain execution environments, to separate test and production activities, and to verify that production was properly executed and completed. User Confinement. The reviewer should verify controls that prevent users from breaking out of their designated environment. Typical examples are Canadian Independent Computing Services Association users who manage to submit batch jobs that inherit the (usually much higher) authorization of the Canadian Independent Computing Services Association production region or users of TSO-based applications who successfully use the attention key to terminate current operations and gain full TSO capabilities. Separation Test and Production. The security review should determine how effectively test and production environments are separated. Programmers frequently have access to production programs and data, and production jobs call programs from development libraries. It is necessary to assess change management procedures and the RACF definitions that enforce them. Monitoring. The protection status of production resources and the audit trails generated while they are accessed and used are important monitoring activities. The reviewer should assess the completeness and effectiveness of monitoring during the security review. Recommended Course of Action MVS/RACF security reviews can be effective and efficient if the following conditions are met. Security reviewers should possess the proper mix of technical skills and professional experience, and they must work within the framework of a sound methodology. system integrity should be assessed as the basis for application security, and technical assessment must take priority over procedural tests. Finally, reasonable security standards must be in place or be adopted during the security review. This article describes how to meet many of these conditions. Those it does not cover are explained in its companion, A Security Review of MVS/RACF: Part 1 ( ). Author Biographies Kurt Meiser Kurt H. Meiser is director of ITSS International, Inc., a consulting firm based in Poughkeepsie NY that specializes in computer security. Previously, Meiser was a manager at Coopers & Lybrand in New York for six years, with responsibility for design, development, and security of information technology security services. Before that he was systems engineer for IBM Corp. for 22 years, with emphasis of MVS and RACF integrity and security.

10

11