Re: SFRs - Requirement Specification or Implementation Description?

[Helmut Kurth <helmut@atsec.com>]

Tony,

our experience so far is that the functionality you have described is
able to satisfy the requirements of FAU_GEN.1 with respect to auditing
the starup and shutdown of the audit function. Since this is combined
with the startup and shutdown of the TOE and an audit record is
generated for those events, and provided the design documentation and
the guidance explains this, I don't see any reason why this part of
FAU_GEN.1 is not satisfied. We have had a TOE that implemented the audit
of the startup and shutdown of the audit system in the same way and this
got accepted (in the German scheme) provided the guidance clearly
explained this behavior such that someone that examines the audit
records is able to associate the audit records generated as a result of
the startup and shutdown of the TOE with the startup and shutdown of the
audit system. In addition the TOE design and implementation needs to be
analyzed that it does not generate auditable events (as defined in
FAU_GEN.1) before the audit system is started and after the audit system
is shut down.

This is our experience.


Apted, Tony J. [RA] wrote:

> 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
>


-- 
Helmut Kurth, atsec information security
www.atsec.com