PD-0129: Deletion of the oldest audit events when audit storage space is exhausted

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Issue

The BR Anti-Virus PP includes the following SFR:

FAU_STG.NIAP-0414-1-NIAP-0429 The TSF shall provide the administrator the capability to select one or more of the following actions [selection: 'ignore auditable events', 'prevent auditable events, except those taken by the authorised user with special rights', 'overwrite the oldest stored audit records'] and [assignment: other actions to be taken in case of audit storage failure] to be taken if the audit trail is full.

If a vendor chooses 'overwrite the oldest stored audit records' the specifics of this action are ambiguous. There is a school of thought that it is only acceptable to delete the minimum number of old audit records necessary to insert a single new audit record, but this is extremely inefficient in an environment capable of generating large numbers of audit records within a short period of time.

Is it acceptable to delete more than the exact number of audit records required to insert a single new record?

Resolution

The following requirement will be added to the Basic Robustness Anti-Virus Protection Profile:

FAU_STG.NIAP-0414-3-NIAP-0429 The TSF shall alert the administrator [selection: time period, number of records, percent free audit storage space available] before audit storage reaches capacity.

The following Application Notes will be added to the element in the PP:

Application Note: The TOE should alert the administrator prior to audit storage becoming exhausted. The objective of this alert is to allow the administrator sufficient time to resolve the audit storage shortage before records must be deleted (for example, by archiving). When audit storage is exhausted and deletion of records is to occur, an administrative alert containing details of the deletion should be recorded in an alternate audit storage location.

Application Note: The ST and VR should characterize the specific behavior of the TOE when audit storage is exhausted. In general, the TOE should delete the minimum number of audit records required, taking into account TOE performance issues. It may be appropriate to delete the newest audit records rather than the oldest. The TOE may also employ a mechanism to delete audit records that are essentially identical. The ST should contain a rationale for the audit storage deletion policy and deletion quantity.

Application Note: The intent of the assignment in this SFR is to indicate the point at which an alert is required. Example completions are along the lines of:

• ...shall alert the administrator [10 minutes] before audit storage reaches capacity.
• ...shall alert the administrator [10 records] before audit storage reaches capacity.
• ...shall alert the administrator [when 3% of the storage space remains] before audit storage reaches capacity.

Support

The Protection Profile provides limited options for the amount or timing of record deletion when audit storage is exhausted. The first Application Note provides advanced administrator notification that audit storage limits are being reached. Any actual audit record deletion should be recorded in a different location to provide the administrator with a record of the event. The second Note requires the ST to describe how the TOE will address audit storage shortfalls, and gives guidance on possible deletion strategies. The second Note also requires the developer to provide a rationale in the ST for the deletion policy implemented.

In high-volume scenarios it may be impractical from a performance perspective to delete one record for every new record insertion. The developer may choose to delete multiple record "chunks" to achieve adequate performance. The developer should explain the rationale behind their choice of record deletion "chunk" size.

In a scenario with high numbers of audit records suddenly overwhelming the audit storage, the most useful audit data may be the initial records. In this case it may be more useful to purge essentially identical new records, or simply the most recent records, in order to preserve evidence of the start of the event.

Modification History:

2006-10-30

PD Created. [October 2006 ODRB Agenda Item 3.a.iii

2007-02-14

PD Updated to clarify SFRs and provide example. [February 2007 ODRB Agenda Item 4.d.iii

References:

• Common Criteria for Information Technology Security Evaluation - Part 2: Security functional requirements, August 2005, Version 2.3, CCIMB-2005-08-002
• Common Criteria for Information Technology Security Evaluation - Part 3: Security assurance requirements, August 2005, Version 2.3, CCIMB-2005-08-003

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0253