|
I think, this might be the case we need
the TSS description on how to implement the requirement
(FAU_GEN.1).
When we implement the requirement
FAU_GEN.1 in the TOE as one large audit functions covered by the
whole TOE, the auditing of the start-up of the TOE would be the auditing of the
start-up of the audit functions. While, if we implement the requirement FAU_GEN.1 in some partial mofules in
the TOE as the audit functions, then the audit modules should have their own
audit start-up and shut-down routines inside and those routines should be
audited when invoked.
Regards,
Hirofumi Yokota
----- Original Message -----
Sent: Thursday, November 30, 2006
3:54 AM
Subject: SFRs - Requirement
Specification or Implementation Description?
What is the purpose of Security
Functional Requirements (SFRs) in a Security Target? Are they intended to
specify what security functionality is to be provided by the TOE, or to
specify the security functionality the TOE
implements?
This question is raised as the
result of a recent validator comment. The ST claims FAU_GEN.1 and the TSS
explains that the TOE satisfies the aspect of the requirement to audit startup
and shutdown of the audit function because auditing is always enabled – when
the TOE starts up, an audit record of TOE startup is generated, which
indicates the startup of the audit function (and, similarly, the TOE generates
an audit record that it is shutting down, indicating shutdown of the audit
function). To my knowledge, and in my own experience, this reasoning has
always been acceptable for justifying that a TOE satisfies this aspect of
FAU_GEN.1. 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 am interested in other people’s
views about this.
Anthony J.
Apted
Lead Evaluator/Senior System
Security Engineer
SAIC
CCTL
Ph: (410)
953-6837
Fx: (410)
953-7001
|