Any good SYSPROG (as opposed to a SMP jockey) cannot be prevented from subverting SMF records without crippling his ability to do his job. Once there is the ability to update APF libraries, anything can be done - from blocking SMF to causing the records to falsely record events .
On Fri, 15 May 2015 15:58:51 +0100 Martin Packer <[email protected]> wrote: :>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: [email protected] :> :>Twitter / Facebook IDs: MartinPacker :>Blog: :>https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker :> :> :> :>From: Lizette Koehler <[email protected]> :>To: [email protected] :>Date: 15/05/2015 13:52 :>Subject: Re: DFSORT and RACF :>Sent by: IBM Mainframe Discussion List <[email protected]> :> :> :> :>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:[email protected]] :>> On Behalf Of Elardus Engelbrecht :>> Sent: Friday, May 15, 2015 4:12 AM :>> To: [email protected] :>> 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 :>> [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 :> :> :> :>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 [email protected] with the message: INFO IBM-MAIN -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
