Auditing Security

The security audit facility audits all types of file pool servers and many of their activities. That is, it applies to CRR and FIFO servers as well as to repository servers.

For repository file pool servers and FIFO servers, this facility audits attempts to access file pool resources.

For CRR, this facility audits the use of these operator commands that intervene in CRR activity:
  • CRR recovery server operator command:
    • CRR ERASE LU
    • CRR ERASE LUWID
    • CRR RESYNC
  • Repository file pool server operator commands:
    • ERASE LUNAME
    • FORCE PREPARED
The security audit facility writes a record in a CMS file, which makes it possible for you to know who is:
  • Attempting to access file pool resources
  • Issuing operator commands that intervene in CRR activity

You can use the server's security audit facility even if you are using an external security manager to check the authorizations. When an external security manager is used (the ESECURITY startup parameter is in effect), the server generates audit records similar to those it usually generates. The server merely records in the audit records what was doing the checking: the server itself, or an external security manager.

Note: External security managers are not applicable to dedicated CRR recovery servers or dedicated FIFO servers.
You can audit security at two levels: partial and complete. In a partial audit, these kinds of events are recorded:
  • Unsuccessful attempts to access objects in the repository file pool server.
  • All repository file pool server access attempts by users having file pool administration authority.
  • All BFS access attempts by BFS superusers.
  • Operator intervention into CRR activity.

While an unsuccessful access attempt might be the result of a command entry error, it might also be an attempt at malicious access. Security audit does not know what the intent of the user was, only that the user tried to access or modify something for which he was not authorized. In the second and third cases above, you are able to tell whether a user with file pool administrator authority or a BFS superuser is misusing their authority. In the fourth case above, you are able to identify who is issuing CRR recovery server or file pool server operator commands that intervene into CRR activity.

In a complete audit, the file pool server records both successful and unsuccessful attempts to access any object in the file pool, and both the repository file pool server and the CRR recovery server record operator intervention into CRR activity. A complete audit can also produce numerous output records, so you need a large output file.

To minimize an audit's effect on performance, the file pool servers write all audit records in an internal form. They do not use processing time to format the records as it generates them. After an audit is complete, you can enter the FILEPOOL FORMAT AUDIT command to format the records for display. The FILEPOOL FORMAT AUDIT command is a separate utility. It does not need a file pool server machine to do its work—only the audit file.

You can start an audit by specifying a FILESERV startup parameter or by entering a file pool operator command. Prior to starting the audit, you must identify where the audit records are to be placed by issuing a FILESERV DEFAUDIT command. Auditing stops when the file pool server is shut down. You can also stop it by issuing a file pool operator command. Security audits cannot be done in dedicated maintenance mode—there is no one to audit.

The following sections describe how to define an audit file, start and stop the audit, and format the audit records.