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

["YOKOTA HIROFUMI" <yokota-hirofumi@jqa.jp>]

Hi,

The following two requirements were mentioned in 'Resolution' of this PD.

--------------------------------------------
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.
--------------------------------------------

I am a bit in confusion here about the use of the labeling convention.
We are instructed about the "labeling convention in NIAP interpretations" at
the web page "http://cio.nist.gov/esd/emaildir/lists/cc-cmt/msg00019.html".

Which says:

1) NIAP-nnnn-m, where nnnn is the interpretation number, and m is
either the new tag (for new classes or families) or (for new
components, elements, or work units) a digit to differentiate the item
from other new items resulting from the same interpretation

2) When the changed item has a label affected by a prior interpretation,
the previous NIAP-nnnn tag is removed. For example, if existing
FPT_SEP.1.1-NIAP-1234 is changed by a subsequent interpretation
I-5678, the changed tag is FPT_SEP.1.1-NIAP-5678, not
FPT_SEP.1.1-NIAP-1234-NIAP-5678.

then, the "NIAP-0429-virus" is what? A new class? or a new family?
and why is the previous "NIAP-0413" not removed ?

Also, I cannot differenciate the intents of those two new requirements
clearly,
although I read the "Issue" and "Rationale" easy.

It looks that above new requirements are putting a refinement each other as
the following.

'shall alert the administrator'
-> 'shall display an alert on the  screen of the Central Administrator if a
session is active'

'before  audit storage failure'
-> 'before audit storage reaches capacity'

Could someone help and explain ?

Regards,
Hirofumi Yokota


----- Original Message ----- 
From: "Observation Decisions Review Board" <faigin@aero.org>
To: "Multiple recipients of list" <cc-cmt@nist.gov>
Sent: Tuesday, October 31, 2006 1:29 AM
Subject: 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.
>
>
>
>