I wouldn't allow a cics to submit jobs on behalf of the user. not as a copy to internal reader, nor by exec interface. I expect the jcl pass a change management process and be stored in a production jcl dataset. the formal and recommended way for jobs is to schedule them by a scheduler. all of the job scheduler products I know allow turning a condition on, including support for CICS transactions.
If the job depends on data supplied by the transaction, it can read it from a DB2 table, VSAM or any other data store. this way, multiple requesters with different requirements (aka sysin) can run. on successful end, the program can delete the entry from where it was read from. My two Israeli shekels. ITschak On Thu, Sep 5, 2019 at 3:35 PM Ambros, Thomas < [email protected]> wrote: > 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 <[email protected]> On Behalf > Of Lennie Dymoke-Bradshaw > Sent: Thursday, September 05, 2019 08:06 > To: [email protected] > 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 <[email protected]> On Behalf > Of ITschak Mugzach > Sent: 04 September 2019 19:33 > To: [email protected] > 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 <[email protected]> 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, [email protected], 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 [email protected] 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 [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to [email protected] 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:[email protected] with 'No Promotional > E-mails' in the > SUBJECT line. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] 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 [email protected] with the message: INFO IBM-MAIN
