On Fri, Jul 7, 2017 at 8:05 AM, Barbara Nitz <nitz-...@gmx.net> wrote:
> A colleague of mine just asked me if ISPF statistics in a data set, > especially the USERID field, can be manipulated. We used ISPF 3.5 and we > were both astonished that I was easily able to fake a userid as the one who > last changed a member (testing in my own dataset, of course). > > This immediately raised the question for me if there is any RACF control > that would prevent this type of manipulation, especially since the userids > in those statistics are widely used as evidence. Does anyone know if there > are such RACF controls? A quick search in the ISPF books didn't turn up any > hint. > There are no control possible for this. The ISPF statistics are simply data in the "user data area" portion of a member's directory entry. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.f54mc00/ispmc28.htm how a PDS directory entry is formatted: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/pdsd.htm Binyamin mentioned ACF2, but a regular program can use the STOW macro to update a PDS directory entry. In fact, must be able to in order to add, delete, or update (other than "in place") a member. I doubt, that even ACF2 has any control to disallow updating the directory entry of a member in a DSN to which the user has update authority. Bottom line: ISPF statistics are NOT ANY GOOD for any kind of security or auditing purposes. User can update them easily using 3.5 and you can't stop them. You would need a product such as PDSMAN https://docops.ca.com/ca-pdsman/7-7/en/administrating/what-is-pdsman > > Barbara > > -- Veni, Vidi, VISA: I came, I saw, I did a little shopping. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
