IBM Security Z Security

Hi,
We are installed zSecure Access Monitor 2.4 on one of the member of our SYSPLEX. Our SYSPLEX has two members such PX11 and PX12. We runs C2PACMON STC on the PX12. We don't want run C2PACMON STC per system. But each system have its own Daily collection files.  

In order to be able to use the same CKRPARM library across all systems of the sysplex, We used &SYSNAME in the C2PAMCLT and C2PAMCNT members.

We installed C2POLICE started task per system such PX11 and PX12 so C2PCOLL runs (at midnight) and produce Daily files for each LPAR.

We will run C2PACMON from only one system. Does Our plan include correct a point of view?

Regards,

Kayhan Tanrıverir

 

------------------------------
[Kayhan] [Tanriverir]
[Sn. Systems Programmer]
[VBT Bilgi Teknolojileri A.Ş]
[Ankara] [Turkey]
------------------------------

Hello Kayhan
Access Monitor uses the C2PACMON started task to receive, buffer and log RACF decisions, from exit points in RACF.  These exits are invoked very frequently, so the buffers and the started task must run in each LPAR to minimize path length (CPU cost).
You must run C2PACMON in each LPAR.  C2PACMON creates a runtime collection data set with summarized access counts, the data set name ends in Dyymmdd.Thhmm, for example, today it would end in D210129.T0000.  This data set is constantly allocated to C2PACMON, until midnight when a new runtime data set is created.  The old runtime is then consolidated into the DAILY data set, ending in Dyymmdd (without the time stamp).
These runtime and daily data sets are create for each LPAR separately.
You can run additional batch jobs, modeled after C2PJMCON, to consolidate these daily into weekly or monthly data sets, for each LPAR separately or combined by SYSPLEX.

But you must run C2PACMON on each LPAR, same as you run C2POLICE on each one.

If you install C2PACMON on one LPAR only, then activity of jobs, started tasks, users, and the system on the other LPARs will go undetected.  Reports produced from the ACCESS data sets about references to profiles or groups will be unreliable.

------------------------------
Rob van Hoboken
------------------------------

To add on to what Rob said, I have used the technique of combining the individual LPAR Access Monitor files into one per SYSPLEX daily as I've found it useful when you have many LPARs sharing one RACFDB, for example.

