IBM Mainframe Forum

by **enrico-sorichetti** » Tue Feb 07, 2012 8:40 pm

the smplog goes to useless details ,
see for example

......GIM20501I APPLY PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12.
......GIM20502I SMP/E PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12.
..â—Š..â—ŠGIM54901I SMPCNTL WAS ALLOCATED BY THE USER AS SYSIN/SYSOUT.
..â—Š..â—Š SET BOUNDARY (GLOBAL) .
..â—Š..â—ŠGIM54901I SMPOUT WAS ALLOCATED BY THE USER AS SYSIN/SYSOUT.
..â—Š..â—ŠGIM54101I DYNAMIC ALLOCATION FOR SMPLOG WAS SUCCESSFUL - DA(****.****
..â—Š..â—ŠGIM54901I SMPRPT WAS ALLOCATED BY THE USER AS SYSIN/SYSOUT.
..â—Š..â—ŠGIM54901I SMPCNTL WAS ALLOCATED BY THE USER AS SYSIN/SYSOUT.
..â—Š..â—ŠGIM54101I DYNAMIC ALLOCATION FOR SMPLOGA WAS SUCCESSFUL - DA(****.****
..â—Š..Â¨GIM20501I SET PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 00.
..â—Š..Â¨ RECEIVE
..â—Š..Â¨ SYSMODS HOLDDATA .
..â—Š..Â¨GIM54903I SYSUT1 WAS ALLOCATED BY THE USER - DA(SYS08259.T073042.RA000.
..â—Š..Â¨GIM54903I SYSUT2 WAS ALLOCATED BY THE USER - DA(SYS08259.T073042.RA000.
..â—Š..Â¨GIM54903I SYSUT3 WAS ALLOCATED BY THE USER - DA(SYS08259.T073042.RA000.
..â—Š..Â¨GIM54903I SYSUT4 WAS ALLOCATED BY THE USER - DA(SYS08259.T073042.RA000.
..â—Š..Â¨GIM54903I SMPPTFIN WAS ALLOCATED BY THE USER - DA(****.****.****
..â—Š..Â¨GIM54903I SMPHOLD WAS ALLOCATED BY THE USER - DA(****.****) VOLUME
..â—Š..Â¨GIM59608I ENQ WAS INITIATED FOR SHARED USE OF ********.GLOBAL.CSI FOR REC
..â—Š..Â¨GIM59603I ENQ WAS SUCCESSFUL FOR SHARED USE OF ********.GLOBAL.CSI FOR RE
and so on and so on

as I said a LIST NOSUP SYSMOD for the target zones would more than enough from my point of view

the SMPLOG is useful during the installation if something went wrong,
never used it for anything else

by **steve-myers** » Tue Feb 07, 2012 9:40 pm

The other problem is it is all to easy to update system libraries without using SMP. Standard IBM utilities such as the Binder or IMASPZAP are used to create and modify load modules, so it is possible to write programs to analyze a load module dataset to detect changes. Another possibility is to use a tool such as the AMBLIST LISTIDR command, and then analyze the SYSPRINT dataset created by AMBLIST to find changes. The AMBLIST utility is described in the "MVS Diagnosis: Tools and Service Aids" manual for your z/OS release.

Changes to source libraries like SYS1.PROCLIB are more difficult to detect after the fact, though it may be possible to use ISPF member statistics to detect some changes.

All of this assumes the "hacker" is using standard tools to perform his dirty deed, and does not know how to sneak changes in without using "standard" tools. It is not all that difficult to "hack" a load module directly, or to "hack" the IDR data or ISPF member statistics to hide a change.

No one has mentioned using SMF type 15 records to determine who has opened system datasets for output. This won't tell you what was changed, but at least you can determine something was changed, and who did the dirty deed.

by **nevilh** » Wed Feb 08, 2012 3:16 pm

the smplog goes to useless details

True but if the SMP environment is set up correctly and one has a SMPLOG dataset for each zone (rather than write all info in one SMPLOG) the amount of data is manageable, Also it is the only command that will meet the posters requirement of specifying a time frame for the report. All other SMP commands will produce reports for the zone as a whole (timewise) . The List command does not offer the possibility of selecting by time.

No one has mentioned using SMF type 15 records to determine who has opened system datasets for output

If you use AMASPZAP to directly zap the disk address SMF will not pick this up as you have not opened the dataset. But noone would do that would they??????

by **v1gnesh** » Wed Feb 08, 2012 3:25 pm

steve-myers wrote:Changes to source libraries like SYS1.PROCLIB are more difficult to detect after the fact, though it may be possible to use ISPF member statistics to detect some changes.
No one has mentioned using SMF type 15 records to determine who has opened system datasets for output. This won't tell you what was changed, but at least you can determine something was changed, and who did the dirty deed.

I will keep SMF 15 in mind. BTW, we have SAS MXG, which i think we can use to find references to any dataset( viewed/modified via job/ISPF, but doesn't say if it was edited ). Also, since the requirement wasn't mentioned properly, we have been providing PTF information the last 2 times. I'm afraid they wouldn't know how to word it better, or ask clearly. Also, i don't think there's any way to have a log of ALL modifications : datasets, SMPE zones, CFRM policy updates, and so on. I guess the only way is to provide the information from the CRs, which would record any major changes

by **steve-myers** » Wed Feb 08, 2012 9:29 pm

v1gnesh wrote:... I will keep SMF 15 in mind. BTW, we have SAS MXG, which i think we can use to find references to any dataset( viewed/modified via job/ISPF, but doesn't say if it was edited ). ... Also, since the requirement wasn't mentioned properly, we have been providing PTF information the last 2 times. I'm afraid they wouldn't know how to word it better, or ask clearly. Also, i don't think there's any way to have a log of ALL modifications : datasets, SMPE zones, CFRM policy updates, and so on. I guess the only way is to provide the information from the CRs, which would record any major changes

System changes applied via SMP is good, but changes that are hacked in present a problem.
Logged changes applied via change requests should include changes applied via SMP.
I am aware of MXG, but know very little about it. SMF type 14 (for input) and 15 (for output or update) should be easy to distinguish, though I don't know if MXG does this. For a sequential dataset, "update" usually implies a partial replacement of the contents, and "output" usually implies complete replacement of contents. For a PDS, "output" usually (but not always) implies a partial change of the contents. Either way, SMF 15 can't distinguish between "update" and "output."

My limited experience with auditors is they are complete idiots. They have things they check off, but have little real understanding of how systems actually work.

For better or worse, I do not know of any formal log of changes other than SMF, which is not always satisfactory, especially for PDS datasets. MXG is good, but it can lose things, which you seem to be saying when you say it can't distinguish between viewing data (input) or writing data (output or update).

by **v1gnesh** » Wed Feb 08, 2012 11:45 pm

steve-myers wrote:[*]Logged changes applied via change requests should include changes applied via SMP.

Guess i'll stick with taking information from the CRs themselves then. Considering that they'll inevitably ask for a CR for any given change, from the ones i provide.

Thanks for all your inputs. You've been very kind!

by **steve-myers** » Thu Feb 09, 2012 10:16 am

nevilh wrote:... If you use AMASPZAP to directly zap the disk address SMF will not pick this up as you have not opened the dataset. But noone would do that would they??????

Oh, yes. IMASPZAP opens the VTOC as output to update it. THAT is why it is authorized; nothing else it does requires authorization.

Similarly, it opens a dataset being updated using CCHHR processing, but access to the dataset is controlled by security; IMASPZAP does not sneak around security.

A properly setup SMF analysis program will see a type 15 record for dataset 44X'04' (to use Assembler terminolgy) when IMASPZAP updates a VTOC, or a "regular" type 15 record when it updates a dataset.

by **nevilh** » Thu Feb 09, 2012 2:57 pm

Similarly, it opens a dataset being updated using CCHHR processing

Are you sure I have a 1.12 system (test) where I can zap (ttr) data that I am not authorised to read . I have not checked SMF to see if a record is written. I admit that it is a test system and that there maybe exits active of which I am unaware

by **steve-myers** » Thu Feb 09, 2012 5:48 pm

nevilh wrote:... Are you sure I have a 1.12 system (test) where I can zap (ttr) data that I am not authorised to read . ..

Are both systems using the same security and share data? If the two systems share data and do not have common security you've got a pretty rinky-dink environment.

"zap (ttr)"? Huh? IMASPZAP only has CCHHR record location, not TTR. Just to be certain, I checked the doc for V1R12 to see if IMASPZAP has been enhanced to support TTR. It hasn't. Or are you using some other mechanism?

by **nevilh** » Fri Feb 10, 2012 1:30 am

Are both systems using thzap (ttr)e same security and share data?

Not sure where you got the idea I had multiple systems. If I gave that impression I apologise, what I have is a standalone system .

zap (ttr)

Bad choice of syntax by me I was in a hurry and just wanted to emphasize I was zapping address rather than DSN.

IBM Mainframe Forum

System-generated list of changes made to the LPAR

Re: System-generated list of changes made to the LPAR

Re: System-generated list of changes made to the LPAR

Re: System-generated list of changes made to the LPAR

Re: System-generated list of changes made to the LPAR

Re: System-generated list of changes made to the LPAR

Re: System-generated list of changes made to the LPAR

Re: System-generated list of changes made to the LPAR

Re: System-generated list of changes made to the LPAR

Re: System-generated list of changes made to the LPAR

Re: System-generated list of changes made to the LPAR