RE: SFRs - Requirement Specification or Implementation Description?

[Nir Naaman <nir.naaman@metasec.com>]

The way I and others on this list understand FAU_GEN.1 is that the
startup/shutdown of audit functions is stated explicitly as an auditable
event in order for the audit reader to be able to determine that there are
"holes" in the audit trail, i.e. periods of time when auditable events might
have occurred but not recorded.

If in the context of the TOE and its operational environment there can be no
such holes (i.e. audit functions cannot be disabled, and auditable events
cannot occur when the TOE is inactive), then the requirement to audit
shutdown of the audit functions is vacuously met (a shutdown cannot occur
and not be audited - since it cannot occur).

In this case, I suggested that a valid approach might be a refinement of the
FAU_GEN.1 component, to clarify that the auditable event is the startup of
the TSF (and its audit functions), and maybe shutdown of the TSF as well.

If the audit functions can be disabled, and this is auditable by the IT
environment of the TOE, then FAU_GEN.1 might be allocated to both TOE and
environment working together to fulfill the requirement.

An explicitly stated requirement should be a last resort, because FAU_GEN.1
is a very critical dependency of many other SFRs, and a rationalization of
those dependencies based on an extended requirement (that is not stated to
be hierarchical to FAU_GEN.1) would be required.

Best regards,
    Nir Naaman

> -----Original Message-----
> From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of 
> YOKOTA HIROFUMI
> Sent: Wednesday, December 06, 2006 2:55 AM
> To: Multiple recipients of list
> Subject: Re: SFRs - Requirement Specification or 
> Implementation Description?
> 
> 
> Please correct me.
> There is a case that the TOE does not provides the startup 
> time and shutdown time, but the IT environment does.
> In such case, yes, we could say, as discussed here, that:
> 1) audit startup/shutdown functions are vacuously satisfied, or
> 2) those functions are to be optional, or
> 3) an explicitly stated requirement should be used.
> 
> Regards,
> Hirofumi Yokota
> 
> ----- Original Message -----
> From: "YOKOTA HIROFUMI" <yokota-hirofumi@jqa.jp>
> To: "Multiple recipients of list" <cc-cmt@nist.gov>
> Sent: Monday, December 04, 2006 3:30 PM
> Subject: Re: SFRs - Requirement Specification or 
> Implementation Description?
> 
> 
> >
> > I think, there are variations. Sometimes, the TOE's 
> startup/shutdown might
> > be the audit function's startup/shutdown, or enabling/disabling some
> > security modules could be the audit functions 
> startup/shutdown. Or, for
> some
> > auditable events, disc failures, communication failures and those
> recoveries
> > might be the audit startup/shutdown functions.
> >
> > In any above cases we would need to audit the "time", when 
> the auditing is
> > enabled and/or disabled.
> >
> > Regards,
> > Hirofumi Yokota
> >
> >
> >
> >
> >
> 
>