General audit controls

You specify general (system-wide) audit controls on either the SETROPTS command or the SET AUDIT OPTIONS ISPF panel. General audit controls direct RACF to log (or not to log) certain security-relevant events, such as the activities of OPERATIONS or group-OPERATIONS users, RACF command violations, and attempts to access RACF-protected resources.

To specify the general audit controls, you must have the AUDITOR attribute. After you have initially established your controls or modified existing controls, it is a good practice to list the current options to verify that the controls are correct.

If you have the group-AUDITOR attribute, you can use only the LIST and REFRESH GENERIC operands.

Logging RACF commands and DEFINE requests

SETROPTS  AUDIT(USER  GROUP  DATASET  TERMINAL)

SETROPTS AUDIT(IMS)

The following table shows the events that SETROPTS AUDIT(class) affects:

If you have the AUDITOR attribute, you can also specify the NOAUDIT operand on the SETROPTS command and identify the class or classes for which you do not want RACF to log RACF command and DEFINE requests. If you specify NOAUDIT(*), RACF does not log RACF commands and DEFINE requests for any class.

NOAUDIT(*) is in effect at RACF initialization.

Bypassing logging of activity of users with the SPECIAL attribute

SETROPTS  NOSAUDIT

If you have the AUDITOR attribute, you can also specify the SAUDIT operand on the SETROPTS command, to indicate that you want RACF to log the command and request activity (except LISTDSD, LISTGRP, LISTUSER, RLIST, and SEARCH, which are never logged) of users with the SPECIAL or group-SPECIAL attribute.

SAUDIT is in effect at RACF initialization.

Logging the activities of users with the OPERATIONS attribute

SETROPTS  OPERAUDIT

If you specify OPERAUDIT, RACF logs all accesses to RACF-protected resources granted because the user has the OPERATIONS or group-OPERATIONS attribute, and all uses of the ADDSD, and RDEFINE commands allowed because a user has the OPERATIONS or group-OPERATIONS attribute.

OPERAUDIT overrides the audit field of data set, file, directory and general resource profiles. OPERAUDIT does not affect any auditing requested by the GLOBALAUDIT operand on the RACF commands.

If you have the AUDITOR attribute, you can also specify NOOPERAUDIT. NOOPERAUDIT does no special auditing of users with the OPERATIONS or group-OPERATIONS attribute.

NOOPERAUDIT is in effect at RACF initialization.

Logging and bypassing RACF command violations

A violation can occur because RACF does not authorize a user to modify a particular profile or to enter a particular operand on a command.

If you have the AUDITOR attribute, you can specify the CMDVIOL operand on the SETROPTS command. This operand tells RACF to log all command violations (except for LISTDSD, LISTGRP, LISTUSER, RLIST, and SEARCH, which are never logged).

CMDVIOL is in effect at RACF initialization.

SETROPTS  NOCMDVIOL

Activating auditing for security levels

If you have the AUDITOR attribute, you can activate auditing of access attempts to all RACF-protected resources. To activate this option, specify the SECLEVELAUDIT operand with an installation-defined security level name on the SETROPTS command. Auditing is done if the profile protecting a resource is equal to or greater than the security level you specify on the SECLEVELAUDIT operand.

SETROPTS  SECLEVELAUDIT(CONFIDENTIAL)

When you specify a security level, RACF audits all attempts to access resources with the specified security level and higher. This option allows your installation to audit access attempts to a RACF-protected resource, based on the sensitivity of the resource, as determined by the installation. If you do not specify a security level, RACF audits all access attempts to all resources for which your installation has defined a security level (SECLEVEL).

If you have the AUDITOR attribute, you can also deactivate auditing of access attempts to RACF-protected resources based on installation-defined security levels. To deactivate this option, specify the NOSECLEVELAUDIT operand on the SETROPTS command.

NOSECLEVELAUDIT is in effect at RACF initialization.

Activating auditing for access attempts by class

If you have the AUDITOR attribute, you can audit attempts to access resources in specified classes according to the option selected. You can specify the DATASET class and any active classes in the class descriptor table. The resources need not have profiles created in order for the auditing to occur.

SETROPTS  LOGOPTIONS(ALWAYS(TERMINAL))

LOGOPTIONS(DEFAULT(*)) is in effect at RACF initialization.

If your installation has specified SETROPTS LOGOPTIONS for any number of classes and you want this reset, specify LOGOPTIONS(DEFAULT(*)) on the SETROPTS command.

