RE: SFRs - Requirement Specification or Implementation Descripti on?

[Nir Naaman <nir.naaman@metasec.com>]

The validator's position does have some merit in that vacuous statements
tend to be misleading.
For example, you could have a PP SFR that requires some third-party
validation for all cryptography used in the TOE. If the TOE does not use
cryptography (and therefore has not been validated), I would think it would
be clearer to omit the given SFR rather than claim it vacuously. You would
then rationalize this omission in the PP Rationale.

In the specific case we've been discussing, a simple refinement of FAU_GEN.1
that makes it clearer what is actually being audited should do the job.

In addition, if the validator felt that it would be natural for reader of
the ST to presume that the audit trail could be disabled, the ST could claim
the following SFR:
FMT_MOF.1.1 The TSF shall restrict the ability to disable the function audit
to no user.

This would make it clear that disabling the audit trail (without a
corresponding audit record being generated) would be considered a violation
of the TOE SFRs.

    Nir

> -----Original Message-----
> From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of 
> Arnold, James L. Jr.
> Sent: Thursday, November 30, 2006 6:53 PM
> To: Multiple recipients of list
> Subject: RE: SFRs - Requirement Specification or 
> Implementation Descripti on?
> 
> I don't think auditing of starting/stopping the TOE should be 
> required when there is no ability to start/stop the auditing 
> function separately. Assuming the intent of the specific 
> requirement is so that the auditor knows when auditing is 
> disabled and hence the TOE is not generating audit events, if 
> the TOE is always generating audit events the intent is 
> satisfied. Whether starting and stopping of the TOE itself is 
> audited is a different topic and could be addressed as a 
> separate auditable event. As an example, if a several hour 
> gap turns up in a audit trail, what is the security 
> difference or ramification if that was because the TOE 
> processed no security relevant events during that time or it 
> was offline during that time? On the other hand, if the TOE 
> is operating and not generating audit events, it might be 
> security-interesting to know unrecorded things could have 
> been happening.
>  
> I think explicit SFRs should be avoided when possible and 
> while one shouldn't go out of their way to assert SFRs that 
> are satisfied vacuously, the possibility that they can be met 
> vacuously should remain. This is particularly important when 
> dealing with PPs. Another similar example that should be 
> allowable when dealing with PPs, for example, is instead of 
> restricting the ability to perform some management function 
> (e.g., modify audit records) it should be acceptable if the 
> TOE doesn't provide that function at all.
>  
> 
> 
> ________________________________
> 
> 	From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On 
> Behalf Of Tom Benkart
> 	Sent: Thursday, November 30, 2006 11:22 AM
> 	To: Multiple recipients of list
> 	Subject: Re: SFRs - Requirement Specification or 
> Implementation Description?
> 	
> 	
> 	I agree with your view - this has been an accepted 
> position in multiple evaluations that I've been involved with.
> 	
> 	If starting/stopping the TOE is equivalent to 
> starting/stopping the audit function and an audit is 
> generated for those events, then the requirement is 
> satisfied.  There is no requirement that a separate 
> management operation for starting/stopping the audit function 
> be available.
> 	
> 	If an explicitly stated variant of FAU_GEN is used, 
> another possible issue is introduced - is the dependency on 
> FAU_GEN from other SFRs satisfied?  
> 	
> 	Tom
> 	
> 	At 01:54 PM 11/29/2006, you 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
> 		 
> 		 
> 
> 	Tom Benkart
> 	Common Criteria Consulting LLC
> 	work: 301-570-9308
> 	cell: 240-401-1173
> 	tom.benkart@consulting-cc.com 
> 
>