If I had to guess I'd say that it is the CICS region that is permitted to submit jobs with USER=<region> in the absence of any evident surrogate profiles.
However one still needs to have a chain of logging events where one can tell which job was submitted from which CICS transaction running under which user context to maintain the whole non-repudiation thing. That's the piece I'd be a little more concerned with establishing and I think it'd be a little harder to manage this in an unalterable form even if I had it given that I would need to tie a few different things together to do it. Thomas Ambros zEnterprise Operating Systems -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Lennie Dymoke-Bradshaw Sent: Thursday, September 05, 2019 08:06 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Submitting batch if you don't have TSO Bob, I think ITschak's words are good advice. However, I am concerned at your statement, "The problem, of course, is that if I'm authorized to submit jobs with USER=<region> on the JOB card then I can submit ~any~ such job, to do anything I want that the region can do." The CICS transaction runs under the security context of the region userid. Are the CICS users explicitly authorised to do job submission? Are security checks made against the requester of the CICS transaction? Is the CICS user involved at all? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of ITschak Mugzach Sent: 04 September 2019 19:33 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Submitting batch if you don't have TSO Bob, few comments: 1. You don't need to specify user= in the job card. any job submitted under CICS without propagation control, will be assigned the CICS userid. 2. can cics end users manipulate the jcl they are submitting or it is just submitted by the transaction? I hope they can't! 3. You can control this facility with the PROPCNTL resource class class (all esms). 4. If STIG framework is of relevant to you organization, submitting jobs under the CICS user-id is a medium level risk. 5. management forgot to mention "currently". what happens when a CICS user will be assigned a TSO segment? 6. FTP is a potential security risk, however, the end-user must have an OMVS segment. go guess who has one and why. 7. You don't leave open doors. Someone may use it to enter in. (see the swiss cheese model). ITschak On Wed, Sep 4, 2019 at 9:06 PM Bob Bridges <robhbrid...@gmail.com> wrote: > Not sure where to ask this, but I've wondered about it off and on for > a while and it's past time I asked. I'm responsible for security at a > mainframe shop where they use a lot of CICS. There are CICS > transactions that fire off batch jobs; the way this place handles it > is to submit the job under the authority of the CICS region ID > (USER=<region> on the JOB card), and give each user of such a transaction the > necessary authority. > > This gives me the screaming heeby-jeebies, but when I complain about > it I get little support back. The problem, of course, is that if I'm > authorized to submit jobs with USER=<region> on the JOB card then I > can submit ~any~ such job, to do anything I want that the region can > do. (And of course any installation that's careless about letting > folks have that authority is even more careless about what their CICS > regions can do.) > > One argument management offers in mitigation is that most of these > CICS users don't have TSO, so they haven't the ability to submit batch jobs. > Off-hand I can't contradict them, but I'm skeptical. I'm thinking > there's probably a way and I just don't know about it. Can anyone > confirm? If I were a CICS user without the ability to log on to TSO, > could I still submit a batch job somehow? > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* You know you've had too much coffee when.... > Juan Valdez names his donkey after you. > You've worn out the handle on your favorite coffee mug. > Your eyes stay open when you sneeze. */ > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in the SUBJECT line. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
