RE: SFRs - Requirement Specification or Implementation Descripti on?

["Arnold, James L. Jr." <JAMES.L.ARNOLD.JR@saic.com>]

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