Can Auditor work be done in batch?

Products

• Auditor for z/OS

Issue/Introduction

Examine provides a neat, but often underused feature known by a number of names such as:

• Batch interface
  
  
• Silent Auditor
  
  
• Batch scripts
  
  
• Batch job
  
  

Environment

Release:
Component: EXAMIN

Resolution

When invoked in online mode (i.e., under TSO), the user navigates via function menus (in standard ISPF fashion), and also via an English-like interface appropriately enough called the "talker". "SHOW PPT", "SHOW SVC", and "SHOW APF" are examples of valid talker commands which will act as if the user entered the proper menu function sequence to get to the proper menu/sub-menu.

If one thinks of a standard auditing sequence - think in terms of the Examine System Review Checklist - and the list of functions to be executed and in which order, this then can certainly be turned into a standard, repeatable set of procedures. This makes sense for many reasons - one of which is the standard auditing sequence by which the auditors conduct a first audit of something. They verify that everything is proper and in doing so establish what they call a "baseline". They then subsequently rerun those same audit functions and compare the current results against the saved baseline results, and address any deviations that are detected.

Proper use of the batch interface can help automate such repeatable auditing functions. There are other easy to use functions as well.

Consider the case whereby SMF data might be lost. Perhaps an SMF exit might have abended, causing automatic scheduling of an SMF dump to be bypassed - thereby letting all available SMF data sets be filled. Perhaps there is a DASD failure affecting the live SMF files. Perhaps there is a malicious attempt by someone to bypass writing of SMF records. In these circumstances - when SMF is unavailable - SMF will generate a type=7 "SMF data lost" record when SMF once again becomes active for writing records. What a customer might do is to schedule an automatic SMF record search to look for type=7 records and thus instances of missing SMF activity.

There are only a handful of functions that cannot be executed via the Batch interface. These are documented in the Usage and Technical Reference guides.

Note: Please be aware that prior to doing large freeze operations, you should perform a backup of the freezer data base (DBASE1). This is documented in EXAMIN informational solution #39 for EXAMIN r3.5.

1. Examine Freezer
   
   The freezer, as its name implies, "freezes" a snapshot of a data set, data set member, or more, and saves it for later analysis. It is an important element of change control verification because of its ability to detect changes.
   
   Consider these situations:
   
   
   • Production application load library
     
     
   • Production application source library
     
     
   • Production PARMLIB library
     
     
   • Production system modification library (i.e., user-written SVCs, user-written exits, user replaceable modules, etc.)
     
     
   
   
   In theory (this depends greatly from installation to installation), changes to these types of production libraries should be very tightly controlled. These types of data sets should not be volatile in terms of update/change modification activity, and it is a fair statement that changes should be few and far between. For many installations, formal change control procedures should be in place to keep track of each and every such update.
   
   So, in this situation, Examine can be used to freeze an application load library, and then periodically re-freeze it (via batch or online) to detect changes. Changes, if detected, can then be noted by the auditors who then can cross-check them with the appropriate installation change control logs.
   
   Just because a change is detected does not necessarily mean that the change is improper. Consider our production z/OS systems - changes are made all the time via change orders. If the auditor can substantiate the change(s) as being valid, then they can be "accepted" and thus have the updated freezer image be considered the updated baseline. If the changes are improper, they then can be backed off, and things can be re-audited to reconfirm accordance with the previous baseline.
   
   A note on freezing. This does not in any way make a complete copy of a member or data set. Instead, it creates a digital snapshot of the member or data set, and uses this to determine if changes are made when comparing to subsequent re-freezes. Also, the freezer can detect changes at a gross level, e.g., whether something has changed from the previous freeze. It cannot detect all instances of updates made during the interval. However, the auditor can use the SMF search function to check for appropriate data set update records.
   
   
2. Baseline Analysis
   
   This new feature (to r12) takes a number of Examine functions  further by "automating" them such that we can save the current results of a function (e.g., APF library list) in a new file called the Baseline File and subsequently use this saved information to compare to "current" results when the function is subsequently re-executed at a later time. In essence, baseline analysis helps to automate much processing that currently is manual, namely the comparison of "before "/" after" results to produce a delta of changes.