RE: Interpretation of FAU_SEL.1.1 and FAU_STG.4.1

["Arnold, James L. Jr." <JAMES.L.ARNOLD.JR@saic.com>]

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

It seems like we are interpreting the requirement perhaps in the wrong
direction. I believe that FAU_STG.4 is about what happens when the audit
trail is full (or, in other words, when audit records cannot be saved). I
see no reason at all that the audit trail has to be included in the TOE.
FAU_STG.1, on the other hand, is about protecting the audit trail so I would
tend to think the audit trail would need to be in the TOE (or alternately
encapsulated by it in some interesting manner). However, it would seem valid
to send audit records off to some external trusted (e.g., to protect the
audit data) entity and to respond to its responses. When the audit storage
entity indicates that it is full, the TOE must act as specified in the SFR.

I see no reason to deny a TOE this SFR claim if it has the capability to
respond appropriately when it becomes aware that audit records can no longer
be recorded.