Activating auditing for security labels

SETROPTS  SECLABELAUDIT

RALTER SECLABEL EAGLE AUDIT(FAILURES(READ))

After this command has been issued, a DATASET profile that has a security label of EAGLE, but no auditing specified, will have failed access attempts audited due to the security label auditing specified.

NOSECLABELAUDIT is in effect at RACF initialization.

If your installation has specified SETROPTS SECLABELAUDIT, additional auditing is done based on SECLABEL profiles. This option can be reset to the default by specifying NOSECLABELAUDIT on the SETROPTS command. The auditing options in the SECLABEL profiles do not have to be changed, however, because NOSECLABELAUDIT causes the audit options to be ignored.

When auditing security labels with the SECLABELAUDIT function, SMF audit records are written, thus requiring a high amount of system overhead. It is advised that auditing not be turned on for every security label in the system. Only those security labels with specific auditing requirements, as defined by the installation, should be audited.

Auditing for APPC/MVS

User verification requests

There are two alternatives used in APPC/MVS that affect how auditing is performed. The alternative in effect is determined by the level of conversation security established between a pair of LUs. With either alternative, you can request a pair of audit records that mark the creation and deletion of a user's security environment.

1. One alternative uses a concept known as persistent verification (PV). When PV is used, the security environment for a user is created when the user's first transaction request enters the system. The security environment persists over multiple transactions before being deleted.
   In terms of audit records for user verification, a user is audited twice at the most:

   • First, when the user begins work on the system
   • Next, when the user signs off, regardless of how many transactions are submitted.
2. In the other alternative (non-PV), the user's security environment is created and deleted for each transaction the user requests.

   In terms of audit records for user verification, every transaction a user submits may be audited. This can potentially produce a large volume of SMF records.

With either alternative, the audit records marking the creation and deletion of the security environment contain a common audit key that links the audit records together.

With either alternative, the auditing is controlled with the APPL profile and the APPLAUDIT operand of the SETROPTS command. See Activating APPC/MVS auditing.

Transaction program auditing

Auditing of resource access attempts is done as part of day-to-day operations set up by the auditor or profile-owner for your installation. This existing auditing also occurs for transaction programs, but with a slight difference in audit records.

The audit records created by a transaction program contain an audit key that can be used to link audit records together.

In the case of persistent verification (where user verification is audited only twice-at signon and signoff), the audit key links records to a particular user. In the case of non-PV, the audit key links records created for a single transaction request.

Relationship of APPC/MVS audit records

Audit records created for users and transaction programs may be linked by a common key. All APPC/MVS audit records contain an 8-byte key that may be used to link the beginning and ending records together.

Activating APPC/MVS auditing

APPLAUDIT is a RACF option that allows user verification auditing to occur at the beginning and ending of a user's transaction processing work. Activating this auditing requires two steps:

1. You must specify the APPLAUDIT operand on the SETROPTS command.
2. You must request auditing for the APPL profile associated with an APPC/MVS LU.

SETROPTS  APPLAUDIT

RALTER   APPL profile-name GLOBALAUDIT(ALL)

Deactivating APPC/MVS auditing

SETROPTS NOAPPLAUDIT

Refreshing profiles

Refreshing in-storage generic profiles

You may want to use GENERIC REFRESH after changing the logging options in a generic profile that protects a specific data set, as described in Specific audit controls. However, extensive use of GENERIC REFRESH can adversely affect system performance.

SETROPTS  GENERIC(DATASET  TERMINAL)  REFRESH

Note that you must issue this command each time you want RACF to perform the refresh process.

If you specify GENERIC(*), RACF refreshes profile lists for the DATASET class and all active classes in the except group resource classes (such as GTERMINL and GDASDVOL). When you initiate the refresh procedure, RACF sets an indicator in the RACF communication vector table for the class(es) that you specified. After the indicator is set, RACF refreshes the profile lists the next time it invokes the generic-profile search routine.

If you specify NOGENERIC on the SETROPTS command, RACF stops using in-storage generic profile lists but does not immediately delete them. RACF deletes the profile lists at the end of the job or TSO session, or when you again specify GENERIC. When you specify GENERIC, RACF rebuilds the profile lists. (If SETROPTS GENLIST has been used on your system, a copy of the generic profiles for the resource resides in common storage. You can also use REFRESH GENERIC to refresh these in-storage generic profiles.)

