OPS/MVS - Identifying product internal security exposures for compliance

Products

• OPS/MVS Event Management & Automation

Issue/Introduction

Customer is tasked with identifying product internal security exposures for compliance across multiple vendors. 

Summary:

1) How to determine whether OPS/MVS has internal security enabled completely or partially? 
   For example, maybe the product only uses internal security for determining which panels are displayed and/or which product commands can be issued.

2) Is the internal security capability equivalent to the external security capability - i.e. can you do all the same things with either?

3) Can the internal security provide capabilities that could be considered as privileged access?

4) What is recommended regarding changing security from internal to external security? 

Environment

Release : 14.0

Resolution

For this case, it’s recommended to read through the document section about Securing from the link below:

https://techdocs.broadcom.com/us/en/ca-mainframe-software/automation/ca-ops-mvs-event-management-and-automation/14-0/securing.html

 

• How do they determine whether [product] has internal security enabled completely or partially? This would likely require a doc request from us as to what combination of parms and tables are set up which is fine. For example, maybe the product only uses internal security for determining which panels are displayed and/or which product commands can be issued.

A:  For OPS/MVS, internal security means AOF security rules. A security rule (SEC) responds to a security event for protecting the many OPS/MVS facilities.

 

To determine if internal security has been enabled completely or partially, user should check the full list of possible event specifier of SEC rules as in the section of “)SEC -- Event Specifier of SEC Rules” from the link below:

https://techdocs.broadcom.com/us/en/ca-mainframe-software/automation/ca-ops-mvs-event-management-and-automation/14-0/using/using-automated-operations-facility-aof-rules/coding-each-aof-rule-type/security-rules.html

 

2) Is the internal security capability equivalent to the external security capability - i.e. can you do all the same things with either?

A: No. OPS/MVS is not used to secure itself. To secure OPS/MVS, it needs an external security products such as Top Secret, ACF2, or RACF.

When parameter EXTSECURITY=ON, AOF security rules (or the OPUSEX security user exit) can still be used as a supplement to external security rules to refine access decisions. AOF rules can be used to reject security events at a more granular level than can be done by using external security rules alone. For example, external security rules can allow access to all OPS/MVS parameters or all OPS/REXX global variables, and AOF security rules can limit access to only specific parameters or global variables.

3) Can the internal security provide capabilities that could be considered as privileged access?

A:  It depends if external security is on. The OPAU variable SEC.OPAUUSID may be used for granting privileged access.

When parameter EXTSECURITY=ON, the privileged access should be granted by the external security rule; while an AOF security rule can further grant or reject the privilege from the external security rule.

When parameter EXTSECURITY=OFF, AOF security rule is the only one to grant or reject the access.

4) Do we have a recommendation to change internal to external security? 

A: No. Internal security is also utilized for its purpose. We recommend to use both external security and internal security. They work together in the way as described below: