This is pretty close to how we operate too. While we are not yet to the vaulting stage for the god ID's. They are working hard to push everything we do in the PROD environment into a Change record. Things that used to fall into "systems administration" gray area.
In the past, if we had to stand up an new CICS region destined to be PROD, we just did the work, tested it, and when ready, put in a change record officially "dubbing" it prod, and anything done to it thereafter required a change record. Now they want to include the act of building the new instance a prod change. And of course because it's a prod change, they want to banish the work to Sunday 2AM-5AM. There isn't a lot of logical thinking going on in some of these risk/audit area's. _________________________________________________________________ Dave Jousma Manager Mainframe Engineering, Assistant Vice President [email protected] 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Tony Thigpen Sent: Tuesday, November 22, 2016 1:44 PM To: [email protected] Subject: Re: Mainframe systems programmer ID 'vaulting' As usual, some pc based person only thinks of the way their world works. I have been though multiple audits at multiple companies where they accepted that: 1) System programmers had two logons. One "normal" and one "higher". The "normal" userid still had some privileged access, but nothing like the "higher" userid which had basically unlimited access. 2) Additional audit trails were created for the "higher" userid. Both that fact that they logged on and what they did. 3) The systems programmers split their libraries and work processes so that they only used the "higher" userid when really necessary. The fact was that we had to negotiate what was considered "daily" work and what was considered "special" work. This took a bit of time and was refined over time. A lot of the decisions revolved around READ-ONLY vs UPDATE rights on many of the libraries. Also, the security rules were different depending on which LPAR or Guest we were logged on to. Our normal userid could do everything on the systems programmer test LPAR. On the Development LPAR, it could do most everything. Our real limits were on the production LPARs. That being said, I think you are going to have to also go down the same road where you split your work processes and libraries into normal daily stuff and "special" stuff. It will take you a while to get into the mindset, but in the end you will find that it worth it. It will take a lot of negotiating, but it Since the first place where I was forced into this arrangement, I have implemented it at other locations. Yes, the systems programmers thought it was terrible at first, but once they got used to it, they realized that it sometimes saved their bacon. (Think "SHUTDOWN" under VM!) They had to learn to think: Which hat am I wearing right now? A limited systems programmer hat or the mainframe "god" hat. If you get your workloads split correctly, you may not need to use a vaulted userid as often. Tony Thigpen James Peddycord wrote on 11/22/2016 11:52 AM: > NTAC:3NS-20 > Our company is undergoing a project to 'protect privileged access' by using a > password vaulting product. We have been doing this for quite some time for > applications teams who require higher levels of access to production datasets > for problem resolution, installs, etc. > The way it works is that a pool of logonids is created, along with an AD > group that allows the appropriate applications folks to be able to 'check > out' one of these pooled logonids for 24 hours via a web interface. The web > interface uses the users lan password plus their secure key passcode and > phrase to validate their identity. > The project has now included Windows and Unix server admins, but instead of a > pooled logonid these users have separate logonids with admin access and they > 'check out' their own individual administrator logonid. > Now the project has moved into the mainframe systems programmer space. So far > we have used the 'privileges' on the logonid records as defined by our > security product to limit this vaulting. Users with 'security' access must > check out logonids from the vault. Users with the non-cncl privilege are next. > During project discussions it has been brought up that the systems > programmers, with their access to SYS1 datasets and operator commands, are > privileged users by nature, and that eventually they are going to want to > vault this access. We (the systems programmers) are strongly against this. > It looks like at some point we will lose our battle and our access to the > mainframe will be vaulted, meaning my entire team will need to check a > logonid out of the password vault every morning before starting work. Our > main argument now is that we do not want these logonids to be generic, pooled > logonids, we want them to be basically the same as our own logonids so that > we can see who did what by using the mainframe's built in logging (SMF data, > ISPF stats, etc...). > > My questions are, are other companies using password vaulting or other > multi-level authentication for mainframe systems programmer access? > What else could we use in our argument against using generic, pooled logonids? > > Thanks in advance! > > Jim > > ---------------------------------------------------------------------- > 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 e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
