At a minimum, I think an IT auditor would require a method of joining who owns one of these id's when, so the mainframe logs (and any other system) can know the real "who" did something. What about long running tasks? Can I start a session that outlives my lease on the ID? I bet my task lives on, but blame goes elsewhere.... Thinking like a bad guy, start a task with 24 hours of low use, then do bad things.
Sounds like a job for an ELK stack :-) Has anyone ever tried sending mainframe things like SMF to ELK (elasticsearch/logstash/kibana, that acronym may not be well known here :-)? Len Rugen Metrics and Automation – umdoitmetr...@missouri.edu -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of william janulin Sent: Tuesday, November 22, 2016 12:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe systems programmer ID 'vaulting' Sounds like the brainchild of this project came from some management type that has no clue about mainframes. Usually ideas like that come from those types. On Tuesday, November 22, 2016 1:37 PM, Bigendian Smalls <mainfr...@bigendiansmalls.com> wrote: This is something I hadn’t heard much about, but a couple questions come to mind - for anyone who has thought about or implemented this: 1) If you have a pool of IDs, then are you losing granularity with which you might want to assign privelages? Meaning you now have to have IDs that have exactly the same permissions - if they are user-agnostic (among some class of users obviously, like DEVs or SYSPROGs or whatever) - Seems like that is back to the old, “Create a new id. What perms to give him? Dunno, just build it like Chad’s, they have the same job.” Which has kind of gone out of style for obvious reasons (though still prevelant in practice). 2) How does tracing back activity go? If Gil & Charles decide to collude and do horrible things, I see this on SMF or whatever I’m using to monitor these guys, then I have to go back to another system of record to see who had those IDs during what time (hoping that all that data is up to date, accurate and available) ? 3) Is this a band-aid, where having MF-RACF (or whichever ESM) passphrases / 2 factor auth would seemingly be preferable, but for whatever reason people can’t/won’t do this? 4) I get the value for privileged IDs that say a production support dev or infrastructure team that’s 2nd level, or oncall might not need everyday, but might need in a “break glass” scenario; but day to day - would it make sense? Certainly if the alternative is the standard password character pool and it’s 30 year old lack of entropy, then anything is an improvement - but given the headaches in doing a huge new process / tooling - I wonder if time wouldn’t be better spent updating the ESM settings + 2 factor? Chad > On Nov 22, 2016, at 10:52 AM, James Peddycord <j...@ntrs.com> wrote: > > 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 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 ---------------------------------------------------------------------- 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
