PD-0136: Using CCv2.x PPs with CCv3.1 STs: Handling of FPT_SEP and FPT_RVM

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

When evaluating a Common Criteria v3.1 Security Target, how does one handle a claim of profile compliance to a CC v2.x profile? In particular, the question is what is to be done with the FPT_SEP and FPT_RVM components when an ST under CC v3.1 claims compliance with a CC v2.x PP containing SEP and RVM.

Resolution

The ADV_ARC family is the CC v3.1 equivalent of FPT_SEP and FPT_RVM. The CC v3.1 ST should include ADV_ARC.1 (or a higher level, if warranted by the EAL), and this should be documented as demonstrably corresponding to FPT_SEP and FPT_RVM by using the correspondence from the rationale.

Support

The creation of the ADV_ARC family from what had been FPT_SEP and FPT_RVM is perhaps the most drastic difference between versions 2 and 3 of the CC. The ARC family levies requirements on the TOE itself, not on the description/evidence of the TOE. This notion was not in v2, which meant that a TOE could presumably be constructed so that its security could be bypassed or corrupted. This is also why this notion, in v3, is no longer captured in functional requirements.

In version 2, the security architecture requirements were functional, so there were no requirements for (or guidance on) its description. As a Part 3 requirement (v3.1), there must be a description provided, and there is opportunity to explain how the description should be made.

The "D" elements, developer action elements, such as ADV_ARC.1.1D, are worded as requirements on the developer, and address how the developer must design the TSF and provide evidence of that design. Consequently, there is no direct mapping to them from CC v2. The remaining "C" elements, content and presentation elements, address the characteristics of the TSF, and how the design evidence demonstrates those characteristics are present. The CC V2 Functional elements have the following mappings to the ADV_ARC "C" elements:

FPT_RVM.1.1 -> ADV_ARC.1.5C

From CC v2.3:

FPT_RVM.1.1 The TSF shall ensure that TSP enforcement functions are invoked and succeed before each function within the TSC is allowed to proceed.

From CC v3.1:

ADV_ARC.1.5C - The security architecture description shall demonstrate that the TSF prevents bypass of the SFR-enforcing functionality.

FPT_SEP.1.1 -> ADV_ARC.1.3C and ADV_ARC.1.4C

From CC v2.3:

FPT_SEP.1.1 The TSF shall maintain a security domain for its own execution that protects it from interference and tampering by untrusted subjects.

From CC v3.1:

ADV_ARC.1.3C - The security architecture description shall describe how the TSF initialisation process is secure.

ADV_ARC.1.4C - The security architecture description shall demonstrate that the TSF protects itself from tampering.

Together, 1.3C and 1.4C prevent tampering from all potential sources, whether from elsewhere in the TSF, from outside the TSF, or from the initialization code (which might be considered inside or outside the TSF).

FPT_SEP.1.2 -> ADV_ARC.1.2C

From CC v2.3:

FPT_SEP.1.2 The TSF shall enforce separation between the security domains of subjects in the TSC.

From CC v3.1:

ADV_ARC.1.2C The security architecture description shall describe the security domains maintained by the TSF consistently with the SFRs.

Until the CC v2.1 PPs are recast into v3, it is appropriate to use ADV_ARC in the ST, and include an argument of correspondence.

Modification History:

2007-05-31

PD created. [ODRB May 2007 Agenda Item 3.a.ii]

References:

• None

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0262