My company is very security focused and this question has come up. How do you secure users issuing commands to CA-7 via CA-OPS? Specifically, the DEMAND command which would allow them to run a job in CA-7. Now, previously I ran into a situation where the SSMSTOP and SSMSTART rules created some issues because now anyone could issue a start or stop command against any task that was SSM managed even though the couldn't before. This was because after the rule processed the command, it updated the states in the table and then it was all CA-OPS user id. To fix it I added a security check before the rule updated the states so that only those authorized to start and stop the task in RACF were allowed to in CA-OPS. This is the same situation we would like to avoid with CA-7.
There are two methods to issue commands to CA-7, both of which are available to us currently. There is the function OPSCA7() and the environment ADDRESS CA7. Based on my reading, it appears that the only place these two constructs are valid is within OPS/REXX which implies that in order to use them, you need to at least be able to edit the RULES/REXX (maybe just the REXX). This means that anyone who can get to that code could use a CA-7 command. This is the only security I can find and it doesn't give me a good feeling. Are there any events or resources we could use to lock this down using RACF? How do others go about securing pieces like this?
Focusing on your initial concern ‘anyone can get that code' and write and execute an OPS/MVS rule or OPS/REXX pgm to do xxxxxxx – this can be addressed by ‘locking up’ the gun cabinet. R/W access to only the automation team for your RULES and REXX pgms, SECurity rules to secure who can enable rules and execute OPS/REXX pgms, and based on OSF security parms, potentially a )CMD osfchar rule with logic to allow/disallow the issuance of a command directed to your OPS servers via the OSFCHAR parm. Another effective means and my favorite is the Baseball Bat approach. Using the OPSLOG ,quickly identify the intruders and proceed to their cube with a baseball bat. A few times of that approach would more than likely resolve all future issues.
On the issue with securing logic within rules that ‘you’ created that perform some work that you want to secure (specifically CMD rules) – Directly incorporate logic to allow/disallow (allow to process logic or RETURN ‘REJECT’) the user that triggered the rule and/or utilize the OPSECURE() to determine if the user has access to some specified generalized resource defined within your security package. Based on the returned resource access from the OPSECURE(), determine if the rule logic should performed or not. Specific to CA7 - you can setup CA7 to force that all external CA7 commands require a LOGON command. I'm sure this info is somewhere in CA7 documentation.
I'm sure the user community may have other security methods here that they can share.
What Dave said. Additionally, if you have no procedures needing anybody to run any of your rexx pgms on servers manually, either from a console or any other (rexx) program, consider setting parameter OSFTSO to NO. That will effectively prevent that (Also make sure only authorized people can change this parm)
Marcel van Ek