For classes RACLISTed by either the SETROPTS RACLIST command or RACROUTE REQUEST=LIST, generic including discrete profiles for the class must be refreshed. This process is described in the next section.

Refreshing RACLISTed profiles

If SETROPTS RACLIST has been used on your system, copies of the discrete and generic profiles for any resource within a general resource class reside in a data space and can be shared among users. SETR RACLIST(classname) REFRESH causes the data space to be replaced with another data space containing new copies of the discrete and generic profiles from the RACF database.

If SETROPTS RACLIST has been issued for a general resource class and you change the logging options for a general resource profile in the class, you may want to use the REFRESH option to refresh the profile.

SETROPTS  RACLIST(DASDVOL  TERMINAL)  REFRESH

The RACROUTE REQUEST=FASTAUTH service routine works with in-storage profiles RACLISTed by the RACROUTE REQUEST=LIST macro with ENVIR=CREATE specified. To refresh those profiles, the application must delete them by using RACROUTE REQUEST=LIST,ENVIR=DELETE and then re-create them using RACROUTE REQUEST=LIST,ENVIR=CREATE again. However, if the GLOBAL=YES parameter is specified, a refresh is accomplished with SETR RACLIST(classname) REFRESH.

SETROPTS REFRESH processing on shared systems

If RACF is enabled for sysplex communication, the refresh operation for SETROPTS processing is propagated to all members of the RACF sysplex data sharing group.

Otherwise, the command applies only to the system (z/VM® or MVS™) on which you issue the SETROPTS command. If your installation has two or more systems sharing a RACF database, you must issue the SETROPTS command on all systems to have the refresh done on all systems.

However, if you do not perform a refresh (issue the SETROPTS command with the REFRESH option) on a system sharing a RACF database and that system needs to re-IPL, the refresh takes effect on that system when re-IPL is performed.

When you issue a SETROPTS REFRESH command, or one of the propagated RVARY commands (ACTIVE, INACTIVE, DATASHARE, NODATASHARE, SWITCH) from one member of a RACF sysplex data sharing group, the request is audited only on the system from which you issue the command, and only if auditing has been selected for that system. The request is not audited on the peer member systems (regardless of whether auditing has been selected).

For more details about SETROPTS commands that are propagated to all members of the RACF sysplex data sharing group, refer toz/OS Security Server RACF Command Language Reference.

Examples for setting audit controls using SETROPTS

The following examples show how to set system-wide audit controls by using the SETROPTS command.

SETROPTS  LIST

SETROPTS  SAUDIT  LIST

Example 1

SETROPTS  AUDIT(USER,GROUP,DATASET,DASDVOL)

Example 2

SETROPTS  SAUDIT

Example 3

SETROPTS  OPERAUDIT

Example 4

SETROPTS  AUDIT(USER)

Example 5

SETROPTS  CMDVIOL

Example 6

SETROPTS  SECLEVELAUDIT(CONFIDENTIAL)

Example 7

SETROPTS  REFRESH  GENERIC(DATASET)

SETROPTS  AUDIT(USER,GROUP,DATASET,DASDVOL)
      SAUDIT  OPERAUDIT  CMDVIOL  SECLEVELAUDIT(CONFIDENTIAL)
      REFRESH  GENERIC(DATASET)

Example 8

SETROPTS  REFRESH  RACLIST(TERMINAL)

Example 9

SETROPTS  LOGOPTIONS(ALWAYS(DEVICES))

Example 10

SETROPTS  LOGOPTIONS(ALWAYS(OPERCMDS))

Example 11

SETROPTS SECLABELAUDIT

Example 12

SETROPTS APPLAUDIT
RALTER   APPL profile-name AUDIT

Example 13 (z/OS UNIX System Services)

SETROPTS LOGOPTIONS(FAILURES(DIRSRCH,DIRACC))

Example 14 (z/OS UNIX System Services)

SETROPTS AUDIT(FSOBJ,PROCESS)

Specific audit controls

You can also list the complete contents of all profiles, including the owner-specified and auditor-specified logging options for resources.

If you have the AUDITOR attribute, you can set specific controls for any user, data set, or general resource, and list the contents of any profile. If you have the group-AUDITOR attribute, you can set controls and list profile contents only for those users, data sets, and general resources owned by the group in which you have the attribute, and any subgroup of that group.

User controls

