RE: SFRs - Requirement Specification or Implementation Description?

["John Boone" <jboone@ashtonlabs.com>]

Hi,

I don't think a refinement would be necessary ...

It is the interpretation of the audit record that matters; i.e., there
doesn't have to be an explicit record that says, "audit is starting," etc.
The record itself could say something arbitrary (e.g., "welcome"), but if
the interpretation of this in the admin guide is that this record means the
TOE is starting and audit is starting, I think that is good enough.

In the previous message by Hirofumi Yokota, if time stamps are provided by
the IT environment that is a dependency of FAU_GEN.1 - which can be
appropriately satisfied by the IT envirionment. FAU_GEN.1 only says that the
information has to be in the audit records, so as long as the records have
this information nothing has to be done with FAU_GEN.1.

	-John

> -----Original Message-----
> From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of Nir Naaman
> Sent: Wednesday, December 06, 2006 5:07 AM
> To: Multiple recipients of list
> Subject: RE: SFRs - Requirement Specification or Implementation
> Description?
> 
> 
> 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
> > >
> > >
> > >
> > >
> > >
> >
> >