Expire passwords on mainframe batch ACID

[Tom Breuer]

Hello,

Our security team has asked us to expire passwords on our mainframe batch ACIDs and change them regularly. This is a new process for us. Currently, our JCL doesn't have a password field for our batch ACIDs. What do others do to secure their mainframe batch ACIDs with respect to password management? I cannot find anything using Google or in reading ~8 pages in the CA-TSS forum.

Thanks,

Tom

[Joseph Porto]

Tom,

 

Most site have a password expiration set globally. So after the set number of days, a password will expired forcing the user to change their password they attempt to signon after the password has expired.

 

Since these acids are used for batch jobs and not a user acid, it would be probably best that a TSS admin change the password s before the password expiration interval is hit. Otherwise, the operator will be prompted to change the password when they run the batch job and the password is expired.

 

Regards,

 

Joseph Porto - CA Level 1 Support

[Tom Breuer]

Thanks JoePorto,

Agreed. However, due to the number of these ACIDs that we have, we figure it will required at least one full time person to do this work, perhaps more. Plus, we're not sure where in the JCL (or other location) to put the password to make these work. If we add the password to the JCL, everyone can see them (we store JCL in Endevor)... that defeats the purpose of having passwords!

Tom

[Josef Thaler]

Hello Tom,

I'd be interested in the intention of the security team! Or, in other words, what kind of security exposure should be counteracted ?

Kind regards,

Josef  

[Tom Breuer]

Hi josef.thaler,

These ACIDs don't (or aren't supposed to have) CICS access. So I am not sure what the security hole is. However, our IT Security folks see one. Further, they see this work as implementing a fix for CSEC Top Ten Security Actions #3. This is why I am trying to figure out what I am missing and what the rest of the world does with their batch ACIDs. I could not find anything via a web search so I am wondering what I am missing.

Thanks,

Tom

[Josef Thaler]

Hello Tom,

 

many thanks for the interesting link.

 

I believe, the intention of enforced periodically password-changes is to counteract situations, that when the password is known by an authorized person, and this person leaves the company, or an unauthorized person gets knowledge of the known password, etc .... isn't it?

 

When the job-statements in your JCL in Endevor

(1) do neither specify USER= nor PASSWORD=,

--> then the user of the batchjob is inherited from the submitting user, who is subject to expiring passwords.  

(2) specifiy only USER=batchusr and no PASSWORD= 

--> then the submitting user needs to be permitted to ACID(batchusr) and does not need to know the password of 'batchusr', and the batchjob executes unter security of batchusr

(3) specify both USER=batchusr and PASSWORD=batchpwd in clear text

--> you have an security exposure, because everybody who is allowed to read this JCL gets knowledge of the password of that userid which then might be used also in other contexts.

(4) specify "softly" both USER=&batchusr& and PASSWORD=&batchpwd& and those placeholders are replaced by the submitter (for example the job-scheduler) from an encrypted source.

--> you have a centralized place (the encrypted source) where the passwords are to be maintained by a security person in power.

 

If you are working with option (2) - specify USER= but not PASSWORD= - nobody needs to know the password and a randomized password can be set once and can be changed at any time again.

Maybe this fact, that nobody has to know the randomized password, satisfies the need resp. intention of your security team. 

 

Kind regards,

Josef      

[Tom Breuer]

Hi josef.thaler,

Yes, our IT Security believes that either insiders or former insiders will exploit this and use these accounts maliciously. None of these ACIDs have CICS access so many of us are scratching our heads and wondering how these ACIDs can be used maliciously. We use a form of one of your suggestions.

 

I am curious about #4. To use #4, it looks like our command centre folks would have to manually key ACID and passwords into JCL. Wouldn't that create a segregation of duties risk if they could update and run JCL? Or, is there an automated way to do this (e.g. a PAM tool working with TSS)?

 

I really appreciate your quick responses. They help me build a case for our next steps.

Tom

[Josef Thaler]

Hello Tom,

If your security administrator sets a randomized password to the batch acid and tells nobody this password, the batch acid can only be used by surrogate user, who have permitted ACID(batchacid). And the password could be changed at any time and every day, because it is not specified in the JCL.

ad #4: I could envision, that a job scheduler has an encryptes password store for the batch acids, for which it submits jobs. At the time of submit, the scheduler supplements the jobcard. I do not know about such a solution out of the box. - This approach only avoids passwords to be coded directly in the jcl which I consider as a security exposure.

... hope this helps, 

kind regards, Josef

[Tom Breuer]

That helps a lot. Thanks for your help, josef.thaler. Now I need to convince IT Security...