How to secure the OPS/MVS OPSVIEW ISPF Interface

Products

• OPS/MVS Event Management & Automation

Issue/Introduction

How to secure the OPS/MVS OPSVIEW ISPF Interface?

 

Environment

 

Resolution

There are two approaches to securing OPS/MVS provided functionality.

• Use an external security product, such as ACF2 or Top Secret, to secure access to OPS/MVS datasets. This method is usually an "all or nothing" type of security: the end user can either use or not use all of the product functionality.
• Use the OPS/MVS security functionality, which can be based on AOF rules or an assembler language exit. This method can produce a range of security implementations from simplistic to a very robust environment that permits varying levels of access.

The OPSVIEW ISPF application is primarily comprised of REXX execs that issue various OPS/REXX functions, ADDRESS environments, and command processors. The security events that can be intercepted by rules are created whenever these OPS/REXX language components are executed. For example, if a user invokes the OPSVIEW option to look at global variables (option 4.8), the code that executes issues the OPSVALUE REXX function to retrieve global variables, which then causes a global variable security event to be created.

The next question is: what security events are generated for each OPSVIEW option? This question can be answered by accessing each OPSVIEW option and observing the security events that are produced in the OPSLOG. This test requires that the parameter BROWSESEC to be set to ON, so that these security events can be seen in the OPSLOG.

Once you know which specific security events are created for the OPSVIEW options you wish to secure, you can begin building SEC (security) rules to intercept events and make determinations whether to allow the events to proceed or reject the requests. To help decide whether to allow the request, you can interrogate several event-related variables that contain more specific information about the request. For example, the user ID performing the action is contained in the SEC.OPAUUSID variable. A listing of all the available event variables is contained in the AOF RULES User Guide. These same event variables are also available to the provided assembler security exit.

Following are two example security rules for securing OPSVIEW option 4.8. One is simplistic and the other is a bit more robust:

Example 1:

)SEC OPSGLOBAL*
)PROC
if SEC.OPAUUSID = 'USER1' then return 'ACCEPT' 

This example does a check of the user ID that is performing the global variable access and allows the request if the ID matches. This type of approach requires that user IDs be hard-coded somewhere the rule can access and thus verify.

Example 2:

)SEC OPSGLOBAL*
)PROC
if OPSECURE('R','OPS','OKTOACCESS','R') <> 'ALLOW' then
  return 'REJECT'
if SEC.AUGLRQTY = 'U' then 
  do
    if OPSECURE('R','OPS','OKTOUPDATE','R') <> 'ALLOW' then
      return 'REJECT'
    else 
      return 'ACCEPT'
  end
return 'ACCEPT' 

This example makes use of an OPS/REXX function, OPSECURE, which interfaces with an external security package. The OPSECURE sub function used in the example checks the user ID that caused the security event against a predefined resource in your security package. The second and third operands in the OPSECURE function, called resource type and name, need to be defined in your external security package and have user IDs or groups assigned for this procedure to work. This example also shows the ability to allow some users to access or browse global variables, but not permit the same users to update any global variables by checking the type of action they are performing. This limitation is reflected in the environmental variable, SEC.AUGLRQTY.

There are a few additional items to be aware of while developing security rules for the OPSVIEW applications:

• There may be multiple security events occurring when accessing an OPSVIEW option. For example, the code may execute an OPSPARM function to retrieve information needed to populate fields in the panel.
• Even though the emphasis for this article has been on OPSVIEW access, security rules also apply to OPS/REXX execs executing 'outside' the OPSVIEW application. In most cases, the same access requirements to the OPSVIEW panels apply to users attempting to use OPS/REXX functionality outside of OPSVIEW.
• You can (and should) use the SECURITYRULESET parameter to designate a particular AOF rule set as the only rule set in which security rules can be enabled. This feature can be combined with external security to permit only designated users the ability to control security rules within OPS/MVS.