OPS/MVS Stateman Security

[Anon Anon]

I am currently looking into ways to secure Stateman. What we have inadvertenly found is that because Stateman now intercepts the START and STOP commands and then reissues the proper commands the security for those proper commands is circumvented because the OPS user ID is now associated with the one issuing the commands. I would like to keep the functionality of the START and STOP rules to intercept commands but also would like to respect the authority we have defined to RACF. I do have some security rules in place and am currently working through exactly what they do as they were written before I got here so maybe I will find something but I wanted to ask the community for thoughts and suggestions. My first thought was to add a list of authorized users to the START and STOP rules but I am concerned that this may come under scrutiny from our security/audit folks so this is probably Plan Z. What methods have others used in securing Stateman?

[Anon Anon]

So after some reading and digging I found my answer. I decided to use OPSECURE() to check my RACF resources to see if a user was authorized to issue the start or stop commands. If the user is not authorized the function will return a RACF error and reject the command.

[Tyrone Lastoria]

Hi Travi,

OPSECURE() in the CMD rule/s for Start and Stop to check the commands issuers' authority is a recommended method to secure the managing of SSM resources, as for the MVS start/stop commands.  Is physical access to your MCS consoles secure and do you require a user to logon to MCS consoles?  If not you will have to account for this type of access.  Also, you may have to secure access to ADDRESS SQL/OPSQL via an OPS/MVS  )SEC SQL* rule, if you have users that know how to issue SQL instructions to update the desired state of an SSM resource.