Re: Interpretation of FAU_SEL.1.1 and FAU_STG.4.1
- Subject: Re: Interpretation of FAU_SEL.1.1 and FAU_STG.4.1
- From: "NIAP Interpretations Board" <firstname.lastname@example.org>
- Date: Thu, 02 Sep 2004 13:07:29 -0700
- Content-description: Mail message body
- Content-transfer-encoding: 7BIT
- Content-type: text/plain; charset=US-ASCII
- Priority: normal
The NIB saw the following questions in this chain.
The first question dealt with the meaning of FAU_SEL.1. Nir is correct when he
notes the SFR has to do with audit preselection. It is not related at all to
modules "registering" the events they can handle; rather, the requirement deals
with establishing a filter of which auditable events are indeed audited and
captured in the audit trail.
The second question revolves around FAU_STG.4. If the NIB understands your
example correctly, the database system is outside the TOE. Thus, the TOE in
question would actually fail FAU_STG.4, because the TSF doesn't actually store
the audit. The example provided:
> 3. When a user tries to start the system:
> 3.1. If the audit trail no longer is full, then the event
> registered in the auxiliary storage is moved to the Audit Trail. In
> this case the system can start correctly.
> 3.2. If the audit trail still is full, then is not possible to
> start the system,
is reasonable, but for the system in question, tailoring of the SFRs would be
With respect to the last question: If the audit trail is full, and there is a
requirement that audit not be lost, the system cannot be brought up into a
"secure state" (for the secure state implies audit can be recorded). It needs
to be brought up in a maintenance mode, where some audit records are moved
offline to make space for additional auditing.
Date Index |
Thread Index |
Problems or questions? Contact email@example.com