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
<[email protected]> 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 <[email protected]> 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 [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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
