The Security audit data generation family includes requirements to specify the audit events that should be generated by the TSF for security-relevant events.
This family is presented in a manner that avoids a dependency on all components requiring audit support. Each component has an audit section developed in which the events to be audited for that functional area are listed. When the PP/ST author assembles the PP/ST, the items in the audit area are used to complete the variable in this component. Thus, the specification of what could be audited for a functional area is localised in that functional area.
The list of auditable events is entirely dependent on the other functional families within the PP/ST. Each family definition should therefore include a list of its family-specific auditable events. Each auditable event in the list of auditable events specified in the functional family should correspond to one of the levels of audit event generation specified in this family (i.e. minimal, basic, detailed). This provides the PP/ST author with information necessary to ensure that all appropriate auditable events are specified in the PP/ST. The following example shows how auditable events are to be specified in appropriate functional families:
"The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
a) Minimal: Successful use of the user security attribute administration functions;
b) Basic: All attempted uses of the user security attribute administration functions;
c) Basic: Identification of which user security attributes have been modified;
d) Detailed: With the exception of specific sensitive attribute data items (e.g. passwords, cryptographic keys), the new values of the attributes should be captured."
For each functional component that is chosen, the auditable events that are indicated in that component, at and below the level indicated in FAU_GEN should be auditable. If, for example, in the previous example `Basic' would be selected in FAU_GEN, the auditable events mentioned in a), b) and c) should be auditable.
Observe that the categorisation of auditable events is hierarchical. For example, when Basic Audit Generation is desired, all auditable events identified as being either Minimal or Basic, should also be included in the PP/ST through the use of the appropriate assignment operation, except when the higher level event simply provides more detail than the lower level event. When Detailed Audit Generation is desired, all identified auditable events (Minimal, Basic, and Detailed) should be included in the PP/ST.
A PP/ST author may decide to include other auditable events beyond those required for a given audit level. For example, the PP/ST may claim only minimal audit capabilities while including most of the basic capabilities because the few excluded capabilities conflict with other PP/ST constraints (e.g. because they require the collection of unavailable data).
Application Notes
The functionality that creates the auditable event should be specified in the PP or ST as a functional requirement.
The following are examples of the types of the events that should be defined as auditable within each PP/ST functional component:
a) Introduction of objects within the TSC into a subject's address space;
b) Deletion of objects;
c) Distribution or revocation of access rights or capabilities;
d) Changes to subject or object security attributes;
e) Policy checks performed by the TSF as a result of a request by a subject;
f) The use of access rights to bypass a policy check;
g) Use of Identification and Authentication functions;
h) Actions taken by an operator, and/or authorised user (e.g. suppression of a TSF protection mechanism as human-readable labels);
i) Import/export of data from/to removable media (e.g. printed output, tapes, diskettes).