[Public Interpretations Database]

I-0397: Iteration On Assurance Components/Elements

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

TITLE:                Iteration On Assurance Components/Elements
SUPERSEDED BY:        
     CCIMB-INTERP-0019

EFFECTIVE:            2001-03-15
SUPERSEDED:           2002-03-12

SOURCE REFERENCE:     CC v2.1 Part 1 Subclause 4.4.1
                      CC v2.1 Part 3 Subclause 2.1.3.5
                      CC v2.1 Part 3 Subclause 2.1.4
RELATED TO:           <None>
CCIMB ENTRY:          CCIMB-INTERP-0152

ISSUE:

The CC, in Part 1, appears to permit iteration at the level of assurance components. However, Part 3 only discusses refinement at the element level; no mention is made of iteration.

STATEMENT

Iteration is permitted on sets of assurance elements (as defined in Part 3, Section 2.1.3.5) and on assurance elements.

RECOMMENDED CRITERIA CHANGES

To address this interpretation, the following changes are made to CC v2.1, Part 3: (additions marked thusly; deletions marked thusly)

  • In Section 2.1.3.5, after paragraph 53, add the following paragraph:

    Iteration is permitted at the level of developer action elements, content and presentation of evidence elements, and explicit evaluator action elements.

  • In Section 2.1.4, replace paragraph 56 with the following:

    In contrast to CC Part 2, neither assignment nor selection operations are relevant for elements in CC Part 3; however, refinements and iterations may be made to Part 3 elements as required.

FURTHER CONSIDERATIONS:

The criteria changes may be subject to further changes depending on the resolution of I-0379 (Documentation Sections) [an RFI sent to the CCIMB]; in particular, assigment may move from the not-relevant category to being relevent when explicitly specified.

Additionally, the above paragraph may be subject to futher changes depending on the resolution of I-0394 (Iteration Must Cover All Scopes); in particular, there may be additional words noting that if iteration is used to apply a requirement to a subpart of the TOE, there must be sufficient iterations that the entire TOE is covered.

Lastly, corresponding methodology changes may be needed to address the effects of these changes.

SUPPORT:

This interpretation corrects the identified discrepancy.

There are three potential levels of iteration for assurance components:

  1. At the level of the entire component.

  2. At the level of a set of assurance elements (C/D/E).

  3. At the element level.

It is difficult to come up with an example of iteration of an entire assurance component that does not result in unnecessary redundancy. It is more appropriate to iterate assurance at either the level of the D/C/E groupings, or at the level of individual elements. For example:

  1. Iteration at the level of D/C/E might be useful for independent testing, if the ST author wanted to have multiple groups performing independent testing. In such a case, the "E" components might be iterated to explicitly specify the groups performing testing.

  2. Iteration at the element level might be useful for indicating that some elements of a design description might have an additional formal specification in addition to the level called out by the EAL.