Jim - You just hit my ballpark
 
We have tried out CA and CyberArk.  We opted for CyberArk, however they have 
absolutely not idea what TN3270 is.  CyberArk has attempted, to write their own 
TN3270 using open Source and its a disaster.  There was a call today with 
CyberArk and they were told to get away from Open Source and/or the "Not 
written here" philosophy and give use a way to use Reflections inside CyberArk.
 
CyberArk cures the "'protect privileged access' but does not cure the Mainframe 
access we need.  We run zVM and Redhat Linux but until they fix the TN3270 
pushing them on Linux is useless.
 
We also user SmartCards with 6 digit pins.  Unless you have that, your are 
looking at MAJOR Dollars to get that in-place and implement for 2FA
 
 
Steve Beaver


--------------------------------------------------------------------------------

This electronic mail (including any attachments) may contain information that 
is privileged, confidential, and/or otherwise protected from disclosure to 
anyone other than its intended recipient(s). Any dissemination or use of this 
electronic email or its contents (including any attachments) by persons other 
than the intended recipient(s) is strictly prohibited. If you have received 
this message in error, please notify us immediately by reply email so that we 
may correct our internal records. Please then delete the original message 
(including any attachments) in its entirety. Thank you


-----Original Message-----
From: "James Peddycord" <[email protected]>
Sent: Tuesday, November 22, 2016 11:52am
To: [email protected]
Subject: Mainframe systems programmer ID 'vaulting'



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

Reply via email to