RE: SFRs - Requirement Specification or Implementation Description?


It is my understanding that it has always been possible for a requirement to be ‘vacuously’ satisfied.  Whenever the requirement is made null or unnecessary by specific characteristics of the TOE, and this does not thereby prevent satisfying the intent of the requirement, the requirement is considered to have been met. 

 

This case here is a great example of same.  The startup and shutdown of the auditing must be recorded.  But if audit is never shut down separate from device shutdown and audit is always active upon startup, then it is true that every (every, every, every) audit startup and shutdown is being audited with the device startup and shutdown entries.  A separate audit entry for audit startup and shutdown is clearly neither helpful nor useful and not needed to fully comply with the SFR.

 

Cheers,

Gary

 


************************************************************************
* Opinions are not intended to reflect an official position of JHU/APL *
************************************************************************
* Gary Stoneburner                                                     *
* Johns Hopkins University Applied Physics Laboratory                  *
* 11100 Johns Hopkins Road, MS 17-N406                                 *
* Laurel, MD 20723-6099                                                *
* Phone: 240-228-2628 (WA DC), 443-778-2628 (Baltimore)                *
* Fax: 240-228-6391 (WA DC), 443-778-6391 (Baltimore)                  *
*
Gary.Stoneburner@jhuapl.edu                                          *
************************************************************************


From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of Apted, Tony J. [RA]
Sent: Wednesday, November 29, 2006 1:55 PM
To: Multiple recipients of list
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

 

 



Date Index | Thread Index | Problems or questions? Contact list-master@nist.gov