[prev in list] [next in list] [prev in thread] [next in thread]
List: racf-l
Subject: Re: privileged identity management
From: Tony.J.Riordan () NAB ! COM ! AU
Date: 2013-06-20 0:51:24
Message-ID: OF75B02A24.1D515FC1-ONCA257B90.0003AA50-CA257B90.0004B4B4 () nab ! com ! au
[Download RAW message or body]
Hi Scott,
We have steered clear of CyberArk for the mainframe as it's likely people
would end up with more access than they really need to perform their job.
In the end you would need to have many super "Firecall" accounts for the
various support teams to use, more than one per team for sure.
Since we have an existing RBAC solution we are extending that,
quarantining privileged access and then elevating the person's actual
userid to a privileged state when required - takes about 4-6 seconds to
elevate a person's access.
All privileged use is monitored and reported on with no licence costs
etc...
Regards
Tony Riordan
Lead Security Specialist | Access & Identity Management | Security
Services
From: "Ruhe, Scott" <Scott.Ruhe@MEDMUTUAL.COM>
To: RACF-L@LISTSERV.UGA.EDU
Date: 20/06/2013 06:32 AM
Subject: privileged identity management
Sent by: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU>
Is anybody using CyberArk or an equivalent product for "privileged
identity management" on the mainframe and, if so, how is it being used in
conjunction with RACF?
Opinions, whether using or not, are very welcome!
Thanks in advance.
-Scott Ruhe, Medical Mutual
http://www.medmutual.com/
Visit http://www.medmutual.com/
CONFIDENTIALITY NOTICE:
This message is intended only for the use of the individual or entity to
which it is addressed and may contain information that is privileged,
confidential or exempt from disclosure by law. If the reader of this
message is not the intended recipient, or the employee or agent
responsible for delivering the message to the intended recipient, you are
hereby notified that you are strictly prohibited from printing, storing,
disseminating, distributing or copying this message. If you have received
this message in error, please notify us immediately by replying to the
message and deleting it from your computer. Neither this information
block, the typed name of the sender, nor anything else in this message is
intended to constitute an electronic signature, unless a specific
statement to the contrary is included in this message.
Thank you, Medical Mutual.
-----Original Message-----
From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of
Automatic digest processor
Sent: Wednesday, June 19, 2013 12:07 AM
To: Recipients of RACF-L digests
Subject: [BULK] RACF-L Digest - 17 Jun 2013 to 18 Jun 2013 (#2013-147)
There are 7 messages totalling 294 lines in this issue.
Topics of the day:
1. "dirm as <uid> cm q disk" problem
2. Automatic reply: "dirm as <uid> cm q disk" problem (3)
3. IBM policy regarding security bugs
4. reg, INVICB (2)
----------------------------------------------------------------------
Date: Tue, 18 Jun 2013 10:34:39 -0700
From: Russell West <list0id1@PACBELL.NET>
Subject: Re: "dirm as <uid> cm q disk" problem
Sonny, there are a few standard points you didn't include, but I'm going
to go for what seems to me, the obvious: your ID doesn't have the
authority.
Does your personal ID have authority to issue DIRMAINT commands, i.e., did
you logon as TUCO, link the necessary MAINT mini-disks and then issue the
same CMS QUERY command to the same target?
Also, I don't understand what you are try do here as MAINT usually has the
higher authority compared to most personal IDs. I'm assuming that MAINT
has no problem issuing the same query. Are you trying to make your
personal ID function in place of MAINT? If so, you need to be defined in
MAINT's control file.
/russ
--- On Mon, 6/17/13, Bonno, Tuco <tuco@CIO.SC.GOV> wrote:
> From: Bonno, Tuco <tuco@CIO.SC.GOV>
> Subject: "dirm as <uid> cm q disk" problem
> To: RACF-L@LISTSERV.UGA.EDU
> Date: Monday, June 17, 2013, 10:36 AM
> cross-posted to both VM as well as
> RACF list server
>
> logged on in VM as MAINT I issue this command:
>
> ?? dirm as tuco cms q disk ??
>
> and receive the following response:
>
> " dvhreq2283e userid tuco at bcbvm01 is not authorized to issue
> the cms command for tuco at * "
>
> I have RACF active, with surrogate class active .
>
> i have consulted the fine "Directory maint facility Messages"
> manual for this message's meaning.
> and
> I have also consulted appendix A, "external security manager
> considerations" in the "DirMaint Fac Tailoring and Admin gde" book .
>
> does the error message mean i should have a profile in class
> SURROGATE for cms.tuco ? with 'tuco' in the access list?
> or MAINT in the access list? or both?
>
> i am confused on exactly how i should proceed; therefore i humbly
> request whatever guidance from any one who has overcome this problem.
>
> thank you.
> /s/ ??sonny?.
> aka, tuco bonno;
> Graduate, College of Conflict Management; University of SouthEast
> Asia; "I partied on the Ho Chi Minh Trail - tiến lên !! "
>
>
>
------------------------------
Date: Tue, 18 Jun 2013 17:37:15 +0000
From: "Carhart, Jon" <Jon.Carhart@LANDREGISTRY.GSI.GOV.UK>
Subject: Automatic reply: "dirm as <uid> cm q disk" problem
I am currently out of the office and will return on Friday 21st of June
20= 13, if you have an urgent enquiry please contact the Access Control
Team d= irectly (AccessControl@LandRegistry.gsi.gov.uk).
The original of this email was scanned for viruses by the Government
Secur= e Intranet virus scanning service supplied by Vodafone in
partnership with= Symantec. (CCTM Certificate Number 2009/09/0052.) On
leaving the GSi this= email was certified virus free.
Communications via the GSi may be automatically logged, monitored and/or
r= ecorded for legal purposes.
------------------------------
Date: Tue, 18 Jun 2013 17:38:29 +0000
From: "Bernard. Fred" <BernardF@SACCOUNTY.NET>
Subject: Automatic reply: "dirm as <uid> cm q disk" problem
I'll be out of the office until June 28 when I can respond to your email.
If you need CJIS support, contact Jack Fordyce at 874-7543.
COUNTY OF SACRAMENTO EMAIL DISCLAIMER:
This email and any attachments thereto may contain private, confidential,
and privileged material for the sole use of the intended recipient. Any
review, copying, or distribution of this email (or any attachments
thereto) by other than the County of Sacramento or the intended recipient
is strictly prohibited.
If you are not the intended recipient, please contact the sender
immediately and permanently delete the original and any copies of this
email and any attachments thereto.
------------------------------
Date: Tue, 18 Jun 2013 17:39:00 +0000
From: "Bohannon, Calvin" <Calvin.Bohannon@SEARSHC.COM>
Subject: Automatic reply: "dirm as <uid> cm q disk" problem
Sorry, Calvin is out of the office. Calvin is expected back on June 19,
2013. For Sears Holding business issues, contact other members of the TS
Software group via the DevWeb URL (http://devweb/) or email address
TSSoftware@searshc.com
------------------------------
Date: Tue, 18 Jun 2013 15:25:32 -0400
From: Gerri Booth <gerri.booth@DOA.STATE.WI.US>
Subject: Re: IBM policy regarding security bugs
On Thu, 13 Jun 2013 15:34:10 -0400, Tom Marchant
<m42tom-ibmmain@YAHOO.COM>
wrote:
> If you are asking that the APARs for all problems that are corrected by
> security/integrity PTFs flag some earlier SYSMOD as an ERROR, I have no
> quarrel with that.
That is what I'd like to see happen. All they have to do is add a
HOLDERROR entry to the FMID (assuming that is wasn't a PTF that caused the
security/integrity) for the security/integrity APARs and these APARs would
be listed in the ERRSYSMODS report. And it seems entirely appropriate for
IBM to do this because a security/integrity problem that's not
atttributable to a specific PTF should cause a HOLDERROR against the FMID.
Prior to your response I hadn't realized that in order for an APAR to be
listed in the ERRSYSMODS report there had to be a HOLDERROR entry against
either a PTF or the FMID. I just thought that any APAR that had a HIPER
flag on it would get included in the report. Thanks for clearing that up
for me.
Regards,
Gerri
------------------------------
Date: Wed, 19 Jun 2013 02:18:38 +0530
From: madhukar reddy <madhukarracf@GMAIL.COM>
Subject: Re: reg, INVICB
Hi,
I can able to read the RBA using BLKUPD but how can i generate complete
record.
example : RBA of IBMUSER is x'D700'. so how can i fetch complete
information of user IBMUSER like name, special, auditor etc
It will be great help for me.
Thanks
N.Madhukar
On Thu, May 9, 2013 at 6:22 PM, Walt Farrell <walt.farrell@gmail.com>
wrote:
> I realized late last night that my note below assumes that the program
> would do random I/Os within the copied database to retrieve
> information, but there is a better alternative. The program could read
> the copy of the database and place all the blocks into storage
> (ideally, a memory object in 64-bit storage) so that after that all
> the random activity is simply moving about in memory. At that point,
> even QSAM could be used for the I/O. GET a 4-K block, move it into the
> memory object. GET another. Move it. Etc.
>
> Everything else remains the same, though. You would need to "navigate"
> through the memory object by locating RBAs and converting them into
> memory addresses. Dealing with profiles that span block boundaries
> would be easier, as all the pieces would automatically be in
> contiguous storage locations, so once you had found the beginning of
> the profile the rest of it would be there for you to examine.
>
> Walt
>
>
> On 5/8/2013 10:36 PM, Walt Farrell wrote:
>
> > Well, that's an easy question to answer. IRRDBU00 uses ICHEINTY,
> > which is one of the mechanisms I recommended to you. It's harder to
> > use than RACROUTE REQUEST=EXTRACT, by the way, so I would still place
> > it 3rd in the list of recommended ways for getting USER information.
> >
> > If you want to read a copy of the RACF database directly, you will
> > probably want to use either BDAM or EXCP to do so, though I suppose
> > BSAM with NOTE/POINT would also work.
> >
> > You will need to understand the structure of the ICB, the index
> > blocks, the entries within the index blocks, the data blocks, and
> > the profiles within the data blocks.
> >
> > You will need to start with a profile name (possibly x'00' or x'40'
> > if you're trying to find all the profiles) and from the ICB you would
> > find the RBA of the top level index block. You would convert that RBA
> > into a block number, and read that block. You would then move through
> > the index entries until you find one greater than the name you have,
> > and that will give you the RBA of the next lower level index block.
> >
> > You will proceed that way until you reach the level 1 index block,
> > which will give you the RBA of the first part of the actual profile.
> > You will convert that RBA to a block number and read that block, and
> > then use the RBA to find the beginning of the profile within that
block.
> >
> > The profile may be completely contained in that block, or you may
> > need to also read some number of additional blocks to get all of the
profile.
> >
> > Once you have accumulated all of the profile, you would work your way
> > through it using the template and field definitions (the ICB also
> > points to them) to locate each segment of the profile, and within
> > each segment each field.
> >
> > That gives you the first profile. You then need to basically repeat
> > that process and find the next appropriate profile (for USERs it will
> > have a name larger than the last one you processed).
> >
> > Your primary source of information for all this will probably be the
> > RACF Diagnosis Guide, as none of this is intended programming
> > interfaces. The Diagnosis Guide will show you the format of the ICB,
> > or the index blocks and entries, and of the data blocks, and the
> > basic format of the profiles. The template and field definitions will
> > help you navigate through the data in the profile once you've found it.
> >
> > And what you will probably want to do is take a copy of a small RACF
> > database, and print it in hex using IDCAMS or AMASPZAP, and then walk
> > through it by hand referring to your reference materials until you
> > understand the format very well, and at that point you could start
> > writing some code.
> >
> > But your code won't be anything like how IRRDBU00 works, since it
> > lets RACF do all the hard work of understanding what the database
> > looks like, and basically just keeps asking RACF to give it the next
> > profile using ICHEINTY NEXT.
> >
> > --
> > Walt
> >
> >
> >
------------------------------
Date: Tue, 18 Jun 2013 17:12:10 -0400
From: Walt Farrell <walt.farrell@GMAIL.COM>
Subject: Re: reg, INVICB
On 6/18/2013 4:48 PM, madhukar reddy wrote:
> I can able to read the RBA using BLKUPD but how can i generate
> complete record.
>
> example : RBA of IBMUSER is x'D700'. so how can i fetch complete
> information of user IBMUSER like name, special, auditor etc
>
> It will be great help for me.
>
BLKUPD will only give you a hex dump of data from a data block. It isn't
intended for displaying profile information, but for diagnosing and fixing
broken RACF databases.
However, if you know that the RBA is x'D700' you could issue the BLKUPD
command
READ x'D700'
or
READ x'D000'
and then
LIST
or
LIST RANGE(x'700', x'900')
The first will list the complete block; the second will list just the part
of the block where the IBMUSER profile starts. You then need to interpret
the hex data yourself to find the fields that you want, using the
information contained in RACF Diagnosis and in the template descriptions
(e.g., from RACF Macros and Interfaces).
--
Walt
------------------------------
End of RACF-L Digest - 17 Jun 2013 to 18 Jun 2013 (#2013-147)
*************************************************************
This email has been scanned at the NAB Group email gateway
for malware and spam.
Report any spam emails to spam@nab.com.au
Report any phishing / suspicious emails to spoof@nab.com.au
For more information visit http://go/infosecurityawareness
____________________________________________________________
The information contained in this email and its attachments may be confidential.
If you have received this email in error, please notify the sender by return email,
delete this email and destroy any copy.
Any advice contained in this email has been prepared without taking into
account your objectives, financial situation or needs. Before acting on any
advice in this email, National Australia Bank Limited ABN 12 004 044 937 AFSL and \
Australian Credit Licence 230686 (NAB) recommends that you consider whether it is \
appropriate for your circumstances. If this email contains reference to any \
financial products, NAB recommends you consider the Product Disclosure Statement \
(PDS) or other disclosure document available from NAB, before making any decisions \
regarding any products.
If this email contains any promotional content that you do not wish to receive,
please reply to the original sender and write "Don't email promotional
material" in the subject.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic