Re: SFRs - Requirement Specification or Implementation Description?

["YOKOTA HIROFUMI" <yokota-hirofumi@jqa.jp>]

I think, in this case and many other cases, startup and shutdown of audit
function would be mandatory functions, not optional.
When we review audit records, it is not sufficient only to see, for example,
an audit-event 'A' has occurred at 10:00 and an audit-event 'B' has occurred
at 12:00.

We would need more of the followings, and if they are not, the above audit
records would be useless and not reliable in the view of security.
1. the TOE startup (time) - for example, at 6:00
2. the TOE shutdown (time) - for example, at 18:00
3. justification that all audit-events are recorded between the TOE startup
time and the TOE shutdown time.
4. justification that no audit-events are recorded outside from the TOE
startup time to the TOE shutdown time.

It would not be sufficient to say that audit startup function is vacuously
satisfied when all the audit-events are recorded after the TOE's startup,
and also, it wout not be sufficient to say that audit shutdown function is
vacuously satisfied when no audit-events are recorded after the TOE 's
shutdown.

I think that audit startup function would be satisfied by describing above
1,3 and 4 in the TSS.
Also, I think that audit shutdown function would be satisfied by describing
above 2, 3 and 4 in the TSS.

Regards,
Hirofimi Yokota

----- Original Message ----- 
From: "Dirk-Jan Out" <out@itsef.com>
To: "Multiple recipients of list" <cc-cmt@nist.gov>
Sent: Friday, December 01, 2006 7:45 PM
Subject: Re: SFRs - Requirement Specification or Implementation Description?


>
> On Thursday 30 November 2006 21:18, Squires, Alicia wrote:
> > "The validator, however, insists that the ST must explicitly state its
> > audit requirement because it clearly does not audit startup and shutdown
> > of the audit function (because the TOE does not provide a capability to
> > turn the audit function on and off)."
> >
> > I've had an issue with some evaluations not being able to meet FAU_SEL.1
> > because they could not turn specific audit functionality on and off, but
> > I've never heard of this being a requirement for FAU_GEN.1.
> >
> > The assertion that a requirement to generate audit events also requires
> > the ability NOT to generate them is contradictory.
>
> The real problem is with FAU_GEN.1 making the recording of start-up and
> shutdown mandatory. While this is a nice thing to have for an OS, other
TOEs
> have problems with it.
>
> In the "alternate" Part 2 drafts for CC 3.0 FAU_GEN was "parametrized" by
> making these items (and others) part of selections.
>
> Heavily summarized "The TSF shall audit [selection: TSF startup, TSF
shutdown,
> [assignment: other events]]"
>
> A PP author was thereby forced to *consider* including startup and
shutdown
> (and others) when making the selections, but not forced to actually
include
> them.
>
> Dirk-Jan
>