I-0378: Meaning Of Compliance Claims

TYPE:                 Request for Interpretation
NUMBER:               I-0378
STATUS:               In CCIMB RI Queue

TITLE:                Meaning Of Compliance Claims

EFFECTIVE:            2000-03-27

SOURCE REFERENCE:     CC v2.1 Part 1 Subclause 4.2.1
                      CC v2.1 Part 1 Subclause 4.3
                      CC v2.1 Part 1 Subclause C.2.8
                      CC v2.1 Part 3 Subclause 5.5 ASE_PPC
RELATED TO:           <None>
CCIMB ENTRY:          CCIMB-INTERP-0112

ISSUE:

• Must all PP assumptions be ST assumptions?

• Must all PP threats be ST threats?

• Must all PP organizational security policies be ST organizational security policies?

• Must all PP objectives be ST objectives, and must they have the same allocation (environment vs. TOE)?

It is clear that all requirements in the PP, modulo permitted operations, must be included in the ST. It is also clear that all requirements allocated to the TSF in the PP must be allocated to the TSF in the ST (although requirements allocated to the IT environment may be reallocated to the TSF). The relationship of the other front matter for compliance, however, is not clear from the CC, and there is not a strong technical argument for or against it.

PROPOSED RESOLUTION

SPECIFIC RESOLUTION

None as yet determined. I-0378 is a request for interpretation addressed to the CCIMB.

SUPPORT:

The CC makes it clear in Section 4.2.1 that the TOE is developed based on the security requirements in the TOE, but that these requirements must be effective in contributing to the security objectives of consumers (Part 1, Section 4.2.1, second paragraph, as well as Figure 4.3 and Figure 4.4.). In Section 4.3.3 of Part 1 the CC makes it clear that the IT security requirements are the refinement of the security objectives. This has the implication that, if the objectives change, the requirements should change.

Part 1, Section 4.3.2 makes it clear that the security objectives are a result of the analysis of the security environment; that is, the security objectives "counter the identified threats and address identified organisational security policies and assumptions" (Part 1, Section 4.3.2, first paragraph). Further, this part of the CC make it clear that the objectives must be consistent with the stated operational aim or product purpose of the TOE, and any knowledge about the physical environment.

The focus of the protection profile in the CC is the requirements contained therein. This is made clear in Part 1, Section 4.4.2.2, which says "The PP contains a set of security requirements" and "A PP is intended to be reusable and to define TOE requirements that are known to be useful and effective in meeting the identified objectives, both for functions and assurance".

In Part 1, Section C.2.8, when talking about PP claims in a Security Target, the CC says "...make a claim that the TOE conforms with the requirements of one (or possibly more than one) PP." The focus, for the most part, in this section, is on the security requirements of the PP, and the fact that they must be consistent (modulo operations) with the requirements in the ST.

The section clearly notes that the ST may have additional objectives than the PP; these additional objectives may translate to additional requirements. The CC is also clear that the ST may restate the objectives of the PP ("The CC is not prescriptive with respect to the choice of restating or referencing PP objectives"). The CC does require that the traceability to any claimed PP be clear.

What does this traceability mean? The CC seems to presume that if the objectives are changed in some significant manner, then the resulting IT requirements will be different. An analysis has not been performed to verify that this is always the case, but it seems reasonable (especially when dealing with reallocation of requirements from the IT product to the IT environment). It is also reasonable to believe that two profiles developed for different sponsors might end up having the same requirements, as the protection objectives (without the PP authors realising it) are likely to be similar.

If the PP registry contains such profiles (i.e., different sponsors and target audiences, but compatible requirements and objectives), then an ST might claim compliance with multiple profiles. Some of these may be for distinctly different target customers than might be accounted for in the introduction of the ST (for example, an ST for general-purpose use claiming compliance with a banking industry PP, as well as a general purpose PP). Would the traceability in such a case be clear?

Consider the following: Could two PPs with distinctly different threats, assumptions, and objectives could result in an ST with the same requirements? If such a result was possible, would it be wrong for that ST to claim compliance with both PPs? Is the traceability clear?

If the focus of traceability is on requirements, the answer is yes. If the focus is on the bigger picture, the answer is maybe. The issue is one of intent: what was the intent of the CC authors? This just isn't clear from the CC.