Annex C
(informative)

Security audit (FAU)

CC audit families allow PP/ST authors the ability to define requirements for monitoring user activities and, in some cases, detecting real, potential, or imminent violations of the TSP. The TOE's security audit functions are defined to help monitor security-relevant events, and act as a deterrent against security violations. The requirements of the audit families refer to functions that include audit data protection, record format, and event selection, as well as analysis tools, violation alarms, and real-time analysis. The audit trail should be presented in human-readable format either directly (e.g. storing the audit trail in human-readable format) or indirectly (e.g. using audit reduction tools), or both.

While developing the security audit requirements, the PP/ST author should take note of the inter-relationships among the audit families and components. The potential exists to specify a set of audit requirements that comply with the family/ component dependencies lists, while at the same time resulting in a deficient audit function (e.g. an audit function that requires all security relevant events to be audited but without the selectivity to control them on any reasonable basis such as individual user or object).

Audit requirements in a distributed environment:

The implementation of audit requirements for networks and other large systems may differ significantly from those needed for stand-alone systems. Larger, more complex and active systems require more thought concerning which audit data to collect and how this should be managed, due to lowered feasibility of interpreting (or even storing) what gets collected. The traditional notion of a time-sorted list or "trail" of audited events may not be applicable in a global asynchronous network with arbitrarily many events occurring at once.

Also, different hosts and servers on a distributed TOE may have differing naming policies and values. Symbolic names presentation for audit review may require a net-wide convention to avoid redundancies and "name clashes."

A multi-object audit repository, portions of which are accessible by a potentially wide variety of authorised users, may be required if audit repositories are to serve a useful function in distributed systems.

Finally, misuse of authority by authorised users should be addressed by systematically avoiding local storage of audit data pertaining to administrator actions.

Figure C.1 shows the decomposition of this class into its constituent components.


Figure C.1 - Security audit class decomposition