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



The ODRB has just issued the following PD:

PD 0129: 

Deletion of the oldest audit events when audit storage space is exhausted

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.

	FAU_STG.NIAP-0414-3-NIAP-0429-virus. The TSF shall display an alert on the 
screen of the Central Administrator if a session is active [selection: time 
period, number of records, percent free audit storage space available] before 
audit storage failure.

The following Application Note 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.

RATIONALE

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.





Date Index | Thread Index | Problems or questions? Contact list-master@nist.gov