You can open a ticket with zSecure support to potentially provide you full details (I don't believe those are published), but you need to run a modified version of the SCKRCARL "C2PAMCMP" member to ensure all of the system names are the same, such as adding these statements:

simulate access_fallback_default
define type=access system(4,"PLEX",hdr$blank) true​

In my opinion, you certainly still want the LPAR datasets to exist using this method since you'll lose the LPAR granularity in the data (from the above, all will show "PLEX"), which can certainly be relevant in using the data, so ensure the "DELETE" keyword is not on the ALLOC statements you use in the consolidation.

------------------------------
Adam Klinger
------------------------------

Original Message:
Sent: Fri January 29, 2021 02:50 AM
From: Rob van Hoboken
Subject: We don't want run C2PACMON STC per system in SYSPLEX.

Hello Kayhan
Access Monitor uses the C2PACMON started task to receive, buffer and log RACF decisions, from exit points in RACF.  These exits are invoked very frequently, so the buffers and the started task must run in each LPAR to minimize path length (CPU cost).
You must run C2PACMON in each LPAR.  C2PACMON creates a runtime collection data set with summarized access counts, the data set name ends in Dyymmdd.Thhmm, for example, today it would end in D210129.T0000.  This data set is constantly allocated to C2PACMON, until midnight when a new runtime data set is created.  The old runtime is then consolidated into the DAILY data set, ending in Dyymmdd (without the time stamp).
These runtime and daily data sets are create for each LPAR separately.
You can run additional batch jobs, modeled after C2PJMCON, to consolidate these daily into weekly or monthly data sets, for each LPAR separately or combined by SYSPLEX.

But you must run C2PACMON on each LPAR, same as you run C2POLICE on each one.

If you install C2PACMON on one LPAR only, then activity of jobs, started tasks, users, and the system on the other LPARs will go undetected.  Reports produced from the ACCESS data sets about references to profiles or groups will be unreliable.

------------------------------
Rob van Hoboken
------------------------------

Adam
Modifications to the CARLa programs in zSecure Target libraries such as SCKRCARL are going to bite you (and your installation).  zSecure tends to ship updates to these programs using PTFs or new releases, and you will have to find out how to apply your change to the new version.  That also applies (and more insidiously) when you copy the SCKRCARL  member into your C2PACPRM data set.

Changing the SYSTEM field in ACCESS records not only removes the granularity of (F)RACHECK records, but also from the RACINIT records (unless you carefully craft the update), and this makes it harder to identify where exactly the task runs that uses this obsolete user ID you found.

To use ACCESS records in simulations, zSecure must have a CKFREEZE at hand for every LPAR that contributed an ACCESS record, if you do not have a matching CKFREEZE the record get discarded(!) for reporting.  (Yes, there is a message to that effect in SYSPRINT).  That means, if you zap the SYSTEM field as described in the technote, each and every user or batch job that wants to do intelligent reporting from these modified records must add a SIMULATE ACCESS_FALLBACK_DEFAULT command in the panel or CARLa source.  Omission of this command is only visible by scrutinizing SYSPRINT (or obviously missing data from your reports).

I have learned the hard way NOT to zap the SYSTEM field in ACCESS records.

------------------------------
Rob van Hoboken
------------------------------

Yes, these are all valid points and concerns one has to be very aware of before considering and using -- it's certainly a "your mileage may vary" approach, that you should not consider without solid reason. The "SIMULATE ACCESS_FALLBACK_DEFAULT" statement can be added in the SE.D.3 preamble, for example.

I have found that it's common practice that installations' scheduling rules require members be contained in libraries controlled by the scheduling software, so doing checks when maintenance is installed becomes mandatory (do not believe things such as SCKRCARL changes are in HOLDDATA, for example). One can automate this to some degree to ensure the only differences from the shipped libraries are the ones you want and notified when things change.

I'd certainly be open to any RFE suggestions on improving the concept "Sysplex" Access Monitor Datasets. One can imagine where an installation that has a large number of LPARs sharing one RACFDB where this sort of thing comes into play.

------------------------------
Adam Klinger
------------------------------

Original Message:
Sent: Fri January 29, 2021 10:03 AM
From: Rob van Hoboken
Subject: We don't want run C2PACMON STC per system in SYSPLEX.

Adam
Modifications to the CARLa programs in zSecure Target libraries such as SCKRCARL are going to bite you (and your installation).  zSecure tends to ship updates to these programs using PTFs or new releases, and you will have to find out how to apply your change to the new version.  That also applies (and more insidiously) when you copy the SCKRCARL  member into your C2PACPRM data set.

Changing the SYSTEM field in ACCESS records not only removes the granularity of (F)RACHECK records, but also from the RACINIT records (unless you carefully craft the update), and this makes it harder to identify where exactly the task runs that uses this obsolete user ID you found.

To use ACCESS records in simulations, zSecure must have a CKFREEZE at hand for every LPAR that contributed an ACCESS record, if you do not have a matching CKFREEZE the record get discarded(!) for reporting.  (Yes, there is a message to that effect in SYSPRINT).  That means, if you zap the SYSTEM field as described in the technote, each and every user or batch job that wants to do intelligent reporting from these modified records must add a SIMULATE ACCESS_FALLBACK_DEFAULT command in the panel or CARLa source.  Omission of this command is only visible by scrutinizing SYSPRINT (or obviously missing data from your reports).

I have learned the hard way NOT to zap the SYSTEM field in ACCESS records.

------------------------------
Rob van Hoboken
------------------------------