PD-0085: How to Handle Explicitly Specified Requirements?

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Issue

An evaluation has included some explicitly specified requirements as SFRs. Do I need to get community concurrence on the correctness of these requirements?

Resolution

The rules that should be followed when dealing with explicit requirements are:

1. Is there an Objective that results in the need for the security requirement? (If no, then stop)
2. If the answer to 1 is yes, then is the necessary security requirement already in the CC? (If yes, then use it)
3. If the answer to 2 is no, the explicit requirement is needed. It must be constructed in such a way that compliance (i.e. passing) can be measured. If it is an assurance requirement, there must also be an accompanying explicit methodology for determining compliance.

Community concurrence (i.e., generation of an OR) is required only if the evaluation methodology for explicitly specified requirements cannot be applied to the proposed component, or its application is uncertain.

Modification History:

2004-08-12

Updated effective date to reflect the date the PD was issued. (August 2004 NIB 6.c.xiv)

References:

• CC v2.1 Part 2

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0207