Who has UPDATE authority to the APF libraries in your shop?

We think this is the first question that should be asked when reviewing the integrity of z/OS or its predecessors. Those with the ability to add to an APF library also have the potential to bypass RACF and all other host-based security measures.

In our consulting work, we're always amazed by the disparity between what systems programmers and RACF administrators believe should be the case in this area, and what in fact exists. The staff might guess that 15 or 20 userids have APF UPDATE authority when a detailed analysis reveals that hundreds or even thousands of userids do! Since we have been using a new tool, APFCHECK , we have found that quite often all defined userids can update at least one APF library!

It's surprising how difficult it has been to get a detailed answer to this important question in a RACF environment. Some people might have access through the OPERATIONS attribute, some through group membership. Some libraries might be accessible through ID(*) or WARNING specifications, or through Global Access Checking.

And exactly which libraries are APF? In a dynamic environment, APF libraries can be added or deleted on the fly. And some Linklist libraries may be authorized as well.

APFCHECK provides the answers quickly and accurately. It provides both summary and detail reports on APF access.