Skip to main content

3.10.3 Managing Auditing


3.10.3 Managing Auditing
The system administrator determines which audit class, audit event, or user to use for auditing before performing auditing. The system administrator also determines at which audit log usage level a warning is generated and what action is taken when the capacity becomes full. These determinations are referred to as the audit policy, which is configured on the XSCF before auditing. The system administrator refers to each audit record in the audit log collected based on the audit policy to check the audit information for any abnormal or suspicious access.

The following provides details on the audit events, audit policy, and audit record, and audit log used for auditing.
Audit event
An audit event is a security-related system operation that can be audited.
Audit events are described below.
  1. XSCF configuration changes, such as an IP address change
  2. Physical partition-related setting changes, operations, and status display
  3. Use of any authentication
  4. Changes to user security attributes, such as the password and user privileges
  5. Reading of audit record information (including failed attempts)
  6. Audit policy changes
  7. Change of the destination of e-mail to be sent when the audit log capacity threshold is exceeded
  8. Changes by the system administrator to an audit log.
  9. Time changes
Audit policy
The audit policy determines how to execute the audit function. The following audit function settings can be configured:
  1. Whether to enable/disable the audit function
  2. Types of events to be audited
  3. An auditor for events
  4. The audit log capacity threshold at which a warning is generated and the destination of e-mail to be sent when the threshold is exceeded
  5. Operation performed when an audit log reaches full capacity (Use this setting with the default value.)
Note - If you want to use e-mail to report that the audit log capacity threshold is exceeded, configure the SMTP server using the setsmtp command.
Audit record and audit log
Audit records are saved in the 4-MB audit log in the XSCF. An audit log is saved in binary format, but can be exported in XML format.
An audit log has two areas: primary and secondary. When these areas become full and a new audit record is generated, the record is not saved but discarded (dropped).
To prevent new audit records from being discarded, the system administrator deletes secondary area data before the audit log reaches full capacity. After the deletion of the secondary area, the primary area becomes a new secondary area and a new primary area is created. When a new audit record is generated, the record is written to the new primary area.
Note - "count" (default) is set as the operation performed when an audit log reaches full capacity. With this setting, new audit records are discarded (dropped) when the audit log reaches full capacity, and the number of discarded records is counted (drop count).
Note - If you specify "suspend," degradation due to an error may occur or the XSCF may be rebooted. Specify "count," which is the default, as the policy for writing to the audit log. Also note that, in XCP 2250 and later, specifying "suspend" results in the same operation as when "count" is specified.
Use the audit policy to set the threshold of the file capacity (such as 50%, 75%, or 80%) so that a warning appears before an audit log reaches full capacity. Upon this warning, the system administrator manually archives the audit log and deletes audit records to secure sufficient new storage. Or, he/she disables the audit function. The older file of the two audit log areas is deleted. If this deletion is performed twice in succession, all the data of the audit log will be deleted.
Note - For XSCF auditing in a configuration with multiple SPARC M12-2S/M10-4S systems, both audit logs on the master and standby XSCFs need to be referred to. For details, see "3.10.10 Managing the Audit Log of the Standby XSCF."