RE: I-0387: Auditing Of Audit Storage Failures

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

> -----Original Message-----
> From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of 
> NIAP Interpretations Board
> Sent: Thursday, September 02, 2004 4:19 PM
> To: Multiple recipients of list
> Subject: Re: I-0387: Auditing Of Audit Storage Failures
> 
> 
> 
>   [NOTE: This proposal is being re-posted after being updated 
> to reflect
>   comments the NIB received on its previous posting, or 
> comments arising
>   from further NIB discussion of the proposal.]
> 
>   The following is a proposal for formal CCEVS guidance related to the
>   Common Criteria and ancillary documents. It is being posted in
>   accordance with the procedures of the NIB.
> 
>   Comments on this proposal are welcomed and should be posted to this
>   transaction chain.  If any party wishes to post a comment 
> anonymously,
>   the comment should be mailed to cc-cmt@nist.gov in a form 
> suitable for
>   posting.  All comments should be posted no later than 
> Sunday, October
>   10, 2004.
> 
> 
>                       CCITSE/CEM  GUIDANCE (PROPOSED)
> 
>      _________________________________________________________________
> 
>                   I-0387: Auditing Of Audit Storage Failures
>      _________________________________________________________________
> 
> TYPE:                 Guidance
> NUMBER:               I-0387
> STATUS:               Ready for External Repost after 
> Interpretations Board
>                       Rework/Review
> 
> TITLE:                Auditing Of Audit Storage Failures
> 
> COMMENTS DUE BY:      Sunday, October 10, 2004 to cc-cmt@nist.gov
> 
> SOURCE REFERENCE:     CC v2.1 Part 2 Subclause 3.6 FAU_STG.4
>                       CC v2.1 Part 2 Subclause 3.6 
> FAU_STG.NIAP-0414-1 RELATED TO:
>      I-0348           Audit Data Loss Prevention Method May 
> Be Site-Selectable
>      I-0414           Site-Configurable Prevention Of Audit Loss
> 
> ISSUE:
> 
>    If the audit storage fails due to lack of storage space for audit
>    records, it is difficult to store an audit record in the 
> audit trail
>    indicating that subsequent auditable events will be ignored.

I am a little confused about which requirement this applies to. FAU_STG.4 is
about what happens when the audit trail becomes full. If events are
overwritten or ignored, for example, I don't see the problem. I would tend
to think PPs would require what they want and STs would claim what they do.
Is there an expectation that this event needs to be generated in the first
place?

> STATEMENT
> 
>    When the audit trail is full, the audit related to the action taken
>    due to storage failure should be stored in an alternate location.

Note that while this guidance might work in some cases (e.g., where the
entire non-volatile storage media is not already consumed), it is not clear
when it should be applied. As indicated above, this is completely
unnecessary if FAU_STG.4 indicates that audit records will be ignored or
overwritten when the space is exhausted.

> SUPPORT:
> 
>    This interpretation addresses a difficulty that exists in 
> some cases
>    of audit storage failure. In particular, this 
> interpretation permits
>    the audit record of the failure in such cases to be recorded in an
>    alternate location. This will permit retrieval of the record in a
>    maintenance mode, when the situation that resulted in audit failure
>    may be corrected and normal auditing behavior restored.
> 
>    Note: This interpretation is being applied to the CC as modified by
>    I-0414.

Note that while this guidance suggests that an alternate location should be
used to record audit failure conditions, there is not guidance that ensures
that the TOE actually provides a means to get access to that data. Perhaps
the intention is that this is just part of the audit trail and FAU_SAR.1
covers it, in which case it is interesting to note that this proposed
interpretation is in effect an implementation suggestion that probably
applies to few situations.