[Public Interpretations Database]

I-0362: Scope Of Permitted Refinements


TYPE:                 NIAP Interpretation
NUMBER:               I-0362
STATUS:               Formally Superseded

TITLE:                Scope Of Permitted Refinements
SUPERSEDED BY:        
     CCIMB-INTERP-0019
     CCIMB-INTERP-0098

EFFECTIVE:            2000-03-27
SUPERSEDED:           2002-03-12

SOURCE REFERENCE:     CC v2.1 Part 1 Subclause 4.4.1.3
                      CC v2.1 Part 2 Subclause 2.1.4.4
                      CEM v1.0 Part 2 Subclause 4.4.6 ASE_REQ
RELATED TO:
     I-0394           Iteration Must Cover All Scopes
CCIMB ENTRY:          CCIMB-INTERP-0106

STATEMENT

The following provides clarification for Part 1, Section 4.4.1.3, with respect to Permitted Operations on Components:

Refinements always have the characteristic that a TOE meeting the refined requirement would also meet the unrefined requirement.

RECOMMENDED CRITERIA CHANGES

In order to address this interpretation, the following changes should be made to CC V2.1: (Additions marked thusly; deletions marked thusly)

  • In Part 1, Section 4.4.1.3, under "Permitted operations on components", reword item "d)" as follows:

    d) refinement, which permits the addition of extra detail when the component is used. Refinements always have the characteristic that a TOE meeting the refined requirement would also meet the unrefined requirement.

  • In Part 2, Section 2.1.4.4, "Refinement", add to the end of the first paragraph:

    Refinement always has the characteristic that a TOE meeting the refined requirement would also meet the unrefined requirement.

The CEM v1.0 already incorporates this definition of refinement in ASE_REQ.1-12; however, it should be reviewed to ensure that additional changes are not required.

SUPPORT:

This interpretation provides the specific criteria changes to capture the definition of refinement used in CCIMB-INTERP-0015b and in the CEM. As such, it brings the CC into agreement with the CEM.

The underlying notion of refinement is that of narrowing. There are two types of narrowing possible:

  • Narrowing of Implementation. In this form of narrowing, the PP/ST author would restrict the set of acceptable implementations in some way. Such a narrowing would always meet the unrefined requirement, and would never create additional dependencies.

  • Narrowing of Scope. In this form of narrowing, the PP/ST author limits the application of the requirement to some subset of what is called out or implied by the unrefined requirement. For example, the scope might be narrowed from the entire TOE to a specific SFP or type of system entry. Narrowing of scope results in a TOE where the unrefined requirement is not met in all cases.

This interpretation limits refinement to narrowing of implementation. If narrowing of scope is required, an explicitly stated IT security requirement must be used. Thus, the use of refinement in crafting requirements is extremely limited.

Note that refinment may be used to clarify meaning or grammar, as long as the change still meets the definition of a proper refinement.

Refinement is acceptable both for functional and assurance requirements. Refinement in the case of assurance might be a narrowing of procedure or paradigm; that is, restricting developers or testers to the use of a specific development or testing paradigm of the many potential paradigms acceptable under the requirements.