Just this week I had a discussion with an IBM specialist supporting a European customer where the companion topic of stopping sysprogs from subverting SMF records came up.
Protect the data is the key. And SMF 15 might be useful for tracking updates. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Lizette Koehler <stars...@mindspring.com> To: IBM-MAIN@LISTSERV.UA.EDU Date: 15/05/2015 13:52 Subject: Re: DFSORT and RACF Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> Just my thoughts. Would you not protect the input (SORTIN) and output(SORTOUT) with RACF from update where appropriate? DFSORT can only change what the user doing the request has authority to do. So if USERA runs a sort against PAYROLL.MSTR.TEMP and writing it out to PAYROLL.MSTR using DFSORT. If USERA does not have alter authority to PAYROLL.MSTR or does not have READ authority to PAYROLL.MSTR.TEMP then the job should fail. What if the sort process used by USERA has concatenated another dataset to PAYROLL.MSTR. What if the sort is done so that certain records (SUM FIELDS=NONE) are pulled from this other file and it does replace the original PAYROLL.MSTR data. There was no editing done by sort, just a removal of duplicate records. Like any 4GL, DFSORT control cards is not where I would rely on security. It would be with the files themselves. If you have TLMS, RMM or CA1, do you allow only certain people to be able to read database? Is the DSN something you should protect people from even seeing? Or do you let them list any tape volser, and RACF prevents them from reading or writing that dataset. I am not sure how touchy auditors are today. Do they think you should not even be able to list that volser to see what is on the tape. I have read where some shops want to prevent a dataset from being listed in 3.4. I am not sure I see the harm at this time. So long as the SAF prevents access, I would think that should be enough. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Elardus Engelbrecht > Sent: Friday, May 15, 2015 4:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFSORT and RACF > > Hi to all, > > I want to ask something on IBM-MAIN before I lodge a formal request for > DFSORT gurus attention: > > It is part of my work to produce many audit reports using DFSORT, ICETOOL, > custom REXX, COBOL, Assembler programs. > > Normally, while supported, we don't modify columns in DFSORT/ICETOOL, > something like this: > > INCLUDE COND=(5,4,CH,EQ,C'0200',AND,118,10,CH,GE,C'2015-01-01') > OUTREC FIELDS=(1,9,10:10,3,CHANGE=(3,C'ABC',C'CBA'), ... etc ... > > or > > INREC IFTHEN=(WHEN=(96,1,CH,EQ,C'S'),OVERLAY=(97:C'ABCDEFGH')), > > But, I have a need to translate the cryptic columns into something readable. > [1] > > Question: > > Is there any need to control the modifying of input/output by > DFSORT/ICETOOL with RACF? > Something like that STGADMIN.?? profiles in FACILITY class to control usage > of ADMINISTRATOR keyword in DFDSS? > > I don't think those auditors will like to see (and not survive) those ability to > modify records. > > Of course I could rerun my jobs from original SMF just to prove these records > are not modified anywhere. > > Thanks in advance! > > Groete / Greetings > Elardus Engelbrecht > > [1] - My auditors already accept that I use a REXX program to translate > something like 'INVPSWD ' by 'Not a valid password' or 'FPROTALL' by 'Failed > by PROTECTALL'. > > ---------------------------------------------------------------------- > 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 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