In general, you would probably not request user audit-logging as a matter of course, but it is useful in special situations. For example, you can specify user-audit logging if you suspect, based on other indicators such as command violations, that a particular user may be misusing the system or persistently trying to access or delete resources outside the user's control. Examples of the type of event that might indicate misuse of the system are either unauthorized attempts to modify a critical system resource (such as a PARMLIB data set) or a highly classified user resource (like payroll or business-planning data).

Example

ALTUSER  SMITH  UAUDIT

Data set controls

If owner controlled logging does not provide enough information for your audit, you can use the GLOBALAUDIT operand on the ALTDSD command or request the corresponding function on the AUDIT DATA SET ACCESS panel, in addition to the owner-specified logging values, to log user accesses to data sets.

GLOBALAUDIT allows you to specify logging for different kinds of attempts that users make to access resources at a given access level. With GLOBALAUDIT, you can log successful accesses, failed accesses, or both to a given resource and specify READ, UPDATE, CONTROL, or ALTER for the access level to the resource.

Figure 1 summarizes the GLOBALAUDIT operand for ALTDSD and what you are able to specify for logging. (For a complete description of the ALTDSD command and its operands, see z/OS Security Server RACF Command Language Reference.)

        [               {   ALL                                     }   ]
        [               {{{ FAILURES }                        }     }   ]
ALTDSD  [ GLOBALAUDIT ( {{{ NONE     } {(audit-access-level)] } ... } ) ]
        [               {{{ SUCCESS  }                        }     }   ]

As with the other specific controls, you do not audit accesses to most data sets, as a general rule. Therefore, GLOBALAUDIT(NONE) is the default for the operand. After you complete your audit of the data set, it is good practice to restore the default. When GLOBALAUDIT(NONE) is in effect, RACF logs accesses to the data set only as specified by the resource owner.

Example 1

ALTDSD  'JIM.MEMO.TEXT'  GLOBALAUDIT(ALL(READ))

Example 2

ALTDSD  'A.B.C'  GLOBALAUDIT(FAILURES(READ) SUCCESS(UPDATE))

General resource controls

You can use the GLOBALAUDIT operand on the RALTER command or request the corresponding function on the AUDIT GENERAL RESOURCES ACCESS panel to log user accesses to a specific general resource.Because the audit level that you specify on GLOBALAUDIT overrides the level the resource owner specified in the profile, you use it when the logging specified in the profile does not produce enough information for your needs.

When you set audit controls for a general resource, you specify what information RACF is to log-the result of the access attempt-and when RACF is to log the information-the level of access. Figure 1 shows the various valid combinations of what to log and when to log it.

As with the other specific controls, you would not audit accesses to most general resources usually. Therefore, GLOBALAUDIT(NONE) is the default for the operand. After you complete your audit of the general resource, it is good practice to restore the default. When GLOBALAUDIT(NONE) is in effect, RACF logs accesses to the resource as specified in the profile.

Example

RALTER  TAPEVOL  NR1234  GLOBALAUDIT(ALL(READ))

Listing specific audit controls

RACF provides commands and corresponding ISPF panels that allow RACF users, depending on their authority or attributes, to examine the contents of RACF profiles. You, as auditor, can list the contents of all the RACF profiles (or all the profiles within the scope of your group if you are a group-AUDITOR). You can find a complete description of each of the commands, including sample output, in the z/OS Security Server RACF Command Language Reference.

Example

LISTDSD  DA('JIM.MEMO.TEXT')  ALL

LISTDSD  DA('JIM.MEMO.TEXT')  ALL  GENERIC

Auditing for the RACF/DB2 external security module

The RACF/DB2 external security module allows you to use RACF resource profiles to check authorization for DB2® privileges and authorities. With these profiles, which represent the various DB2 privileges, you can use the RACF auditing tools to extract the information you need.

You can use the SMF data unload utility or the RACF report writer to extract and format the SMF records. When the RACF/DB2 external security module uses a RACROUTE REQUEST=FASTAUTH request to create an audit record, the record contains log string data that includes additional diagnosis information described in Using the log string (LOGSTR) data. You can use the log string information to link DB2 trace record IFCID 314 and a corresponding RACF SMF record.

Restriction

This topic contains information about using RACF with DB2 Version 7, and earlier DB2 versions. For information about using RACF with DB2 Version 8, and later DB2 versions, see http://publib.boulder.ibm.com/infocenter/imzic.