Re: Interpretation of FAU_SEL.1.1 and FAU_STG.4.1



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

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 list-master@nist.gov