External Security Manager Information › Security Exit Analysis › Security Exit Analysis Considerations

Security Exit Analysis Considerations

When auditing security exits you should consider:

• Is it an installation-written application that issues the security call? How you be certain that the application properly interprets the SAF codes and takes the proper action by implementing the denial of the access? Because the SAF call is issued by installation-written code the program should be subject to tight auditing scrutiny that entails:
  • Examination and testing of the actual code
  • Traditional security/change controls on the source/executable libraries containing the applications
• If the SAF router is modified or replaced by a non-IBM or non-CA version, the router should be subject to auditing along with a review of the code.
• If a SAF router exit is used the exit code should be audited
• If one or more ESM exits are used by the ESM, they should be audited
• The SAF router supports two user exit points, one for z/OS system initialization (ICHRTX01) and one after initialization is complete (ICHRTX00). This exit point can modify the SAF parameter list and set a return code value which bypasses ESM invocation. For example:
  • An authorization request can be modified so that the entity being authenticated is adjusted from a tightly protected entity to one with less security controls.
  • An exit might exist to enforce a “good guy” list. Pre-defined users are automatically granted access without securing an access determination from the ESM.
  • An exit might be used to eliminate an audit trail in the form of ESM logging records. If a site depends on standard security loggings to determine when accesses to secure resources were made the security loggings will not be present.